4 ms·

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 see

by 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
- foolfoolz 2y ago
  i was surprised to see such advanced type features. i worked at a large scala company. we wouldn’t let most of this stuff through code review. it generally is the kind of magic that saves a tiny amount of code at a high cost of complexity. sounds like this was the authors pet project and wanted to explore instead of write maintainable code
kokada 2y ago
I don't know, if anything the Scala situation seems much worse than the Python situation. The language looks completely different and there is no easy migration path (not that Python had one, but at least the language was almost the same and you could with some effort write code that worked in both versions). We are in Scala 2.13 and while there are talks about migrating there is no actual plan. Looking at this blog post the situation seems to be more dire than I initially expected. I think we will only end up migrating when the situation becomes unsustainable (libraries stop supporting Scala 2).
- adamwk 2y ago
  Odersky forcing through major syntax changes for Scala 3 was such an unforced error. It's baffling add new syntax on top of major semantic changes to the type system.
  - Pet_Ant 2y ago
    But did it provide a gain in power and soundness? There issues with the 2.x system.
    - merb 2y ago
      Most programming languages have unsound features.
    - lmm 2y ago
      It did, which makes it all the more frustrating that you can't adopt it separately from the syntax and tooling changes.
      - Taikonerd 2y ago
        But the new syntax is optional, right? So you could upgrade and keep the old syntax? (I'm not a Scala dev, so this is just my impression.)
        2y ago
AlexITC 2y ago
While the tooling isn't perfect, it has improved considerably over the last years, I remember when IntelliJ couldn't deal with Scala 3 but now, it rarely complains. Related to Python 2->3, I don't see how Scala 2->3 compares, there are clear migration guides + tools to help re-writing to switch between the new/old syntax, I have done many migrations and I have used these tools since the time when Scala 3 was launched (I admit that I reverted a migration at that time).

by dtech 2y ago

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
foolfoolz 2y ago
i was surprised to see such advanced type features. i worked at a large scala company. we wouldn’t let most of this stuff through code review. it generally is the kind of magic that saves a tiny amount of code at a high cost of complexity. sounds like this was the authors pet project and wanted to explore instead of write maintainable code

kokada 2y ago

I don't know, if anything the Scala situation seems much worse than the Python situation. The language looks completely different and there is no easy migration path (not that Python had one, but at least the language was almost the same and you could with some effort write code that worked in both versions). We are in Scala 2.13 and while there are talks about migrating there is no actual plan. Looking at this blog post the situation seems to be more dire than I initially expected. I think we will only end up migrating when the situation becomes unsustainable (libraries stop supporting Scala 2).

adamwk 2y ago
Odersky forcing through major syntax changes for Scala 3 was such an unforced error. It's baffling add new syntax on top of major semantic changes to the type system.
- Pet_Ant 2y ago
  But did it provide a gain in power and soundness? There issues with the 2.x system.
  - merb 2y ago
    Most programming languages have unsound features.
  - lmm 2y ago
    It did, which makes it all the more frustrating that you can't adopt it separately from the syntax and tooling changes.
    - Taikonerd 2y ago
      But the new syntax is optional, right? So you could upgrade and keep the old syntax? (I'm not a Scala dev, so this is just my impression.)
      - 2y ago

AlexITC 2y ago

While the tooling isn't perfect, it has improved considerably over the last years, I remember when IntelliJ couldn't deal with Scala 3 but now, it rarely complains. Related to Python 2->3, I don't see how Scala 2->3 compares, there are clear migration guides + tools to help re-writing to switch between the new/old syntax, I have done many migrations and I have used these tools since the time when Scala 3 was launched (I admit that I reverted a migration at that time).