Live data from Hacker News

Learning Spring with Kotlin – Sprint 0

thatsabug.com

21–30 of 41 posts

Re: Learning Spring with Kotlin – Sprint 0

#21
post #18

Earlier quoted context omitted.

Why do you want db access to be non-blocking? Are you not interested in the result?

I want to resume business logic when the result is available, but I don't want tens of thousands of kernel threads blocked on results until java finally gets fibers. People who write synchronous drivers also tend to make big poorly-used connection pools which defeat TCP flow control.

> I don't want tens of thousands of kernel threads blocked on results

If that is because of the memory consumption of kernel threads, be aware you are trading less memory consumption for increased cognitive complexity (if you agree that asynchronicity is more complex than synchronicity).

Re: Learning Spring with Kotlin – Sprint 0

#23

Earlier quoted context omitted.

Kotlin is taking over the JVM ecosystem like Scala could only have dreamed of doing. The JetBrains team took one of Scala's more glaring weaknesses, the tooling support, and made it the foundational strength of Kotlin. 100% inter-op with Java. It's a first class citizen alongside Java in IDEA for a long time, since before the language was even production ready. Supremely clean, coherent, and most of all concise docum…

Kotlin does not really take over JVM ecosystem, very few projects use Kotlin outside of Android world (which is not really JVM ecosystem). And even for Android, I believe, its promotion from Google was more to mock Oracle.

> And even for Android, I believe, its promotion from Google was more to mock Oracle.

It certainly helps them shift away from Java reliance, but have you ever actually coded an Android app? Android is stuck on Java 8 syntax, and Kotlin fixes that. It has a laundry list of QoL improvements over Java (delegation, type alias, extension functions, data classes, better string formatting, operator overloading, smart casting, to name a few) that make it so much more pleasing to use over Java. ESPECIALLY when coupled with the aging Android framework, which it enhances greatly.

Re: Learning Spring with Kotlin – Sprint 0

#24

Earlier quoted context omitted.

Kotlin does not really take over JVM ecosystem, very few projects use Kotlin outside of Android world (which is not really JVM ecosystem). And even for Android, I believe, its promotion from Google was more to mock Oracle.

