4 ms·

I don’t disagree on the summary of your post. Especially for refactoring, types can be great. But it is funny you chose the creator of Scala as the example. Th

I don’t disagree on the summary of your post. Especially for refactoring, types can be great. But it is funny you chose the creator of Scala as the example. The gold plated banana cables of typing. The entire language and its endless lang mailing list discussions is a meme by now.

threeseed 3y ago
To be fair the new languages like Rust, Swift, Kotlin etc have all borrowed heavily from Scala in their design. So clearly it is resonating. And his upcoming research work could be game changing. The benefits of Rust's concurrency safety without the annoying borrow checker.
noelwelsh 3y ago
That's not it. The issues Scala had were: 1. A whole lot of programmers who didn't know how to use the language effectively in 2010. Less of an issue now the patterns are well established and industry wide the level of knowledge has increased (even Java has algebraic data types now) 2. Some idiots in the community, who have now left 3. Some rough edge cases in the Scala 2 type system; fixed in Scala 3
- pkolaczk 3y ago
  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.
  - ackfoobar 3y ago
    6. Both the pure FP and better Java crowds think they use the language "idiomatically".
eloisant 3y ago
On the contrary, the power of Scala types means you are less likely to get in a case where the compiler blocks you despite your code being safe. See the example of the article, where you don't have covariance in Go and the compiler fails. Same in Java where you have to cast (and add unsafety) to make the compiler accept your code. In Scala when using immutable structure (the default) you have covariance and the compiler will happily let you call a function that takes a List[A] with a List[B] if B extends A. Now that's true that you can do overly complex things with Scala types, but you don't have to.

threeseed 3y ago

To be fair the new languages like Rust, Swift, Kotlin etc have all borrowed heavily from Scala in their design. So clearly it is resonating. And his upcoming research work could be game changing. The benefits of Rust's concurrency safety without the annoying borrow checker.

noelwelsh 3y ago

That's not it. The issues Scala had were: 1. A whole lot of programmers who didn't know how to use the language effectively in 2010. Less of an issue now the patterns are well established and industry wide the level of knowledge has increased (even Java has algebraic data types now) 2. Some idiots in the community, who have now left 3. Some rough edge cases in the Scala 2 type system; fixed in Scala 3

pkolaczk 3y ago
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.
- ackfoobar 3y ago
  6. Both the pure FP and better Java crowds think they use the language "idiomatically".

eloisant 3y ago

On the contrary, the power of Scala types means you are less likely to get in a case where the compiler blocks you despite your code being safe. See the example of the article, where you don't have covariance in Go and the compiler fails. Same in Java where you have to cast (and add unsafety) to make the compiler accept your code. In Scala when using immutable structure (the default) you have covariance and the compiler will happily let you call a function that takes a List[A] with a List[B] if B extends A. Now that's true that you can do overly complex things with Scala types, but you don't have to.