|
| 1 | +--- |
| 2 | +layout: contact |
| 3 | +title: Scala Center Activity Report for 2023 Q4 |
| 4 | +--- |
| 5 | + |
| 6 | +Scala Center team: |
| 7 | +Darja Jovanovic, 100%; |
| 8 | +Anatolii Kmetiuk, 100%; |
| 9 | +Adrien Piquerez, 80%; |
| 10 | +Jamie Thompson, 100%; |
| 11 | +Sébastien Doeraene, 80%; |
| 12 | +Guillaume Martres, 20%; |
| 13 | +Valérie Meillaud: 30%. |
| 14 | +VirtusLab team: Jędrzej Rochala, 100%. |
| 15 | + |
| 16 | +## At a Glance |
| 17 | +{: .no_toc} |
| 18 | + |
| 19 | +* Table of Contents |
| 20 | +{:toc} |
| 21 | + |
| 22 | + |
| 23 | +## Language, Compiler, Standard Library |
| 24 | + |
| 25 | +### Maintainance of the Scala 3 Compiler |
| 26 | + |
| 27 | +For Scala 3. |
| 28 | + |
| 29 | +Every month, about 100 new issues are opened on [the Scala 3 repository](https://github.com/lampepfl/dotty/). |
| 30 | +The project welcomes any help it can get in triaging, bug-fixing, PR reviewing, etc. |
| 31 | + |
| 32 | +Our goal is to solve long-standing issues while keeping up with new ones. |
| 33 | +We also aim to get more people involved in working on the compiler to ensure the sustainability of the project. |
| 34 | + |
| 35 | +We contributed PRs for bug fixes in various areas, but would like to highlight one. |
| 36 | + |
| 37 | +Our previous work on [SIP-56, Specification for Match Types](https://docs.scala-lang.org/sips/match-types-spec.html), landed. |
| 38 | +It will be released as part of Scala 3.4.0, which is currently in the Release Candidate phase. |
| 39 | +The new specification and implementation provide a strong basis for future stability of the compiler. |
| 40 | +Feedback from Release Candidates surfaced a few minor issues, which we have addressed. |
| 41 | +We still intend to improve on this topic, notably in the area of error reporting. |
| 42 | + |
| 43 | +### Compile Progress reporting |
| 44 | + |
| 45 | +For Scala 2 and 3. |
| 46 | + |
| 47 | +A key part of the user experience is estimating how long you still have to wait for builds to run. |
| 48 | +Both Metals and IntelliJ can report this information to the user, through a dedicated interface to the compiler. |
| 49 | +Until now this was not supported by Scala 3, but added an integration to the compiler in PR [lampepfl/dotty#18739](https://github.com/lampepfl/dotty/pull/18739). |
| 50 | + |
| 51 | +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](https://github.com/scalameta/metals/pull/5788). |
| 52 | + |
| 53 | +### Scala.js maintenance |
| 54 | + |
| 55 | +For Scala 2 and 3. |
| 56 | + |
| 57 | +We released [Scala.js 1.15.0](https://www.scala-js.org/news/2023/12/29/announcing-scalajs-1.15.0/) during this quarter. |
| 58 | + |
| 59 | +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](https://docs.scala-lang.org/sips/drop-stdlib-forwards-bin-compat.html). |
| 60 | +That will allow us to evolve the Scala 2.13.x standard library. |
| 61 | + |
| 62 | +### Improving Performance of the Scala 3 compiler |
| 63 | + |
| 64 | +For Scala 3. |
| 65 | + |
| 66 | +#### Support for pipelined concurrent compilation |
| 67 | + |
| 68 | +Pipelined concurrent builds are a technique for increasing throughput in the context of multi-module projects. |
| 69 | +The concept is that dependent modules can begin compilation "as-soon-as" necessary artifacts for separate compilation can be produced. |
| 70 | +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). |
| 71 | + |
| 72 | +Pipelined builds have been implemented in sbt since 1.4, with support in Scala 2.13. |
| 73 | +We have made critical progress towards supporting them also in Scala 3. |
| 74 | + |
| 75 | +In PRs [lampepfl/dotty#19074](https://github.com/lampepfl/dotty/pull/19074) and [lampepfl/dotty#19259](https://github.com/lampepfl/dotty/pull/19259) we stabilised the production of outline signatures in TASTy for Java source programs. |
| 76 | +That is is necessary for pipeline compilation of mixed Java/Scala projects. |
| 77 | + |
| 78 | +In PR [lampepfl/dotty#18880](https://github.com/lampepfl/dotty/pull/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. |
| 79 | + |
| 80 | +#### Support for outline compilation |
| 81 | + |
| 82 | +In PR [lampepfl/dotty#19589](https://github.com/lampepfl/dotty/pull/19589) we are experimenting with an outline type checking mode, which builds on top of pipelining. |
| 83 | +It also gives us the chance to test out how compatible the compiler is with rudimentary batch parallel compilation of a single module. |
| 84 | +So far we can reduce the time to compile Scala 3 itself by a third, compared to no-pipelining. |
| 85 | +We demonstrated that work at Scala Italy, the London Scala User Group and finally the Paris Scala User Group. |
| 86 | + |
| 87 | +### Scala 3 New Features |
| 88 | + |
| 89 | +For Scala 3. |
| 90 | + |
| 91 | +#### SIP-57 `runtimeCheck` |
| 92 | + |
| 93 | +We made a proposal [SIP-57](https://github.com/scala/improvement-proposals/pull/67) to provide a better replacement for the `@unchecked` annotation, for the purpose of pattern match checking. |
| 94 | +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. |
| 95 | + |
| 96 | +#### Dropping `withFilter` by default in for comprehension in 3.4 |
| 97 | + |
| 98 | +In PR [lampepfl/dotty#18842](https://github.com/lampepfl/dotty/pull/18842) we activated the feature to prevent calls to `withFilter` being generated by default in for comprehensions. |
| 99 | + |
| 100 | +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. |
| 101 | +Developers can opt out of this check, and generate `withFilter` instead, by adding `case` before a pattern. |
| 102 | + |
| 103 | +### Scala Improvement Process |
| 104 | + |
| 105 | +For Scala 3. |
| 106 | + |
| 107 | +The [Scala Improvement Process](https://docs.scala-lang.org/sips/) coordinates the evolution of the language. |
| 108 | +It ensures that the decisions are made by taking into account the needs of all the stakeholders of the language. |
| 109 | + |
| 110 | +Four SIP meetings happended since the last report. |
| 111 | +Of note: the previously mentioned [SIP-56, Specification for Match Types](https://docs.scala-lang.org/sips/match-types-spec.html), was approved for Implementation and later for Shipping. |
| 112 | +Several new SIPs are in progress. |
| 113 | + |
| 114 | +### Better error messages for Scala 3 |
| 115 | + |
| 116 | +For Scala 3. |
| 117 | + |
| 118 | +In Q4 we started a campaign to get users to report problematic error/warning messages in Scala 3. |
| 119 | +We created a new [issue template](https://github.com/lampepfl/dotty/pull/18672) and promoted it in [a blog](https://scala-lang.org/blog/2023/10/17/feedback-wanted-error-messages.html). |
| 120 | +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](https://x.com/scala_lang/status/1720423780382634276?s=20). |
| 121 | + |
| 122 | +At the Center itself we worked on improving the reporting of mismatched TASTy versions, as seen in PR [lampepfl/dotty#18828](https://github.com/lampepfl/dotty/pull/18828). |
| 123 | + |
| 124 | +We plan to promote this initiative again. |
| 125 | + |
| 126 | +## Developer Experience |
| 127 | + |
| 128 | +### Stable Presentation Compiler |
| 129 | + |
| 130 | +For Scala 3. |
| 131 | + |
| 132 | +This quarter, we focused on simplification and stabilisation of the Presentation Compiler of Scala 3. |
| 133 | +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. |
| 134 | +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. |
| 135 | + |
| 136 | +### sbt |
| 137 | + |
| 138 | +For Scala 2 and Scala 3. |
| 139 | + |
| 140 | +We have been reviewing the big PR ([sbt/sbt#6746](https://github.com/sbt/sbt/pull/6746)) opened by Eugene Yokota, which kick-starts the development of sbt 2. |
| 141 | +Following the ["sbt 2 ideas" blog post](https://eed3si9n.com/sbt-2.0-ideas) and [discussion](https://github.com/sbt/sbt/discussions/7174), a significant focus of sbt 2 should be on simplifications and performance improvements. |
| 142 | +After the initial PR was merged, we worked on consolidating and simplifying the internals. |
| 143 | + |
| 144 | +Noteworthy pull requests include: |
| 145 | + |
| 146 | +* [#7444 Reduce abstraction in `Execute` and around](https://github.com/sbt/sbt/pull/7444) |
| 147 | +* [#7456 Remove `AList`, replace it with `TupleMapExtension`](https://github.com/sbt/sbt/pull/7456) |
| 148 | + |
| 149 | +### Debugger in Metals |
| 150 | + |
| 151 | +For Scala 3 mostly. |
| 152 | + |
| 153 | +We made significant progress on Better Stack Traces for the debugger. |
| 154 | +We finished the main work on decoding class files and method names. |
| 155 | +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. |
| 156 | + |
| 157 | +We also improved on smaller areas of the debugger: better information for Metals, support of Scala 3.4, and better handling of exported methods. |
| 158 | + |
| 159 | +### Support Scala CLI in Scala Steward |
| 160 | + |
| 161 | +For Scala 2 and 3. |
| 162 | + |
| 163 | +Scala Steward became a critical tool for maintenance of open source projects. |
| 164 | +It had minimal support for Scala CLI projects for a long time, but now in PR [scala-steward-org/scala-steward#3188](https://github.com/scala-steward-org/scala-steward/pull/3188) we added support for the various ways to declare dependencies with using directives. |
| 165 | + |
| 166 | +### Scastie maintenance |
| 167 | + |
| 168 | +For Scala 2 and 3. |
| 169 | + |
| 170 | +We made various improvements to Scastie, mostly affecting the editor experience. |
| 171 | +This includes the new tree-sitter-based syntax highlighter that we mentioned in the last report. |
| 172 | + |
| 173 | +We started collecting Metals crashes happening within Scastie, which will be used to improve the quality and stability of our tooling. |
| 174 | + |
| 175 | +### Scastie Scala-CLI |
| 176 | + |
| 177 | +For Scala 2 and 3. |
| 178 | + |
| 179 | +We resumed work on scala-cli support for Scastie. |
| 180 | +It is now under review, and we are still working on it for the upcoming quarter. |
| 181 | +This improvement will improve the performance of Scastie and will provide a fully-pledged scala-cli in the browser. |
| 182 | + |
| 183 | +### tasty-query maintenance |
| 184 | + |
| 185 | +For Scala 2 and 3. |
| 186 | + |
| 187 | +We fixed a number issues in [tasty-query](https://github.com/scalacenter/tasty-query), notably when processing Scala 2 artifacts. |
| 188 | +They were mostly driven by the needs of the debugger, mentioned above. |
| 189 | + |
| 190 | +We made the entire API of tasty-query thread-safe. |
| 191 | +It is now possible to safely use tasty-query from parallel algorithms. |
| 192 | +As a concrete use case, we have a prototype of [tasty-mima](https://github.com/scalacenter/tasty-mima) running in parallel, making it about twice as fast. |
| 193 | + |
| 194 | +## Documentation and Education |
| 195 | + |
| 196 | +### Work-in-progress AI integration |
| 197 | + |
| 198 | +For Scala 2 and Scala 3. |
| 199 | + |
| 200 | +We are investigating the possibility of improving the usability of the Scala documentation by integrating it with the latest advancements in AI. |
| 201 | +At the moment, we are in an exploratory phase internally within the Scala Center. |
| 202 | +We have a prototype implementation for question-answering with internal data. |
| 203 | +We are planning to extend this solution to the Scala documentation so that Scala users can get their questions answered in chat format. |
| 204 | + |
| 205 | +## Community and Contributor Experience |
| 206 | + |
| 207 | +For Scala 2 and Scala 3 throughout. |
| 208 | + |
| 209 | +#### Scala Advent of Code |
| 210 | + |
| 211 | +As in the past two years, we stewarded the participation to [Advent of Code](https://adventofcode.com/) for Scala developers. |
| 212 | + |
| 213 | +One of our core priorities is to communicate excitement about Scala. |
| 214 | +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. |
| 215 | +Another key priority is to improve the onboarding experience for newcomers. |
| 216 | +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. |
| 217 | + |
| 218 | +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. |
| 219 | +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. |
| 220 | +We could have done more promotion but overall we had good results. |
| 221 | + |
| 222 | +See the [announcement blog](https://scala-lang.org/blog/2023/11/23/advent-of-code-announce.html) and [recap blog](https://scala-lang.org/blog/2024/01/10/advent-of-code-recap.html) for more details. |
| 223 | + |
| 224 | +### Compiler Sprees |
| 225 | + |
| 226 | +We maintained our involvement in the [Scala 3 Compiler Academy Issue Spree](https://www.scala-lang.org/blog/2022/11/02/compiler-academy.html). |
| 227 | +We collaborated with both new and experienced contributors on issues such as [dotty#19464](https://github.com/lampepfl/dotty/pull/19464) and [dotty#19463](https://github.com/lampepfl/dotty/pull/19463). |
| 228 | + |
| 229 | +Since its inception, the compiler spree has helped close [more then a hundred issues](https://github.com/lampepfl/dotty/issues?q=is%3Aissue+sort%3Aupdated-desc+label%3ASpree+is%3Aclosed) with the help of over 80 contributors. |
| 230 | + |
| 231 | +### GSoC 2023 Finalization |
| 232 | + |
| 233 | +During this quarter, we finalized the cycle for the 2023 edition of Google Summer of Code. |
| 234 | +Six students successfully completed their projects. |
| 235 | +You can read more about our GSoC 2023 results, including all the projects our contributors worked on, in [our dedicated blog article](https://scala-lang.org/blog/2023/12/20/gsoc-report.html). |
| 236 | + |
| 237 | +### Collaboration with ESL |
| 238 | + |
| 239 | +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. |
| 240 | +They have an interest in using Scala for circuits design with Chisel. |
| 241 | +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. |
| 242 | + |
| 243 | +Currently, we are in the process of helping ESL to integrate Chisel within their existing System Verilog-based setup. |
| 244 | +Once done, the work will be available on GitHub and may be also useful for people outside EPFL who are working in the domain. |
| 245 | + |
| 246 | +### Scala Center Fundraising Initiative |
| 247 | + |
| 248 | +We continued our ongoing fundraising effort, exploring various avenues to establish partnerships with the industry. |
| 249 | +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. |
| 250 | +We are also working on the structure of our corporate membership. |
| 251 | +Both of these are work in progress. |
0 commit comments