Scala Center team: Julien Richard-Foy, 80%; Jamie Thompson, 100%; Adrien Piquerez, 100%; Valérie Pedroni, 60%; Sébastien Doeraene, 100%; Darja Jovanovic, 100%; Quentin Bernet, 50%. VirtusLab team: Tomasz Godzik, 33%; Jędrzej Rochala, 67%.

External contractors, part-time: Adam Goodman, leadership and governance expert.

At a Glance

Tooling

Scala Steward GitHub Action

For Scala 2 and Scala 3.

The widespread adoption of Scala is a function of many factors. One of them is the stability of the ecosystem. The stability is ensured, in part, by having a robust infrastructure to automatically test the code and keep its dependencies up-to-date.

Scala Steward is a bot that keeps the dependencies of the Scala ecosystem projects up to date. It achieves this by submitting PRs to projects which subscribed to it whenever there is a new version of their dependencies.

During Q3, it became obvious how critical Scala Steward is. Fortunately, VirtusLab overtook running the public instance of Scala Steward, but it became apparent that a fallback plan is important to have. Such a plan was an existing GitHub Action that allows individual repositories to run the bot independently of the public instance. Furthermore, the GitHub Action solution can also be used with private GitHub repositories.

One problem with the Action, however, was that its documentation was not easy for a beginner to follow. In Q3, we collaborated with the author of the Action to learn better what it can do and improve its documentation.

Debugger in Metals

For Scala 3 and Scala 2.

A debugger is a powerful tool to understand the execution of a program. While it increases the productivity of every programmer, it also makes it easier for newcomers to experiment with the language, and it can speed up their learning process.

