Hi everybody, I've been a huge proponent of Kotlin...

# server

[gpeal]

Hi everybody, I've been a huge proponent of Kotlin and helped migrate Airbnb's Android team to Kotlin and am not well underway doing the same at Tonal (https://www.tonal.com/). I'm meeting with our backend team tomorrow to introduce the idea of using Kotlin to them. Right now, they do everything in Go but I think there could be a ton of value to having shared language/code/knowledge/tooling. Plus, Kotlin is wonderful. However, I have very limited experience with Java/Kotlin on the server side of things. Any suggestions for talking points or ideas I could lead that discussion with?

[kenkyee]

Wow... Didn't realize you left Airbnb... Hope you're still taking care of Lottie ☺️
Against Go, your hardest problem will be speed comparisons. Some of the Kotlin server frameworks support GraalVM including Spring, ktor, http4k, and vert.x.
You lose a lot of java lib support though...and the tech is in its infancy.
Kotlin is a more expressive language than Go but Go folks have a lot of workarounds so they're generally pretty happy.
Sharing code with clients is also a good talking point if you need to do workflows while offline (e.g., billing and booking).

[gpeal]

yes, Lottie is definitely 100% maintained 🙂 We're using it at Tonal too

[gpeal]

Based on preliminary reading I've done, it seems like people have been happy with Spring Boot

[herlevsen]

I too am pretty happy with Spring Boot, it is really easy to setup and handles a lot of the heavy lifting for you, while stile giving you the ability to customize it to your needs.

I dont know too much about Go, but from what i’ve read, i think that kotlins type system is far superior to Go. AFAIK Go doesn’t even have generics, which for me at least would be a selling point.

And then i would guess the number of libraries available for Kotlin is far greater (because of its interoperability with Java).

[herlevsen]

Oh, and it might also be easier to hire for Kotlin? (Java)

[Mike]

If they’re serious Go users, you have a tough sell.

Spring Boot is great, Pivotal is adopting more and more Kotlin. Netflix is contributing back to Spring Boot for Cloud, and they use Kotlin.

BUT Kotlin/JVM is still heavier on memory consumption, and slower to start (unless you are really adventurous and move to GrallVM). I don’t think it’s necessarily slower on performance, but benchmarks are a tricky thing.

KTor is an all Kotlin library. Micronaut also looks very interesting (Java, Groovy, Kotlin) and they have examples for GraalVM.

Regardless, if they’re big Go users, you’ll have a tough time convincing them. Good luck!

[napperley]

Kotlin Native is an option for doing specialised back-end development (includes Serverless - https://github.com/JetBrains/kotlin-native/tree/master/samples/weather_function ) where performance and platform integration is important, however it is in Beta and doesn't have a sizeable/mature ecosystem yet. Some of the major Kotlin libraries/frameworks (eg Ktor - https://github.com/ktorio/ktor/issues/571 ; https://blog.jetbrains.com/kotlin/2018/07/kotlinnative-v0-8-released/ ) have plans to provide a Kotlin Native version.

Already there is reasonable tooling available for Kotlin Native where a Kotliner can use IntelliJ (Community or Ultimate edition), Gradle via the Kotlin Multiplatform plugin (Gradle Kotlin DSL support is arriving "soonish" with Kotlin 1.3.20 - https://youtrack.jetbrains.com/issue/KT-28458 ; https://youtrack.jetbrains.com/issue/KT-26389 ). Looks as though there is a Kotlin Native Benchmark tool under development ( https://github.com/JetBrains/kotlin-native/tree/master/tools/benchmarksAnalyzer ). There are many Kotlin Native samples available ( https://github.com/JetBrains/kotlin-native/tree/master/samples ).

[kenkyee]

K/N is only for libs, not executables AFAIK. At least for now...
Spring Boot is the safest choice because of Netflix. I like Micronaut as well.
Depends on what they're doing with Go. If it's lambda/cloud functions, Go is still the fastest and lightest. Once the JVM spins up, it's competitive but slower and more of a memory hog as Mike mentioned. Go is still the fastest and lightest framework...

[napperley]

Not sure where you get the impression that Kotlin Native can only do libraries. Kotlin Native can do binaries (both dynamically and statically linked - https://superkotlin.com/kotlin-native/ ) which is a capability that has been available since v0.1, with support for developing libraries landing in a later version.

[kenkyee]

For some reason, I thought the JB folks recommended GraalVM for Kotlin executables... Thanks for the clarification 🙂

[gildor]

I wouldn’t choose K/N for backend except if you don’t do serverless
JVM is just much safer and powerful platform for big BE application imo

Agree with @Mike that transition from Go to JVM is not so obvious decision and if BE team doesn’t have relevant JVM experience is probably not the best solution. I prefer JVM, but the best choice is what you know and where you have more expert knowledge

[dave]

The big API that I'd be worried about missing in K/N is the date time one - is there a current replacement that matches the JDK? I can't really imagine not having to use that in pretty much any significant backend (or if I think back to any of my previous projects for the last decade), unless it was just some kind of proxy or BFF. As has been mentioned, the benefits of having an standardised toolstack are huge, especially in a growing company.

[gildor]

<ctime>?

[Ema]

JVM means your container images are big and require more resources though - if you got many containers running, switching to JVM roughly implies (256 MB * nr of containers) more memory needed. Right comparison would be Go vs KN.

[Ema]

i tend to not like VMs on containers. Seems duplicated abstraction to me.

[Mike]

JVM != VM really, even though it’s in the name, but your point is completely valid. Using JVM (other than GraalVM) implies at least a 256MB increase/container.

[Mike]

VM is a full blown OS, and the JVM definitely isn’t that.

[gpeal]

Thanks for the information everybody 🙂

[Paul N]

I'd definitely go for Spring Boot and Kotlin, an awesome stack. Dave Syer from Pivotal did a good blog entry on Spring Boot startup time, with a bit of tuning a basic serverless spring Boot app can easily start in under a second, so startup time is no big deal.

https://youtu.be/97UTDmonq7w▾

[kenkyee]

If you use cloud functions it does....Go and GraalVM start up in under 10msec...

[napperley]

David D - Agree on the Date API being essential for back-end development. There was a discussion a while back on the possibility of JB developing a Kotlin multi-platform Date API however nothing has materialised since the discussion.

[napperley]

With the Kotlin 1.3.20 release Gradle Kotlin DSL can now be used to manage Kotlin multi-platform projects via the Kotlin Multiplatform Gradle plugin which will aid in providing standard Kotlin tooling (including Kotlin Native).

[gpeal]

Just chatted with the team. They're excited to try Kotlin but their major concerns are around startup time (for development work) and memory usage. How have those two faired at scale for you all? Would there be a major difference for them if we went with Spring Boot vs another framework?

[gpeal]

One engineer thinks that the overhead of managing the jvm/the extra servers required to scale it vs Go will be the difference between having an ops team and not

[napperley]

One of the major differences between Kotlin JVM and Kotlin Native is that there is very little fine turning that needs to be done (if any) with a Kotlin Native program since it doesn't use a VM. Another major difference from a perception POV is that the memory usage of a Kotlin Native program is significantly lower than a equivalent Kotlin JVM one (even when GraalVM is used). If Kotlin JVM is used then it would be recommended to evaluate the GraalVM ( https://www.graalvm.org/ ) route in order to get lower resource usage (memory, CPU, program size, startup overhead etc).

[gildor]

Fine tuning is not something bad, it’s a great feature of managed runtimes, especially on big projects

[napperley]

With VMs (software development platforms) fine tuning is problematic when there is too much that needs to be tuned at which point fine tuning becomes a burden (too much maintenance). Gabriel Peal - This video provides a introduction to JVM performance:

https://www.youtube.com/watch?v=hjpzLXoUu1Y▾

[gildor]

For small or medium project tuning just not required.
For huge projects this may save millions of dollars to a company

[gildor]

and of course not every VM supports this,. But very JVM does

[dave]

A second is a comically long time to start up a server, even in a regular container environment where instances might not be moving around that much. This is triply relevant if you want to spin up servers in tests (which admittedly you should try to avoid since everything should be testable without network) to keep your build time down.

[dave]

In terms of memory, we expect our http4k microservices to run at <100mb heap on a standard JVM. @kenkyee also had a link to some research about GraalVM startup times for various http libs (too lazy to look it up at the mo 🙂 ).

[Paul N]

Here's the link to the blog entry on Spring Boot start up time:

https://spring.io/blog/2018/12/12/how-fast-is-spring

I guess it boils down to how important you consider startup time to be versus the functionality of the framework you use. For Spring Boot you can also add Spring Boot Dev Tools to your project; this allows warm restarts of the application (it throws away the application classloader when a class is recompiled) but the jvm is left running. This really speeds things up when developing.

[mp]

fwiw https://bitbucket.org/marshallpierce/ktor-demo/src/master/ starts up in 500ms on my linux box, including configuring a DB connection pool, Jackson, etc.

[Jeremy]

also see spring fu

[Jeremy]

if you want to use spring but concerns are startup/memory

[kenkyee]

https://www.bouvet.no/bouvet-deler/comparing-java-and-node.js-on-aws-lambda
https://blog.travelex.io/blazing-fast-microservice-with-go-and-lambda-d30d95290f28
Those are from my KotlinConf 2018 slides.
The last one is especially relevant; TL;DR: if you use cloud functions/lambdas...use Go...or a Kotlin framework w/ GraalVM support but that's pretty bleeding edge now.
Competing w/ Go on speed is probably a losing race...Go is pretty much the fastest uServices framework there is (beat the former champ Node.js a while back) and has been for years. You'll have to emphasize other things like generics, inheritance, etc. that are better ironically for larger systems (which uServices are not BTW...and Go has enough workaround and libraries/ecosystem now that being able to connect to everything isn't an issue).

[tjb]

I would like to say this has been a very informative thread as I am trying to bring Kotlin into our team for backend dev right now (currently only use kotlin for tests).

[dave]

@tjb if you're used to Scala, we can throw in some more insults if that would make you feel more at home 😉

[dave]

That's the problem with kotlin - everyone is too nice

[tjb]

fortunately for me then i have not had to interact with the scala community or use the language yet 😛

[dave]

@tjb it's quite a treat. For maximum toxicity,I suggest starting with the JSON AST in the stdlib thread: https://github.com/scala/slip/pull/28

[tjb]

let me get my popcorn — back on topic though! sorry to distract

[gpeal]

In practice, how much of an issue has memory size/startup time been? I can find a lot of articles that talk about some absolute numbers. They also vary quite a lot and it's not clear to me how much we should worry about their impact on productivity and ops vs near instant build/start for dev and low memory footprint for Go

[mp]

For FaaS, especially lightly utilized, startup time may be an issue. For long running services it’s typically not a problem.

[mp]

It’s not like Go doesn’t have memory consumption issues — its GC is, last I checked, non compacting so it will suffer from memory fragmentation, for instance. They’re just different issues.

[mp]

But if you want generics and other type system things, tooling that isn’t insane, etc, then it may well be worth provisioning somewhat more memory. Maybe. Depending on your workload.

[mp]

Java has a “slow startup time” rep from terrible things done a decade ago by people who didn’t quiiiiite know what they were doing. These days, it’s pretty simple to make most things start up in a second or two, which for non-CLI or non-FaaS use is generally not a problem.

[psilospore]

@dave I've found the Scala community to be really helpful. The gitter channels are great.

[paulex]

I love this thread! Learnt quite a lot.