scala
scala3
Scala2014–2026
scala / scala3
scala3
The Scala 3 compiler, also known as Dotty.
48Distinct people
76Mentions
0Explicit recommenders
6.3KGitHub stars
What to know before exploring
What it is
The Scala 3 compiler, also known as Dotty.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- scala/scala · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year76 dated mentions
Observed mentions: 2014-02-19 09:03:06 UTC to 2026-09-03 14:19:53 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 8 | 3 | 5 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 8 | 2 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 16 | 6 | 10 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 15 | 6 | 9 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 4 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 1 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Scala 3
This is the home of the Scala 3 standard library, compiler, and language spec.
More documentation here.
Building a Local Distribution
sbt dist/Universal/packageBin
Find the newly-built distributions in dist/target/
Code of Conduct
Scala 3 uses the Scala Code of Conduct
for all communication and discussion. This includes both GitHub, Discord and
other more direct lines of communication such as email.
How to Contribute
Contributing guide
Issues where help is wanted
Policy regarding the use of LLM-based tools
License
Scala 3 is licensed under the Apache License Version 2.0
Read the full README on GitHubWhat Hacker News says
76 sources> It's kind of like the small string optimization you see in C++ ...
Agreed. These types of optimizations can yield significant benefits and are often employed in language standard libraries. For example, the Scala standard library employs an analogous optimization in their Set[0] collection type.
0 - https://github.com/scala/scala3/blob/88438e2c6e6204e12666067...
In Allocating on the Stack> PS Perhaps they should make an actual unit test suite for their compiler. Instead they have a couple of dozen tests and have to guess if their compiler PR will break things.
You did not even try to formulate it in a way that could be interpreted as you just not knowing; instead you make blatant false statements in the most confident way possible.
Your statement is therefore an outright lie, spreading FUD.
As a matter of fact the Scala compiler has thousands, likely even tens of thousands of test cases.
https://github.com/scala/scala3/tree/main/tests
But that's not all. Scala (2 & 3) has also a test case called "community build" where new compiler releases are tested by compiling millions of LOCs from all kinds of Scala OpenSource projects.
https://github.com/VirtusLab/community-build3
https://github.com/scala/community-build
In Scala 3 slowed us down?Interesting.
I wonder how Nim 3/Nimony handles or will handle bindings in patterns regarding copy, move or reference. Rust can change it per binding, and Ada's experimental pattern matching might have some plans or properties regarding that.[1]
> By default, identifier patterns bind a variable to a copy of or move from the matched value depending on whether the matched value implements Copy.
> This can be changed to bind to a reference by using the ref keyword, or to a mutable reference using ref mut. For example:
match a {
None => (),
Some(value) => (),
}
match a {
None => (),
Some(ref value) => (),
}
.
The Github issue had a strange discussion. I really disliked goteguru's equals-sign-based syntax, though I had difficulty judging the main design syntax.
I wonder what Araq thinks of Scala
Read the rest
's Expression AST type. Tree, TermTree, and all the subtype case classes [2]. Tree has fields. Though I am not certain how the common variables are initialized.
[1] https://doc.rust-lang.org/reference/patterns.html#r-patterns...
[2] https://github.com/scala/scala3/blob/main/compiler/src/dotty...
> 1) The language is too unstable
Thankfully not anymore. They got their act together and have been maintaining compatibility since Scala 3.0.0 has been released in May 2021, which is almost 4 years and counting.
https://github.com/scala/scala3/releases/tag/3.0.0
Scala 3.x is to remain compatible for the whole 3.x series (think of semantic versioning). There's no Scala 4 (breaking with Scala 3) in sight.
Also, Scala 3 and Scala 2.13 JARs are also compatible with each other, which helped with the transition.
> 2) The tooling around it is not the best
sbt may not be good. But Mill is much better than either Maven or Gradle. Especially Gradle. Bleep is also promising.
Scalafmt is widely used and liked. Scalafix -- the linter/fixer -- is used a bit less, but still of a good quality.
In Evolving ScalaThe IntelliJ IDEA plugin for Scala is built by Jetbrains, so it has official support. It has its quirks, but so does the Kotlin plugin.
Sbt is better than Gradle IMO, as it has a saner mental model, although for apps you can use Gradle or Maven. Sbat has had some awesome plugins that can help in bigger teams, such as Scalafmt (automatic formatting), Scalafix (automatic refactoring), Wartremover and others. Scalafmt specifically is best in class. With Sbt you can also specify versioning schemes for your dependencies and so you can make the build fail on problematic dependency evictions.
Scala CLI is also best in class, making it comfortable to use Scala for scripting – it replaced Python and Ruby for me: https://scala-cli.virtuslab.org/
Note that Java and Kotlin have Jbang, but Scala CLI is significantly better, also functioning as a REPL
Read the rest
. Worth mentioning that other JVM languages hardly have a usable REPL, if at all.
The Scala compiler can be slow, but that's when you use libraries doing a lot of compile-time derivation or other uses of macros. You get the same effect in similar languages (with the exception of Ocaml). OTOH the Scala compiler can do incremental compilation, and alongside Sbt's support for multiple sub-projects or continuous testing, it works fairly well.
Scala also has a really good LSP implementation, Metals, built in cooperation with the compiler team, so you get good support in VS Code or Vim. To get a sense of where this matters, consider that Scala 3.5 introduces "best effort compilation": https://github.com/scala/scala3/pull/17582
I also like Kotlin and sadly, it's missing a good LSP implementation, and I don't think Jetbrains is interested in developing it.
Also you get all the tooling that's JVM specific, including all the profilers and debuggers. With GraalVM's native image, for example, Scala fares better than Java actually, because Scala code relies less on runtime reflection.
I'd also mention Scala Native or ScalaJS which are nice to have. Wasm support is provided via LLVM, but there's also initial support for Wasm GC.
So to answer your question, yes, Scala has really good tooling compared to other languages, although there's room for improvement. And if you're comparing it to any other language that people use for FP, then Scala definitely has better tooling.
Distinguish between pure and impure functions
2 points · Open discussionWho isn't waiting to finally get an usable effect system?
But there is something on the horizon for Scala:
https://github.com/lampepfl/dotty/blob/release-3.1.0/docs/do...
One can have a proper effect system on the JVM also already today with Flix:
https://en.wikipedia.org/wiki/Flix_(programming_language)#Po...
In ‘Woof’, a pure Scala 3 logging libraryLooked it up, the official announcement that it would become Scala 3 happened in 2018.
https://www.scala-lang.org/blog/2018/04/19/scala-3.html
You can dig through the git history of the readme for Dotty, it's actually pretty enlightening how Odersky's perception of it has evolved over time. For example, in 2014 he referred to dotty as an experimental compiler for a dialect of scala.
https://github.com/lampepfl/dotty/commit/6a42d32181bd7b8639f...
In Scala 3.0As someone who has spent a lot of time diving deep into Scala (I worked on compiler related semantic tooling for scalameta, worked on a experimental parallelizable Scala compiler, and even have a single commit in this release from almost four years ago LOL), and who more recently has been working with TypeScript, I find this really interesting and agree in some ways.
Scala 2.x already had path-dependent types, which combined with implicits and type inference were technically sufficient to implement versions of of the dependent function types we have now in 3.x. In my opinion, how you did this previously could get really clunky (See e.g. hlist mapping in https://github.com/milessabin/shapeless/blob/8933ddb7af63b8b...). Lots of things that frankly felt like casting magic spells, and there were sometimes fragile and weird bugs especially wit
Read the rest
h how implicits were resolved, see e.g. https://github.com/scala/scala/pull/6139.
The native type-level meta-programming coming in 3.x along with a lot of streamlining of the underlying type system and implicit resolution rules (e.g. https://github.com/lampepfl/dotty/pull/5925) could help a lot.
This is just one example of a more advanced feature, but there are lots of things like this that changed in Dotty (maybe the most interesting is the DOT calculus that makes a better backbone for the type system). I don't know what tooling for Scala 3.x looks like, but even Intellij's frankly amazing Scala plugin broke down sometimes for 2.x.
After using TypeScript, I just personally enjoyed the experience better. Technically Typescript's type system is equally as powerful as Scala's, but the primitives for expressing more complicated types just seem much easier compared to the path-dependent stuff you would need to do in Scala.
I was amazed to find stuff like this https://github.com/aws-amplify/amplify-js/blob/dedd5641dfcfc... in mainstream wide usage. I'm not even sure how you could write these type of transformations as well in any version of Scala. I suppose maybe records work, or in this specific case there are functional patterns that are preferred.
Caveat, I haven't followed Dotty for a couple years now, so I could be missing a lot. Regardless, I have really enjoyed the tooling around Typescript as well as the design. The real-world usage of more complicated dependent types (and there are good uses IMO) have been more fluent and easier to understand, and less dependent on tricky behavior like for implicits.
VS Code's tools are really magical, and I hope with some of the amazing underlying work done in Dotty the Scala developer experience could look more like that.
Scala 3.0.0 (Dotty) is released
9 points · Open discussionLooks like we're a go with Scala 3.0.0 final release
4 points · Open discussion22 is just arbitrary.
> Is it one of those no one is going to need more than 22 arguments?
You can work around this limit with nested tuples, or just defining Function23 yourself. Although if your function accepts 23 arguments, you should probably refactor that anyways.
It is also worth noting that Scala 3 drops this limitation by implementing function arguments with arrays: https://github.com/lampepfl/dotty/pull/1758
In From First Principles: Why Scala?Showing the 15 most recent of 76 sources. Enable JavaScript to search and browse every indexed mention.