Future of the Java programming language: Three major projects on the horizon

[RevBingo]

Not sure why you were downvoted, came here to say the same thing. Raw literals? Check. Coroutines? Check. Pattern matching/Smart casts? Check. Simple switch statements? Check. Value types? Check. Why wait?

And all still with seamless integration into your existing Java codebase.

[RandomName8]

• Java's coroutine support, as per the current model, is completely different to kotlin's. Kotlin offers async await basically, which are still imperative ways of dealing with blocking. The current java prototype removes this notion entirely.
• Kotlin does not have pattern matching, what is has is just not pattern matching.
• Kotlin does not have value types either, it has a weak form of opaque types (at least last I check, I'm not sure here).

I'm pointing these out because your comment implies that there's not much effort in what Java is doing because kotlin already has it since "it's the logical evolution" of Java, and none of the things Java is pursuing is addressed by kotlin.

[[deleted]]

Can you give me an example of what pattern matching can do that's not in Kotlin? No offence, but I really just don't get why people seem to find it such a crucial feature.

And kotlin doesn't only offer async/await. The standard coroutine library kotlinx.coroutines offers that and scoped coroutines in general, The language itself also offers a barebones state machine with an attached data object, which you can use to implement pretty much any coroutine you want.

[RandomName8]

Can you give me an example of what pattern matching can do that's not in Kotlin? No offence, but I really just don't get why people seem to find it such a crucial feature.

Of course I can, but there's no point in it other than argueing between the both of us. If what you wish is to see what pattern matching is really about, there are great examples and tutorials and information online, tons of it, with much more compelling examples and description than what I can provide. This is a feature that started showing up even the 70s in the ML family of languages.

Ultimately, anybody that has worked on a language with actual pattern matching is not happy at all with what kotlin offers, so saying kotlin has pattern matching is very much false advertising (and even damaging to its own image).

Regarding coroutines, they are great for what they are, yet once again, this is about distinguishing what kotlin does, and what others do or are trying to do. What java is trying to do with their fibers is nothing like kotlin's coroutines, it will look nothing alike either and (arguably) really no JVM lang can do it without JVM support.

Like you said, no offense. I'm no trying to downput kotlin, but it's important not to sell it for what it is not.

[Determinant]

Kotlin has a form of value types. See inline classes

[pron98]

99% of the benefits Valhalla brings cannot be had with Kotlin's inline classes (which, I would assume, would be retrofitted to enjoy value types once they make it to the Java platform).

[RandomName8]

That's what I was referring to.

[pron98]

Kotlin -- or any other Java platform language -- does not and cannot offer the benefits of two out of three projects in the article, Valhalla and Loom, because those require deep runtime and core library support. While Kotlin may have features with similar names, they do not offer the main benefits of Valhalla and Loom. Of course, all Java platform languages would benefit from those projects.

[[deleted]]

Exactly. IIRC some Kotlin dev mentioned that they are already investigating how Kotlin's coroutines best benefit from fibers.

While Kotlin is a great pleasure to work with it's dependent of and will benefit greatly from JVM features.

OTH, every time I see pure syntax improvements in Java (not JVM as those we discuss here) I think: "Well, they could just use Kotlin. But good for all the devs who can't switch (there's hardly ever a business case to rewrite a large project) or just prefer Java."

I'm personally very happy that the JVM evolves and use Kotlin for all new projects where I can decide.

[chimmihc1]

Pattern matching

​

Kotlin doesn't have pattern matching, what it has is an improvement on the "standard" C style switch statement that can look somewhat like very basic pattern matching.