12 ms·

Scala 3 Migration: Report from the field

159 points by AzzieElbab 2y ago

philipkglass 2y ago
This is a good report. I started a project last year on Scala 2.13, but had all Scala 3 compatibility features/warnings enabled from the beginning. It sounds like it should be an easy upgrade in the future as long as I don't rely on macros or libraries that rely on macros. I've tried to stick to libraries that already have Scala 3 releases or that come from plain Java.
- noelwelsh 2y ago
  It doesn't matter if libraries rely on macros because 1) you only depend on their compiled output and 2) you can use Scala 2.13 code from Scala 3. That said, the vast majority of the open source ecosystem has Scala 3 releases by now.
- rendaw 2y ago
  Is it recommended to start with Scala 2 instead of 3 right now?
cbeach 2y ago
Very useful document, thanks Pierre! Our company is still on 2.13 and probably will be for a long time. The reality is that we need rock-solid library support across all transitive dependencies, and mature battle-tested tooling. I like that the Scala language continues to improve, but its appeal in real-world enterprise applications took a hammering due to the backwards-incompatible changes in Scala 3, shaky tooling and ecosystem issues. Also the elephant in the room - the Scala Center and toxicity within the Scala community. The Scala Center Executive Director is a political sciences graduate with no commercial Scala experience, who gave this expletive-laden sexualised rant at a Scala conference: https://x.com/jdegoes/status/1633888998434193411?s=46&t=V_LFasefQl-Q0BteAGBqDg https://x.com/jdegoes/status/1633888998434193411?s=46&t=V_LF... When this ugly performance was called out by a member of the Scala ecosystem, it was the guy that called it out that got brigaded and cancelled, while the executive director Darja Jovanovic was defended by the community, and remains in place. And then there's Scala Center Community Representative Zainab Ali, who led an orchestrated witch hunt against a contributor to the Scala ecosystem. She ended up in the UK High Court for her role in this, and admitted fault (defamation) and settled. https://pretty.direct/statement https://pretty.direct/statement Like the executive director, the community rep remains in place at Scala Center: https://www.scala-lang.org/ambassadors/ https://www.scala-lang.org/ambassadors/
- paulddraper 2y ago
  Most of the Scala ecosystem exists outside of the Scala Center. Same with Rust, Go, and any other language.
- michaelmrose 2y ago
  The rant was "whoever it is I challenge that person to grow some fucking male anatomy and come and speak to me ... you little female anatomy plural you are just fucked up" Fairly shocking language but also pretty devoid of context although I come to suspect it has to do with people talking behind her back regarding the second part. The second case appears to be a fellow who was publicly libeled professionally ruined and then sued the shit out of the offender. According to him this was solely because he had dumped community rep. In the settlement they admitted that they had circulated the letter claiming he was a serial sexual harasser based on no evidence but unverified claims. Settled for a rather paltry sum of £5000. So community rep and contributor split for whatever reasons and then she shit talks him spreading possibly true likely untrue claims that he's a particular type of jerk which she likely can't back up with anything like evidence other than her own now terminated relationship. If they didn't fire her they probably believe that she was in the right but settled. No part of this probably belonged as part of professional life and should have stayed between them. I don't believe enough evidence exists for people who don't know either party to declare anyone a villain and if I had any professional involvement with either I would simply pretend none of that existed and move on. If I was merely using the code I would definitely ignore it.
  - tsss 2y ago
    This sort of behaviour is so pervasive among certain influential circles, which makes it hard to ignore. Thankfully, the conflict seems to have died down a bit in the last 2 years and I'm looking forward to changes in Scala 3 that make the libraries that those people develop mostly superfluous.
- pie_flavor 2y ago
  Organizational political drama is just about the least relevant thing possible to whether you update from Scala 2 to Scala 3. The ultimate fate of Jon Pretty does not impact the behavior of macro annotations.
paulddraper 2y ago
I didn't know the ecosystem wasn't on 3. It was released May 2021. It is a big change though.
- AlexITC 2y ago
  Most of the ecosystem is on Scala 3, I think Spark would be the biggest piece pending to upgrade.
  - aeroevan 2y ago
    With spark 4 defaulting to scala 2.13, that does move things in the right direction since the 2.13 -> 3 interop is possible
