Scala 3 introduces a new macro system that replaces the experimental Scala 2 system with one that should avoid unsoundness, be simpler to use, and simpler for the compiler team to evolve and maintain.
Perhaps the most significant feature missing from Scala 3 today is the lack of support
Jan Nasiadka from scalac contacted me to get some feedback about our usage of ZIO. My answers below, since they can benefit the community more broadly.
Context: we use ZIO in the context of https://rudder.io, a scala application that is 11 years old - far from a greenfield application with ZIO as base architectural choice. We used ZIO as a better framework to cleanly manage errors, porting piece of existing code to it. We are part of ZIO community since 2018 (since ZIO inception, when it was not yet ZIO but a part of scalaz, and when there was only a bifunctor, no context in it). Given our usage, we use ZIO in a specific way: we have tons of entry points and evaluation of ZIO effects, not one main entry point in the "main" method of the app. For correctness, that forced us to call a lot of blocking effects (you never know what a java lib is doing), and so we stressed the thread pool ergonomics, and helped make that part better (and some part
I think opaque type aliases is one of Scala 3's most interesting features. Many use cases for it has already been discussed. One oppertunity that I think would be quite useful, while at the same time being a very good fit with the rest of the language, is the ability to expose members of the underlying type as members on the opaque type.
For example: The current imlementation of IArray uses extension methods to export methods from Array:
| // | |
| // EXERCISE 4 | |
| // | |
| // Create a type class to describe `printLine` and `readLine`. | |
| // | |
| trait Console[F[_]] { | |
| def printLine(line: String): F[Unit] | |
| def readLine: F[String] | |
| } |
