Scala 3 is not production ready | Hacker News Reader

Scala 3 is not production ready

gvolpe.com

24 pointsghuntley49 comments

I get being a bit tongue in cheek with a grabby title, but the ending of this post is:

> Although some features are still missing, I absolutely love Scala 3 and promote its usage in production

That's the precise opposite of the message of the title. That's a bit annoying and makes me feel like I'm being hoodwinked.

No one wants to:

a) migrate their production server to a new language for a weak reason

b) learn new syntax when the old one works fine

I am sure Scala 3 is great but I see no reason to learn it. The constant change with Scala with only slight performance improvement doesn’t make me excited. I would rather spent my time learning Rust.

"Constant change" is pretty misleading. This is the language's first major version bump in 16 years since its first public release, and there were few significant changes between 2.10 (2013) and now. I struggle to think of another language that has been that stable; even Java has had more breaking changes (at least in practice) in the same time period.

Still at Clojure 1.x

The Scala ABI is the constant change that broke me. Oh, you want to use 2.13 but your dependency only ships for 2.11 and 2.12? You're happy with 2.11, but your dependency now only ships bugfixes in the 2.12/2.13 libs? Hmm.

Java's ABI is far more stable.

3.0 is backwards compatible with libraries built against 2.13 and they intend to continue that, FWIW.

Okay, that's awesome, thank you for letting me know :)

Python 2 -> 3?

What are you trying to say? Python has had much bigger changes than Scala over the same time period - indeed I'd say that the changes of some Python "minor" updates are comparable to Scala's "major" update.

I am curious whethere there is anything wrong with staying with modern Java? I haven't looked at Java ecosystem for a while, just Python and C++ these days, but I remember they were aggressively putting features out that were making Scala less needed. What is the situation right now?

The problem with seeking employment in "modern Java" is like doing the same for "modern C++", so many teams with Java 8 (or older)/C++98 codebases that drown out the options to do modern work. Plenty of them might advertiser planned/inprogress updates while hiring but then put roadblocks on the way of ever doing them.

What makes Scala great is their language syntax. The ability to do higher kind functions makes it a joy to work with. I program much faster than I would Java. I am also not a big fan of OOP myself. The downside is that it’s slow to compile and it’s no faster than any Java based languages. I am slowly realizing if I want performance, I need to forgo Scala altogether.

Have you tried GraalVM (not native, but as a pluggable JIT compiler)? It has slightly better escape analysis which might help Scala, which tends to create small helper classes. Nonetheless, hotspot and graal and hand-in-hand, but you may find one working better for your particular situation.

Most of the reasons to use Scala still apply. Java has made some improvements but is still a long way behind, e.g. Java "has" "pattern matching" but only a very basic, very restricted form of it, and that's if you're using the latest version. Java "has" "optionals" but limited in a way that makes them useless in practice. Fibers have finally landed, about a decade later than promised, but the ecosystem hasn't even begun to adopt them yet and who knows what edge cases or issues may turn up. The type system has made some limited progress, but writing Java still means chafing under many of the same restrictions that were noticeable 20 years ago.

It's great to see Java finally starting to move again, but frankly if you think "modern Java" is good then you could've had all that for 15+ years with Scala - why do you want to wait 15 more years for the other half of what Scala offers?

> Fibers have finally landed, about a decade later than promised, but the ecosystem hasn't even begun to adopt them yet and who knows what edge cases or issues may turn up.

First, Project Loom was announced in late 2017 [1]. So I don't really understand where you get that decade from? Second, it is available as a preview feature in latest JDK. Why would people adopt a preview feature in their production systems? A lot of frameworks have already added support or as a minimum started working on support for virtual threads. I'm sure all major frameworks will support them once they are out of preview.

[1] https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1....

> First, Project Loom was announced in late 2017 [1]. So I don't really understand where you get that decade from?

I might've been mixing them up with value types. Or I may have been thinking of an earlier effort that was then subsumed into Project Loom.

> Second, it is available as a preview feature in latest JDK. Why would people adopt a preview feature in their production systems?

Exactly my point. If someone is arguing "I don't need Scala's support for lightweight concurrency because modern Java has that" - well, it sort of does, but they're not actually production ready.

> A lot of frameworks have already added support or as a minimum started working on support for virtual threads. I'm sure all major frameworks will support them once they are out of preview.

This is purely speculative, but I think there are going to be a lot of unforseen bugs and edge cases when people start actually using them. So I think it's really important to be clear that they're not in actual production use at the moment.

What makes option useless

Deliberate weird behaviour around nulls. In particular you can't have Some(null), which means you can't really use it to solve the problems it's meant to solve - one of the key motivating examples for why you want optionals is that if Map.get(x) returns null, you don't know if that means there's no mapping for x in the map, or there's an entry with key x and value null. So the idea would be to add Map.safeGet or some such which returns Option<V>, and then if it returns None there's really no mapping, and if it returns Some(null) then there's a mapping with value null. But you can't do that in Java because in the standardisation process they decided they... didn't want to allow it.

I thought it was wrapping successful Java calls that return nulls. Try.toOption caught me off guard with this behaviour

Did you reply to the wrong comment? I'm talking about Java's Optional implementation.

