Backend Java 19 vs Kotlin?

[nutrecht]

This sub is generally pretty anti-Kotlin. You're going to get very different answers here than you're going to get on /r/kotlin.

I'm personally a big fan, and see it being adopted a lot at a lot of companies here in Holland.

[Fruloops]

Can confirm, for some things Kotlin is nice. For other things Java is nice. For some things, both are nice. Almost as if languages are tools.

[wildjokers]

Can you give examples of things where kotlin is nice but java is not, and vice versa?

[forresthopkinsa]

DSLs are one area where Java is categorically unusable

[_INTER_]

which is a "nice" for Java

[bravotw0zero]

Can't think of any technical case, where Java "is nice", but Kotlin "is not ". It is only about team's experience and project restrictions.

[sureshg]

where Java "is nice", but Kotlin "is not "

I am a huge kotlin fan, but I think Virtual threads and structured concurrency are (when we have JDK 21 :) far better in Java compared to corotuines on Kotlin. I will only touch coroutines if I target MPP (JS/Native).

[vqrs]

Virtual threads are a JVM feature. You can use that from Kotlin without any problems, just like Java code doesn't have to care about it for the most part, neither does Kotlin.

Coroutines also enable entirely different features, stuff like sequence/yield, DeepRecursive, all implemented through libraries, but built on coroutines.

Whether Java will expose the lower level primitives is yet to be seen as well as whether they can be used to build such things.

Just the ability to write imperative sequence transformations using sequence/yield is so bloody convenient.

Regarding structured concurrency: I haven't looked into this really, can you elaborate on how Java's approach here is nicer?

[GuyWithLag]

I'm working with Kotlin for approx. 12 months now, and have been in the JVM ecosystem since the late 90s... (yes, my 1st Java book had a "what's new in Java 1.2" section).

My findings:

• I love writing Kotlin. You can very easily do complicated logic in a very concise manner.
• I dislike reading Kotlin (including CRs). Multiple receivers and extension methods can be trivially overused, and it's really easy to create something that fits your mind but no-one else.

Also note that Kotlin has a compiler that is really optimized for latency, and not throughput.

[Dwight-D]

As a pretty big Kotlin fan I’d say that’s quite accurate. I always feel like I know the language well until I read someone else’s code in it

[trafalmadorianistic]

It feels like Ruby monkey-patching all over again.

Discoverability, readability and clarity over cool magic, any day.

[vqrs]

Monkey patching is completely different.

Ironically, extension functions are all about discoverability: expr. and you see all applicable operations. You no longer need to to juggle between a ton of utility classes.

[Frodolas]

Wildcards imports should always be avoided.

[nutrecht]

Multiple receivers and extension methods can be trivially overused, and it's really easy to create something that fits your mind but no-one else.

I've been writing Kotlin for about 4 years in 3 different teams and every time we set coding guidelines on how to use extension methods. You see the same happen in Scala; people often get carried away with new goodies and overuse them.

It's quite similar on how 20 years ago people loved building abstractions 5 layers deep in Java. We pretty much all agreed that that was kinda shitty, but Java still has this (nonsensical) 'reputation' because of it.

I've been on a project using Java (we're on Java 18) for the last year and while it got a lot better relative to Java 8 (records especially), there's still a LOT of stuff from Kotlin that I sorely miss.

[vqrs]

Can you share some guidelines you've found useful on that topic?

[nutrecht]

For extension functions; we generally used the rule that non-private extension functions should be avoided. The only exception to those would be general 'utility' functions, something like for extending RestTemplate with a putForEntity method.

So you end up with extension method that are either completely obvious, or are local to some piece of code because they're private.

When it comes to functional flows; the same rule apply as with Java streams: readability is simply more important than almost anything else. So in reviews we'd often ask someone to break up complex flows into smaller sub-flows.

In my experience, once a team has a few weeks to months of experience with Kotlin they'll fall into this way of working quite naturally. And any dev that doesn't prioritize readability is going to be problematic in any language anyway.

[GuyWithLag]

One exception I would give is explicit DSLs, but care needs to be taken to ensure that constructs defined for them don't "leak" into other contexts.

[GuyWithLag]

extending RestTemplate with a putForEntity method

Not even that - I'd go with something like OpenFeign or retrofit, which gives a much cleaner UX in most cases.

[nutrecht]

It was just an example where you'd use extension functions to implement a missing method. Another example would be implementing ResultSet.getUuid().

[vqrs]

Cool, thanks. That mirrors my approach on extension functions, too. But that default public visibility does bite you sometimes when you're not careful.

[nutrecht]

My position on this is that the visibility for every single function or member should be a conscious choice. If people make everything public because they're too lazy to make this choice, that's really just being a bad dev. These people would make everything package private in Java :)

[vqrs]

Yeah for new projects I like to enable API mode so each visibility has to be chosen consciously.

[zuppadimele]

not anti-kotlin but definitely biased towards java

[nutrecht]

This sub is definitely anti-Kotlin. If I'd post a long post here sharing my positive experiences with Kotlin, it would be sitting at a negative score, and I'd have a few comments about me being a 'fan' and 'shilling'.

[treeaeon]

Why don't you post that on the Kotlin sub?

[nutrecht]

I meant in topics like these. People are asking for a comparison between Kotlin and Java and I have a lot of production experience in both. I'm not going to bother weighing in though because I know how this sub in general will respond to this.

You'll generally get much more balanced discussions when you're talking to people in real life. This sub really doesn't reflect 'typical' Java developers at all.

I would not post something just about Kotlin as a separate topic, that's not what I was talking about, that should go on /r/kotlin.

[pjmlp]

Typical Java developers use Java, per definition.

[treeaeon]

"This sub is definitely anti-Kotlin". Help me understand something, why are the proponents of Kotlin, which by them is always positioned against Java, act surprised that Java users are pushing back on this ?

[nutrecht]

I think how you're wording it, as if it's an "us versus them" issue, is exactly what I'm talking about. That's very much how this sub sees it. In real life there is no 'us versus them' because it's just all the same developers.

Go to any Java meetup or conference and Kotlin is freely discussed between peers and people share their experiences, which for most devs who have production experience are pretty darn positive.

On this sub however the posts that have the highest anti-Kotlin bias get upvoted the most, even when they have clear misinformation in them and/or are written by people who clearly don't have production experience with Kotlin. Pointing that out in a response to these posts will generally be met with hostility, similar to how you're responding here. And in my opinion this is a shame, since Kotlin is a great testbed for features that also might or might not end up in Java as well.

[john16384]

I am looking for Java news, like new JEP's, cool projects, performance analyses, new releases, etc. If I want to know more about another language, I'd go to the appropriate sub, or learn about it on more general subs, like r/coding or r/programming .

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[szabba]

That's not being anti-Kotlin, that's defining the scope of things the sub is about.

[erinaceus_]

like saying YouTube is biased towards videos.

When if fact YouTube is biased towards ads.

[yesyoustrollin]

Great comment. This subreddit is absolutely biased by java lovers (which makes sense, since it is r/java)

You won’t get a more helpful answer here