Scala Resurrection | Hacker News Reader

Scala Resurrection

degoes.net

50 pointsnmat46 comments

Scala is a great language. Any time I'm programming in other statically typed languages it's like programming but with my hands tied backward: bumping into things and realizing there's no HKT, Type Class, GADT etc.

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.

How do you get over the lack of type inference in Scala?

Scala has type inference [1]

[1] https://docs.scala-lang.org/tour/type-inference.html

Scala's type inference is not very good, especially in comparison with Haskell

Yeah it works whenever you yourself can infer the type without it already.

> Any time I'm programming in other statically typed languages it's like programming but with my hands tied backward

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".

Maybe Rust is close enough to this ideal imaginary Scala-like language. I'm not a Rust expert, but I really like how Rust combines power with a certain minimalism (not in the Go sense, though). There are, for example, no classes with inheritance in Rust, but traits, whereas Scala has traits an all the Java OOP heritage. Another thing is error handling that is handled with return types in Rust, where Scala has also exceptions from the JVM. Same is true for null, what probably shouldn't exist in any modern functional language. Rust doesn't have it while Scala needs it.

Rust has no GC and, unlike Scala, doesn't embrace full immutability. This is of course fine, because it focuses on performance, but it means a very different development experience.

Also, Rusts typesystem is lacking many of Scala's features and I don't think it's realistic to add them retrospectively.

To be honest, I think he is way-overly critical. It would seem like he thinks there needs to be some sudden changes or something. Scala is great today - there is nothing better (for experienced programmers) in my opinion (at least when it comes to backend development), and it's on a great path and trajectory.

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.

Would you recommend someone currently using F# to try out Scala?

Scala is both more functional than F# (type system has more features) and less functional (more emphasis on OOP). I don’t think it’s a net improvement tbh. Better JVM access is nice though.

Why would OOP and functional programming be at opposite ends of a spectrum?

Minimising state vs hiding state behind interfaces / methods

The two can coexist in one code base but they are fundamentally opposed.

A common joke in my previous org that heavily used Scala with functional paradigms is that an engineer’s first few PR’s were often implemented in “Scava” since Scala lets you lean into OO paradigms. It kind of means that there are two (or more) “right” ways to do things in Scala which IMO is a detriment to the language. This is where other languages like Python got it right by introducing the concept of “Pythonic”. You can do weird stuff, but it won’t be accepted into the zeitgeist that was defined by the benevolent dictator.

They aren't diametrically opposed, though OO methods obscure function composition (point-free style).

A good example would be [1], where covariance and contra-variance are offered to you by the language due to its relation to OOP and the need for subtyping for it, whereas you'd probably be better off if you forgot about their existence (most of the times) and designed everything with Invariance and higher-kinded data [2].

[1] https://docs.scala-lang.org/tour/variances.html

[2] https://reasonablypolymorphic.com/blog/higher-kinded-data/

I don't have any experience with F#, so it's hard for me to say, but I love Scala. I think JVM is the best probably and could be worth your effort hard to say

F# does not really support pure functional programming in the sense that Scala does, so yeah. Use Scala ZIO and you will see what I mean.

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, ...)

Scala is also an FP language that places emphasis on types, but it does so in a way very different from F#, which is still based on Hindley–Milner. I think Scala is worth checking out for a different perspective.

He’s actually arguing against sudden changes.

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

Good point, but he also seems to be arguing that the language has significant problems and needs fundamental change, which I don't agree with. For example, he says:

> 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.

Over 9 years of Scala here. Scala definitely has quite a few warts.

I don't see anything better, or even close

I also agree that the author is overly critical. He also misses a couple of points.

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.

I've just recently tried to pick up Scala, by going through the excellent Hands-on Programming with Scala so I can provide a newcomer's perspective.

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.

Sadly, given the behaviour of Typelevel as an organization (leftwing political activism, targeting rivals with cancellation etc), it seems vital that there’s an alternative.

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.

The difference between monofunctor and bifunctor is definitely clear.

> Why are there two functional programming ecosystems?

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'm not sure if I'm enjoying this, but there's certainly a lot of passionate content out there!

This is the curse of all guest languages, regardless of the platform.

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.

Yet more context. DeGoes was targeted for "cancellation" by members of certain scala communities. His response has been to, with impressive success, create his own community with its own implementations of common libraries.

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.

It was obvious to some of us that De Goes was targeted for political reasons, in a nasty example of cancel culture coordinated by one of John’s OSS competitors within the Scala ecosystem.

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).

Well, I think Scala is a nice niche language but with a lot of problems. I like it but the tooling sucks and it is slow to compile. Compared to other ecosystems like Java or Kotlin there are still things to be improved if this resurrection is to take place. We'll see.

I’ve worked in mainstream companies e.g. Morgan Stanley who have made massive investments in Scala. The company I work at now ($5bn valuation) is 100% Scala.

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.

The Java ecosystem is hardly a benefit

I worked at a Scala shop briefly back in 2010-2011. Slow compiles and bad tooling did not begin to describe it. I had hoped things would be better now, but I haven't touched it since.

Things are 100% better. It compiles in speeds comparable to my golang shop now.

Just upgraded to the latest 2.x compiler and it’s definitely leagues slower to compile than javac.

Scala is way different now and tooling is honestly great, unless you compare it with Java tooling (which is best in class).

Compile times got better but are still slower and can be quite annoying. Hope it will be improved further.

Damn, that guy is ripped. If that's what Scala does to you, I'm all in.

Every time I write a syntax error in Scala, I do one push up.

For anyone unaware John is an extremely polarizing figure in the Scala community. So much so I'd attribute Scala's negative light partially to him.

That’s a matter of opinion. The attempts to smear John (by association) seemed desperate to me, and now we know where they originated, it’s pretty obvious that this was a vexatious attack on a decent man.

I was a big fan of the Scala language some years ago and really like the improvements made in Scala 3. But I lost my confidence in Scala and the article is more a confirmation of this assessment than something that would give me hope that I would return to this powerful and beautiful language in the future.

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.

> 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!

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?

[1] https://docs.vavr.io/

The point to tooling was based on the original authors assessments. My own experiences are a bit dated, but I had problems with valid Scala code that wasn't understood by IntelliJ. The reason was probably that this IDE relies on its own analysis and not on the official compiler and nothing has changed in this regard. But I'm happy to hear that you are satisfied so far.

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.

Reply on news.ycombinator.com