6 ms·

> Another common request is to “stop implementing features”. Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a coupl

> Another common request is to “stop implementing features”. 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.

btreecat 2y ago
The tooling is IMO one of the leading causes of why the language has had a collapse in developer mind-share. 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.
- bishabosha 2y ago
  We have to be more specific about this “tooling” - what are you missing
  - dmos62 2y ago
    Not sure why this is being downvoted. It's hard to do something actionable based on abstract critique.
openplatypus 2y ago
> Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years. Please avoid generalisation. Not "all".
- epolanski 2y ago
  Virtually.
  - vaylian 2y ago
    Implicit
- xboxnolifes 2y ago
  Know it's generalization, you should also know generalizations aren't literal readings.
sideeffffect 2y ago
> > Another common request is to “stop implementing features”. > 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.
bishabosha 2y ago
What do you want from the ecosystem?
- ATMLOTTOBEER 2y ago
  - faster compile times - 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 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
  - sideeffffect 2y ago
    The first five points are fixed by using Mill https://mill-build.org/mill/comparisons/why-mill.html#_performance https://mill-build.org/mill/comparisons/why-mill.html#_perfo...
- KajMagnus 2y ago
  I'd like better debugging of async call stacks. Seems that'll start working better, with Java 21 and virtual threads, so looking forward to that. 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
redcannon218 2y ago
Unfortunately Rust is making the exact same mistake. Edit: It focuses too much on the language instead of the ecosystem.
- pas 2y ago
  Care to elaborate on which changes do you consider a mistake? --------- 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.html#flagship-goals https://rust-lang.github.io/rust-project-goals/2025h1/goals.... [2] https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_for_rust_where_are_we/ https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_fo...
  - redcannon218 2y ago
    Please see my edit
- culi 2y ago
  Rust is younger than Scala. It makes sense for it to still focus on features
  - redcannon218 2y ago
    But Go has proven that the ecosystem is way more important than the language. It's time to shift priorities.
    - sideeffffect 2y ago
      Go has proven that people want cheap threads. If it didn't have it, it wouldn't get anywhere. 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.
pas 2y ago
It's a fundamental misreading of the situation. 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.
- ATMLOTTOBEER 2y ago
  This is a fair characterization. Unfortunately Scala's corporate backing is weak compared to something like Java. So the people in the best position to give us a faster horse are in fact these researchers. :(
  - pas 2y ago
    That might be so, and it's okay to kindly tell them that, but to me it seems the community is pretty abusive regarding the researchers sometimes. (Well, and ... in general, Scala drama was not unheard of over the years, powerful languages tend to attract people with their powerful vision. And of course said researchers' people skills tend to show some room for improvement from time to time.) Anyway, squeezing water from stone might be easier than persuading certain folks :)

btreecat 2y ago

The tooling is IMO one of the leading causes of why the language has had a collapse in developer mind-share. 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.

bishabosha 2y ago
We have to be more specific about this “tooling” - what are you missing
- dmos62 2y ago
  Not sure why this is being downvoted. It's hard to do something actionable based on abstract critique.

openplatypus 2y ago

> Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years. Please avoid generalisation. Not "all".

epolanski 2y ago
Virtually.
- vaylian 2y ago
  Implicit
xboxnolifes 2y ago
Know it's generalization, you should also know generalizations aren't literal readings.

sideeffffect 2y ago

> > Another common request is to “stop implementing features”. > 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.

bishabosha 2y ago

What do you want from the ecosystem?

ATMLOTTOBEER 2y ago
- faster compile times - 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 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
- sideeffffect 2y ago
  The first five points are fixed by using Mill https://mill-build.org/mill/comparisons/why-mill.html#_performance https://mill-build.org/mill/comparisons/why-mill.html#_perfo...
KajMagnus 2y ago
I'd like better debugging of async call stacks. Seems that'll start working better, with Java 21 and virtual threads, so looking forward to that. 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

redcannon218 2y ago

Unfortunately Rust is making the exact same mistake. Edit: It focuses too much on the language instead of the ecosystem.

pas 2y ago
Care to elaborate on which changes do you consider a mistake? --------- 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.html#flagship-goals https://rust-lang.github.io/rust-project-goals/2025h1/goals.... [2] https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_for_rust_where_are_we/ https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_fo...
- redcannon218 2y ago
  Please see my edit
culi 2y ago
Rust is younger than Scala. It makes sense for it to still focus on features
- redcannon218 2y ago
  But Go has proven that the ecosystem is way more important than the language. It's time to shift priorities.
  - sideeffffect 2y ago
    Go has proven that people want cheap threads. If it didn't have it, it wouldn't get anywhere. 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.

pas 2y ago

It's a fundamental misreading of the situation. 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.

ATMLOTTOBEER 2y ago
This is a fair characterization. Unfortunately Scala's corporate backing is weak compared to something like Java. So the people in the best position to give us a faster horse are in fact these researchers. :(
- pas 2y ago
  That might be so, and it's okay to kindly tell them that, but to me it seems the community is pretty abusive regarding the researchers sometimes. (Well, and ... in general, Scala drama was not unheard of over the years, powerful languages tend to attract people with their powerful vision. And of course said researchers' people skills tend to show some room for improvement from time to time.) Anyway, squeezing water from stone might be easier than persuading certain folks :)