dylanowen 2y ago
This is a great write up! For people using gradle to compile scala (definitely not my first choice) the initial hurdle to migrating individual modules has been fixed! I'm guessing it'll be in gradle 8.13 https://github.com/gradle/gradle/pull/31118 https://github.com/gradle/gradle/pull/31118
dtech 2y ago
I left the Scala ecosystems (mostly) a year or 4 ago, right around the release of Scala 3. It's a shame that the compatibility and tooling situation doesn't seem to have improved much since then. The Scala devs always said they wanted to avoid a Python 2->3 situation, but it seemed like they didn't quite achieve that.
- dkarl 2y ago
  I think you should read this report. They made heavy use of many advanced features of Scala 2. Few codebases look like this (and very, very few need to) yet they were able to do it. Moreover, they didn't need to do it. What makes it similar to the Python 2 -> 3 situation is the lack of urgency to migrate, because nobody suffers for not migrating. That's a good thing.
  - merb 2y ago
    Most people used advanced features, even if they were hidden behind libraries. Even if you’ve just had a codebase which only used playframework.
    - noelwelsh 2y ago
      If they are in libraries it doesn't matter, because you can use Scala 2.13 code in Scala 3.
    - AlexITC 2y ago
      It definitely took a while for most libraries to catch-up with Scala 3, now, I don't see anything is missing in the main area I work with (web development), playframework already works for Scala 3.
    - jodersky 2y ago
      The article mentions they used an experimental language feature, which is enabled via a special compilation flag and came with a big warning from the start that it was in fact experimental and could be removed any time. I highly doubt that most people use any libraries that use those. As a side note, I've personally had the experience of migrating several projects to Scala3 (when it was still called Dotty), and never had any issues with 3rd party dependencies, since Scala 3 is binary-backwards compatible with Scala 2.13
slavomirvojacek 2y ago
I am wondering whether with GenAI, migrations like this one will be less and less painful, and therefore more people will be able to migrate to newer technologies/versions sooner and quicker.
- aiono 2y ago
  Why use GenAI for this use case? Instead you can write transformers from one syntax to another syntax that will not hallucinate and work correctly every time. The conversion is well-defined.
  - nsonha 2y ago
    Or use GenAI to write the codemod :)
lopatin 2y ago
I only allow myself to use Scala these days if follow some rules: no sbt (just Maven) and no Scala libraries (just Java ones). I never used fancy stuff like Cats anyways. Curious to hear who actually does, and for what.
- threeseed 2y ago
  I use ZIO (https://zio.dev https://zio.dev) and nothing really like it exists on any platform. You can wrap any computation in a single ZIO object e.g. normal, callback, future, promise etc. Which you can then chain together in different ways e.g. run them in parallel, sequentially, race them against each other and kill the loser, schedule in elaborate ways, run with a timeout and then run another if it’s exceeded etc. And it will execute this either using normal or virtual threads i.e. fibers without locks so it’s extremely fast. But the incredible part is that it does all of this whilst seamlessly handling every type of error. Which if you’ve ever written complex concurrent code is extremely hard to get right.
  - pas 2y ago
    EffectTS? :)
    - senorrib 2y ago
      Not even close.
  - KajMagnus 2y ago
    Now I feel curious about what do you build that makes that much use of parallel computations, races and killing the loser, etc?
- AlexITC 2y ago
  sbt is way better than what it used to be, also, check-out scala-cli which is very nice.
- jim-jim-jim 2y ago
  This thread is interesting; so many tools and libraries referenced that I am not familiar with at all. I think some of us are writing very different languages. I've used Scala my entire career at multiple companies, and Typelevel has been the default at all of them. I'm not even entirely sure where Scala ends and Cats begins, so it's hard to identify what's "fancy", let alone justify it. I do like IO, and monad transformers. I think neither of those are native. Flat code tends to be maintainable. From my perspective, fully baked frameworks and ORMs are what's "fancy" (a readability nightmare). I don't know if it's a cultural thing, but Scala codebases that go hard on FP tend not to introduce these, which I appreciate. Pick your poison I guess.
