Scala Center team: Darja Jovanovic, 100%; Anatolii Kmetiuk, 100%; Adrien Piquerez, 80%; Jamie Thompson, 100%; Sébastien Doeraene, 80%; Guillaume Martres, 20%; Valérie Meillaud: 30%. VirtusLab team: Jędrzej Rochala, 100%.

At a Glance

Language, Compiler, Standard Library

Maintainance of the Scala 3 Compiler

For Scala 3.

Every month, about 100 new issues are opened on the Scala 3 repository. The project welcomes any help it can get in triaging, bug-fixing, PR reviewing, etc.

Our goal is to solve long-standing issues while keeping up with new ones. We also aim to get more people involved in working on the compiler to ensure the sustainability of the project.

We contributed PRs for bug fixes in various areas, but would like to highlight one.

Our previous work on SIP-56, Specification for Match Types, landed. It will be released as part of Scala 3.4.0, which is currently in the Release Candidate phase. The new specification and implementation provide a strong basis for future stability of the compiler. Feedback from Release Candidates surfaced a few minor issues, which we have addressed. We still intend to improve on this topic, notably in the area of error reporting.

Compile Progress reporting

For Scala 2 and 3.

A key part of the user experience is estimating how long you still have to wait for builds to run. Both Metals and IntelliJ can report this information to the user, through a dedicated interface to the compiler. Until now this was not supported by Scala 3, but added an integration to the compiler in PR lampepfl/dotty#18739.

Metals combined with sbt as a BSP server was not reporting progress from either Scala 2 or 3, so we fixed that in PR scalameta/metals#5788.

Scala.js maintenance

For Scala 2 and 3.

We released Scala.js 1.15.0 during this quarter.

The main highlight of this release is that it makes Scala.js ready for SIP-51, Drop Forwards Binary Compatibility of the Scala 2.13 Standard Library. That will allow us to evolve the Scala 2.13.x standard library.

Improving Performance of the Scala 3 compiler

For Scala 3.

Support for pipelined concurrent compilation

Pipelined concurrent builds are a technique for increasing throughput in the context of multi-module projects. The concept is that dependent modules can begin compilation “as-soon-as” necessary artifacts for separate compilation can be produced. In the Scala compiler, these products can be emitted about 30-40% into the compilation of a single module (even sooner if outline type-checking is used).

Pipelined builds have been implemented in sbt since 1.4, with support in Scala 2.13. We have made critical progress towards supporting them also in Scala 3.

In PRs lampepfl/dotty#19074 and lampepfl/dotty#19259 we stabilised the production of outline signatures in TASTy for Java source programs. That is is necessary for pipeline compilation of mixed Java/Scala projects.

In PR lampepfl/dotty#18880 we are close to finalising support for the semantics expected by Zinc’s model of pipeline compilation, and aim to merge it in Q1 2024.

Support for outline compilation

In PR lampepfl/dotty#19589 we are experimenting with an outline type checking mode, which builds on top of pipelining. It also gives us the chance to test out how compatible the compiler is with rudimentary batch parallel compilation of a single module. So far we can reduce the time to compile Scala 3 itself by a third, compared to no-pipelining. We demonstrated that work at Scala Italy, the London Scala User Group and finally the Paris Scala User Group.

Scala 3 New Features

For Scala 3.

SIP-57 runtimeCheck

We made a proposal SIP-57 to provide a better replacement for the @unchecked annotation, for the purpose of pattern match checking. This proposal will enable making unsafe pattern matches an error by default, by providing a convenient and readable way to tell the compiler to ignore checks for safety.

Dropping withFilter by default in for comprehension in 3.4

In PR lampepfl/dotty#18842 we activated the feature to prevent calls to withFilter being generated by default in for comprehensions.

The improvement for users is more data types can be used in for comprehensions, as long as the pattern in a generator is statically guaranteed to match, or else report an error. Developers can opt out of this check, and generate withFilter instead, by adding case before a pattern.

Scala Improvement Process

For Scala 3.

The Scala Improvement Process coordinates the evolution of the language. It ensures that the decisions are made by taking into account the needs of all the stakeholders of the language.

Four SIP meetings happended since the last report. Of note: the previously mentioned SIP-56, Specification for Match Types, was approved for Implementation and later for Shipping. Several new SIPs are in progress.

Better error messages for Scala 3

For Scala 3.

In Q4 we started a campaign to get users to report problematic error/warning messages in Scala 3. We created a new issue template and promoted it in a blog. At the start we got many issues reported using the new template, and a lot of them were improved by compiler contributors, as we reported on social media.

At the Center itself we worked on improving the reporting of mismatched TASTy versions, as seen in PR lampepfl/dotty#18828.

We plan to promote this initiative again.

Developer Experience

Stable Presentation Compiler

For Scala 3.

