3 ms·

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

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

pjmlp 11mo ago
Depending on the market, C# isn't always an option. One example out of many, https://www.aicas.com 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 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,....
- blandflakes 11mo ago
  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.
  - pjmlp 11mo ago
    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.
    - 11mo ago

pjmlp 11mo ago

Depending on the market, C# isn't always an option. One example out of many, https://www.aicas.com 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 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,....

blandflakes 11mo ago
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.
- pjmlp 11mo ago
  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.
  - 11mo ago