Sebastian Deleuze who is one of the Kotlin people working on Spring just gave a presentation of the status of Kotlin support in Spring: https://www.infoq.com/presentations/spring-kotlin-boot-kofu/.

In short, if you are using Spring and are ignoring Kotlin, you are missing out a lot of good stuff. Or in other words, the same that happened to Java on Android is now happening to backend Java. You can still use it but why would you when things can be so much better with a simple upgrade to Kotlin (I've migrated tens of thousands of lines of code, it's easy). And yes Java 9-14 added a bunch of things that are definitely nice/useful but it doesn't come close to Kotlin in terms of expressiveness and language ergonomics.

Also, KotlinConf was on last week. There was a nice presentation about the state of kotlin-js, which is getting some nice updates in the next year including much better dead code elimination resulting in very compact minified code (< 100kb is now feasible for simple stuff), better integration of existing typescript type script defifinitions (i.e. support for most relevant npms out there), better build tooling in the form of an improved gradle plugin. Or put different, Kotlin might start doing to typescript/javascript what it already did to Java. IMHO it's a more capable language than typescript, which I consider to be pretty nice but it just lacks a bunch of things and comes with a some ugliness that relates to backwards compatibility with js.

In related news, Kotlin native is also happening. So, Kotlin is joining a list of full stack languages that used to be really short.

I tried using Spring with Kotlin last year but it felt verbose as if I'm writing Java so we decided to implement support for Kotlin in our in-house Netty-based server (https://github.com/buremba/netty-rest) and use it. Great to hear that Spring finally has native integration with Kotlin!

What's the status of Kotlin Native for writing backend apps? I really like it but I wouldn't want to get dragged into Gradle, JARs and JDBC again...

The native compiler is maturing and they are moving the JVM and JS compilers to the IR format they have developed for that. Additionally, they are going to support a new type of library that compiles to IR and that is reusable for all platforms.

They already have a few multi platform things. Mainly Ktor currently, which kind of should work on native. Additionally, you can target the node-js ecosystem via Kotlin-js. Also, one goal with Spring Kofu at least is also supporting GraalVM at least.

They are also adding more platforms to the native target.

Reading between the lines with what was announced last week at Kotlinconf, I expect a lot of this stuff might stay at least partially experimental through the 1.4 cycle (current is 1.3.61) and would expect that they might start pushing harder on backend native stuff around 1.5. Also there are still a lot of question marks around things like WASM where e.g. MS has a more clear strategy with .Net and Blazor.

Thanks a lot for all the info! :)

Problem is that thanks to Android (stuck on partial Java 8 support), and JetBrains plans to put Kotlin everywhere as they try to build a business on top of it (Borland Turbo Pascal style), there is only so much that they can access on the JVM while making Kotlin code portable, specially regarding the Valhala, Panama and Loom roadmaps.

There is nothing keeping them from not making some constructs not portable to certain platforms. Mostly they try to do this with standard language constructs (of course), but for example the 'dynamic' type is completely javascript specific.

This only goes for Valhala. The other examples seem to be java playing catch-up to Kotlin (Panama for Kotlin native and Loom for co-routines).

Co-routines aren't the same as Loom, as they require explicitly code and thus might not interop cleanly with the new Loom thread semantics.

Does Kotlin/Native support multi field value classes?

Yes you can get around portability issues with multiple platform Kotlin, as many other guest languages have tried to.

However then one begs the question why use the language at all, when having to write the same stuff multiple times.

I rather have the JVM, .NET take the OS decision away, not see them as yet another OS to deploy on.

Yes, the upside of one language should be that you don't have to write the same stuff multiple times. But if you don't want the downside of having one common denominator holding you back, then you have to write some parts specifically for each platform. That is the option Kotlin gives you. And my point was that this doesn't necessarily mean it will hold the specific platforms back (which seemed to be your point).

I the company I've been working at in Austin and we've been increasingly choosing Kotlin for our backend services as well. We started with Scala and found the ramp up to be tough. I came from a company that used mostly Ruby before and had no JVM experience at all and I found kotlin really easy to get productive with in a short amount of time. I actually prefer it in many ways not to everything else I had done before (I think I just really like static typing).

I'm curious to know what difficulties you found using Scala and your experiences transitioning to Kotlin, if you are willing to expound upon it.

I have been using Kotlin on the backend for 4 years. I never used it on Android!

That's interesting. I'd be more inclined to use Rust/C++ for the android devices since they are slow and more inclined to use Kotlin on the server because they are powerful :D