This quarter, we focused on simplification and stabilisation of the Presentation Compiler of Scala 3. The work includes missing code completion inside extension constructs, better error recovery from errors and alignment of text replacement logic with respect to Scala 2. In terms of stability, we refactored the implementation of completions to rely on compiler logic, which not only deduplicated computations but also added missing completions.


For Scala 2 and Scala 3.

We have been reviewing the big PR (sbt/sbt#6746) opened by Eugene Yokota, which kick-starts the development of sbt 2. Following the “sbt 2 ideas” blog post and discussion, a significant focus of sbt 2 should be on simplifications and performance improvements. After the initial PR was merged, we worked on consolidating and simplifying the internals.

Noteworthy pull requests include:

Debugger in Metals

For Scala 3 mostly.

We made significant progress on Better Stack Traces for the debugger. We finished the main work on decoding class files and method names. We are now working on releasing an independent library for decoding stack traces, which will provide better stack traces for the debugger itself, but also Scastie, scala-cli, running applications, etc.

We also improved on smaller areas of the debugger: better information for Metals, support of Scala 3.4, and better handling of exported methods.

Support Scala CLI in Scala Steward

For Scala 2 and 3.

Scala Steward became a critical tool for maintenance of open source projects. It had minimal support for Scala CLI projects for a long time, but now in PR scala-steward-org/scala-steward#3188 we added support for the various ways to declare dependencies with using directives.

Scastie maintenance

For Scala 2 and 3.

We made various improvements to Scastie, mostly affecting the editor experience. This includes the new tree-sitter-based syntax highlighter that we mentioned in the last report.

We started collecting Metals crashes happening within Scastie, which will be used to improve the quality and stability of our tooling.

Scastie Scala-CLI

For Scala 2 and 3.

We resumed work on scala-cli support for Scastie. It is now under review, and we are still working on it for the upcoming quarter. This improvement will improve the performance of Scastie and will provide a fully-pledged scala-cli in the browser.

tasty-query maintenance

For Scala 2 and 3.

We fixed a number issues in tasty-query, notably when processing Scala 2 artifacts. They were mostly driven by the needs of the debugger, mentioned above.

We made the entire API of tasty-query thread-safe. It is now possible to safely use tasty-query from parallel algorithms. As a concrete use case, we have a prototype of tasty-mima running in parallel, making it about twice as fast.

Documentation and Education

Work-in-progress AI integration

For Scala 2 and Scala 3.

We are investigating the possibility of improving the usability of the Scala documentation by integrating it with the latest advancements in AI. At the moment, we are in an exploratory phase internally within the Scala Center. We have a prototype implementation for question-answering with internal data. We are planning to extend this solution to the Scala documentation so that Scala users can get their questions answered in chat format.

Community and Contributor Experience

For Scala 2 and Scala 3 throughout.

Scala Advent of Code

As in the past two years, we stewarded the participation to Advent of Code for Scala developers.

One of our core priorities is to communicate excitement about Scala. We participate in the Advent of Code so that we can share to the wider programming community how great Scala is for solving these programming puzzles. Another key priority is to improve the onboarding experience for newcomers. We hope that we will be able to share the solutions as a “Scala by Example” showcase to newcomers, giving a vital first impression of elegant Scala code.

This year, we increased overall engagement from the community, with 45% more solutions contributed than last year, and many first-time participants in the Scala Discord channel. We also engaged many more volunteers from outside of the Scala Center to write articles (with 100% coverage: each day now has a full article!), a vast improvement from 2022. We could have done more promotion but overall we had good results.

See the announcement blog and recap blog for more details.

Compiler Sprees

We maintained our involvement in the Scala 3 Compiler Academy Issue Spree. We collaborated with both new and experienced contributors on issues such as dotty#19464 and dotty#19463.

Since its inception, the compiler spree has helped close more then a hundred issues with the help of over 80 contributors.

GSoC 2023 Finalization

During this quarter, we finalized the cycle for the 2023 edition of Google Summer of Code. Six students successfully completed their projects. You can read more about our GSoC 2023 results, including all the projects our contributors worked on, in our dedicated blog article.

Collaboration with ESL

As part of our effort to promote usage of Scala at EPFL, and to gather the Scala community around common initiatives, we started a collaboration with the Embedded Systems Lab at EPFL. They have an interest in using Scala for circuits design with Chisel. Our common objective is to establish a semester project track for students at EPFL in which they can do hardware design with Scala as part of their studies.

Currently, we are in the process of helping ESL to integrate Chisel within their existing System Verilog-based setup. Once done, the work will be available on GitHub and may be also useful for people outside EPFL who are working in the domain.

Scala Center Fundraising Initiative

We continued our ongoing fundraising effort, exploring various avenues to establish partnerships with the industry. We have started to research the possibility of registering the Scala Center as a US non-profit, which would allow contributions from US-based companies to be tax-exempt. We are also working on the structure of our corporate membership. Both of these are work in progress.