
Learning Spring with Kotlin – Sprint 0 - joaogfarias
http://thatsabug.com/blog/spring_learning_week0/
======
jillesvangurp
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 wrong. You are missing out on a ton of
stuff the Spring people did to support Kotlin. Yes Java is still supported but
it is increasingly in the same way that Google hasn't completely deprecated
Java for Android yet despite that obviously very much being a second class
citizen in that ecosystem.

In short, if you are a conservative institution like a bank and evolving your
tech stack at a glacial pace; yes you can still use Java. Everybody else, you
probably should be using Kotlin.

My advice to anyone looking to do this is:

1) Do it, it's easy and you end up with better code. You can start simple and
mix Java and Kotlin code. I would advice starting with some tests or some new
features.

2) Beware of the java idioms and cruft in Spring and do things the Kotlin way.
So, DSLs instead of annotations + AOP, co-routines instead of spring flux,
immutable data classes instead of java beans, etc.

3) Spring has a lot of stuff and not all of it is great or even good. IMHO the
added advantage of e.g. spring-cloud or spring-data is very limited and
sometimes it's just very limiting/backwards. I ripped out spring-data on
several projects where people naively supposed it was the easiest/best way to
interact with Elasticsearch. It turns out it is neither. Spring cloud sounds
nice until you realize most of the stuff you need is supported in the amazon
driver but yet not exposed in spring-cloud. Also all the code samples on
Amazon are for their own driver and not for spring-cloud.

4) Re-assess if you actually want to go anywhere near hibernate. IMHO it made
a lot of sense when java beans were hard to write. Kotlin data classes take
away most of that pain and there are some nice alternatives. Also, you should
be using non blocking IO for talking to your DB and hibernate is still stuck
on blocking IO. That in itself is a good reason to not use it on new projects.

Once you get a bit further, you'll find yourself wondering if ktor would work.
The answer is probably yes. It's actually pretty good. Spring does a lot of
things but ultimately do you really need all of that and the associated
complexity?

~~~
humbleMouse
Do you have any thoughts about Groovy?

~~~
krakatau1
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.

~~~
humbleMouse
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.

------
fergie
Some guy writes an article where he says he is thinking about learning Spring
with Kotlin and this is worthy of the front page of Hacker News??

