The first point on Scala 3 roadmap is about committing to frequent, predictable releases. Below we have specified our plans on how to achieve that. Here’s what you can expect in Scala’s future:
Every six weeks, a release is branched off from the main branch
When Scala 3.0.0 was released, we had an ambitious plan to publish a new update every 6 weeks. However, we treated it more as a guideline than a rule. With each release, we wanted to add as many improvements as possible, such as integrating additional fixes to enhance tooling compatibility. This created a snowball effect that affected the next release and the ones after it, pushing new releases into a 9 to 16-week circle.
Starting from Scala 3.4.0, we are going to follow a strict release cycle for Scala Next. Every six weeks, our Scala development team will split a new release branch from the main branch and introduce it as a release candidate (RC). Simultaneously, with an RC for a new version, we will release a stable build of the previous one.
Just like in previous years, we are committed to making every new version work with your tools immediately. Some delays might occur, however, we have a new model in place to keep delays to a minimum.
In our new model, the branching point is fixed in time and independent of the release. So, delaying the previous release will not add work to the next one. This will result in fixes and improvements being available for the users at a much faster and much more predictable pace.
We’ll release versions 3.5 by June, and 3.6 by the end of the year
Scala has two kinds of releases: patch releases and minor releases.
Patch releases are backward and forward-compatible but can bring only bug fixes and small usability improvements, such as new linting options. They are also the most common type of release.
Minor release is used for any new definitions added to the standard library, for example, new methods in Quotes API. They can also be used for changes to the language itself, like a new, backward-compatible desugaring of for-comprehensions.
This year, we are planning on two minor releases. The first one, 3.5, will be out before the summer holidays, and the second, 3.6, should come out before the end of the year. They will keep all our compatibility guarantees and will be able to use dependencies compiled with all previous releases of Scala, most importantly the LTS line.
At least one LTS patch for every two Next patch releases
In 2024 we will continue to support Scala LTS. Throughout the year, the 3.3.x line will receive patches with fixes and user experience improvements backported from Scala Next.
We are putting a strong emphasis on maintaining compatibility guarantees in the LTS line. Our Scala developers are checking over a thousand projects for possible regressions. Also, we will ensure that everything working correctly on 3.3.1 and will continue to do so on all future releases.
Because of our commitment to high compatibility and extensive testing, it takes some time to apply fixes from the latest Scala versions back to the LTS version. Nevertheless, we will continue the work and are committed to releasing at least one LTS patch for every two Scala Next releases.
In the near future, Scala 3 will have improved build times. This will be achieved in 2 ways: by completing the introduction of pipelined compilation and evaluating the benefits of parallelizing side tasks. Here’s how it fits into the roadmap exactly.
Pipelined compilation
Last year, we made significant progress in introducing pipelined compilation in Scala 3. Every potentially non-forward-compatible change has been merged and released. This year, we will make sure that all the tooling is ready and then make a few last changes in the compiler. This will speed up build times.
If you want to learn more about pipelined compilation and other planned build-time speedups we recommend the talk by Jamie Thompson.
Evaluating benefits of parallelizing side tasks
The compiler is still performing multiple side tasks on the main thread. In theory, some of them can be moved to other threads and parallelized. This year, we plan to check and benchmark the parallelization of bytecode and semanticDB generation, TASTy files reading, and many others. Our Scala engineers will also analyze their impact on memory footprint and, depending on the results, introduce some of them to the main line of the compiler either as a configurable option or the default behavior.
As Scala maintainers, we have always been putting a strong focus on tooling, since multiple user surveys showed that this is a main concern for most developers. The roadmap starts with improvements to the Presentation Compiler, followed by the introduction of Scala CLI as a default language runner and the introduction of a 'best-effort compilation' mode. Below, we have explained how these changes will affect the integration with tooling.
Further improvements to the Presentation Compiler
Scala tools, such as Metals, often need to reimplement crucial parts of the compiler. It allows them to provide the best possible support for the language. Last year, most of such code was removed from Metals and moved to the new module in the compiler codebase — the Presentation Compiler.
Starting from compiler version 3.4.0, Metals will no longer require compiler version-specific code. Our goal for this year is to achieve the same effect with Scala LTS and to continuously improve the Presentation Compiler.
Scala CLI integrated with the compiler
This year, we will implement Scala Improvement Proposal 46 (SIP-46). Scala CLI will replace the old scala and scalac commands and it will be distributed together with the compiler as lightweight native runners for multiple platforms.
Adding a best-effort compilation mode
When using Metals, the IDE functions work great as long as the code is passing the compilation. However, once the user starts changing the code, the support drops in quality. This gets worse with a larger number of compilation errors and subsequent modifications. The best-effort compilation is our solution to that problem.
In this new mode, the compiler will try to work despite the errors and provide as good an approximation of code information as possible. This will allow for accurate code completions and type information, even for a code that was not compiling.
The improvement in the user experience of future Scala 3 iterations will come from two changes: adding new features to default REPLs and improving the common line interface through compiler flags. Here’s how we plan to achieve these milestones on the Scala 3 roadmap.
Better REPL
Scala REPL is a convenient tool for prototyping and testing. However, it’s missing some of the features that users would have found helpful. This is why the alternatives to REPLs, such as Ammonite, are currently more popular.
As a part of the Scala 3 roadmap, we plan on including new features to default REPLs. For example, we want users to be able to add new dependencies in an already running session. As a stretch goal, we want to expose API for the third-party integrations, so alternative REPLs, such as Ammonite, can be even more powerful and don’t need to rely on fragile hacks that can break with any release of the compiler.
Better Command Line Interface
As Scala maintainers, we want the compiler command line interface to be more consistent and user-friendly. This is useful for both build tools and users passing the compilation flags directly.
In 2024 we will go through all of the compiler flags, improve the help messages for them, and try to lower the bar for more complex ones. We will also clarify which ones can be treated as stable, which as experimental, and which ones are intended only for usage by tooling.
We will achieve better reporting in future Scala 3 iterations by expanding static analysis during the compilation. It will help users identify potential bugs, inefficiencies, and style issues. On top of that, we will continue our work to improve error report messages.
More linting in the compiler
The lints have been successfully added to the compiler in Scala 3.3.0. In 2024, we will add dead code detection and emit warnings about common performance pitfalls.
Continuous effort to improve error messages
One of Scala’s powerful type system’s side effects is the perceived complexity of error messages. We are constantly working on making error messages more informative and actionable for users. We guarantee further improvements in that regard in the coming versions.
The roadmap includes experiments with proposals and projects that we believe to be beneficial to Scala’s 3 future. These experiments will focus on Capture Checking, as well as 3 Scala improvement proposals: SIP-58, SIP-62, and SIP-63. Here’s why they are important.
Inclusion of Capture-checked standard library
Our Scala developers are currently working on the Capture Checking project. It will be an opt-in system that would enrich the Scala-type system in a backward-compatible way.
Once completed, it will allow tracking capabilities referenced by values and will allow users to eliminate a large class of tricky bugs. It will also facilitate the creation of user-friendly libraries for challenging tasks, such as handling resources in asynchronous computations.
The new opt-in system has been available for testing and experimenting for a while now. Unfortunately, the lack of capture checking in the standard library limits what users can currently do with it.
This will change once we publish an experimental artifact with a capture-checked standard library that users could use for proofs of concept and experiments.
Evaluation of Scala Improvement Proposals
As part of Scala 3 roadmap, there are three Scala Improvement Proposals (SIP), that we plan to implement as experimental features and evaluate this year, namely:
Each proposal has already been approved for proof-of-concept implementation. The next step in our evaluation process is gathering feedback from early adopters. This feedback will help the SIP Committee to make well-informed decisions about final approval, making the way for the inclusion of these three SIPs as stable features.
As in previous years, Scala 3 roadmap will continue to emphasize improvements in the overall stability of Scala, striving to make it as free of bugs as possible. Beyond routine bug-fixing efforts, we will concentrate on resolving issues related to the Long Term Support (LTS) release and enhancing the presentation of data from the Open Community Build.
Bugfixing with a strong focus on regressions
Just like in previous years, our Scala developers are committed to improving the compiler's stability and correctness. All the bugfixes that maintain both backward and forward, source and output compatibility will eventually be backported to the 3.3 LTS line.
Eliminating all crashes from the LTS, keeping source compatibility
We decided to include source compatibility in Scala 3 roadmap as this topic keeps returning. Our users reported that there are still some rare cases of the compiler crashing after encountering incorrect code. These cases will be our priority in our bug-fixing efforts in 2024.
We intend to provide users with useful error messages instead of crashes, especially if the bug is present on the LTS line.
Public page for checking the status of Open Community Build
Open Community Build is an invaluable tool that helped us improve the stability of the compiler.
The data, despite being public, lacks in terms of presentation. The users find it difficult to compare the results of different builds or filter out true regressions from other, usually inconsequential, problems.
This year, we will build and publish a public page that will allow anyone to quickly gather and compare data from different runs of the Open Community Build.
Curated by Krzysztof Radzik
