If we want to say it really doesn't matter what language we choose, because any solution can be cooked up regardless, it absolutely matters then what the tools around that language bring to the table.
Please avoid generalisation. Not "all".
> Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
I, for one, think Capture Catching can't arrive soon enough. It will allow us to write much simpler programs, getting an edge over modern Java & co. I'm very much looking forward to it.
Don't use experimental Scala features in production code. They may change or be removed. And they will likely lack support in IDEs. But that is a common sense.
- faster compile times
- faster compile times
- I want sbt+scalatest (the blessed build tool/test framework) to not leak memory constantly (https://olegych.github.io/blog/sbt-fork.html this is an issue I specifically run into)
- I want useful documentation when I ctrlclick into settingKeys in build.sbt
- I want Intellij to not bug out when you pass explicitly the implicit arguments required by a function that uses both context bounds and implicits
- I want intellij to always agree with the scala compiler
https://mill-build.org/mill/comparisons/why-mill.html#_perfo...
And support for Scala in [web frameworks for Java].
Still on Scala 2.13, so don't know what 3.* I'd want, more than what already exist
Edit: It focuses too much on the language instead of the ecosystem.
2. Rust has improved its compiler performance by >3x in the last 5 years.
3. Rust hasn't gotten any major new language feature in the last 6 years. Most language improvement is improving orthogonality of existing features.
4. Rust has an excellent backwards compatibility story also right from the start. Code/libraries written in 2015 can be still compiled and used together with code from 2025.
5. Rust has a serious backing from all major IDE / editor providers.
6. Rust has integrates easily with other languages and ecosystems. It's easier to call Rust from Python than to call Scala from Python. It's easier and more performant to call C from Rust than to call C from Scala. Things like that. It's sad that Scala even struggled with interoperability with Java; which should theoretically be easy as it is the same platform.
Seriously, doesn't look to me like the same mistakes. It's actually quite opposite.
Rust also ships with a functioning epoch/edition system that makes it feasible to rework existing language features for improved generality, elegance etc. without losing backward compatibility. I'm not sure if Scala has anything like that.
Also, the nightly/stable split in Rust means that most new features don't reach the final adoption stage unless there's a very real consensus about their design. A lot of effort is made to get rid of incidental complexity wherever feasible, before the new features are actually stabilized.
Most language implementations that "haven't gotten any major new language feature in the last 6 years" would be described as broadly stagnant or stale, but Rust is quite different.
If you want a more useful standard library, perhaps consider Go.
But it makes up for the minimalist stdlib by making it a breeze to use third-party libraries.
There's plenty of old modules in the Python standard library that hardly any one uses. But removing them would break backwards compatibility guarantees. The Rust project has decided that they want to keep the standard library lean. And this works well in practise, because cargo is a really good package manager.
Cargo is a really good tool, but I wouldn't say it is 10x better than SBT.On the other hand, Scala can be used with different build tools: Maven, Gradle, Mill. With Rust you have no choice(or I'm not aware of). Rust-analyzer is better than metals, can't argue with that...
>Rust has improved its compiler performance by >3x in the last 5 years
Rust compiler is very slow. I can't imagine what compilation time was 5 years ago, but even now, it is incredibly slow, even compared to "slow" Scala compiler(which is no longer true). I'm working on a little project with bevy, and even on such small project compilation time sucks. You can't compare it with Scala, it's just completely different experience.
>Rust hasn't gotten any major new language feature in the last 6 years.
That's not true. Rust team handles these changes correctly. Rust has concept of "Editions", and every 3 years new edition introduces significant changes. I really like how editions work, it's a great way to maintain backwards compat.
>4 Mostly agree
>5 Fully agree
>It's easier and more performant to call C from Rust than to call C from Scala.
Yep, but it's not Scala but the JVM limitation. JNI sucks, but there is an effort to improve that (project Panama).
Overall, both Scala and Rust are great languages. Rust team has addressed many typical issues from the beginning. Scala had its mistakes, but moving in the right direction.
---------
To me the goals are sensible the flagship goals (for 2025H1 for example [1]) are all about DX and focus on downstream devs and their needs (all hands, Rust in the kernel).
The usual problem of "compile times" [2] (usually link times and LLVM throughput and so on) are things that are being worked on, but fundamentally they all can only be solved by caching, incremental compilation, and better developer tooling that are not language problems.
[1] https://rust-lang.github.io/rust-project-goals/2025h1/goals....
[2] https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_fo...
It's time to shift priorities.
Now even Java has cheap threads (Loom).
And Go even has generics. Just 20-ish years later than Java. And it's likely that more features that now Java has will trickle into Go. If Go wants to survive.
All this to say that there is no space in the market for another language which is a stupid simple Algol. Go already occupies that space. And even Go will have to add features developers want/need, if it doesn't want to get cornered out of the market.
It's not only Scala that must evolve.
If by "cheap threads" you mean M-on-N threads a.k.a. fibers/green threads, Java had that on Solaris well before Go.
Java is one of the few languages that does have it, besides Erlang, Haskell and Go. That "even" is absolutely not warranted.
Java needed Apple, Go needed Google, React needed Facebook, TypeScript needed Microsoft, etc
In this way Rust is actually a pretty unique success story in that there's no singular major tech firm pushing it
What do you mean by that? What is missing?
Language geeks want language geeking, what Scala users want is a "faster horse". (Faster compiler, nicer project/package manager [sorry sbt], incremental compiler, LSP-compatible compiler, and so on. All good and nice and completely valid and important things!)
Unfortunately usually corporate backers can deliver these things not language researchers.
There's no need for the tooling and community to keep up. If Scala 2.12 is so good for the community stick with it.
The obvious problem is that Scala 3 delivers features (and whatever Odersky et al. cooks up will likely be useful for a lot of Scala users) that incentivizes attention fragmentation.
Yes, it's true that the community cannot keep up. (Yet the community is not a hivemind, it was able to churn out so many effect libs over the years I lost count.)
But it's an unforced error to put this responsibility on the researchers.
Anyway, squeezing water from stone might be easier than persuading certain folks :)
Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
Tooling and the community just can't keep up and the language is very good already that the focus should be on the ecosystem and not language.
But Scala devs are beyond deaf and that's what you get when a programming language is an ongoing research project on which many students and professors depend.
It's not enough to say "if we stop developing new features the language will die" when there's 0 evidence by it and a huge fatigue towards the relentless development coming from most of the community.