theLiminator 2y ago
Back when I used to use Scala, the biggest PITA was how every minor version bump you'd run into binary version incompatibilities that you'd only run into at runtime. Has that situation changed? I've always felt that Scala the language was always pretty nice, but Scala the ecosystem/tooling was moderately painful to work with. It was getting better over time, but they lost all the momentum they had.
- philipkglass 2y ago
  Yes, that's one of the big improvements in Scala 3. https://docs.scala-lang.org/overviews/core/binary-compatibility-of-scala-releases.html#guarantees-and-versioning https://docs.scala-lang.org/overviews/core/binary-compatibil... For Scala 3, the minor version is the second number in a version, e.g., 2 in v3.2.1. The third number is the patch version. The major version is always 3. Scala 3 guarantees both backward and forward compatibility across patch releases within a single minor release (enforcing forward binary compatibility is helpful to maintain source compatibility). In particular, this applies within an entire Long-Term-Support (LTS) series such as Scala 3.3.x. Scala 3 also guarantees backward compatibility across minor releases in the entire 3.x series, but not forward compatibility. This means that libraries compiled with any Scala 3.x version can be used in projects compiled with any Scala 3.y version with y >= x. In addition, Scala 3.x provides backward binary compatibility with respect to Scala 2.13.y. Libraries compiled with Scala 2.13.y can be used in projects using Scala 3.x. This policy does not apply to experimental Scala 2 features, which notably includes macros.
- dionian 2y ago
  yes, and you can even use 2.13 binaries in 3
- jeremyjh 2y ago
  It still seems bizarre to me that the Java ecosystem relies upon code-sharing through precompiled binary packages. Compared to for example Rust or Elixir where you only download source and build it locally so that everything is built with the same compiler and environment. This makes it absolutely trivial to debug your dependencies and even fork them when necessary. Most Java programmers wouldn't ever dream of doing that.
virtualwhys 2y ago
Migrated a Scala 2.8(!) era codebase to Scala 3. As OP explains, macros and abstract type projections tend to be the biggest pain points in complex applications; otherwise, with Scala Rewrite tool it's pretty straightforward. I think it's more inertia than anything else that more Scala 2 companies don't migrate. Unpopular opinion, but setting a Scala 2 sunset time would spur companies into action :) As it stands Akka (previously Lightbend, previously TypeSafe) is the maintainer of Scala 2, and derives part of its revenue from Scala 2 support contracts so there's even less incentive to migrate when there's no EOL date as Python 2 (eventually) had.
- hocuspocus 2y ago
  While a bit late to the party, Akka on Scala 3 is perfectly viable nowadays, and they have a couple employees contributing to Scala 3. The bigger issue comes from Databricks being the biggest Scala Center sponsor while holding the entire ecosystem back, for instance with their managed Spark runtime still on 2.12.
- rat87 2y ago
  As someone who has done a couple of python 2 to python 3 migrations I'm still surprised that there isn't someone big selling support/security patches for python2. There must be a lot of giant corporate python2 code bases that were a lot harder to port and where it was much less acceptable to find random 2to3 bug I'm production then the QA and build system codebases I ported
codr7 2y ago
That's how I learned to do migrations/major refactoring from my mentors back in the days. First brute force it, observe but don't panic, until you don't get any further. Then start over and do it properly.
- foretop_yardarm 2y ago
  This idea was also more or less explained in the book "The Mikado Method". https://www.manning.com/books/the-mikado-method https://www.manning.com/books/the-mikado-method
caterama 2y ago
Scala used to be my hobby / enthusiast language. Introduced to it through a college course, and used a bit through school. Later, I would use it for Advent of Code, tinkered with a Scala Play webapp, and dream about using it professionally. Rust has almost completely filled that void now. Rust is native, I'm not waiting on the 1.0 release of `scala-native` anymore. The community around Rust seems to be enthusiastic and growing, as opposed to languishing for Scala. I hold some reservations about Rust in terms of how complicated it is. Despite having used it for an amount of time that I would be feeling comfortable in most languages, I am still not comfortable and continually encounter _stuff I don't understand_. RIP Scala, I will miss you! You showed me the joy of pattern matching, functional OO, currying, how to use `map` `flatMap` `fold`, etc. All things with continued influence! <3
- threeseed 2y ago
  I have been writing Scala and Rust everyday for the last few years. I actually don’t see the two overlapping all that much. Rust is a terrible backend language compared to Scala/JVM. When you are dealing with real world concurrency i.e. error/thread management Rust’s memory management model becomes unusably complex very quickly. And the entire ecosystem lacks maturity i.e. the majority of libraries I use are not at version 1. Whereas from Scala you can just use any Java library e.g. Vertx, Spring almost all of which have commercial, enterprise support and continue to be proven time and time again. It almost always just works. Rust’s strength is in desktop apps e.g. Tauri and low-level programming.
  - packetlost 2y ago
    > When you are dealing with real world concurrency i.e. error/thread management Rust’s memory management model becomes unusably complex very quickly I've seen this several times, but having built several highly concurrent applications in Rust, I just don't agree. Building a concurrent Rust application the wrong way is certainly complex, but if you know how Rust's strong opinions on how to structure an application work, it's downright pleasant. Except async. Rust's async story still sucks and should be avoided as much as possible.
