Comment by blandflakes | Hacker News Reader

Comment by blandflakes | Hacker News Reader

Parent Full thread

> However, now that Java is making strides in the language features, as compared to historical improvements at the VM level, I’m curious to see how the market share for Kotlin outside of android is going to be affected.

My employer has decided to abandon Scala, and they proposed Java as the language to head toward. I don't think Java's strides are fast enough to provide modern table stakes. In 2025, the big ones to me are:

1. null handling at the cultural and language level

2. abstractions over concurrency

For null handling, Java has Option, but you're just going to have to deal with the fact that basically any API or caller can give you null. This is not good enough in 2025.

For concurrency, Java has an excellent java.util.concurrent package (and the JVM is very good at concurrency in general). However, I've come to believe that it's a losing proposition to expect the average programmer to use concurrency primitives correctly, even at that level of abstraction. Every Java PR I review I have to add 20-30 comments about thread interruption, memory barriers, etc.

Structured Concurrency helps, but is new/in preview, and hardly helps with actually providing safer concurrency operations.

I think Java is doing the right things and the glacial pace of innovation at the language level is correct for protecting their users (contrast this with Scala 3...), but on the flipside I just think that it is hard to recommend Java vs C#/Kotlin.

Depending on the market, C# isn't always an option.

One example out of many, https://www.aicas.com

This isn't like Meadows, this is a real-time VM with AOT compilation and soft-realtime deadlines, there are others.

Or stuff like https://www.azul.com/products/prime/cloud-native-compiler, again there are others offering the same.

Kotlin will always be a second language on the JVM, it isn't what Oracle, IBM, and others think about when designing runtime features, and eventually like all guest languages will face the problem to either exposed the platform features, or have multiple ways, with different semantics, to achive the same.

Virtual threads, versus co-routines, structured concurrency, SIMD/Vector, value class/records,....

It frankly doesn't matter in which markets C# isn't an option - if you're in one of those, well... then obviously don't consider C#. That doesn't somehow indict C# as a language which better makes it possible to write concurrent code. For a very large proportion of the population, you're picking a language and running some services on a cloud provider or machine you control.

The problem I'm citing in Java is not the performance, it's the semantics and having to explain what an InterruptedException is to every generation of programmers, including those who came before me. If you think virtual threads somehow do anything about what's difficult about concurrency on the JVM, we're talking on different wavelengths. Structured Concurrency is the TINIEST of baby steps and doesn't really do anything to change the experience, and it's only just now in preview, in the most recent LTS JVM? Hardly a solution.

It doesn't matter whether the JVM is developed with Kotlin in mind, as long as Kotlin continues to offer a better way to leverage what the JVM does have to offer. It's not some killer argument that Kotlin somehow can't be useful if the host platform isn't specifically developing their roadmap (especially because you can... just write Java, if you need it?).

Scala's demise likewise has nothing to do with whether the JVM is supporting Scala, and any suggestion that Java's language features have eliminated Scala's value proposition are similarly misplaced.

It matters, because these arguments are always done as if programming languages exist in a vacuum.

Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.

People reach out to guest languages, as they think they don't have to learn the underlying platform, then they discover the hard reality to master two ecosystems.

Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.

Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.

Kotlin has a better future than Scala, beyond the JVM, because papa Google has ensured it happens, at least as long as they care about Android.

No, it doesn't matter. You are advocating for the special case, not the average case, and it has no bearing on C#'s _general_ aptness that it can't be deployed somewhere. The same is true of Java! This is nitpicking with no justification.

> Any guest language on the JVM will trip on the InterruptedException just as well, it is called leaky abstractions for a reason.

They can (and do) reduce how often and where you have to interact with it. I at this point am not sure whether you are intentionally arguing from a position of ignorance or whether this is actual bad faith. Are you suggesting that abstraction is not useful or impossible? Yes _obviously_ InterruptedException is still on the classpath and in implementation code; that doesn't mean we should throw in the towel and interact with APIs that constantly throw it.

> Improvements on the platfrom language eventually always drive the guest languages away, because all guest languages either lose their value proposition, or use the platform to bootstrap their own ecosystem.

You have done nothing to address the issue that Java adopts new features extremely conservatively and slowly. I already used the perfect example that you gave of Structured Concurrency, which is not only not enough, but not even available, and ten years late. It is simply false that Java has done anything significant to compete with its guest languages. Javascript, yes! C#... debatable, but certainly better at it than Java.

> Turns out when they take second option, they open the door to having libraries that only work in one platform, and the usual #ifdef like complexity.

This is why I'm skeptical of multiplatform approaches such as Kotlin's, but that my suggestion that Kotlin is useful is not based on any degree of multiplatform support. Even at the end of the day if I thought Kotlin didn't have a future, my point is that that is table stakes level of abstraction in 2025 and Java ain't it.

Reply on news.ycombinator.com