Skip to content

Commit 6e82fac

Browse files
authored
Merge pull request #323 from sjrd/report-2023-q4
Add the 2023 Q4 report and the 2024 Q1 roadmap.
2 parents f37375a + 6ff105d commit 6e82fac

File tree

4 files changed

+388
-1
lines changed

4 files changed

+388
-1
lines changed

projects.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,3 @@
11
---
2-
redirect_to: /records/2023-Q4-roadmap.html
2+
redirect_to: /records/2024-Q1-roadmap.html
33
---

records.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,7 @@ Every quarter, the Scala Center publishes an activity report detailing the
1414
work that has been achieved. You can find the roadmap for the current quarter
1515
in the [Projects page]({% link projects.md %}).
1616

17+
- [2023, Q4]({% link records/2023-Q4-activity-report.md %})
1718
- [2023, Q3]({% link records/2023-Q3-activity-report.md %})
1819
- [2023, Q2]({% link records/2023-Q2-activity-report.md %})
1920
- [2023, Q1]({% link records/2023-Q1-activity-report.md %})

records/2023-Q4-activity-report.md

Lines changed: 251 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,251 @@
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

Comments
 (0)