> And even for Android, I believe, its promotion from Google was more to mock Oracle. It certainly helps them shift away from Java reliance, but have you ever actually coded an Android app? Android is stuck on Java 8 syntax, and Kotlin fixes that. It has a laundry list of QoL improvements over Java (delegation, type alias, extension functions, data classes, better string formatting, operator overloading, smart castin…

These are all Android problems. Not Java's.

Re: Learning Spring with Kotlin – Sprint 0

#25

I've been using spring and Kotlin together for nearly 3 years. Since then, a lot of Kotlin specifics have crept into Spring. Also, there's an effort to move to a fully declarative Kotlin DSL for driving spring (kofu), which gets rid of basically all anotations, AOP processing, and other magic that makes spring both nice and hard to debug. At this point, if you are using Spring and not using Kotlin: you are doing it w…

Do you have any thoughts about Groovy?

as much as I love Groovy, it is sadly essentially a dead language. None of the language bugs and issue I have with it will probably ever get fixed. Kotlin has learned a lot of things from Groovy, and carries on a similar tradition of "java with syntactic sugar", though they've taken it slightly farther. And with the support of both JetBrains and Google behind it, it actually gets the fixes and improvements it needs, combined with all the growing community and overall momentum.

Re: Learning Spring with Kotlin – Sprint 0

#26
post #21

Earlier quoted context omitted.

I want to resume business logic when the result is available, but I don't want tens of thousands of kernel threads blocked on results until java finally gets fibers. People who write synchronous drivers also tend to make big poorly-used connection pools which defeat TCP flow control.

> I don't want tens of thousands of kernel threads blocked on results If that is because of the memory consumption of kernel threads, be aware you are trading less memory consumption for increased cognitive complexity (if you agree that asynchronicity is more complex than synchronicity).

True, if hardware cost nothing we might still be on python. Chaining futures with f1.thenApply(arg -> f2) hasn't been that bad, but kotlin's coroutine DSL does look better.

Re: Learning Spring with Kotlin – Sprint 0

#27
post #13

Earlier quoted context omitted.

Kotlin is taking over the JVM ecosystem like Scala could only have dreamed of doing. The JetBrains team took one of Scala's more glaring weaknesses, the tooling support, and made it the foundational strength of Kotlin. 100% inter-op with Java. It's a first class citizen alongside Java in IDEA for a long time, since before the language was even production ready. Supremely clean, coherent, and most of all concise docum…

> They got support from Google surprisingly early on in the Android world. You can thank the Oracle lawsuit for this. Google has been preparing Kotlin as their escape hatch.

So they better get that Kotlin/Native ready, and rewrite all of Maven Central libraries being used in Android in Kotlin/Native.

Re: Learning Spring with Kotlin – Sprint 0

#28

I've been using spring and Kotlin together for nearly 3 years. Since then, a lot of Kotlin specifics have crept into Spring. Also, there's an effort to move to a fully declarative Kotlin DSL for driving spring (kofu), which gets rid of basically all anotations, AOP processing, and other magic that makes spring both nice and hard to debug. At this point, if you are using Spring and not using Kotlin: you are doing it w…

Kotlin is taking over the JVM ecosystem like Scala could only have dreamed of doing. The JetBrains team took one of Scala's more glaring weaknesses, the tooling support, and made it the foundational strength of Kotlin. 100% inter-op with Java. It's a first class citizen alongside Java in IDEA for a long time, since before the language was even production ready. Supremely clean, coherent, and most of all concise docum…

Kotlin is meaningless in the JVM ecosystem, it is just yet another Groovy, Scala, Clojure and it will never get beyond single digit percentage.

In about 5 years it will be as meanigfull as former guest languages are today.

Without having any language support for what Java 25 will be capable of doing with value types, GPGPU, SIMD, Graal integration, as per JVM/Java roadmap, as it will be jailed by what Android is able to do.

Re: Learning Spring with Kotlin – Sprint 0

#29

Earlier quoted context omitted.

Kotlin does not really take over JVM ecosystem, very few projects use Kotlin outside of Android world (which is not really JVM ecosystem). And even for Android, I believe, its promotion from Google was more to mock Oracle.

> And even for Android, I believe, its promotion from Google was more to mock Oracle. It certainly helps them shift away from Java reliance, but have you ever actually coded an Android app? Android is stuck on Java 8 syntax, and Kotlin fixes that. It has a laundry list of QoL improvements over Java (delegation, type alias, extension functions, data classes, better string formatting, operator overloading, smart castin…

That is how Google plays the game to sell Kotlin, by placing it against a half baked implementation of Java 8.

If Android had an up to date full implementation of Java, the sales pitch wouldn't work that well.

In fact, there are several people that mistakenly think Android Java is Java and then get positively surprised when they learn about the real deal.

Re: Learning Spring with Kotlin – Sprint 0

#30

I've been using spring and Kotlin together for nearly 3 years. Since then, a lot of Kotlin specifics have crept into Spring. Also, there's an effort to move to a fully declarative Kotlin DSL for driving spring (kofu), which gets rid of basically all anotations, AOP processing, and other magic that makes spring both nice and hard to debug. At this point, if you are using Spring and not using Kotlin: you are doing it w…

Agreed on all points, also that spring-cloud is subpar. Also, if you're using Gradle (I usually prefer Maven), there is now a Kotlin DSL. Glad to get rid of Groovy.

The Kotlin DSL is an improvement but it still suffers from a lot of groovy legacy. If find it is almost impossible to navigate my way around the DSL using autocomplete. Absolutely everything is both different from groovy and somewhat counter intuitive.

Maven is a bit easier to Google; mainly because it stopped evolving in any meaningful way about a decade ago and nothing is really changing. The XML feels really backwards at this point It seems attempts to move away from that have stalled. It's also a lot slower to run. We're using it on the project I'm currently on and it eats up a lot of my time. Every time I do an mvn spring-boot:run, it goes off and compiles stuff. Even after it just did that and literally nothing changed. Gradle is much better at eliminating unnecessary work.

Post reply on HN