However, it's sad to see it's growth is likely to be capped - because JVM languages is not that fashionable like 2003 or 2007. What's in nowadays is Go and Rust: bear metal, small binary, fast startup speed, solid module packaging system (without all historical stuff or touching Maven), etc.
Even though Scala Native is there, the language was tailored for JVM and it will never get rid of that.
Maybe a ground-up Scala-like language like Go or Rust could fill in the market and gain popularity? A language with GC/runtime like Go but not as awkward on abstrations. But it's unlikely to happen - the compiler would be much harder and complex to implement compared to Go.
I feel the same when I have to code in Scala instead of Haskell, because the former has to be used for third-party JARs from enterprise vendors that pretend that there only are JVM and .NET.
After the newstyle Cabal, Sbt feels like a bunch of dynamic nonsense too, especially if there's classpath-based runtime-delayed dependency resolution.
I also find that documentation feels more lacking, simply because I cannot easily find third-party libraries and standard definitions by their signatures in my browser address bar, like I can in Haskell with Hoogle: "!h f a -> f b".
Also, Rusts typesystem is lacking many of Scala's features and I don't think it's realistic to add them retrospectively.
Slow progress and change is good.
I think he would do well just calming down a little bit. He has some good critique, yes, but it's overblown in my opinion. I don't think the future of scala is as "uncertain" as he thinks.
I also think the scala community is fabulous, it full of great, smart people who work together. Just because there's heavy disagreements here and there, mostly just with a couple individuals, isn't necessarily a bad thing anyways, nor does it necessarily reflect the community as a whole.
Scala will never attract the mainstream, because its principals take too long to learn. There is nothing wrong with this, though. It's a language for long-time programmers who are interested in becoming super effecient.
Scala is awesome, and I'm excited for its future. Will it live 100 years, no, probably not, but there's nothing better in the next 10, 20 years.
He talks about SBT, but never mentions Gradle which is a massive and powerful tool that handles Scala just fine. When I worked at BigCorp that made heavy use of Scala no one used SBT. Everyone used Gradle.
A lot of the IDE based complaints the author has would be eliminated if they used Gradle. Now I know Gradle has its own issues, but saying IDE support is missing entirely just because it’s not available with your tool of choice seems incorrect to me. In fact it seems crazy to me that the author has the concepts “build tool” and “JVM” together in an article and proceeds to go about writing hundreds of words without even mentioning Gradle.
He also doesn’t discuss the current issues around Play Framework being essentially abandoned by Lightbend. Play is the most robust and de facto leading framework to build web apps in Scala. There is also akka-http, but it’s nowhere near as mature and has the same issue as Play framework does of being Akka based. I think he does bring up some serious legitimate concerns about the ecosystem now that Lightbend has gated usage of Akka. Akka had a ton of momentum before that.
From the article:
> The looming threat of a future radically different Scala 4 is the single greatest existential threat to Scala.
I think what prompted John to write this article is that there’s a huge commercial penalty in releasing a new major version of the language, and we should be focussing on making the existing language version(s) more commercially viable before we start another academically-led reinvention
> I believe that the time for action has come > In the ashes of Scala 2 and the Lightbend OSS ecosystem, we need a rebirth for Scala.
Then he gives all sorts of horrible grades that in my opinion aren't justified when compared to any other language. Make small things seem huge.
It also has some other nice features that F# lacks. But F# also has some nice things that Scala lacks. Overall I think it's worth to learn it for learning new concepts, but F# is already great, so don't expect Scala to be way ahead and even worse in some ways (syntax, no type providers, ...)
Metals is great if a bit buggy. Being able to just install a VSCode plugin and start hacking is huge. If you want to win new programmer mind share, improving Metals (or some other VSCode language server) is the way. Scalafmt is nice to see coming from Java.
The build tooling situation is awkward. Mill looks much more modern than sbt but clearly isn't the de facto choice. The general community displease about sbt further adds to the unease. The main take away here should be the onboarding experience to the build ecosystem does not instill confidence.
The difference between ZIO/Typelevel stuff is not immediately clear. Why are there two functional programming ecosystems? I guess it's a convention vs configuration debate? It seems like the two ecosystems should overlap then, but fair enough.
A single language level package repo would be cool for discoverability purposes, but I'm also used to the multi-repository thing. A directory or something to make packages more discoverable might be a good half-step.
Ammonite is fantastic, but along with Metals and all the other tooling I've used, it works better under Scala 2. Scala 3 is still kind of weird.
The biggest things to me would improve Metals, improve onboarding for build system, improve Scala 3 support for tooling all around, improve discoverability of defacto best/most active packages.
Reading the politics in Scala was a guilty pleasure of mine.
I think these two discussions should give a clear enough picture.
https://www.reddit.com/r/scala/comments/9a11p1/newbie_wonder...
https://www.reddit.com/r/scala/comments/qweo20/a_statement_a...
I invested a lot of effort in implementing systems using Typelevel libraries (which are great, by the way), but I feel increasingly nervous about wedding myself to this side of the ecosystem.
I attended the Functional Scala conference in December (organized by De Goes and friends). It was invigorating and demonstrated that there’s momentum, professionalism and a warm community in the ZIO side of the ecosystem.
They never contend with being better at using the existing platform, rather try to create an ecosystem of their own on top of the platform.
Idiomatic libraries to wrap existing ones, new IDE plugins, new build tooling, new package managers, introduce language features that only go one way, ....
Eventually they decide that targeting just that platform isn't enough so they go multi-platform, adding more design compromises to their abstraction layer for all platforms.
Meanwhile, the languages that are designed alongside the platform, evolve alongside it, no need for the added complexity, and eventually decisions are made that introduce forks in the road compared to the introduction of the guest language that create issues with those features.
Using the platform languages might not be hip, yet as long as the platform matters, they will matter, the guest languages, who knows.
It's not hard to imagine that he's signalling here that his community will attempt to implement its own version of some fundamental platform libraries or systems.
Fwiw, I've been a scala dev for years and I think his analysis of what works and what doesn't in the ecosystem is quite accurate.
Since then the ringleader of this cancel culture has been exposed for what he is - an aggressive and politically motivated stalker who built tools for forensically analyzing people’s social media history and associations, shared lists of targets, lengthy public character assassinations, doxxing etc. As a measure of his extreme views, even paulg was included in his ‘hate speech graph’
Sadly this stalker also managed to coordinate the complete cancellation of at least one other prominent member of the Scala community before the community realized what was going on.
There are extreme personalities in the Scala world. As a language, it attracts mathematical purists with deep specialism. This makes it a magnet for aspies (no offense intended. I am autistic).
It’s not a common language like Java, but I don’t mind that. It attracts smart developers who value the benefits of Scala over Java.
The Scala ecosystem has great libraries and platforms. It also gets the benefit of the entire Java ecosystem and the battle-hardened JVM.
Compile times got better but are still slower and can be quite annoying. Hope it will be improved further.
Let me go through some of the points of this excellent write-up.
> However, Java has a very simple type system that is static and well-defined. Scala’s type system is extremely complex and defined only by the implementation, which itself has numerous quirks, edge cases, and of course bugs. Moreover, the semantics, quirks, edge cases, and bugs all vary somewhat between minor versions of the Scala compiler, and are completely different between major versions.
This is a very good summary of why Scala is not a good fit for tool support.
> Perhaps their next-generation editor Fleet is an acknowledgement both of the fact that JVM desktop applications are truly dead
The author probably doesn't know that Fleet is also built upon the JVM!
> The truth is Fleet is built on a reliable, performant and wonderful platform called the JVM.
https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...
> In short, there are no IDEs for Scala right now with a modern experience suitable for commercial software development, nor any obvious path to a commercial-grade IDE.
Even the best Scala IDE (IntelliJ IDEA) is poor and nothing better is to be expected in the next years. This is basically the point where you could cross out Scala from your short list of programming languages!
Akka, once the most prominent Scala framework, is essentially doomed since the company behind it decided to switch to "Business Source License".
> Thus, every company I have talked to about Akka has told me they are ripping it all out.
The former killer application of the Scala ecosystem no longer drags any new developers into it.
ZIO as a potential Akka (and Spring) alternative is stil not mature, so probably not the reason to switch to Scala.
> It is virtually impossible for Java or Kotlin code to call into Scala code. [...] Scala’s support for newer versions of Java, as well as new JDK or JVM features, lags behind. When the JVM gets value objects, for example, it is quite likely Scala support will severely lag; or as another example, the Scala compiler itself has been known to crash on modern JVMs.
I'd say that Scala is not a good citizen in the Java world. This is problematic in existing code bases. Kotlin is a much better fit there.
Scala Native (LLVM) and Scala.js or WASM are far from production ready yet. One major problem is missing tool support and I can not imagine any responsible software engineer would pick it as the basis for a new critical product. If anything else than the JVM is needed as a runtime, you should probably use somete other language, maybe Rust or Go (or Kotlin?).
> It is absolutely true that Scala 3 is not a perfect language. It is also true that Java is not a perfect language. Yet Java remains backward compatible with the very first Java program ever written, which allows the ecosystem to continuously improve, and which gives companies confidence in investing in the Java programming language.
That is absolutely the core of the "Resurrection". The Scala community was too long focussed on the language itself ignoring all other aspects like tooling and existing code bases. Maybe this is no surprise if you look at Scala's history, but it is a big problem in practice. The best language is worth nothing if everything else is poor compared to the competition (be it Java, Kotlin, Go, Rust or whatever ...). Essentially Scala is the Haskell of the JVM, but the Haskell community decided early on that academics is their focus and that it should stay that way. However, Haskell is therefore a niche language in commercial projects. The Scala community should really make a bold decision for one of the sides, but it should no longer wander between the two camps.
As the author writes, Scala need completely new tooling: a new IDE, a new build tool replacing the horrible SBT, and a new package manager. But who should build it in a sensible time? Who should invest money?
> Does Scala really need 20 JSON libraries, 5 schema libraries, 9 CLI libraries, 4 effect system libraries, and so on? Probably not. We need to consolidate, and rally around strong projects; merge our strengths, cancel our weaknesses.
This assumption is simply not realistic. What was the original motivation to create those libraries? Has anything fundamentally changed? It is not like in a big corporation where you would should down one of two competing projects (like Microsoft did with Atom in favor of VS Code). Just look at the Linux desktops ...
"Worse is better." (https://en.wikipedia.org/wiki/Worse_is_better) seems to apply to Scala very well. Go, which is probably on the other end of the spectrum of programming languages in expressiveness and the type system, is probably a much better bet for most companies. Java is also quite good these days and in any case "good enough" for almost all commercial projects (as long as technical constraints don't require something without a VM). Kotlin is somewhere between Scala and Java, highly productive with world class tooling and a healthy ecosystem. I can not really see in what niche Scala could exist.
So, as sad as it might be, I think Scala has no bright future.
What do you mean? I use Community version of Idea for Scala3 and syntax highlighting, refactorings, jumping to definitions, javadocs, usage points, sbt integration, and build targets are all working as expected. The only thing that I noticed as issues are module reloads: sometimes a tab has to be re-opened for the inference engine to notice changes, but that's not a deal-breaker when it comes to IDE experience to me. What else do you need from it?
> I'd say that Scala is not a good citizen in the Java world. This is problematic in existing code bases. Kotlin is a much better fit there.
The current version of Kotlin is lagging behind Java 19 features like improved pattern matching. Why would anyone bet on Kotlin if there's a mix of modern Java+Vavr[1] and Scala3 to be had instead?
The problem with Java/Scala interop is that you can hardly use idiomatic Scala code from Java, while this no issue with Kotlin.
You're right about patter matching. It is sad that Kotlin doesn't have more to offer. But Kotlin has some nice things not present in Java like named parameters with default values, (limited) reified generics, proper covariance / contra variance, extension methods, first-class functions and what not.