whoodle 2y ago
I currently work at a company who is primarily writing in Scala. I really like Scala but assume my next role won’t be in that. Are my two best options Rust and Java if I want to keep some of the typing, functional style, and pattern matching while also moving to a more popular language?
- lyall 2y ago
  Kotlin is gaining steam in the Java world. We're moving to make it our default server-side language at my company instead of Java. Given its great Java interop, you can basically think of it as a modern, more functional Java that doesn't have multiple decades of baggage associated with it. I highly recommend considering it in any place you'd consider Java.
  - spockz 2y ago
    Now that Java has caught up a lot with records, value classes, project loom (virtual/green threads), pattern matching. What is left? Scala has the better type system with union types and effects (a more generic way of having “throws”.) Kotlin has a nicer way of dealing with optional values with the ? operator. What’s left is the syntax. Or am I missing something? These alone do not seem to justify moving an organisation.
    - imtringued 2y ago
      Java still sucks. Where are Java properties, so people can stop writing the silly getter setter nonsense? Where are default parameters and named parameter calls? Where is the null friendly field access operator ?. ? Where is the convenient list and hashmap literal syntax? Why is the stream API so verbose? Why not offer a third generation collections API? Where are the sane ORMs? Now here is some JVM hate: How do I make sure that my application starts up quickly and isn't slow the first time you're accessing a web page after a restart? How do I make sure that I don't need a 2GB RAM server for a simple web app? Cloud providers are stingy with RAM, so this adds up, even though RAM costs are an insignificant part of overall server costs. How do I write a CLI app with the JVM? You don't. So yeah, Java is in this uncanny valley where it is either obsoleted language wise by JVM languages from 2009 and runtime obsoleted by languages like Rust, where you trade off a bit of convenience, which Java by the way does not have either, for a bit of performance.
rr808 2y ago
Currently work on a Scala/Spark project as part of our work. Everyone hates it except the one guy who knows it well, but for most people who spend most of their time doing imperative languages its just too much of a mind jump. Hopefully soon we'll be on a new big data platform soon and we wont have to deal with a migration like this.
spockz 2y ago
As I mentioned deeper in the thread, https://news.ycombinator.com/item?id=42969519 https://news.ycombinator.com/item?id=42969519, Java seems to have caught up with Kotlin and Scala language wise. (With Scala3 having the most extensive type system.) The ecosystem also seems to have petered out. Akka, spark, and flink used to be reasons to do scala. But they have decent java interfaces now. I’ve had too much struggles convincing colleagues that actually more information in the type is convenient. It seems like the same religion of untyped vs typed. What is left as reasons to choose for scala or Kotlin?
- dtech 2y ago
  I think you're over-selling the parity. Value based classes aren't definable by your own code yet. Records are severely underbaked, unless I missed it there isn't even a copy method yet, and those are essential for working with immutable data. Then there's still a lot of features that Java is sorely lacking like extension methods, named parameters and delegation, even though they have proven themselves in multiple other programming languages by now.
fulafel 2y ago
It will be interesting to see how Clojure and Scala do in the longer run in the industry oriented FP languages scene. I wonder if there's any data points around that could tell a tale.
danielciocirlan 2y ago
This is a good report. Scala 3 is really what Scala was supposed to be. The language is just about perfect, and the most important and popular libraries and tools (Cats/Cats Effect, ZIO, Play Framework, Akka/Apache Pekko) are all supporting the new version for years already. It's really a shame that IDE support has yet to catch up and the dev experience is frustrating at times, but I'm using Scala 3 for everything I can.
- KajMagnus 2y ago
  > The language is just about perfect Yes totally lovely :- ) And the best std lib? (On shared 1st place I'd guess, Rust looks nice too) I just miss better debugging of async code, so I could see the execution context in other threads earlier in the "async call stack".
- Bgd1 2y ago
  Totally agree. I'm surprised that the new scala-cli is almost not mentioned at all in other comments. To me this is a game changer and the best in class. I don't think I've seen anything that comes close to its power and ease of use in other programming language SDKs.
aristofun 2y ago
Scala has some nice and cool vibes and features to it. But that is where good parts end. From the POV of real world boots-on-theground software challenges and developers it is a poorly designed, overengineered and overrated piece of complexity. Complexity disconnected from reality of software engineering as a tool to serve business needs. I can explain why this happens but I don’t want to get downvotes. People hate hearing bitter truth:)