Isn’t that a map of optionals Optional::Empty, optional with value or null ?

Your 3 states

That's a lot more cumbersome to work with, and only possible at all if you're controlling the construction/population of the map rather than getting it back from a library or framework.

This is exactly my sentiment as well. I'm still deeply in the Java ecosystem. It was stagnant for a while, especially between Java 5 and 8 (which spanned multiple years).

But now that it's modern, and it's moving quickly... I see less and less need to use these "better Java" languages.

Interesting. There are tons of great new languages these days, but the sheer mass of existing libraries, documentation, tooling, etc... make it very difficult to break in and gain momentum. I feel that three major languages emerged to dominate (not to be confused with being loved!), at least for now: Python, Java and C/C++/C# block. All for very different use cases. And JavaScript for the browsers, of course.

It got suddenly better. The effect are visible in my last two jobs.

It’s still good old verbose Java. But the entreprise Java insanity is over and other stuff than spring emerge ( Java Lin for instance )

Functional programming is still cumbersome. Having a map of <enum,function> for instance requière some googling and weird syntax.

But it’s possible. Getter/setter are gone. Immutable records replace them.

Next version the thread model gets an update. No more system thread. So spawning them carelessly will be possible ( ala Coroutine in go)

Carpal tunnel syndrome would be one. Still very hard to write expressive code in Java without tones of boilerplate

That somehow neger brought up against Go, which is in fact much more verbose than Java. I recommend trying Java out again if you haven’t been up-to-date, because I think it is more about how we remember it vs how it actually is (but it may not apply to you).

Also, Java IDEs are still the best imo, so I wouldn’t be surprised if in fact you would type less for equivalent Java programs than in case of a much less verbose language sheerly due to the killer autocomplete.

I never said Go is a better language than Java. Go might have a better modern runtime, but the language itself is meh. Wrt to IDE vomit, imho it is still very counterproductive when someone has to read it

I haven't seen any junior roles for Scala in the past 6 years.

Probably wise to switch to Java or Kotlin where there is growth.

Kotlin is where it's at.

With the faster pace for Java now, I wonder if I'm the only one feeling lesser need / lesser incremental benefit of moving to Kotlin.

Yes, some of my fellow engineers like it for the language itself, but I feel these days it's getting harder to argue that "the team using Kotlin is so much more productive than the team using Java".

Curious what HN thinks about this.

What's the story with nullability in Java these days? I used to be a Java dev, and NullPointerExceptions were a thorn in my side.

Kotlin has (real, language-level) non-nullable references, which strikes me as a big improvement.

Even basic intellij suggestions can save you from most instances of NPEs, but you have the option for complete third-party static analysis (with either default to nullable, or default to non-nullable, and then adding @NonNullable or @Nullable annotation, respectively ). These are not standard annotations, but all third party analyzers do in fact understand each other, and they have the stdlib annotated. Oh and debugging story became much better, you get exact property-access instead of only a line number, but that is a JVM-change not java.

If you do some long, chained property accesses (which imo are the primary sources of NPEs) I can only recommend mapstruct. You basically declaratively write what has to be mapped to what and it will generate at compile-time the necessary, performant Java code with proper null-handling, even n level deep.

So my empirical evidence is that NPEs ”million dollar” fallen victim of inflation :D

Thank you -- glad to hear there's been progress!

I think that’s reasonable if you are on a recent JVM version and expect to upgrade very regularly. Many are in organizations where that’s not the case.

The biggest annoyances in Java cannot be fixed for backwards compatibility reasons. It will always allow you to do the wrong thing.

What wrong thing?

Java

Kotlin has always been positioned as a better Java.

But with Java on a faster release schedule the point of Kotlin gets weaker every day.

Scala on the other hand is more and more a true FP language.

Scala is not a true FP language. A true FP language won't let you do imperative stuff.

I guess Haskell is not an FP language then.

s/true/pure/g

If you need to be on the JVM, that seems to be the case. I just wish there was something better than gradle for managing dependencies and building apps in kotlin.

I don’t get the hate for gradle. Sure, one can make some monstrosities with it, but the common case is pretty much just listing your deps, not different to, say cargo.

Yet, when you inevitably have to add something more complex, it will let you do it. Gradle is perhaps one of the most misunderstood technologies, many people believe it is some imperative ant-script, when in fact you have the script write a declarative plan for you, which will be later executed “purely” (much more so than maven for example)

It’s not so much hate, I just don’t think the dependency management story for any of the JVM tools is very good.

I recently did a Kotlin project using Bazel and it wasn't perfect but it was definitely serviceable.

One thing was that while iterating on the build was painful compared to Gradle with Kotlin script it did have very nice performance in combination with remote build cache and I imagine the remote build execution feature could be very nice for large JVM projects.

I don't know if you were being dramatic, but Maven builds kotlin just fine and my experience is that it is a ton more stable over time than "./gradlew ohGawdWhatGradleInternalsAreGoingToDieNow"

I can’t say I love maven either. I haven’t really lived in the JVM for a few years but other ecosystems just have way better tools for building and dependency management.

Not even tangentially related, but I can't help complaining how I hate the dotless syntax in scala.

No, "list map function" is not as readable as "list.map(x => function(x))". Anyway.

Reply on news.ycombinator.com