Out of curiosity, how many of you are using Kotlin for backend development? It seems that Java has caught up a bit, and the advantages of Kotlin (extension methods, better syntax, better null-checking) might not be enough to justify the risk of lock- in?

Personally, I quite like Kotlin, but I haven't been able to convince most of my greybeard colleagues to make the leap.

▲ Tmpod 2 days ago | parent | next [-]

I think those features are quite good on their own, but Kotlin has many more worthy features, such as sealed hierarchies, import aliases, delegation, operator overloading, default arguments, named arguments, reified generics, inline value classes (though somewhat limited by JVM features still), a very nice stdlib (in part augmenting Java's stdlib), etc. Even newer stuff like context parameters are really interesting and have useful applications.

The language ends up being more complex, but I find it a joy to use; going "back" to Java projects always leaving me wishing I could use Kotlin instead :P

Yet it's true, Java has improved quite a lot in the last decade. It is ahead of Kotlin in a few things, like pattern matching (though not incredible, it's still better than the nigh nonexistent support in Kotlin).

▲ Defletter a day ago | parent [-]

Kotlin can be fairly pleasant to write but it's so incredibly unpleasant to inspect. For example, Ktor is the Kotlin backend framework, but good luck figuring out how any of it works. It's a complete mess of "higher-order functions", extension methods, and other abstraction-hell as to make it extremely difficult to figure out what is executed when and under what circumstances. Basic Kotlin code is fine, great even, but once people stop writing Kotlin as Java developers, but as Kotlin developers, then it goes downhill fast.

▲ Tmpod a day ago | parent | next [-]

Can't speak about Ktor in particular, but most DSLs I've used are essentially just syntax sugar for the builder pattern, stream-like APIs and so on. I don't think it's bad per se, you just have to think a bit differently when you're inspecting code.

But again, could be wrong about Ktor specifically.

▲ jackpeterfletch 19 hours ago | parent | prev | next [-]

Interesting. Coming from Spring to Ktor, being able to easily inspect the internal workings has been one of my favourite bits!

It’s ‘advanced’ kotlin in there for sure, and takes some learning of the internal plumbing, but having everything not hidden behind annotations has been great.

Just a CMD+click on whatever Ktor DSL/plugin API your using and you can immediately start to follow along / debug what it’s actually doing.

	▲	Defletter 10 hours ago \| parent [-]
		Oh absolutely. I admittedly haven't used Spring beyond trying it out for a couple hours and deciding never again, but I can easily imagine Ktor being an improvement over Spring. When I wrote my comment, I was more thinking about it in comparison to Netty and Java-Websockets (relevant: https://news.ycombinator.com/item?id=43800784), rather than as a web framework, though I have used it as such. Netty is also a struggle to inspect so perhaps I just struggle with deep abstraction in general? I find code to be far better documentation than actual documentation, particularly when so much of it is along these lines: `/** * Gets the next string. * * @return Returns the next string, or null. / public abstract @Nullable String getNextString();` This documentation is entirely unnecessary because everything it says is present within the method signature. But say you have an abstract method that users override to handle incoming data, often documentation will not contain things like: whether the ByteBuffer is a slice or the whole buffer at a particular offset; or whether the buffer is a copy or a view; etc. So I end up doing a lot of defensive copying which is possibly* unnecessary, but because it's very difficult to figure out where that buffer is coming from without first trudging through a seemingly endless forest of abstractions first.

▲ qcnguy a day ago | parent | prev [-]

[dead]

▲ ragnese 2 days ago | parent | prev | next [-]

EDIT: Forgot to confirm that I do, in fact, use Kotlin for a fairly large and moderately complex backend system (multiple deployed systems, including one HTTP REST-ish API).

I'm of two minds about it.

I started working with Kotlin back when Java was still a very ~~stagnant~~ stable language. I definitely find Kotlin's syntax to be much more comfortable, expressive, and in many ways much more simple than Java's.

But at this point, the only big technical features that still put Kotlin over Java for me is the handling of nulls by the type system (which is, admittedly, mitigated decently well in practice by Java tooling configurations and ugly annotations), and value types (zero heap-allocation wrapper classes).

Another thing to keep in mind is that now that Java is actually adding features again, the Kotlin developers will have to also play "catch-up" to Java in ways that it didn't have to when it first gained popularity. It puts Kotlin in an awkward spot when Java's implementation of sealed classes and interfaces was initially better and more flexible than Kotlin's, or when Java's `switch` is now more powerful than Kotlin's `when`, etc.

