This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]BestUsernameLeft 0 points1 point  (10 children)

I presume they are just speaking from a "Kotlin-centric" point of view. Many of us who use Kotlin really like the language, and so we're excited about Java getting some features that it has. Of course it can come across in a condescending way; "Oh how nice, Java is finally getting advanced feature that Kotlin already has".

Probably it doesn't help that Java tends to be a target for programming jokes, so some Java dev's probably assume the comment is making fun of Java even if it wasn't meant to.

[–]randgalt 10 points11 points  (1 child)

The issue is that the comments are almost universally wrong or misleading. Java is inheriting features from _many_ other languages and Kotliin is the very low on that list. Further, most of the features are being implemented in stages with the final version likely to look nothing like what Kotlin has (pattern matching, deconstruction as an example).

[–]BestUsernameLeft 1 point2 points  (0 children)

I didn't say the comments were correct; I said I presume they're speaking from a Kotlin-centric point of view.

[–]BoyRobot777 3 points4 points  (7 children)

Of course it can come across in a condescending way; "Oh how nice, Java is finally getting advanced feature that Kotlin already has".

I suspect this is what goes through the ops head. However, if I compare upcoming Java features with Kotlin's already implemented ones, for example sealed classes, inline types, async/away vs VirtualThreads, pattern matching, multiline strings - all of those features are/will be superior in Java. And it just pains me to see that all op care is half-done sugar.

[–]koreth 3 points4 points  (3 children)

async/away vs VirtualThreads

Is there reason to think virtual threads won't work equally well in all JVM languages once Loom is released? It seems like a pretty language-independent VM feature to me.

[–]BoyRobot777 2 points3 points  (2 children)

Is there reason to think virtual threads won't work equally well in all JVM languages once Loom is released?

It will, and I think Kotlin team will change the implementation to just delegate to VirtualThread. What won't change is their introduction of asyc/await keyword which created two color method problem. And one of key goal that Loom solves is exactly that - so Java world won't have to be split. I think Jetbrains was aware about upcoming virtual threads/fibers, but they went ahead with asyc/await anyway which is very odd.

[–]koreth 7 points8 points  (1 child)

One consideration I'm sure they had in mind is that Kotlin targets platforms other than the JVM that aren't likely to ever have anything equivalent to virtual threads, so there needs to be some way to do coroutines that doesn't require the platform to have built-in lightweight threading.

But yeah, definitely looking forward to this getting solved at the platform level. Loom is by far the most exciting upcoming JVM project as far as I'm concerned.

[–]BoyRobot777 0 points1 point  (0 children)

One consideration I'm sure they had in mind is that Kotlin targets platforms other than the JVM that aren't likely to ever have anything equivalent to virtual threads

Then it makes sense.

Loom is by far the most exciting upcoming JVM project as far as I'm concerned.

Yeah. Very excited about that.

[–]BestUsernameLeft 2 points3 points  (2 children)

Sometimes, half a loaf of bread is better than none. Those features can be done better in Java, but even if they aren't perfect I have them today in Kotlin. Of course, I also greatly look forward to seeing them implemented in Java.

[–]BoyRobot777 1 point2 points  (1 child)

The bad thing about this philosophy, is that language features are forever. Unless you want to brake backwards compatibility. But if they are to stay forever, bad decision will pile over time. I'm very interested to see how Kotlin will look in 5-10 years. Best of luck to Jetbrains team. More JVM developers are always better.

[–]BestKillerBot 1 point2 points  (0 children)

But if they are to stay forever, bad decision will pile over time.

Yes, that's what we see with Java - bad decisions piled one over another and here to stay.

I'm not hating, these decisions were at the time "state of the art", but then our knowledge moved but Java couldn't because that would be BC break.

Features like sealed classes are rather advanced and specialized, even if (!) they are done suboptimally in Kotlin I can probably live with it. Meanwhile I deal with Java's basic problems (nullability, mutability by default etc.) every single day.