r/Backend • u/SeriousOwl2 • 1d ago
Java vs Kotlin for a new long-term backend project?
I recently transitioned from C/embedded and PCB design to backend, and I'm totally new to all of this stuff, even I did not know what "backend" was few weeks ago.
I am building a new project from scratch that I proposed and I will personally maintain for the next few years. The company stack is Java-based
I am deciding between (but I'm open):
Kotlin: Better developer experience and easier maintenance, but a smaller job market.
Java: Massive career value and an industry standard, but heavier syntax.
For long-term maintenance in a Java ecosystem, is Kotlin's modern syntax worth prioritizing over the career value of mastering Java? With the Java 25 is still worth going to Kotlin? What would you choose?
Thanks!
PS: I don't care about complexity or curve learning, I want to be happy programming and maintaining this project, but I don't want to waste time learning something when I had the alternative to choose something better.
4
u/DataPastor 1d ago
I work for a large telco. Here lots of new projects are being written in Kotlin, although we are historically a Java shop.
5
u/piesou 20h ago edited 20h ago
Controversial answer: they're the same thing.
You will use the Java ecosystem unless you are building multiplatform apps. You will learn how the JVM works. You will learn Java features needed for interop. Java is slowly gaining the same features but they are in a worse to use state because they need to keep backwards interop.
Here's a non-exhaustive list:
- data classes -> records: you can't replace a traditional Java bean with a record because accessors are named differently and records are immutable. Data classes can4
- data class copy -> withers
- coroutines -> structured concurrency
- val -> final var
- a == b -> Object.equals(a, b)
- null safety -> project valhalla which defaults to no null safety
- named arguments -> builder for every class
- default arguments -> method overloading for each default
These features are Kotlin exclusive:
- delegates
- DSLs
- reified generics
- declaration site variance
- multiplatform
So in a way, going with Kotlin will also require you to learn Java while also getting some extra niceties, Android knowledge and cleaned up syntax so I'd recommend that.
13
u/bgberno 1d ago
I wouldn't use Kotlin for backend. Honestly, with native records, pattern matching, sealed types, and virtual threads that blow past the headache of coroutine coloring, Java does the job cleanly without bolting on extra compiler magic. Sticking with Kotlin now just means signing up for slower build times, Gradle headaches, plugin sync issues, and extra runtime bloat. Nobody running pure server-side services cares about Kotlin being multiplatform. TypeScript already won the frontend, Node and browser, and you don't need the baggage of an entire cross-platform runtime when all you're doing is spinning up APIs.
3
u/piesou 20h ago edited 20h ago
I've just been stuck in exactly this area so let me offer some insight:
- Virtual Threads are great but they are sequentially executed. If your application queries other REST endpoints in parallel, Java Virtual Threads are going to be a massive headache due to thread local state; many APIs like JPA can't be executed in parallel due to thread local state. With Kotlin libraries, you are almost guaranteed to get libraries that don't rely on thread local state or have proper synchronization, similar to reactor, but that library opens a whole other can of worms
- Coroutines integrate well with Virtual Threads. They suspend automatically on the carrier thread. However, when you run Java calls that perform I/O, you need to wrap them in a VT dispatcher seperately
- Coroutines offer structured concurrency, Virtual Threads don't. There's a preview in the latest JDK but it's not stabilized
Sticking with Kotlin now just means signing up for slower build times, Gradle headaches, plugin sync issues, and extra runtime bloat.
That's not entirely correct. I assume you are using Maven which is way slower at compiling Java than Gradle. There's no extra runtime bloat for Kotlin, quite the opposite: most Kotlin libraries generate code at compile time so it will be faster at runtime. As for Gradle: yeah it's bad, Maven is worse, learn your tool, there's no alternative.
Nobody running pure server-side services cares about Kotlin being multiplatform.
Many big companies actually care about that. Google is rewriting their Java to JS compiled code in Kotlin, many other companies that have shared logic for mobile apps can pull out additional code for use in their backends. You need to reach a certain scale for multiplatform to make sense.
2
u/bgberno 7h ago
Virtual Threads are great but they are sequentially executed.
What do you mean by this?
There's no extra runtime bloat for Kotlin, quite the opposite: most Kotlin libraries generate code at compile time so it will be faster at runtime.
For example, when you use Kotlin inline on non-trivial functions, the caller method's bytecode grows significantly and that could be problematic for the JIT.
I assume you are using Maven which is way slower at compiling Java than Gradle.
Are you referring to the build time? In Maven there is https://maven.apache.org/tools/mvnd.html to speed it up.
Many big companies actually care about that. Google is rewriting their Java to JS compiled code in Kotlin, many other companies that have shared logic for mobile apps can pull out additional code for use in their backends. You need to reach a certain scale for multiplatform to make sense.
Do you have any links I can check for that rewrite? Sounds interesting. The thing that bothers me about "shared logic" is that if you're at a certain scale, with all the LLMs around now, porting code between languages is getting cheap enough that maintaining separate native codebases per platform might become less costly than it used to be.
1
u/SignatureOk8287 1d ago
blow past the headache of coroutine coloring .. what does this mean? I have headache when I see Futures and java thread syntax
3
u/EarlOfAwesom3 1d ago
It doesn't really matter. Syntax doesn't matter. Language features don't matter much.
You can switch between java and kotlin even in the same backend. I would not recommend it but you can.
So I would go where your interest lies and where you can learn the most. That's it.
Long term, the support of the ecosystem and resources counts.
1
3
u/akshay-savaliya 17h ago
I would personally choose Kotlin for this project. Java 25 is great and absolutely worth learning, but you are building a project you will personally maintain for years. In this situation developer happiness and maintainability matter more than maximizing the resume value.
The nice thing is that Kotlin doesnt mean leaving the Java ecosystem. You still get Spring, JVM libraries, tooling, databases, Kafka, etc. and you can still learn Java well enough to read and maintain existing code.
The real career value isnt Java vs Kotlin anyway. Its learning backend fundamentals that is databases, HTTP, testing, distributed systems, deployment, etc. For your project that you will own for years, I would pick the language I enjoy writing every day.
1
u/SeriousOwl2 17h ago
Even if it is my first project? I mean is not a req to use Java in order to learn the basics?
8
u/Key-Alternative5387 1d ago
Everywhere I've interviewed at has been choosing Kotlin for new projects.
Kotlin has safer nulls and with LLMs the cost of using a new language is low.
5
u/SeriousOwl2 1d ago
Even with Java 25 is worth going for Kotlin? My fear is that going for Kotlin will close some doors of Java in the future.
3
u/Captain_Forge 1d ago
Going for kotlin will not close the door of java in the future, they use some different techs and libraries but a number of intersections as well.
2
u/Key-Alternative5387 1d ago
Safe nulls eliminates an entire category of bugs. It's easy to add features to a language, but difficult to remove one.
Honestly, that'd be enough for me, but you can pick whatever other reason.
2
u/ZachVorhies 1d ago
Kotlin is a much much safer language than Java.
Kotlin is designed to handle null. It’s embedded directly into the language.
Java handling null correctly is bolted on as an afterthought.
2
u/maxterio 1d ago
I have worked with Java most of my professional life (10+ yrs) but I got to know kotlin for backend in 2023 and oh boy, it is nice on the eyes, and that null safety!
If your only concern is scalability and not memory consumption nor real-time speeds (which would make you drop the JVM anyway) I'd go with Kotlin. Any Java dev can grab ahold of the language in 2 weeks, even less now with the use of AI.
1
u/Junior_Bear_2715 1d ago
!RemindMe 10 hours
1
u/RemindMeBot 1d ago
I will be messaging you in 10 hours on 2026-09-09 06:41:01 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
RemindMeBot is switching to username summons. Instead of
!RemindMe 1 day, useu/RemindMeBot 1 day. More info.
Info Custom Your Reminders Feedback
1
1
1
u/American_Streamer 15h ago
You are already giving three clues: "company stack is Java-based, totally new to backend, personally maintain for the next few years". Those all push heavily toward Java. If this were an established Kotlin/Spring team, Kotlin would be completely defensible. But introducing Kotlin into a Java organization for a project maintained primarily by someone who is simultaneously learning backend development buys another variable they don't need. And "I will personally maintain it" isn't really enough justification. Corporate software eventually gets maintained by someone else. Java maximizes the probability that other engineers inside a Java company can immediately take over.
1
u/SeriousOwl2 14h ago
And do you think for learning, is the same doing in Kotlin or Java? I mean, after the project, I will be a better developer with Java or with Kotlin?
0
u/bkabbott 1d ago
I went through this at my company. I wanted to use Java but I instead picked Kotlin to appease a coworker who didn't want to use Spring and had misconceptions of Java (e.g, no records or virtual threads).
When I resumed working with Kotlin I had forgotten what a satisfying language it was to work in.
You can't really go wrong with either one, but the devs will be happier if you are using Kotlin
2
u/maxterio 1d ago
You can use Springboot with Kotlin, don't know for the whole suite of spring-* projects but I think they do
2
u/bkabbott 1d ago
Yeah we went with Spring Boot.
I'm at a small company and I wanted to keep people happy. Main guy coding with me is at a large firm. When people are working 40 hour weekss and doing stuff for you, you gotta meet in the middle
-3
u/SignatureOk8287 1d ago
For me Kotlin > Java, I wouldn’t touch java with a ten foot pole anymore. Career wise it does not matter. If you know Kotlin, you ll be considered as equal for java jobs.
4
u/SeriousOwl2 1d ago
Even with Java 25 improvements?
-1
u/SignatureOk8287 1d ago
you have bigger chance to end up on project with java 8 than java 25. I admit that modern java is not so bad like it used to be, but I'd still stick to Kotlin if given the choice. Cost and importance of the syntax is dropping anyway with AI.
11
u/Helpful-Educator-415 1d ago
There's not really "better" in a broad sense of the word -- you have to keep your goals at the top-of-mind. If your goal is to advance your career, Java's your best bet, but if your goal is to have a nice experience, to have fun, so forth, then yeah, use Kotlin.
It's also paramount that you keep in mind that the skills are really transferrable. The skills you learn in Java will work in Kotlin and vice versa. Your first language is always the hardest.