Problem Statement
This is a follow-up to the discussion around whether Future and Twitter Future should be removed from kyo-compat, referenced in https://discord.com/channels/1087005439859904574/1087005440623259681/1506781659456999525.
My proposal is to keep kyo-compat useful as a library-compatibility layer for the broader Scala ecosystem, not just for Kyo-specific code.
Motivation
kyo-compat is valuable because it lets library authors support multiple ecosystems from one codebase. In that context, I strongly think Scala Std Lib support should remain part of the story.
In particular:
- keep support for Scala Std Lib
Future.
- consider adding support for Scala Std Lib
Try.
- keep standard-library interoperability as a first-class use case alongside effect-system integrations.
The reason is that library authors often need to serve a broad audience. Some consumers will use effect systems like Kyo, ZIO or Cats Effect, but others will want plain Scala APIs. A compatibility layer that supports standard-library abstractions helps bridge that gap.
Why Try matters
I’m not assuming the exact API shape for Try support, but I do think it should be considered as a legitimate compatibility target.
In practice, Try is a simple and widely understood abstraction, and it can be a very natural fit for synchronous or blocking code paths where a full effect system is unnecessary. For example, implementing a simple AWS Lambda function with plain Scala code and Try may be enough.
Architecture discussion
The discussion in the thread also suggested that requiring Java 21+ and virtual threads could be a reasonable architectural baseline, similar to what Ox does.
That seems like a sensible direction for this kind of compatibility layer: if the goal is to support straightforward synchronous code cleanly, then targeting a modern JDK baseline is acceptable, and virtual threads are not necessarily required when there is no concurrency problem to solve.
Proposed Solution
Request
Please consider keeping Future support in kyo-compat and adding Try as a supported Scala Std Lib integration, so kyo-compat remains useful for library authors targeting the wider Scala ecosystem.
Alternative Solutions
No response
Current Workaround
No response
Additional Context
No response
Problem Statement
This is a follow-up to the discussion around whether
FutureandTwitter Futureshould be removed fromkyo-compat, referenced in https://discord.com/channels/1087005439859904574/1087005440623259681/1506781659456999525.My proposal is to keep
kyo-compatuseful as a library-compatibility layer for the broader Scala ecosystem, not just for Kyo-specific code.Motivation
kyo-compatis valuable because it lets library authors support multiple ecosystems from one codebase. In that context, I strongly think Scala Std Lib support should remain part of the story.In particular:
Future.Try.The reason is that library authors often need to serve a broad audience. Some consumers will use effect systems like Kyo, ZIO or Cats Effect, but others will want plain Scala APIs. A compatibility layer that supports standard-library abstractions helps bridge that gap.
Why
TrymattersI’m not assuming the exact API shape for
Trysupport, but I do think it should be considered as a legitimate compatibility target.In practice,
Tryis a simple and widely understood abstraction, and it can be a very natural fit for synchronous or blocking code paths where a full effect system is unnecessary. For example, implementing a simple AWS Lambda function with plain Scala code andTrymay be enough.Architecture discussion
The discussion in the thread also suggested that requiring Java 21+ and virtual threads could be a reasonable architectural baseline, similar to what Ox does.
That seems like a sensible direction for this kind of compatibility layer: if the goal is to support straightforward synchronous code cleanly, then targeting a modern JDK baseline is acceptable, and virtual threads are not necessarily required when there is no concurrency problem to solve.
Proposed Solution
Request
Please consider keeping
Futuresupport inkyo-compatand addingTryas a supported Scala Std Lib integration, sokyo-compatremains useful for library authors targeting the wider Scala ecosystem.Alternative Solutions
No response
Current Workaround
No response
Additional Context
No response