|
|
|
|
|
|
by pjmlp
197 days 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. |
|
|
> 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.