159 points by AzzieElbab 2y ago

This is a good report. I started a project last year on Scala 2.13, but had all Scala 3 compatibility features/warnings enabled from the beginning. It sounds like it should be an easy upgrade in the future as long as I don't rely on macros or libraries that rely on macros. I've tried to stick to libraries that already have Scala 3 releases or that come from plain Java.

noelwelsh 2y ago
It doesn't matter if libraries rely on macros because 1) you only depend on their compiled output and 2) you can use Scala 2.13 code from Scala 3. That said, the vast majority of the open source ecosystem has Scala 3 releases by now.
rendaw 2y ago
Is it recommended to start with Scala 2 instead of 3 right now?

cbeach 2y ago

Very useful document, thanks Pierre! Our company is still on 2.13 and probably will be for a long time. The reality is that we need rock-solid library support across all transitive dependencies, and mature battle-tested tooling. I like that the Scala language continues to improve, but its appeal in real-world enterprise applications took a hammering due to the backwards-incompatible changes in Scala 3, shaky tooling and ecosystem issues. Also the elephant in the room - the Scala Center and toxicity within the Scala community. The Scala Center Executive Director is a political sciences graduate with no commercial Scala experience, who gave this expletive-laden sexualised rant at a Scala conference: https://x.com/jdegoes/status/1633888998434193411?s=46&t=V_LFasefQl-Q0BteAGBqDg https://x.com/jdegoes/status/1633888998434193411?s=46&t=V_LF... When this ugly performance was called out by a member of the Scala ecosystem, it was the guy that called it out that got brigaded and cancelled, while the executive director Darja Jovanovic was defended by the community, and remains in place. And then there's Scala Center Community Representative Zainab Ali, who led an orchestrated witch hunt against a contributor to the Scala ecosystem. She ended up in the UK High Court for her role in this, and admitted fault (defamation) and settled. https://pretty.direct/statement https://pretty.direct/statement Like the executive director, the community rep remains in place at Scala Center: https://www.scala-lang.org/ambassadors/ https://www.scala-lang.org/ambassadors/

paulddraper 2y ago
Most of the Scala ecosystem exists outside of the Scala Center. Same with Rust, Go, and any other language.
michaelmrose 2y ago
The rant was "whoever it is I challenge that person to grow some fucking male anatomy and come and speak to me ... you little female anatomy plural you are just fucked up" Fairly shocking language but also pretty devoid of context although I come to suspect it has to do with people talking behind her back regarding the second part. The second case appears to be a fellow who was publicly libeled professionally ruined and then sued the shit out of the offender. According to him this was solely because he had dumped community rep. In the settlement they admitted that they had circulated the letter claiming he was a serial sexual harasser based on no evidence but unverified claims. Settled for a rather paltry sum of £5000. So community rep and contributor split for whatever reasons and then she shit talks him spreading possibly true likely untrue claims that he's a particular type of jerk which she likely can't back up with anything like evidence other than her own now terminated relationship. If they didn't fire her they probably believe that she was in the right but settled. No part of this probably belonged as part of professional life and should have stayed between them. I don't believe enough evidence exists for people who don't know either party to declare anyone a villain and if I had any professional involvement with either I would simply pretend none of that existed and move on. If I was merely using the code I would definitely ignore it.
- tsss 2y ago
  This sort of behaviour is so pervasive among certain influential circles, which makes it hard to ignore. Thankfully, the conflict seems to have died down a bit in the last 2 years and I'm looking forward to changes in Scala 3 that make the libraries that those people develop mostly superfluous.
pie_flavor 2y ago
Organizational political drama is just about the least relevant thing possible to whether you update from Scala 2 to Scala 3. The ultimate fate of Jon Pretty does not impact the behavior of macro annotations.

paulddraper 2y ago

I didn't know the ecosystem wasn't on 3. It was released May 2021. It is a big change though.

AlexITC 2y ago
Most of the ecosystem is on Scala 3, I think Spark would be the biggest piece pending to upgrade.
- aeroevan 2y ago
  With spark 4 defaulting to scala 2.13, that does move things in the right direction since the 2.13 -> 3 interop is possible

dylanowen 2y ago

This is a great write up! For people using gradle to compile scala (definitely not my first choice) the initial hurdle to migrating individual modules has been fixed! I'm guessing it'll be in gradle 8.13 https://github.com/gradle/gradle/pull/31118 https://github.com/gradle/gradle/pull/31118

