We would like to go from php, to kotlin backend so...
# spring
c
We would like to go from php, to kotlin backend solutions. Does is have any advantages to prefer kotlin over java in spring? My thought was, that if we would decide for spring, it would be likley to not go for kotlin.
t
You're asking in the Kotlin group, so expect the awnsers to be biased 😉 I think both have trade-offs, and I personally think the added value of Kotlin is not big enough to go for it
👎 1
k
imho only downside of using kotlin is ide support
👀 1
1
nono 1
t
build in general is slower, community is smaller, language can be quity clunky
c
@Thomas What do you mean by clunky?
t
some things have a weird syntax, like writing anonymous inner classes
but java has it too for some things
c
sure:
Copy code
fun handleIp(ipAdress: IpAdress) : Nothing = when(ipAdress) {
    is IpAdress.IpV4 -> TODO()
}
t
we use kotlin with spring, it mostly works oob. however, given the improvements in java 21 I am thinking of trying java again in the next service we start (trying to do microservices here). you could also think of splitting your service into modules, keep kotlin for the business logic and java for the boundary integration (controllers, jpa, etc)
👀 1
I am saying mostly because indeed there are some quirks, like you need classes to be open if you use them as beans and proxy (there is a gradle plugin, but only if you use annotation-based I think)
1
👎 1
c
@thanksforallthefish I was hired to migrate from PHP to Kotlin or Java. Some developers like to research for code on chatgpt. My thought is, that kotlin neads experienced developers, because of the small community and some features that can code more likely to read and fast, but are also predestined to vomit the code. Most likely if you use chatgpt and others, you would to better implementing Java. Code will be vomit, but lesser vomit.
d
I like Kotlin better, but you have to make an effort to write idiomatic code instead of just Java code with Kotlin flavor. Just don't overdo it in Kotlin, not everything has to be a 10 line functional expression just because it can The syntax is richer, but you still have to write readable code
💯 1
s
Biased Kotlin user here 🙂 I was writing Java Spring backends before learning Kotlin ~ 2.5 years ago. After that I'm still using Spring, but with Kotlin only whenever possible. To me there's no coming back. You can still achieve everything Spring-wise with Kotlin, just as with Java, but at the same time Kotlin makes you more productive, your code is less boilerplated, way less error-prone, and a lot of cognitive load is just taken off of you at times. Kotlin's syntax may be weird to you at first, but that's something you jest get used to. I personally didn't like Kotlin's way of writing lambdas when I started learning it, but after using it for a while it just makes total sense - you structure your code differently in Kotlin because of its features in many cases, and its syntax is adapted to it (take a look at builders DSLs for example: https://kotlinlang.org/docs/type-safe-builders.html). IMO null safety and Kotlin's type system are big enough reasons themselves, to use Kotlin instead of Java. And these are just 2 factors out of many. For example, when you try to tackle concurrency related problems, Kotlin's coroutines can make things waaay easier and safer. Besides that, to me Java's APIs often suffer a lot of issues because of decisions made and/or backwards compatibility issues. A lot of Java possible runtime failures are solved in compile time in Kotlin. Collections API is one of such things. In Java, you can call mutable methods as add on any List, but you'll soon find out that the result of such call actually depends on the underlying implementation, and you might get
UnsupportedOperationException
fairly quickly. Kotlin seperates mutable collection interfaces, so if method's signature states to return read-only List, you just cannot invoke mutable methods on it - compiler has you covered in compile-time there. They are also inconsistent in use of generics. Let's say you have a list of dogs declared as
List<Dog> dogs = new ArrayList<>();
. If you would like to add something to the list,
add
method takes element generic argument, so you can only add another instance of a Dog, but when it comes to removing elements... well you can call
dogs.remove(new Pickaxe());
because
remove
takes an element of type
Object
. That's just one example of method that uses
Object
where it would make sense to use generics. It's also another example of failing in runtime (for example by ClassCastException), where the compiler could easily handle error case given proper method signature. You still have to know how to use the API, but you're less likely to shoot yourself in the foot. 🙂 There are many such examples of inconsistencies and unintuitiveness in Java's API. Sure, if you are proficient in Java and you know its design, you will most of the bugs possibly related to above, but why not to choose a language that just has those fixed? Besides Java issues, there are just a ton of Kotlin features that can make your life easier. I don't want to make this post too long, so I'll just throw in some bullet points for you to look up: extension functions, named arguments, coroutines, lambdas with receivers, inline functions, reified generics. I'm no Java champion, but I've used Java before, and I'm working on JVM, so I do see it everyday at job. Having that said, I'm working on Kotlin-first JVM backends for 2.5 years and here's my take: It's definitely worth understanding Java and its APIs if you're targeting JVM, but I don't see compelling enough reason to pick Java over Kotlin for language to write in, if you're given a choice. They are interoperable, so you can call any Java code from Kotlin. And if you are just switching from entirely different language as PHP and want to just use new language, no fireworks or fancy features, then I would still be suggesting Kotlin - you can still benefit many crucial mechanisms as null safety, while also being able to just use richer and (IMO) more mature standard library. Of course, you can make your code highly unreadable when trying to overuse all syntactic features you've just learned, but firstly that wouldn't be language's fault, and secondly, at least in 99% of chances you will not get
NullPointerException
where you don't expect it (caugh caugh Java) 🙂 It is true that Kotlin's tooling is not yet on the same level as Java's, but given reasons above, to me it's definitely not a deal breaker, especially considering the fact that it's getting better over time.
👍 1
a
I can second everything @Szymon Jeziorski said ☝️ . I have been working in Spring for 15+ years and switched to Kotlin about 5 years ago. Will not go back to Java. In Kotlin I am faster to get to "Dune" and with many fewer bugs than I ever experienced in Java (and have been writing in Java since v1.1). Kotlin is faster, better, cheaper with excellent IDE support from IntelliJ.
3
d
What I can't judge however, coming from Java and having quite a few years experience with it, how good of a Kotlin-JVM developer I would be if I came from another platform / language
h
I've been doing Kotlin with Spring since 2017 and I think it's awesome. Spring continues to extend Kotlin support, so it got even nicer to use with Kotlin over time. When I had to switch back to a Java project last year, I was immediately struck with the amount of bugs due to `NullPointerException`s. I think avoiding that class of errors alone is worth doing Kotlin instead of Java. IMO, compile time almost doesn't matter, as the test suite dominates the build time anyway. The only real downside is hiring – while there are quite a few Kotlin developers out there, most of them are doing Android, not server backend. Some Java devs are quick to adapt, but some have a harder time.
w
Spring has kotlin code in it and even has kotlin specific DSLs you can use. So pick the language you like, Spring is great with either one.
b
I’ve migrated from Java to Kotlin since 2017 for all my spring projects and have used it in production for many services, and it’s awesome. The combination of Webflux and reactive makes it even better. Created a bunch of
starter
modules, which, with Kotlin, is again better! if you combine it with Gradle Kotlin DSL, makes it the perfect solution, and now I’m trying to bring KMM