Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning Spring with Kotlin – Sprint 0

thatsabug.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Learning Spring with Kotlin – Sprint 0

#31

Post by jillesvangurp »

ebiester wrote: post #8
jillesvangurp wrote: post #2

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…

I just wish that Kotlin had a testing solution as great as Spock (groovy), or rspec for ruby, for that matter. But you mention not using Hibernate. I fully agree myself, and used JOOQ, but what is your preference?

Kotest is pretty nice as well. I haven't really tried spek but it sounds alright. I'm generally not that much into BDD; IMHO it just leads to lots of verbosity stating the obvious. Mostly junit5 with some nice assertions library (assertk) and mocking library (mockk) covers most of my needs.

For database stuff; I've always preferred good old JdbcTemplate in Spring combined with TransactionTemplate. IMHO writing mapping code is not that much of a problem; especially if you stop pretending that your complex object hierarcy maps 1 to 1 to tables and do a proper database design instead.

Writing that code sounds harder than it is. Compared to littering your models with annotations to say "this field is that column and this type", it's about the same lines of code. Except it's in one place where it is easy to maintain. Several frameworks exist to automate this business of course but given how trivially easy it is to do this manually, I don't see the value.

Re: Learning Spring with Kotlin – Sprint 0

#32

Post by jillesvangurp »

humbleMouse wrote: post #3
jillesvangurp wrote: post #2

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?

With Kotlin out there, groovy is completely redundant. Also development seems to have stalled a little. I removed it from a few projects I inherited to simplify my life a couple of times.

Re: Learning Spring with Kotlin – Sprint 0

#33

Post by jillesvangurp »

songshu wrote: post #11
jillesvangurp wrote: post #2

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…

What are you using for non-blocking database access? Is not JDBC a roadblock?

I've not yet done any non blocking DB stuff. JDBC is blocking but there's R2DBC in the spring world that you can use. There are probably a few other options.

Re: Learning Spring with Kotlin – Sprint 0

#35

Post by MrBuddyCasino »

jillesvangurp wrote: post #30
MrBuddyCasino wrote: post #7

Earlier quoted context omitted.

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 backw…

> It's also a lot slower to run.

Huh interesting. Its the other way around for me, Gradle usually being a lot slower. Also, IDE integrations (IntelliJ) is usually better with Maven due to its declarative nature.

Re: Learning Spring with Kotlin – Sprint 0

#36

Post by krakatau1 »

humbleMouse wrote: post #3
jillesvangurp wrote: post #2

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?

I still go with Groovy for scripting and tests with Spock.

Scripting is better because Kotlin doesn't have simple dependency management like Grape and compilation speed is way faster than Kotlin's. One of Kotlin's downsides is compilation speed and kts (kotlin script) is even slower. Also, Groovy still has ton of utility methods in GDK not matched in kotlin stdlib.

Other than that, I'm sad to say, Groovy is dead or in process of dying. I'm seeing companies rewriting Grails apps to Spring Boot and switching to Kotlin dsl in Gradle. It's a shame really, such a fun language to program in.

Re: Learning Spring with Kotlin – Sprint 0

#37

Post by vbezhenar »

dietkoch wrote: post #23
vbezhenar wrote: post #16

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…

Kotlin is awesome language, don't get me wrong. I used it for some of my backend projects. I just don't see it overtaking Java ecosystem, it's a wishful thinking. Developers don't care about QoL improvements that much, they just follow vendor standards.

Another aspect is that JVM evolves without taking Kotlin in consideration, so there's always danger of JVM introducing a feature that won't be available in Kotlin (and JVM has several interesting developments namely Loom, Valhalla). Like it or not, Kotlin is second-class citizen on JVM. It made sense in Java 7 era, when Java development seemed stuck and Java thought to be mostly done. Times changed, Java is evolving at much faster rates (I would even say, faster than Kotlin these days).

This is about JVM, of course on Android Kotlin is first-class citizen and everything's good for Kotlin there.

Re: Learning Spring with Kotlin – Sprint 0

#38

Post by jillesvangurp »

zests wrote: post #20
jillesvangurp wrote: post #2

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…

Why do you prefer co-routines to reactor flux/mono? I have plenty of flux/mono experience and I enjoy the api so I didn't even consider coroutines. It looks like there is a kotlinx-coroutines-reactor module, I'm not sure if that's what you are referring to.

Co-routines + flows are basically designed to address some problems with reactive things like flux or rxjava. Spring can support co-routines anywhere it currently supports flux/mono as well. Basically, the way things are going. I consider flux to be effectively deprecated. IMHO it will probably stick around for a long time to support those who depend on it already (like lots of other things in Spring) but you should avoid using it.

Basically, with co-routines you lose the need for all the container types like Mono, Flux, etc. and replace them with simple suspend functions. This makes code a lot more readable, easier to test, and reason about.

Instead of callbacks for errors, you can rely on the normal try/catch. Any uncaught exception causes the co routine and co routine scope to fail and cancel in a controlled way. The Flow API allows you to do reactive style processing. It also handles back pressure and a few other things.

Basically fully reactive code written using this is structurally very similar to the normal blocking version of the code.

Re: Learning Spring with Kotlin – Sprint 0

#39

Post by zests »

jillesvangurp wrote: post #38
zests wrote: post #20

Earlier quoted context omitted.

Why do you prefer co-routines to reactor flux/mono? I have plenty of flux/mono experience and I enjoy the api so I didn't even consider coroutines. It looks like there is a kotlinx-coroutines-reactor module, I'm not sure if that's what you are referring to.

Co-routines + flows are basically designed to address some problems with reactive things like flux or rxjava. Spring can support co-routines anywhere it currently supports flux/mono as well. Basically, the way things are going. I consider flux to be effectively deprecated. IMHO it will probably stick around for a long time to support those who depend on it already (like lots of other things in Spring) but you should…

I actually enjoy the container types and callback errors. The wrapper type Mono acts like a monad of type Promise>. This completely isolates a computation from the rest of the code and puts all of the error handling in one place.

I despise side effects as well as try/catch error handling so these are an especially welcome improvement to java/kotlin.

I don't have much experience with coroutines/flow so I can't actually compare the two approaches but this is my experience with the reactor library. Its unlikely that I will get a chance to continue using Kotlin in the near future but next time I do use Kotlin I will definitely try the coroutine approach and see how it compares.

Re: Learning Spring with Kotlin – Sprint 0

#40

Post by humbleMouse »

krakatau1 wrote: post #36
humbleMouse wrote: post #3

Earlier quoted context omitted.

Do you have any thoughts about Groovy?

I still go with Groovy for scripting and tests with Spock. Scripting is better because Kotlin doesn't have simple dependency management like Grape and compilation speed is way faster than Kotlin's. One of Kotlin's downsides is compilation speed and kts (kotlin script) is even slower. Also, Groovy still has ton of utility methods in GDK not matched in kotlin stdlib. Other than that, I'm sad to say, Groovy is dead or i…

I feel like the sweet spot is using groovy where it makes sense, like parsing unstructured xml and json, reading in files, pojos, and of course spock. I was never the biggest fan of grails.

I’ll have to check out Kotlin though, seems like the new wave for sure when it comes to simple readable jvm code.

Post reply on HN