dtech 2y ago

I left the Scala ecosystems (mostly) a year or 4 ago, right around the release of Scala 3. It's a shame that the compatibility and tooling situation doesn't seem to have improved much since then. The Scala devs always said they wanted to avoid a Python 2->3 situation, but it seemed like they didn't quite achieve that.

dkarl 2y ago
I think you should read this report. They made heavy use of many advanced features of Scala 2. Few codebases look like this (and very, very few need to) yet they were able to do it. Moreover, they didn't need to do it. What makes it similar to the Python 2 -> 3 situation is the lack of urgency to migrate, because nobody suffers for not migrating. That's a good thing.
- merb 2y ago
  Most people used advanced features, even if they were hidden behind libraries. Even if you’ve just had a codebase which only used playframework.
  - noelwelsh 2y ago
    If they are in libraries it doesn't matter, because you can use Scala 2.13 code in Scala 3.
  - AlexITC 2y ago
    It definitely took a while for most libraries to catch-up with Scala 3, now, I don't see anything is missing in the main area I work with (web development), playframework already works for Scala 3.
  - jodersky 2y ago
    The article mentions they used an experimental language feature, which is enabled via a special compilation flag and came with a big warning from the start that it was in fact experimental and could be removed any time. I highly doubt that most people use any libraries that use those. As a side note, I've personally had the experience of migrating several projects to Scala3 (when it was still called Dotty), and never had any issues with 3rd party dependencies, since Scala 3 is binary-backwards compatible with Scala 2.13

slavomirvojacek 2y ago

I am wondering whether with GenAI, migrations like this one will be less and less painful, and therefore more people will be able to migrate to newer technologies/versions sooner and quicker.

aiono 2y ago
Why use GenAI for this use case? Instead you can write transformers from one syntax to another syntax that will not hallucinate and work correctly every time. The conversion is well-defined.
- nsonha 2y ago
  Or use GenAI to write the codemod :)

lopatin 2y ago

I only allow myself to use Scala these days if follow some rules: no sbt (just Maven) and no Scala libraries (just Java ones). I never used fancy stuff like Cats anyways. Curious to hear who actually does, and for what.

threeseed 2y ago
I use ZIO (https://zio.dev https://zio.dev) and nothing really like it exists on any platform. You can wrap any computation in a single ZIO object e.g. normal, callback, future, promise etc. Which you can then chain together in different ways e.g. run them in parallel, sequentially, race them against each other and kill the loser, schedule in elaborate ways, run with a timeout and then run another if it’s exceeded etc. And it will execute this either using normal or virtual threads i.e. fibers without locks so it’s extremely fast. But the incredible part is that it does all of this whilst seamlessly handling every type of error. Which if you’ve ever written complex concurrent code is extremely hard to get right.
- pas 2y ago
  EffectTS? :)
  - senorrib 2y ago
    Not even close.
- KajMagnus 2y ago
  Now I feel curious about what do you build that makes that much use of parallel computations, races and killing the loser, etc?
AlexITC 2y ago
sbt is way better than what it used to be, also, check-out scala-cli which is very nice.
jim-jim-jim 2y ago
This thread is interesting; so many tools and libraries referenced that I am not familiar with at all. I think some of us are writing very different languages. I've used Scala my entire career at multiple companies, and Typelevel has been the default at all of them. I'm not even entirely sure where Scala ends and Cats begins, so it's hard to identify what's "fancy", let alone justify it. I do like IO, and monad transformers. I think neither of those are native. Flat code tends to be maintainable. From my perspective, fully baked frameworks and ORMs are what's "fancy" (a readability nightmare). I don't know if it's a cultural thing, but Scala codebases that go hard on FP tend not to introduce these, which I appreciate. Pick your poison I guess.

theLiminator 2y ago

Back when I used to use Scala, the biggest PITA was how every minor version bump you'd run into binary version incompatibilities that you'd only run into at runtime. Has that situation changed? I've always felt that Scala the language was always pretty nice, but Scala the ecosystem/tooling was moderately painful to work with. It was getting better over time, but they lost all the momentum they had.

