Apologies in advance for the incendiary comment and to all of those who have investments in the JVM ecosystem. I am sure my comment is myopic in that respect. I just wish Scala would discard the legacy baggage and move on to being the Go that some of us wish Go could have been. Scala 3 is nearly perfect (well as close as we can reasonably expect with the targeted feature set, e.g. type inference is ambiguous with HKT) except for the baggage it can’t overcome because of the JVM.
Btw, I am very, very excited and happy that Scala 3 was brought to fruition. And the Scala.Js output target enables me to ignore the dreaded JVM. And thank the coding Gods you all enabled block indenting to replace the noisy curly braces. The one major syntactical feature from my wish list that is missing would be the optional ability to extract verbose type signatures from the embedded declaration and write it off to the right-hand side to get that noise out of the way.
After a multi-year hiatus, I am coming back to the Scala ecosystem because of Scala 3. Well done to all involved. My gratitude.
I understand this comment will be flagged because the Scala community does not believe in free speech even when someone has been extra cautious in wording their comment so as to be respectful of everyone. So in that case just be aware that crypto billionaires can fork the turd if they decide to.
I don’t think this comment should be flagged, but I do think you’re off-base.
I mean, yes – there are times when I wish erasure wasn’t a problem. But keep in mind, it isn’t just a pure environment wart: there are environments that don’t have erasure, which wind up with different issues. And erasure isn’t that hard to work around, if you’re following standard Scala idiom.
Other than that, what’s the problem? The JVM provides access to a colossal and mature ecosystem, that most of us leverage every single day. It’s generally a massive net positive.
You don’t say what your actual beef is, so it’s hard to have a rational conversation about it…
So, I think it’s worth realigning here. This really comes down to a question of priorities.
Scala is an intensely pragmatic language, which was never really intended to live on its own – from the outset, an extremely high priority has been placed on good interoperability. That was true originally for the JVM, and was doubled down on for JS: in both cases, it is strikingly easy to work with “native” libraries.
These issues you’re talking about largely arise from that. It’s possible to write a language that works differently, but it’s challenging to achieve the same sort of deep and easy interoperability that way. (Not necessarily impossible, but it’s a steep hill to climb.)
Basically, you’re asking for a more standalone language. That’s not a terrible thing, but it would be a language with very different priorities, that makes different decisions. It isn’t clear to me that there is a compelling use case for that level of effort, especially given that there are lots of good such languages out there.
What good language out there with the essential higher-kinded-types, implicits (for type classes) and anonymous union types? There is none. Not even Haskell and Haskell has the entire type system inverted to think like a mathematician which doesn’t grok for us who want to program the way we did in Basic, C, Python, etc… I am entirely sold on type classes and I don’t want to go back to OOP.
Btw, I think I was the one of the first who pushed for the anonymous union types in Scala.
Thanks I did check out Scala Native (which has apparently gone no where in the years hence and not surprisingly so) and maybe I have forgotten the details but didn‘t seem like it was headed in the necessary direction. I would need to dive back in to enumerate the details. That is if anyone is interested.
Scala Native is amazing with its easy-to-use C/C++ interop and LLVM backend and fast GC. It has evolved greatly and now supports Scala 3 as well. I think Scala Native has great potential as it approaches production grade.
AFAIK, this was already discussed before. I think the blocking issue was the impossibility to combine opaque types with inline method (to fully erase overhead). Maybe we should put it on the table again since this limitation was fixed in 3.0.1+