Our main contribution to the debugger is the “step filter”. Its goal is to skip the irrelevant steps of execution so that the user can focus on what matters: its code. Thanks to the step filter, the debugger will now skip the method generated by the compiler to go directly to actual written code, in the user’s project or in the library dependencies. For instance, it will skip the mixin-forwarders, the getters, the setters, the bridges and the synthetic methods of case classes. The Scala 2 step filter (#253) is based on a copy of the Scala 2 unpickler and the Scala 3 step filter (#271) is based on TASTy Query.

Other contributions to the debugger are:

  • Add filter to skip class loading (#281)
  • Add support for conditional breakpoints (#282)
  • Fixed evaluation of by-name parameters in Scala 3 (#277)
  • Configure the expression compiler on each managed entry (module), with their own scalacOptions (#280)
  • Add support for Scala 3.2.0, 2.12.17 and 2.13.9
  • Use BackgroundJobService in sbt-debug-adapter to properly forward the log to Metals (#266)

Scaladex

For Scala 3 and Scala 2.

The main recent improvement in Scaladex is a community contribution: the commit activity chart (#1002) by @joke1196. We also replaced the forks sorting criteria by the commit activity sorting criteria. It is now possible to sort the projects from most active to least active in terms of number of commits in the past year.

Additionally, we added the Mill filter (#1071) to enable browsing the ecosystem of Mill plugins.

sbt

For Scala 3 and Scala 2.

We fixed the logging of background jobs triggered from the sbt client (sbtn) (#6992): In sbt 1.8.x the user will be able to run many background jobs (bgRun) from different clients and the logs will be correctly forwarded to the client that started them. Since the jobs run in the background the sbt server can simultaneously be used as the build server. Ideally we would like to be able to also run the tests in the background but this is not yet possible.

GitHub Security Alerts in sbt projects

For Scala 3 and Scala 2.

We released scalacenter/sbt-dependency-submission a GitHub action that submits the full graph of dependencies of an sbt project to GitHub for security scanning. It is used in more than 50 open repositories. It can also be used in private repositories.

Language Improvements

For Scala 3.

We have created two Scala Improvement Proposals:

The implementation for the first is almost done and can be found here. We have also started working on its support by Scalameta.

TASTy Manipulation Library (tasty-query)

For Scala 3.

tasty-query is a library to read semantic information from Scala 3 classpaths. It reads Scala .tasty files, Scala 2 pickles and Java .class files, and presents the semantic information they contain in a unified API.

tasty-query will be an essential tool for any static analysis involving Scala code. In particular, it will be the basis for TASTy-MiMa. More information can be found in the readme of tasty-query.

In this quarter, we made significant progress on tasty-query, and released a first in-progress version 0.1.0. That version is used in the Scala Debug Adapter to provide smart step-into filters for Scala 3 code.

The main improvements are:

  • Read all symbols and types from class files and Scala 2 pickles (in addition to TASTy files, which were already handled)
  • Read the flags of all symbols
  • Read the parents of classes
  • Compute the erased name of fields and methods
  • Compute type substitution (applying actual type arguments to polymorphic methods, classes and higher-kinded type lambdas)
  • Compute the types of members “as seen from” given prefixes
  • Look up inherited members from parent classes
  • Lots of bug fixes
  • Cleaning up the public API of the library
  • Support both the JVM and Scala.js on the Node.js platform

Education and Documentation

Reference Documentation

For Scala 3.

The Reference page outlines the differences between Scala 2 and 3. This makes it an important document for people who want to migrate, be it libraries and projects, or just their mental model.

To ensure the quality of the Reference documentation, we have reviewed it with fresh eyes, and we have contributed changes to make it clearer and more correct.

The PR containing all these changes can be found here.

Scala Website

We continued to work on our goal to improve the user experience for people visiting the Scala website. As a reminder, the long-term goals are to:

  • improve the usability of the website
  • solidify the getting-started experience for newcomers
  • show the proven use-cases of the language (rather than only its features)
  • communicate the strength of the tools surrounding the language
  • reach out to new kinds of users.

To this effect, we achieved the following work:

  • Updated many pages of the documentation to show both Scala 2 and Scala 3 code examples. We also created an issue to coordinate this effort while inviting the community to contribute to it (#2481).
  • Clarified parts of the Getting Started tutorial (#2520).
  • Simplified the path for Java programmers coming to Scala (#2414).
  • Added a new page showing the benefits of using Scala for teaching programming (#1402).
  • Updated mdoc to Scala 2.13 syntax (#2529).
  • Significantly improved the loading time of pages containing code snippets (#2460).

An integrated Scala.js ecosystem

For Scala 2 and Scala 3.

The Scala.js ecosystem contains individual pieces of great quality, from the compiler to the UI libraries. However, it is a challenge for every newcomer to find the pieces that are relevant, to connect them, and to build a good development experience. To address this issue, we want to provide a clear “integrated Scala.js ecosystem”. You can find the complete roadmap here.

The first video in the series, Getting Started with Scala.js and Vite was published in June 2022. We recorded the second video, which will be released soon after ScalaCon.

We are also preparing a written tutorial version that we will publish to the Scala.js website, and we will give a talk at ScalaCon on the same topic.

Extension School

For Scala 3.

Our partnership with the Extension School allows us to provide more support to people learning Scala online. We have been answering the questions of the learners, and providing feedback to their homeworks. We have started a communication campaign about this partnership. We publish a new post every week for 11 weeks.

Communication

Let’s Talk About Scala 3 Videos

For Scala 3.

We published a new video, Immutable Data: Your Next Superpower, explaining how to leverage immutable data in Scala.

Scala Center LinkedIn Page

For Scala 2 and 3.

Our LinkedIn page is growing in followers and content.

We published 17 posts (consistent with last Q2 posting rhythm) gathering 129 new followers and 68% augmentation in page views and 77% unique visitors. Our page has now a total of 1,100 followers.

The Scala Enthusiasts page has now more than 34,347 members (435 new members since last quarter). We repost all of our LinkedIn content on this page and accept new members daily.

Community, Sustainability, and Governance

Compiler Academy

For Scala 3.

A major challenge for Scala is the maintainability of the compiler. Scala originated and is still maintained in large by the team of PhD students at EPFL led by Martin Odersky which comes with its own challenges. Maintenance is not a primary focus of the researchers. The time people spend at EPFL is a couple of years, and after they move on with their careers, their expertise is lost.

The Scala 3 Compiler Academy is an effort to provide one avenue of many to address this challenge by involving the community more in the compiler development process. Currently, we have two branches of the Academy:

  • Issue Sprees: pair programming sessions for the community people where they fix Scala 3 Compiler issues together.
  • YouTube Channel: we publish videos with thorough overview of the compiler internals there for the expertise to be preserved.

In Q3, we published 3 videos on the YouTube channel. We’ve gained 101.3 hours of total watchtime of those videos, 1.4K views in total, and 105 new subscribers. We’ve also produced another video which is pending to be published.

Also, we’ve laid out plans on opening up the Issue Spree to the wider public by migrating it to Discord. This will happen in Q4, and the objective is to scale the effort, involving even more people in the sprees.

Community Expansion

For Scala 2 and 3.

One of our goals at the Scala Center is to increase the adoption of Scala – and one of the best places to start is at EPFL where we are located. During Q3, we’ve been working on the Scala in Science project – a gamified workshop that introduces young scientists to Scala using rocket science.

In Q3, we’ve set up everything at EPFL to make the workshop happen, and conducted the first dry run of the workshop for the teams of LAMP and Scala Center. In Q4, we’ll start conducting the workshop for the wider EPFL community which will hopefully lead to a wider awareness about Scala.

To get an idea of what the workshop is about, see the following blog article.

We have also organized a local event, a “Scala Lunch”, where people using Scala or curious about Scala could hang out and discuss together. 31 attendees were present.

Google Summer of Code

For Scala 2 and 3.

We’ve been mentoring 4 students during this year’s iteration of GSoC. Two of them have already passed their final evaluations, while the other two extended their deadlines and are due to finish in October. The two passed final reports can be found here and here.

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.

We organized two SIP meetings:

We also published an article summarizing the goals of the process, the way it works, and the results of the first meeting.

Scala Developer Survey

In partnership with VirtusLab, we have created and published a survey to know the community better and learn about the libraries and tools they use. You can read the announcement here, and fill the survey here (until 21st of October 2022).

Maintenance Work

TASTy Reader

For Scala 2 and 3.

TASTy Reader allows Scala 2 programs to consume artifacts compiled by Scala 3.

We added improvements to the TASTy reader, released in Scala 2.13.9:

  • We restrict depending on an experimental definition from Scala 3 unless the defining scope is also declared as experimental. This will make it safer to depend on Scala 2 libraries from Scala 3. Without this change, it could be possible to accidentally create a transitive dependency on an experimental Scala 3 API. This would manifest by depending on a Scala 2 library that has a public API whose implementation depends on an experimental Scala 3 API. Now this situation is impossible without explicit opt-in.
  • Scala 3.2.0 increased the version of TASTy its signatures are encoded with. Scala 2.13.9 is able to read definitions published by Scala 3.2.0. This includes support for new encoding of constructor signatures. We also added lazier reading of annotations, meaning that only the Scala 3 definitions that are explicitly used are checked - this prevents more “unsupported Scala 3” feature errors occurring for unused definitions.

The corresponding PRs are #10068 and #10127.

Improved Mirror Synthesis

For Scala 3.

Mirrors are critical to metaprogramming in Scala 3. The compiler can automatically provide a Mirror value that reflects the structure of certain types, in particular, all case classes and enums. Mirrors enable implementation of type class derivation without advanced metaprogramming techniques such as macros.

We released many improvements to Mirror synthesis in Scala 3.2.0. Most importantly, Mirrors are now generated for local and inner classes and generic tuple types up to the size of 22 (#15404, #15814, #15847). We now also report the exact reason why in certain cases Mirror synthesis fails, which will help users to better design their types to support Mirror synthesis (#15164). Additionally, we fixed many bugs in the implementation of Mirrors. For example, case classes whose companion is also a case object now have the correct Mirror.

Interactive Usage of the Compiler

We have fixed the list of completions returned by the compiler when it used in interactive mode by IDEs such as Metals (#15795, #15807).

Implement JSR-45

For Scala 3.

Debugging a program containing code that has been inlined is difficult because the debugger shows code and positions that don’t match the source code anymore. The JSR-45 specification provides a solution to this issue. We decided to focus our efforts on implementing JSR-45 in the Scala 3 compiler because inline is now part of the language, and any Scala 3 program is likely to have inlined code fragments.

We took over the initial work that was done on the compiler by @Kordyjan, we rebased it, and fixed several issues in it (#15684). We will be addressing the remaining issues during the next quarter.

Scala.js

For Scala 2 and 3.

We published Scala.js versions 1.10.1 and 1.11.0. The most important changes in these releases are:

  • A number of bug fixes
  • Better error messages for StringIndexOutOfBoundsExceptions
  • Handle the sbt setting envVars
  • New optimizations (contributed by Tobias Schlatter)

We also updated Scala.js for the new Scala releases 2.12.17 and 2.13.9. We back-published Scala.js 1.7.1->1.11.0 for those versions of Scala.

In addition, we improved the internal test coverage of Scala.js for Scala 3. All the relevant compiler tests of Scala 3 are now also tested in their Scala.js variant, bringing it on par with the Scala 2 coverage.

Scastie

For Scala 2 and 3.

We performed various maintenance tasks on Scastie:

  • Updated the CodeMirror editor to version 6.0 (#628)
  • Replaced reactive-mongo with the official mongodb driver (#637, #639)