Scala Space in 2025
Co-authored by Piotr Chabelski, Tomasz Godzik and Łukasz Biały and Adam Warski
Time flies fast! 2024 will end sooner than you'd expect ;). But we're already looking forward to 2025. What's coming up, Scala-wise?
Just as we've been committed to evolving the Scala ecosystem in the past years, we have ambitious plans for 2025 regarding our open-source projects. The motto of Scala Space, which is the combined Scala efforts by members of the VirtusLab Group (VirtusLab and SoftwareMill), is "Where Scala meets the industry"—and that's indeed where our focus lies.
When looking at VirtusLab and SoftwareMill's open-source projects, you get the complete package: a build system, developer tooling, infrastructure-as-code, concurrency, and HTTP libraries.
In other words, we aim to provide what's needed for "industrial" Scala usage, complementing the best JVM language out there with a sane set of tools that address the most common pain points and tasks.
Let's take a tour of specific 2025 plans for our projects.
scala-cli
After Scala CLI has become the official Scala runner, we plan to focus on making it the most stable tool you can have in your developer's toolbox. This might also include some UX improvements and ensuring your friendly neighborhood build server Bloop runs smoothly.
As for the new features, we aim to help get source generation across the finish line since that is one of the most anticipated features that users requested. Scalafix integration is also right behind the corner, with its initial implementation likely to enter its experimental phase in version 1.6.0. Further down the line, we plan to stabilize some of our other experimental features (like benchmarking with JMH and cross-compilation) and improve existing integrations with external tools.
Ox
Ox started as a research project in 2023 and has seen considerable interest in 2024. That's why we'd like to stabilize the core APIs and release a 1.0 version, hopefully close to the beginning of the year.
After several different designs, we tried a year ago, the structured concurrency APIs (supervised scopes) have been stable for quite some time, and we don't expect many changes. Also the high-level concurrency operators (such as race or par) seem to meet the expectations.
The first area that needs completing is the streaming API. We first introduced Channels, followed by a higher-level, "functional", Flow API a few weeks ago. When it comes to the streaming operators, most of the functionality is there, but a couple are missing: we definitely need to fill that gap before releasing a 1.0 version. We might also consider working on additional integrations (in addition to the Kafka one that is already there), to validate that the approach we've taken is flexible and versatile enough.
The second area where we want to put some work is the resiliency components of Ox. We already have solid repeat and retry implementations. We're also developing rate limiters as we speak (write?). What's left is circuit breakers, bulkhead, and maybe some cache integrations—this is still something to plan out precisely.
Ox 1.0 will target JVM 21; it won't work with newer ones, as Ox uses Java's preview structured concurrency APIs, which have changed in more recent versions. Once Java 25 (the next LTS) is out, hopefully with stable structured concurrency and scoped values features, we'll release a new major Ox version.
Metals
One of the issues most raised about Metals is the overall stability of the solution. We plan to spend next year focusing on making it as reliable as possible by looking into reports sent to us by the users. Don't hesitate to report any possible issues, as it's vital that we get as many reports as possible to pinpoint the weakest parts of the server and fix them.
We will also make it easier for us to support multiple editors, including any new ones that people might want to use. To that end, we will remove most of our custom protocol extensions and reuse the existing protocol methods. This will also allow us to reduce the tech debt related to them.
Regarding language features, we mainly plan to improve the support for Scala 3 to ensure any new language features are properly supported. We will also be improving code actions to make sure that refactorings are always correct and maybe add a few new ones. If you have any ideas for potential refactoring options that you would like to have included do let us know! Or, if you would like to help implement them, we can guide you on how to do it properly.
One last improvement we would like to work on is making the support for multiplatform and multiversion projects a much smoother experience. To that end, we will be adding solutions to allow users to pick which parts of the codebase they want to work on and make sure the defaults work better for a large number of users.
sttp client & Tapir
When it comes to sttp client, we've got the 4.0 release that is long overdue. Resource constraints have delayed the final push needed to finalize the design, but this only means we should double our efforts to make the release happen. There are two more important changes that we'd like to introduce before the release. First, the implicit BodySerializers should be removed in favor of an explicit design. That is, to specify how a body should be serialized, you'll have to write something like .body(asJson(myInstance)) or .body(asXml(myDocument)).
Secondly, we'd like to make the APIs for specifying response types more discoverable and developer-friendly, especially regarding the various error-handling variants. Some use cases are better served with returning an Either[String, T], while others avoid the "either" layer by just returning a T or throwing an exception. Both are currently supported in sttp-client, but the API for specifying which should be used can certainly be better.
On the server side, we've got Tapir. We aren't planning big releases but rather polishing what's already there. This is especially true for the Netty backend, which is quite versatile (supporting cats-effect, ZIO, Future, and direct-style) but still lacking in some areas (e.g., multipart support, compression). We'd also like to revive the Tapir-pickler feature, which promised joint JSON+Schema derivation, delivering better compile performance and central configuration. The current prototype works, but we're considering switching to Jsoniter as the base implementation.
We've also started reworking Tapir's documentation, separating tutorials, how-tos (examples), and reference documentation. That's an ongoing process, which we hope to accelerate as the year progresses.
Besom
Infrastructure-as-code tool Besom is now very close to being feature-complete with the upcoming 0.4 version coming in December 2024. The subsequent version, 0.5, will be the last beta version before the 1.0 series is released in 2025. The team is focusing on building component libraries enabling Scala developers to bootstrap new projects quickly. The first template will bring a turnkey solution to instantly deploy a Bootzooka based project onto the cloud of your choice. We are also working on a project codenamed Yaga, which brings a new approach to the development of complete systems—TypeOps. Yaga's core functionality allows for type checking of application/infrastructure boundaries, and by doing that, it prevents whole classes of deployment and runtime issues. The first release of Yaga will focus on typed serverless applications on AWS Lambda and allow users to have a guarantee that their lambdas are as type-safe as Scala functions.
Summing up
Of course, these are all just plans, so take these with a grain of salt. You never know what's ahead, and we'll try to respond to any new trends or niches of Scala as 2025 unfolds.
Ultimately, it's up to you—users of our open-source projects—to let us know which areas we should focus on. But we're only as smart as the data that we have. So, if you have a favorite feature or bug that you'd like to see implemented/fixed, create an issue on GitHub, or if it exists, leave a :+1:! We can't promise to fix every issue voted on, but it's certainly a great indicator.