4 ms·

4. Ignoring the fact that not only language but also tooling is a significant factor affecting developer experience. Extremely long compile times, weird build s

4. Ignoring the fact that not only language but also tooling is a significant factor affecting developer experience. Extremely long compile times, weird build system, lack of good IDE support. 5. Breaking backwards compatibility with each release. This is something that businesses care a lot about.

realusername 3y ago
Also the learning curve isn't great for new developers in my opinion, lots of uncommon concepts and built-in keywords which aren't googleable. This is a big issue for a language which isn't too popular since learning it is expected.
kaba0 3y ago
4. There is Mill now, which is very great (and also not scala-specific) 5. AFAIK it is also solved with Scala3 with a binary compatible format.
lmm 3y ago
> 5. Breaking backwards compatibility with each release. This is something that businesses care a lot about. This is a myth. Scala has had one significant compatibility break in 10+ years. Not even Java beats that. Meanwhile the likes of Python really do break compatibility every release, and businesses continue to use them.
- fl0ki 3y ago
  I think people forget just how bad compatibility was a decade ago. The compiler promised no ABI compatibility even between minor versions, which on its own could have been fine; Go and Rust don't promise ABI compatibility either. The problem was that people still used maven and sbt for dependency management, which used binary dependencies, not source like Go and Rust. So to get a Scala project going with several dependencies, you needed all of them to agree on a specific Scala compiler version and publish JARs built against it. If even one dependency lagged behind (and many often did), you couldn't update the compiler version for your project, locking you out of new versions of every Scala library you use. This led to the ironic situation that it was easier to use Java JARs from Scala than to use Scala JARs. If the ecosystem had used source dependencies instead of binary dependencies, this could have been avoided, even if compile times may have been horrendous. Rust walks this tightrope steadily enough these days, and Go even makes it look easy. Finally, even though the language didn't meaningfully break compatibility until Scala 3, the ecosystem as a whole did not respect backwards compatibility. For an example I'm sure many people here will remember viscerally, Lift Web kept making substantial backwards-incompatible changes regularly even after they knew they had commercial users who faced real-world costs for churn. Even the most foundational things like how to bind template elements to variables changed completely. Adding further insult, the documentation was not nearly up to the standard that would make migration productive even for those who could afford the churn. I loved Scala but these factors burned me hard. It remains to be seen how Rust libraries will compare, but Go libraries have already proven backwards compatible to a fault, and both build dependencies from source so ABI is not an issue. I do however appreciate that Scala taught me that a beautiful language is not enough, real world usage requires responsible commitments from projects to users. It sounds like they've learned this, but a decade too late.
  - lmm 3y ago
    > I think people forget just how bad compatibility was a decade ago. I think you're forgetting how long ago the issues were. It was pretty bad in the 2.7-2.9 days, but a decade ago was already into the 2.10 era. > This led to the ironic situation that it was easier to use Java JARs from Scala than to use Scala JARs. If the ecosystem had used source dependencies instead of binary dependencies, this could have been avoided, even if compile times may have been horrendous. I don't think that would've been worth it. Binary dependencies work great given that libraries cross-build; the real issue was back when source compatibility was broken often enough that that wasn't practical. > For an example I'm sure many people here will remember viscerally, Lift Web kept making substantial backwards-incompatible changes regularly even after they knew they had commercial users who faced real-world costs for churn. I don't think there'll be many remembering that. Lift was big, what, 15 years ago? It was already fading by the time I started Scala back in 2011.
    - fl0ki 3y ago
      That's just the thing, Scala and its ecosystem had these problems right at the height of its popularity, meaning that the situation was the worst right when the most people were around to experience it, and understandably many never looked back. Even if many individuals can look past it, it's become a very hard sell to teams. It's the same story with any kind of merit vs trust. When you have a clean slate, you can build trust based on your merit, but once you break trust, merit alone isn't enough to win it back. In this industry in particular, far too many other options are already holding and building trust. I truly wish Scala had indeed become the mainstream industry language instead of say Go. I hope Rust polishes off its rough edges and succeeds where Scala failed and where Go doesn't go far enough. But I don't see any future where Scala regains industry relevance, not even if both Go and Rust self-destruct as well.
      - lmm 3y ago
        Meh. OCaml spent over a decade underappreciated, fixed a few sticking points like package management, and then underwent a resurgence. I'd like to think that merit will ultimately win through.
- pkolaczk 3y ago
  No, I meant binary compatibility. Upgrading to a newer version always required recompiling all dependencies. One dependency didn't get an update and you were essentially locked on the old version. Some projects took years to upgrade from 2.11 to 2.12 and then 2.12 to 2.13 e.g Spark. This was a real pain for us. Source compatibility based model would be ok if Java/Scala build systems worked like Cargo/Go/Npm and compiled dependencies from sources. However, that would make compile times orders of magnitude worse, and they were already unacceptable without it. I remember our project that had about 30k lines of Scala and 300k lines of Java took about 7-12 minutes to build from scratch (and the biggest contributor of compile time was scala). And we didn't even use advanced and slow stuff like macros or typelevel programming. I remember we were seriously looking into stuff like keeping the compiler in memory between the runs (thanks Bloop) and that made it much better although it came with it's own set of new problems. Comparably on the same (now outdated) hardware Rustc is able to compile 500k lines of all dependencies in about 28 seconds (including linking).
  - lmm 3y ago
    > One dependency didn't get an update and you were essentially locked on the old version. Some projects took years to upgrade from 2.11 to 2.12 and then 2.12 to 2.13 e.g Spark. This was a real pain for us. Spark is a special case though - it really was just Spark, and you can't really compare that to something like Rust where as far as I know there's no equivalent. Everything else that was maintained at all put out cross-builds very quickly once the changes between versions got to be small.
