Hey hey Kotlin Spring people - could you drop reas...

# spring

[Eugen Martynov]

Hey hey Kotlin Spring people - could you drop reasons in thread why you would still develop in kotlin especially java so advanced in feature parities these days?

[Robert Jaros]

I develop fullstack apps with shared Kotlin code for the frontend (js , wasm) and the backend (kotlin, spring, webflux, coroutines). No place for java here 🙂

[Thomas]

time for our monthly Kotlin-vs-Java discussion 🙂

[hho]

Java's Feature parity is a myth: Java is not null safe, doesn't have Kotlins excellent stdlib and will never have its concise syntax either.

[Eugen Martynov]

@hho the null safety is similar with annotations and errorprone compiler. And Vallhalla is brining more. And standard library and concise syntax are good one.

[Szymon Jeziorski]

null safety, extension functions, named arguments, default arguments, richer, more extensible and more mature std-lib (for example read only vs mutable collections, declaration site variance etc.)

Each of those would be enough of the reason for me to go for Kotlin. Having all of them combined with all the other goodness like coroutines makes the choice a no-brainer for me.
Kotlin doesn't only add new stuff or quality of life improvements on top of Java, but also fixes a lot of its issues, which will most likely not be fixed in any feasible future, due to backwards compatibility (like mentioned collection interfaces for example)

I would ask different question: Why would I want to write in Java, having Kotlin available?

[Szymon Jeziorski]

> the null safety is similar with annotations and errorprone compiler
I wouldn't really say so.
Kotlin null safety is a natural part of the language. All its mechanisms had just been there working by default from the very beginning. If you see some kotlin code, you know it must had been written with nullability handled.
Java's annotations on the other hand is non-mandatory solution which not only implies additional boilerplate but also requires developers' meticulousness needed for it to actually work, which may not be easy to enforce effectively especially in bigger teams.

[mbonnin]

> And Vallhalla is brining more.
I don't think it will ever match Kotlin's nullability because it has to stay backward compatible. Java has will at some point have 3 nullability "variants" (String, String? and String!) where Kotlin has only 2 (String and String? )
This was a fun question at Devoxx 😄

https://www.youtube.com/watch?t=3010&v=Dhn-JgZaBWo&feature=youtu.be▾

[mbonnin]

(the talk is excellent BTW, gives a clear overview of Valhalla if you're curious about it, I recommend 100%)

[krousseau]

Java's reliance on attributes makes me want to bang my head on the desk. Kotlin is a sane modern language. Java is a language from 1995 that has haphazardly thrown in a bunch of new features.

[Klitos Kyriacou]

Java has will at some point have 3 nullability "variants" (String, String? and String!) where Kotlin has only 2 (String and String? )

And of course this means that Java String types (which will continue being of unspecified nullability) will continue being shown as String! in the IDE in Kotlin code, while Java's String! will be String in Kotlin code. I will wait to see how much confusion this will bring.

[Jakub Gwóźdź]

hot take: none of those two languages properly count indices from one, hence both are prone to off-by-one. But Kotlin is a lesser evil thanks to built-in null-safety.

[Eugen Martynov]

Thanks, the initial question is wrongly worded. I was more on the place if you would start a new project now. Nullability Kotlin and Java approach - they look similar to me for a new code - or I write ? in Kotlin or add annotation - and both are checked by the compiler. Sure, things change if I need dependencies.

[wakingrufus]

null safety and router and beans DSLs. functional spring FTW https://github.com/wakingrufus/spring-funk come to my TED talk: https://devnexus.com/presentations/functional-spring-boot

[Jacob]

Easy immutability