Hacker News Reader

Comment by g42gregory | Hacker News Reader

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?

View on HN

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?

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.

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

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

Reply on news.ycombinator.com