philipkglass 2y ago
Yes, that's one of the big improvements in Scala 3. https://docs.scala-lang.org/overviews/core/binary-compatibility-of-scala-releases.html#guarantees-and-versioning https://docs.scala-lang.org/overviews/core/binary-compatibil... For Scala 3, the minor version is the second number in a version, e.g., 2 in v3.2.1. The third number is the patch version. The major version is always 3. Scala 3 guarantees both backward and forward compatibility across patch releases within a single minor release (enforcing forward binary compatibility is helpful to maintain source compatibility). In particular, this applies within an entire Long-Term-Support (LTS) series such as Scala 3.3.x. Scala 3 also guarantees backward compatibility across minor releases in the entire 3.x series, but not forward compatibility. This means that libraries compiled with any Scala 3.x version can be used in projects compiled with any Scala 3.y version with y >= x. In addition, Scala 3.x provides backward binary compatibility with respect to Scala 2.13.y. Libraries compiled with Scala 2.13.y can be used in projects using Scala 3.x. This policy does not apply to experimental Scala 2 features, which notably includes macros.
dionian 2y ago
yes, and you can even use 2.13 binaries in 3
jeremyjh 2y ago
It still seems bizarre to me that the Java ecosystem relies upon code-sharing through precompiled binary packages. Compared to for example Rust or Elixir where you only download source and build it locally so that everything is built with the same compiler and environment. This makes it absolutely trivial to debug your dependencies and even fork them when necessary. Most Java programmers wouldn't ever dream of doing that.

virtualwhys 2y ago

Migrated a Scala 2.8(!) era codebase to Scala 3. As OP explains, macros and abstract type projections tend to be the biggest pain points in complex applications; otherwise, with Scala Rewrite tool it's pretty straightforward. I think it's more inertia than anything else that more Scala 2 companies don't migrate. Unpopular opinion, but setting a Scala 2 sunset time would spur companies into action :) As it stands Akka (previously Lightbend, previously TypeSafe) is the maintainer of Scala 2, and derives part of its revenue from Scala 2 support contracts so there's even less incentive to migrate when there's no EOL date as Python 2 (eventually) had.

hocuspocus 2y ago
While a bit late to the party, Akka on Scala 3 is perfectly viable nowadays, and they have a couple employees contributing to Scala 3. The bigger issue comes from Databricks being the biggest Scala Center sponsor while holding the entire ecosystem back, for instance with their managed Spark runtime still on 2.12.
rat87 2y ago
As someone who has done a couple of python 2 to python 3 migrations I'm still surprised that there isn't someone big selling support/security patches for python2. There must be a lot of giant corporate python2 code bases that were a lot harder to port and where it was much less acceptable to find random 2to3 bug I'm production then the QA and build system codebases I ported

codr7 2y ago

That's how I learned to do migrations/major refactoring from my mentors back in the days. First brute force it, observe but don't panic, until you don't get any further. Then start over and do it properly.

foretop_yardarm 2y ago
This idea was also more or less explained in the book "The Mikado Method". https://www.manning.com/books/the-mikado-method https://www.manning.com/books/the-mikado-method

caterama 2y ago

Scala used to be my hobby / enthusiast language. Introduced to it through a college course, and used a bit through school. Later, I would use it for Advent of Code, tinkered with a Scala Play webapp, and dream about using it professionally. Rust has almost completely filled that void now. Rust is native, I'm not waiting on the 1.0 release of `scala-native` anymore. The community around Rust seems to be enthusiastic and growing, as opposed to languishing for Scala. I hold some reservations about Rust in terms of how complicated it is. Despite having used it for an amount of time that I would be feeling comfortable in most languages, I am still not comfortable and continually encounter _stuff I don't understand_. RIP Scala, I will miss you! You showed me the joy of pattern matching, functional OO, currying, how to use `map` `flatMap` `fold`, etc. All things with continued influence! <3

threeseed 2y ago
I have been writing Scala and Rust everyday for the last few years. I actually don’t see the two overlapping all that much. Rust is a terrible backend language compared to Scala/JVM. When you are dealing with real world concurrency i.e. error/thread management Rust’s memory management model becomes unusably complex very quickly. And the entire ecosystem lacks maturity i.e. the majority of libraries I use are not at version 1. Whereas from Scala you can just use any Java library e.g. Vertx, Spring almost all of which have commercial, enterprise support and continue to be proven time and time again. It almost always just works. Rust’s strength is in desktop apps e.g. Tauri and low-level programming.
- packetlost 2y ago
  > When you are dealing with real world concurrency i.e. error/thread management Rust’s memory management model becomes unusably complex very quickly I've seen this several times, but having built several highly concurrent applications in Rust, I just don't agree. Building a concurrent Rust application the wrong way is certainly complex, but if you know how Rust's strong opinions on how to structure an application work, it's downright pleasant. Except async. Rust's async story still sucks and should be avoided as much as possible.