ackfoobar 3y ago
6. Both the pure FP and better Java crowds think they use the language "idiomatically".

realusername 3y ago

Also the learning curve isn't great for new developers in my opinion, lots of uncommon concepts and built-in keywords which aren't googleable. This is a big issue for a language which isn't too popular since learning it is expected.

kaba0 3y ago

4. There is Mill now, which is very great (and also not scala-specific) 5. AFAIK it is also solved with Scala3 with a binary compatible format.

lmm 3y ago

> 5. Breaking backwards compatibility with each release. This is something that businesses care a lot about. This is a myth. Scala has had one significant compatibility break in 10+ years. Not even Java beats that. Meanwhile the likes of Python really do break compatibility every release, and businesses continue to use them.

fl0ki 3y ago
I think people forget just how bad compatibility was a decade ago. The compiler promised no ABI compatibility even between minor versions, which on its own could have been fine; Go and Rust don't promise ABI compatibility either. The problem was that people still used maven and sbt for dependency management, which used binary dependencies, not source like Go and Rust. So to get a Scala project going with several dependencies, you needed all of them to agree on a specific Scala compiler version and publish JARs built against it. If even one dependency lagged behind (and many often did), you couldn't update the compiler version for your project, locking you out of new versions of every Scala library you use. This led to the ironic situation that it was easier to use Java JARs from Scala than to use Scala JARs. If the ecosystem had used source dependencies instead of binary dependencies, this could have been avoided, even if compile times may have been horrendous. Rust walks this tightrope steadily enough these days, and Go even makes it look easy. Finally, even though the language didn't meaningfully break compatibility until Scala 3, the ecosystem as a whole did not respect backwards compatibility. For an example I'm sure many people here will remember viscerally, Lift Web kept making substantial backwards-incompatible changes regularly even after they knew they had commercial users who faced real-world costs for churn. Even the most foundational things like how to bind template elements to variables changed completely. Adding further insult, the documentation was not nearly up to the standard that would make migration productive even for those who could afford the churn. I loved Scala but these factors burned me hard. It remains to be seen how Rust libraries will compare, but Go libraries have already proven backwards compatible to a fault, and both build dependencies from source so ABI is not an issue. I do however appreciate that Scala taught me that a beautiful language is not enough, real world usage requires responsible commitments from projects to users. It sounds like they've learned this, but a decade too late.
- lmm 3y ago
  > I think people forget just how bad compatibility was a decade ago. I think you're forgetting how long ago the issues were. It was pretty bad in the 2.7-2.9 days, but a decade ago was already into the 2.10 era. > This led to the ironic situation that it was easier to use Java JARs from Scala than to use Scala JARs. If the ecosystem had used source dependencies instead of binary dependencies, this could have been avoided, even if compile times may have been horrendous. I don't think that would've been worth it. Binary dependencies work great given that libraries cross-build; the real issue was back when source compatibility was broken often enough that that wasn't practical. > For an example I'm sure many people here will remember viscerally, Lift Web kept making substantial backwards-incompatible changes regularly even after they knew they had commercial users who faced real-world costs for churn. I don't think there'll be many remembering that. Lift was big, what, 15 years ago? It was already fading by the time I started Scala back in 2011.
  - fl0ki 3y ago
    That's just the thing, Scala and its ecosystem had these problems right at the height of its popularity, meaning that the situation was the worst right when the most people were around to experience it, and understandably many never looked back. Even if many individuals can look past it, it's become a very hard sell to teams. It's the same story with any kind of merit vs trust. When you have a clean slate, you can build trust based on your merit, but once you break trust, merit alone isn't enough to win it back. In this industry in particular, far too many other options are already holding and building trust. I truly wish Scala had indeed become the mainstream industry language instead of say Go. I hope Rust polishes off its rough edges and succeeds where Scala failed and where Go doesn't go far enough. But I don't see any future where Scala regains industry relevance, not even if both Go and Rust self-destruct as well.
    - lmm 3y ago
      Meh. OCaml spent over a decade underappreciated, fixed a few sticking points like package management, and then underwent a resurgence. I'd like to think that merit will ultimately win through.
pkolaczk 3y ago
No, I meant binary compatibility. Upgrading to a newer version always required recompiling all dependencies. One dependency didn't get an update and you were essentially locked on the old version. Some projects took years to upgrade from 2.11 to 2.12 and then 2.12 to 2.13 e.g Spark. This was a real pain for us. Source compatibility based model would be ok if Java/Scala build systems worked like Cargo/Go/Npm and compiled dependencies from sources. However, that would make compile times orders of magnitude worse, and they were already unacceptable without it. I remember our project that had about 30k lines of Scala and 300k lines of Java took about 7-12 minutes to build from scratch (and the biggest contributor of compile time was scala). And we didn't even use advanced and slow stuff like macros or typelevel programming. I remember we were seriously looking into stuff like keeping the compiler in memory between the runs (thanks Bloop) and that made it much better although it came with it's own set of new problems. Comparably on the same (now outdated) hardware Rustc is able to compile 500k lines of all dependencies in about 28 seconds (including linking).
- lmm 3y ago
  > One dependency didn't get an update and you were essentially locked on the old version. Some projects took years to upgrade from 2.11 to 2.12 and then 2.12 to 2.13 e.g Spark. This was a real pain for us. Spark is a special case though - it really was just Spark, and you can't really compare that to something like Rust where as far as I know there's no equivalent. Everything else that was maintained at all put out cross-builds very quickly once the changes between versions got to be small.

ackfoobar 3y ago

6. Both the pure FP and better Java crowds think they use the language "idiomatically".