Kotlin is also betting heavily on their multi-platform stuff, which I'm skeptical about. It seems to me that it will further slow the ability to add useful features to the language if you have to cater to the lowest-common-denominator between Java and JavaScript (and Objective-C? -is that how it works for iOS?) runtimes. Instead of being the best language for a given platform, it'll just be a pretty good language for a few platforms. I wish them all the best in dethroning JavaScript from infecting every computing platform and domain, but I'm just skeptical.

So, honestly, I don't actually recommend people start new projects in Kotlin. I'd suggest going for Java, or something that's meaningfully different in semantics and philosophy like Clojure or Scala. I say this, but I'm not actually sure that I'd be able to follow my own advice, because I really don't want to have to stomach Java's syntax, idioms (way too many annotations), and stupid null handling.

▲ vips7L 2 days ago | parent | next [-]

>but at this point, the only big technical features that still put Kotlin over Java for me is the handling of nulls by the type system

Soon (tm): https://openjdk.org/jeps/8303099

The one feature that keeps me in Java, albeit not popular, is checked exceptions. I far prefer checked errors over checked nulls if I have to make a choice.

▲ Defletter a day ago | parent | next [-]

While I am definitely impatiently waiting for null-restricted types, what I feel Java really needs overall is ergonomic handling syntax, notably: "safe calls" (https://kotlinlang.org/docs/null-safety.html#safe-call-opera...), "elvis operator" (https://kotlinlang.org/docs/null-safety.html#elvis-operator), and inline catching (https://ziglang.org/documentation/0.14.1/#catch).

Relevant: https://news.ycombinator.com/item?id=44672787

▲ vips7L a day ago | parent [-]

Yeah I’ve writen about error handling syntax here a bit: https://news.ycombinator.com/item?id=44551088

https://news.ycombinator.com/item?id=44432640

It’s actually my #1 issue. I hate not knowing about error conditions and no one in Java uses checked exceptions because the language syntax for dealing with them sucks. Brian had a proposal for handling exceptions in switch but it seems to have died in the water.

Part of me secretly hopes Swift takes over the world because they have a typed throws that works and handling errors is a breeze.

▲ Defletter a day ago | parent [-]

While I am certainly a fan of Swift's error handling and think it'd be an improvement to Java's current state of affairs, I do think that using null as an error analogue is... unwise. What happens when a function is throwable but also may return null? How do you determine whether the null is a coerced error or a valid return? Or rather, how do you do this without returning to the un-ergonomic try-catch? Zig solves this by having errors and nulls be separate parts of the type system which you can deal with separately and inline.

▲ vips7L a day ago | parent [-]

You don't coerce it. You don't care in that situation. That's the whole point. You're saying you don't care and are going to use null. If you care, you don't use try! you do the more verbose catching:

    let i: Int?
    do {
        y = try someThrowingFunc()
    } catch SomeError.err {
        y = nil
    } catch SomeError.youCareAbout {
        //
    }

▲ Defletter a day ago | parent [-]

You misunderstand. In the question given, we don't care about the error, only that an error having occurred is detectable. In Rust, this would be represented as: Result<Option<ExampleType>, ()>, whereas using try? would reinterpret the error as a null, so there's no way to tell the difference between an error-as-null and a returned-null.

This has consequences for config parsing, for example, where a particular subsection (sub-object? keyed struct?) may be optional, so it being missing is perfectly legal. But if you use try?, then there's no way to distinguish between it simply being missing and it being present but malformed. It unfortunately seems like the only other options in Swift is to propagate the error, or revert back to verbose try-catch blocks.

Whereas, in Zig, you can do inline catching and care about the error only as much as you want to, for example:

    // This is equivalent to Swift's try
    const i: ?i32 = try someThrowingFunc();

    // This is equivalent to Swift's try?
    const i: ?i32 = someThrowingFunc() catch null;

    // This is a yielding inline catch block that does not care about the error
    const i: ?i32 = someThrowingFunc() catch brk: {
        logger.warn("Something went wrong!");
        break :brk null;
    }

It's not perfect, I don't love the block-label-break thing, but I much prefer this if only because then the variable can be defensively const, which I do not believe is possible with the kind of code snippet you provided. Also, instead of breaking out, it could capture and return the error or return a new error. It's incredibly versatile.

▲

vips7L a day ago | parent [-]

I’m not misunderstanding. You weren’t making a point about _verbosity_ originally. You were talking about distinguishing errors you care about; which is perfectly possible, you don’t use the construct that says “I don’t care what error it is”.

	▲	Defletter 12 hours ago \| parent [-]
		I did ask "Or rather, how do you do this without returning to the un-ergonomic try-catch?" but I don't want to die on this hill. Can I just assume then that this distinction isn't possible in Swift without returning to try-catch blocks?

▲ ragnese 19 hours ago | parent | prev [-]

I'm with you when it comes to checked exceptions. I have several ranty comments on this site about how everyone has been wrong to cargo-cult hatred of the feature for the last decade or so.

But, I'd still rather have safe/correct null type checking, because at the end of the day, I can always write MY code to return a Result/Try/Either type instead of throwing unchecked exceptions for expected business logic "failure" paths.

▲ ItsHarper a day ago | parent | prev | next [-]

It's not compiling to Objective-C, it's compiling to machine code with a garbage collector packaged in, (similar to go, I think it would be fair to say).

▲ esafak 2 days ago | parent | prev | next [-]

I do, because the Java ecosystem (which includes its programmers) is always going to have one foot in Java 8; it's the prototypical enterprise language.

	▲	ragnese 2 days ago \| parent [-]
		That's a fair point. You don't have to write Java with giant graphs of objects-in-objects-in-objects and heavy mixing of (often mutable) data and logic in the same classes, but it's hard to deny that the culture, conventions, and idioms in the Java ecosystem can be quite different from the culture, conventions, and idioms in Kotlin. On the other hand, when I see Kotlin code that's not written by JetBrains (especially on the backend), it often does just look like Java code with cleaner syntax...

▲ clumsysmurf 2 days ago | parent | prev [-]

I am also worried about the concurrency side of Kotlin. Since Roman Elizarov, the architect of the coroutine / flow implementation, left JetBrains two years ago, it seems to be stagnant. Looking through the tracker conversations I almost get the impression whoever inherited it doesn't know where to take it next.

▲

ragnese 2 days ago | parent | next [-]

That's a whole huge can of worms, too. Coroutines and the suspend keyword were a great innovative feature at the time (very clever implementation on the JVM and good API design given the limitations of the implementation and syntax design constraints), but now that Java has so-called virtual threads, you don't "need" Kotlin for convenient(-ish), simple(-ish), scalable, structured concurrency like you used to, either.

One could rightly debate over whether Kotlin's coroutines design and APIs are better than Java's virtual threads for writing asynchronous code. But, at the core, the story used to be that Kotlin had coroutines and lightweight structured concurrency "built-in" (with a blessed first-party helper library for the actual concurrency part) and Java did not have anything that accomplished the same goals. Now it does.

	▲	qcnguy a day ago \| parent [-]
		[dead]

▲

gavinray 2 days ago | parent | prev [-]

Vsevolod Tolstopyatov (https://github.com/qwwdfsad) is the other brain behind Coroutines, Concurrency, and Atomics in Kotlin, and he's still very much active.

▲ frevib 2 days ago | parent | prev | next [-]

We introduced Kotlin at ING (15k IT colleagues) years ago and adoption rate is 11% and growing: https://medium.com/ing-blog/kotlin-adoption-inside-ing-5-yea...

Many larger companies in The Netherlands have moved away from Scala and Java and use Kotlin now. The switching costs are neglegible and the benefits are big.

The problem with Kotlin is, you don’t want to go back to Java.

	▲	litmus-pit-git a day ago \| parent [-]
		Hey. Do you folks have office in India or are you hiring remote for Kotlin? (esp. someone from Android bg but pretty decent at general Kotlin; and also at Java)

▲ glasskaar 2 days ago | parent | prev | next [-]

My workplace of ~3k employees has Kotlin as the golden path for our backend services. We previously mainly used Java, but I think it's been Kotlin for almost every new service since 2018. I think it works great for us.

▲ kevinherron 2 days ago | parent | prev | next [-]

We use it for (non-Spring) backend development. It's lovely and always my first choice over Java.

I like to avoid mixing Java/Kotlin within the same module when I can, but it still works, and parts of our codebase are mixed this way. (by module I mean e.g. the same Maven or Gradle module, i.e. try to avoid a situation where you have a `src/main/java` and `src/main/kotlin` next to each other)

	▲	selimco 2 days ago \| parent [-]
		You can put kotlin code in src/main/java

▲ simon_void a day ago | parent | prev | next [-]

at the (semi-state owned) company (in Germany) I work at, Kotlin is a first-class language also for backend. It depends on the teams wheather they prefer Java or Kotlin. I'm firmly in the team-Kotlin camp and Java code that becomes my responsibility has the strong tendency to suddenly become Kotlin code. By the way, I never worked on Android, so all my Kotlin work (since 2019) was server-side Kotlin.

Java is getting better, so maybe in 10 years it'll be a less ergonomic Kotlin variant.

PS: Jetbrains - the company behind Kotlin - started a strategic partnership with the Spring team, to make the combo Kotlin-Spring even better: https://blog.jetbrains.com/kotlin/2025/05/strategic-partners...

PSS: Jetbrains is actually working on an official Kotlin-lsp server: https://github.com/Kotlin/kotlin-lsp So devs in the near future won't be locked into the IntelliJ ecosystem, if that is a concern of yours.

▲ Traubenfuchs 2 days ago | parent | prev | next [-]

One of our ex developers was a big kotlin fan and enabled it in every java/maven project he touched -that is actually quite easy and interoperability between java and kotlin is fine. He also refactored every class he touched to kotlin. After he left, no one else was really into continuing his work. Our mobile devs use kotlin though and they are happy.

I'd say it's nice and I would actually start every new (spring/java) project I do in kotlin now. But for existing projects, I actually see no value. It does not magically make code easier to understand and it doesn't reduce bugs, it's just a bit more fun and challenging to write and pads your resume...

We did have one issue where upgrading the kotlin version from 1.x to 2.x in a project broke all depending projects due to a classfile version issue though. I deferred it by just forcing the version back to 1.x. That's the kind of annoyance you can encounter.

	▲	simon_void a day ago \| parent [-]
		I know one of these developers as well! It's me :D

▲ mx_03 2 days ago | parent | prev | next [-]

We use it for backend. F500 company.

There is almost no locking with Kotlin. You can stop writting Kotlin code any time and start writting Java code.

However I think it's not possible to call coroutine code from Java.

▲ jasonmarks_ 2 days ago | parent | prev | next [-]

I do not have an opinion on if Kotlin is great as a backend for every project. Kotlin does excel as a pick for projects where you are also compiling for native mobile front ends.

Write a Kotlin multiplatform client side business logic module in tandem with your Kotlin backend. The multiplatform module compiles for both your Android and Apple environments and for extra flexibility you are able to quickly port code from the client business logic module to the backend (or vice versa).

▲ stefs 2 days ago | parent | prev | next [-]

i use kotlin at work mainly for frontend development, but i choose it for almost all projects i have control over (i.e. personal projects which are usually backend development and smaller scratch-an-itch tools at work). that said, i haven't re-evaluated pure java in a long time, but i'm pretty sure i'd still miss many of kotlins features.

▲ RamblingCTO 2 days ago | parent | prev | next [-]

We did and it's awesome. Normal SaaS startup-sized codebase. Migrated from java maybe 4 years back. Was so perfect that you could migrate file by file. Later on we split up the codebase via gradle modules. Very very happy with that! Java will never get where kotlin is. It's a perpetual catch up game.

▲ killingtime74 2 days ago | parent | prev | next [-]

Atlassian uses Kotlin extensively. Thousands of developers working on JIRA, Confluence and other associated products.

▲ darthrupert 2 days ago | parent | prev | next [-]

As a Rust enjoyer, I wouldn't get into Java at least without being forced to (better is not good enough in this case), but Kotlin seems neat. The only thing that has been blocking trying it out is that the non-IntelliJ experience has been rather poor.

▲ rileymichael 2 days ago | parent | prev | next [-]

i've been writing kotlin since 1.0 (2016) and my past few jobs have been at startups using kotlin entirely on the backend. it's really enjoyable, there isn't another language with as good of a development experience due to Jetbrains controlling both sides.

coroutines are the biggest downside imo. they're great for android and other environments, but now that we've got loom on the jvm they're needlessly complex (accidental blocking calls, coloring, headaches with libraries that use thread locals, reentrant lock, etc.)

▲ esafak 2 days ago | parent | prev | next [-]

I've never heard of language lock in. The source is here: https://github.com/JetBrains/kotlin

Come in; the water is fine.

▲ jillesvangurp 2 days ago | parent | prev | next [-]

I'm a bit opinionated here and I know some people will disagree. But being a grey beard myself (50), I don't disagree with your sentiment here. People tend to get stuck in their ways as they get older. And I've observed a lot of people my age resisting anything new (languages, frameworks, anything that's newer than what they learned 20 years ago.

Working with younger people exposes that quite mercilessly and I can recommend doing that if you catch yourself doing a lot of repetitive projects with people well over 40. Try something new if you want to stay relevant. Move on if your colleagues can't deal with that. It's only going to get worse with them.

I've been using Kotlin with Spring boot for backend development since 2018. I did Java before that; since 1995. Java has indeed improved and was probably nudged along by what Kotlin and Scala and other languages have done. But it hasn't really caught up properly IMHO. Everything Kotlin does right out of the box (intentionally, to fix what Java did wrong here), Java continues to do wrong out of the box and this is actually a big deal because it does a lot of important stuff wrong mainly for compatibility reasons. That's the big biggest difference. These are things that Java cannot fix in a backwards compatible way. That alone is a good reason to switch.

Examples of this are that it makes code less null safe, non final, introduces unnecessary mutable state, etc. Kotlin allows you to do these things when you need to but it defaults to things being closed, final, val (instead of var), etc. And these are just things that Kotlin has been doing right since it's first releases. It has progressed a lot since then.

If you like verbosity and don't want access to the countless convenient extension functions, DSLs, co-routine support, etc. that e.g. Spring ships for Kotlin, go for Java. In they end you kind of do the same things. But IMHO in a needlessly verbose and clumsy way.

But you are missing out. IMHO anything to do with Spring Flux is just an order of magnitude easier via Kotlin and co-routines and IMHO even attempting to use that from Java is misguided. But in Kotlin, you can hardly tell the difference with non reactive code. With Java, this turns into a mess of leaky abstractions, function chaining, and lots of boiler plate. Our server is effectively using only a handful of threads with lots of websockets, connections, background processing etc. happening.

Reactive/async stuff across all of the mainstream Java server frameworks is well supported from Kotlin and has been for many years. E.g. the co-routines library ships with lots of extension functions for just about anything you can name. The green thread stuff Java does is often cited as a thing that closes the gap. But from a Kotlin point of view it's just something that makes using legacy Java code a bit less tedious.

Jetbrains and Spring did some joint announcements at the latest Kotlin conf. The upcoming major release of Spring Boot is going to be even more Kotlin heavy and centered than the current one is. And honestly, you had a superior experience with v1 way back even. They won't abandon Java support. But at this point, you are really missing out if you are sticking with Java. There are non technical reasons for doing that but very few (if any) technical reasons.

They are doing a big push with the new release on making nullability checks on all the Spring Java stuff stricter for Kotlin and making sure Kotlin does the right things. And all their documentation was already dual Kotlin/Java but looks like it might be leaning towards Kotlin first going forward.

Many reasons to like Kotlin. If somebody tells you it's Android only that was never true and there's a lot of quiet Kotlin usage with anything Java because there's not a single Java framework that you can't seamlessly use from Kotlin. And almost universally it's a better experience. The older the better actually. Because the old one tend to not use any of the new Java features. Where new is introduced in the last 15 or so years.

▲ dzonga a day ago | parent | prev | next [-]

kotlin is nice for backend development if you're using quarkus or springboot.

don't use ktor etc where some people wanna take their scala religion and put into kotlin.

kotlin is nice is you keep is super simple. use it the same way as you do Golang and you will find it pleasurable.

▲ LennyWhiteJr 2 days ago | parent | prev | next [-]

Almost my entire org uses it for backend server development at Amazon. There is very strong support for Kotlin support within the Amazon dev community.

▲ corytheboyd 2 days ago | parent | prev | next [-]

Been in a weird position where I had to learn Java real fast, then learn Kotlin real fast to replace it. I find Java to be so incredibly unproductive compared to Kotlin, for all the reasons a sibling comment listed. I mean come on, default argument values and named input parameters are table stakes— it kills off the billion overloads, billion positional arguments, annd builder pattern nonsense all at once. Kotlin immutability by default is fantastic, I am 1000% behind default immutable data structures. The stupid, awful nullability madness disappears (mostly, need to train people to never use ! and !!). I appreciate Java, it got us to Kotlin, but Kotlin is ACTUALLY FUN to use, and expresses all ideas I have cleanly. Less, cleaner code just makes things easier to maintain, full stop.

▲ jamesgasek 2 days ago | parent | prev | next [-]

It is used extensively at Amazon

▲ gavinray 2 days ago | parent | prev | next [-]

Raises hand

▲ sannysanoff 2 days ago | parent | prev [-]

when you do LLM-assisted coding in Kotlin, it burns 2-3 times less tokens than Java!

PROFIT!