whoodle 2y ago

I currently work at a company who is primarily writing in Scala. I really like Scala but assume my next role won’t be in that. Are my two best options Rust and Java if I want to keep some of the typing, functional style, and pattern matching while also moving to a more popular language?

lyall 2y ago
Kotlin is gaining steam in the Java world. We're moving to make it our default server-side language at my company instead of Java. Given its great Java interop, you can basically think of it as a modern, more functional Java that doesn't have multiple decades of baggage associated with it. I highly recommend considering it in any place you'd consider Java.
- spockz 2y ago
  Now that Java has caught up a lot with records, value classes, project loom (virtual/green threads), pattern matching. What is left? Scala has the better type system with union types and effects (a more generic way of having “throws”.) Kotlin has a nicer way of dealing with optional values with the ? operator. What’s left is the syntax. Or am I missing something? These alone do not seem to justify moving an organisation.
  - imtringued 2y ago
    Java still sucks. Where are Java properties, so people can stop writing the silly getter setter nonsense? Where are default parameters and named parameter calls? Where is the null friendly field access operator ?. ? Where is the convenient list and hashmap literal syntax? Why is the stream API so verbose? Why not offer a third generation collections API? Where are the sane ORMs? Now here is some JVM hate: How do I make sure that my application starts up quickly and isn't slow the first time you're accessing a web page after a restart? How do I make sure that I don't need a 2GB RAM server for a simple web app? Cloud providers are stingy with RAM, so this adds up, even though RAM costs are an insignificant part of overall server costs. How do I write a CLI app with the JVM? You don't. So yeah, Java is in this uncanny valley where it is either obsoleted language wise by JVM languages from 2009 and runtime obsoleted by languages like Rust, where you trade off a bit of convenience, which Java by the way does not have either, for a bit of performance.

rr808 2y ago

Currently work on a Scala/Spark project as part of our work. Everyone hates it except the one guy who knows it well, but for most people who spend most of their time doing imperative languages its just too much of a mind jump. Hopefully soon we'll be on a new big data platform soon and we wont have to deal with a migration like this.

spockz 2y ago

As I mentioned deeper in the thread, https://news.ycombinator.com/item?id=42969519 https://news.ycombinator.com/item?id=42969519, Java seems to have caught up with Kotlin and Scala language wise. (With Scala3 having the most extensive type system.) The ecosystem also seems to have petered out. Akka, spark, and flink used to be reasons to do scala. But they have decent java interfaces now. I’ve had too much struggles convincing colleagues that actually more information in the type is convenient. It seems like the same religion of untyped vs typed. What is left as reasons to choose for scala or Kotlin?

dtech 2y ago
I think you're over-selling the parity. Value based classes aren't definable by your own code yet. Records are severely underbaked, unless I missed it there isn't even a copy method yet, and those are essential for working with immutable data. Then there's still a lot of features that Java is sorely lacking like extension methods, named parameters and delegation, even though they have proven themselves in multiple other programming languages by now.

fulafel 2y ago

It will be interesting to see how Clojure and Scala do in the longer run in the industry oriented FP languages scene. I wonder if there's any data points around that could tell a tale.

danielciocirlan 2y ago

This is a good report. Scala 3 is really what Scala was supposed to be. The language is just about perfect, and the most important and popular libraries and tools (Cats/Cats Effect, ZIO, Play Framework, Akka/Apache Pekko) are all supporting the new version for years already. It's really a shame that IDE support has yet to catch up and the dev experience is frustrating at times, but I'm using Scala 3 for everything I can.

KajMagnus 2y ago
> The language is just about perfect Yes totally lovely :- ) And the best std lib? (On shared 1st place I'd guess, Rust looks nice too) I just miss better debugging of async code, so I could see the execution context in other threads earlier in the "async call stack".
Bgd1 2y ago
Totally agree. I'm surprised that the new scala-cli is almost not mentioned at all in other comments. To me this is a game changer and the best in class. I don't think I've seen anything that comes close to its power and ease of use in other programming language SDKs.

aristofun 2y ago

Scala has some nice and cool vibes and features to it. But that is where good parts end. From the POV of real world boots-on-theground software challenges and developers it is a poorly designed, overengineered and overrated piece of complexity. Complexity disconnected from reality of software engineering as a tool to serve business needs. I can explain why this happens but I don’t want to get downvotes. People hate hearing bitter truth:)