Hacker News new | ask | show | jobs
by nadavwr 1457 days ago
The "better Java" niche was hot during Java's stagnation era (starting 2006 and lasting for almost a decade). The JVM was considered a great runtime, with a stagnant language, and lots of newer languages competed in that niche.

Scala and Clojure, and later Kotlin and others benefited greatly from that niche. The problem for the "better Java" niche was that Java never had to be the best JVM language in order to beat its JVM-based competition in the market. When Java started moving again (Java 8 introduced anonymous functions) and when the release cadence accelerated to every 6 months on 2017, the "Java is stagnant" justification for using other JVM languages lost a lot of traction.

Clojure was never really a "better Java" -- it's a JVM-based Lisp with good Java interop. Scala never leaned too much on the "better Java" niche, and the community is increasingly consolidated around FP. Kotlin still has some "better Java" ambitions, but they also have the Android community at their back. Without Android you would have seen Kotlin trying harder to differentiate itself from Java (EDIT: Google and Kotlin tied the knot in 2017, when Java moved to 6-month release cycle; probably not a coincidence).

Fairly young languages can still see rapid growth -- see Go (1.0 in 2012) and Rust (1.0 in 2015). But you are much less likely to see new languages trying to go head-to-head with Java on the JVM these days.

2 comments

There is also the matter that between Clojure (a Lisp), Scala (an ML/FP/fraken-language), Kotlin (multi-paradigm/"modern syntax") there isn't a lot of space for new JVM languages to explore right now unless you were to build something like Pony or Erlang/Elixir that leveraged the new Loom runtime.

Most of the popular paradigms (with Java taking the "C++ alike" role) are already serviced effectively by existing langauges.

Haskell on the JVM is a well-explored niche with lots of working but abandoned projects (Eta, Frege, etc). Getting a JVM backend into GHC would fulfill the "pure/lazy/FP" space, which is notably absent from your list.
Oh that is a good one too. I would actually kind of dig that if one could get off the ground.
Ceylon came out at around the same time as kotlin; for a while they were both good contenders for "a better Java that wasn't too different"
It doesn't seem like the JVM is that great to me; it's so memory-inefficient that it can't be performant except by brute force, and Java's famous lack-of-expressiveness is reflected in the bytecode too.

Of course it does exist and works, so it's mature which is something. But all constants are in memory instead of on disk, no value types, gigantic headers on every object?

C#/.NET is better here.

Do check out the binary-tree benchmark of the benchmark game. You can see how ridiculously ahead of every other managed language Java is when it comes to GC - and while C# and Go can indeed get away with slightly less allocations (until Valhalla happens at least), my experience is that object allocation can’t be that easily avoided in most general purpose applications, and allocation/GC is often the bottleneck at the typical big web application scale. Here Java’s state-of-the-art GC algorithm(s) are pretty much unbeatable.

It is not without reason that FAANG and Fortune500 companies have many/most of their critical web services running on top the JVM (Apple, Google, Amazon, Alibaba, Twitter, etc).

You should update your knowledge on this matter. I suggest reading about GrallVM, Loom, Valhalla and many such topics. JVM also has much wider support in terms of management and 3rd party enterprise tooling.
I'm aware, but GraalVM isn't "the JVM" (HotSpot) and Valhalla hasn't shipped yet.

(I didn't realize but apparently Valhalla is 8 years old now?)

Apparently it has SIMD now, so that's nice.

It's a JVM that solves a lot of the overhead issues. There are multiple other implementations that can provide a level of scale that's available nowhere else (e.g. Azul).

My point is that the JVM has a huge 3rd party driven ecosystem that's moving at scale. It has very deep backend adoption and has many upcoming projects that will make it even better e.g. project leyden, panama, etc.

Just to add that Java already is so performant it is often used for HFT! With the technologies/projects you mentioned it’s only going to be better.