1. More frequent releases
Branching a new release from the main branch every six weeks
Since Scala 3.0.0, we wanted to follow a 6-week release train. However, we treated it more as a guideline than a rule. Releases were often delayed for various reasons, from wanting to include more fixes to problems with integration with the tooling. With each release, the delays accumulated, and each one, in effect, became bigger and more prone to further delays. As a result, a typical release took from 9 to 16 weeks.
Starting from Scala 3.4.0, we will closely follow a six-week release cycle for Scala Next. Every six weeks, a new release branch will be split from the main branch and released as a release candidate (RC) as soon as possible. Simultaneously, with an RC for a new version, we will release a stable build of the previous one.
Some delays may still occur, as we guarantee that tools will work with a new version from the day of the release. However, with the new model in place, the delays won’t be accumulating. This will result in fixes and improvements being available for the users at a faster and more predictable pace.
3.5 before June, 3.6 by the end of the year
In Scala, the are two kinds of releases. The first and most common ones are patch releases. They are backward and forward-compatible but can bring only bug fixes and small usability improvements, such as new linting options.
For any new definitions added to the standard library (for example, new methods in Quotes API) or for changes to the language itself (like a new, backward-compatible desugaring of for-comprehensions), we need a minor release.
This year, we are planning two minor releases. The first one, 3.5, will be out before June, 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, especially the LTS line.
At least one LTS patch for every two Next patch releases
We will continue to support Scala LTS. Throughout this year, the 3.3.x line will receive patches with fixes and user experience improvements backported from Scala Next.
We have much stronger guarantees about compatibility in the LTS line. We are checking over a thousand projects for any possible regression, and we are working to keep all that were working correctly on 3.3.1 and continue to do so on all future releases. This is why there need to be delays between implementing fixes in Scala LTS and Scala Next.
Nevertheless, we will continue the work and are committed to releasing at least one LTS patch every two Scala Next releases.
2. Better build times
Pipelined compilation
We recently made significant progress in introducing pipelined compilation in Scala 3. All potentially non-forward-compatible changes have been merged and released.
In 2024, we will make sure that all the tools are ready and make a few last changes in the compiler. This should result in a speeding up of build times.
You can learn more about pipelined compilation and other planned build-time speedups in 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.
We will also analyze their impact on memory footprint. Depending on the results, we will introduce some of them to the main line of the compiler either as a configurable option or the default behavior.
3. Tighter integration with tooling
Presentation Compiler
To provide the best possible support for the language Scala tools, such as Metals, often need to reimplement crucial parts of the compiler. Thanks to the enormous effort 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 no longer need to have 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 SIP-46. Scala CLI will replace the old scala and scalac commands. It will be distributed together with the compiler as lightweight native runners for multiple platforms.
Best-effort compilation
When using Metals, you can observe curious behavior. The IDE functions work great when the code is passing the compilation, but once the user starts changing the code, the support drops in quality. This gets even worse with a larger number of compilation errors and subsequent modifications. The best-effort compilation is our solution to that problem.
It’s a new mode in which the compiler tries to work despite the errors and provide as good an approximation of code information as possible. This allows for accurate code completions and type information, even for a code that is not compiling.
4. UX improvements
Better REPL
Scala REPL is a convenient tool for prototyping and testing. However, it lacks some of the features that users would have found helpful. This is why alternative REPLs, such as Ammonit, came about.
This year, we want to investigate the features of those alternative REPLs and add utilities to perform tasks, such as adding new dependencies in an already running REPL session. As a stretch goal, we want to expose API for the third-party integrations so alternative REPLs can become even more powerful it won’t have to rely on fragile hacks that can break with any release of the compiler.
Better Command Line Interface
Our goal is to make the compiler command line interface more consistent and user-friendly. This would be useful for both people passing the compilation flags directly and build tools.
This year, we will go through all of the compiler flags and improve the help messages for them. Also, we will try to lower the bar for more complex ones and clarify which ones can be treated as stable, which ones are considered experimental, and which ones are intended only for usage by tooling.
5. Better reporting
More linting in the compiler
Since Scala 3.3.0, lints have been successively added to the compiler. Our work on them will continue this year. Our next steps will be adding dead code detection and emitting warnings on common performance pitfalls.
Continuous effort to improve error messages
One of the side effects of Scala’s powerful type system is the perceived complexity of error messages. We are constantly working on making them more informative and actionable for users. We guarantee further improvements in the coming versions.
6. Evaluation of Experiments
Capture-checked Standard Library
Capture checking is an ongoing research project. It will be an opt-in system that would enrich the Scala-type system in a backward-compatible way, allowing for tracking capabilities referenced by values. It 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.
While the system has been available for testing and experimenting for a while now, nothing really productive can be done with it as the standard library still lacks capture checking. Soon, we will publish an experimental artifact with a capture-checked standard library that will be useful for proofs of concept and experiments for users.
Evaluation of Scala Improvement Proposals
We are currently debating multiple, frequently requested, Scala Improvement Proposals (SIPs). The compiler’s team does not have the authority to decide whether to include them in the language. However, once they are approved by the SIP Committee as experimental features, we will implement them so they can be evaluated. This year, we plan to assess at least those proposals:
All three of them already have a proof of concept implementation.
7. Improving the compiler’s stability and correctness
Bugfixing with a strong focus on regressions
In 2024 we will continue our work on 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
There are still some rare cases in which the compiler crashes after encountering incorrect code. Fixing those cases will become our priority, together with providing users with useful error messages instead of crashes – especially for bugs present in the LTS line.
Public page for checking the status of Open Community Build
Open Community Build is an invaluable tool that helped us immensely to improve the stability of the compiler. Despite being a publicly available data, it lacks in terms of user-friendly presentation. This makes it harder to compare the results of different builds and filter out true regressions from other usually inconsequential problems.
This year, we will build and publish a public page that allows anyone to quickly gather and compare data from different runs of the Open Community Build.
Curated by
Krzysztof Radzik
