6 ms·

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 met

• glasskaar 1y ago
  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.
• Traubenfuchs 1y ago
  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 1y ago
    I know one of these developers as well! It's me :D
• Tmpod 1y ago
  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 1y ago
    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.
    • qcnguy 1y ago
      [dead]
    • Tmpod 1y ago
      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 1y ago
      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 1y ago
        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 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.
• jillesvangurp 1y ago
  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.
• darthrupert 1y ago
  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.
  • simon_void 1y ago
    this will change, Jetbrains is working on a Kotlin-LSP, just don't expect it to be done anytime soon: https://github.com/Kotlin/kotlin-lsp https://github.com/Kotlin/kotlin-lsp
• killingtime74 1y ago
  Atlassian uses Kotlin extensively. Thousands of developers working on JIRA, Confluence and other associated products.
• gavinray 1y ago
  Raises hand
• stefs 1y ago
  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.
• frevib 1y ago
  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-years-later-df6421b14dc4 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 1y ago
    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)
• ragnese 1y ago
  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.
  • clumsysmurf 1y ago
    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.
    • 1y ago
• kevinherron 1y ago
  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 1y ago
    You can put kotlin code in src/main/java
• LennyWhiteJr 1y ago
  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.
• esafak 1y ago
  I've never heard of language lock in. The source is here: https://github.com/JetBrains/kotlin https://github.com/JetBrains/kotlin Come in; the water is fine.
  • smokel 1y ago
    There are many systems written in Cobol, Delphi, C++, that would really benefit from not being written in those languages. There are serious headaches to be had when you have to maintain software for ten years and up. Porting systems to another language is often terribly expensive.
• jasonmarks_ 1y ago
  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).
• mx_03 1y ago
  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.
  • cogman10 1y ago
    Exactly why we use it. Our java devs have been able to pickup and start writing kotlin. None of them have regretted it that I've seen. It's extremely close to Java in terms of most concepts. That makes it an easy language to switch into and out of. It's java with a nicer syntax and more sugar.
• sannysanoff 1y ago
  when you do LLM-assisted coding in Kotlin, it burns 2-3 times less tokens than Java! PROFIT!
• corytheboyd 1y ago
  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.
• RamblingCTO 1y ago
  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.
• jamesgasek 1y ago
  It is used extensively at Amazon
• rileymichael 1y ago
  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.)
• dzonga 1y ago
  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.
  • simon_void 1y ago
    i've used ktor for 2 small-ish microservices. It's fine. I was curious about corouitnes. I know SpringBoot has support for corouitnes as well, but in ktor it's front and center. (Disclaimer: I never used Scala)
• simon_void 1y ago
  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-partnership-with-spring/ 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 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.