I hope I see Jetbrains pay more attention to Kotlin/Native, and try to make Kotlin more independent of Java and “stands on its own”.
Most startups are turning to Go instead of Kotlin because of that, they do not want to deal with JVM and Gradle.
1 Like
Good article. I’m still enjoying the kotlin experience but feel it only works for me because I have decades of java experience. For a newcomer or startup without such experience, it would be quite the challenge.
Would also be interesting to see the performance comparison with java21 virtual threads in place.
As a small development team we don’t have the luxury of building a spring replacement. Long live Spring!
1 Like
My personal opinions:
the era of the JVM is coming to an end
The JVM is not going anywhere in the near future. I wish I had that much money how many times I have heard that “Java is dead”.
Nowdays it gained even more momentum, partly because Oracle’s panic because of Kotlin’s popularity.
Just take a look at GraalVM to realize how diverse the JVM ecosystem has become.
ReactJS and Typescript
Golang
Rust
Good luck writing quality and maintainable code with so many languages and frameworks (or even managing a team developing with such diverse technologies).
I’m a Java and Kotlin veteran, and even I read new info day by day. These days you cannot know everything, if you say that “I will use Rust for this problem instead of Kotlin” then
- either the problem is very small or very specific
- or you will run into trouble soon maintaining the code and/or your ecosystem
- (or you are a genious
)
In short, it standardizes on some libraries in the Go ecosystem for things like Logging, DI, etc
It is relatively easy to write new frameworks and libraries based on the experience of old (Java 
) ones.
The real challenge is to provide long-term support for them, and Java shines in it.
These Go libraries will get old in 4-5 years too, and you will have the same “problems” you think you have now “because Java/JVM is outdated”.
This article is 3 years old and and the JVM is still not obsolete
I don’t know the author but I think that she/he has not much experience with maintaining and supporting complex software products for a long-term…
My opinion is that multiplatform development is very hard, and Kotlin seems to solve it successfully. We should not underestimate the advantages of having the same language (and ecosystem) on the server, client, build system, your scripts - everywhere.
You can find high-quality Kotlin developers easily but you will struggle to find one having strong and deep Go/TypeScript/Rust/etc. knowledge. (And this is only the coding part… you have to know the whole ecosystem to successfully develop a non-trivial software: packaging managers, DevOps, monitoring, optimization, etc.)
4 Likes
I certainly wasn’t the one who stated the era of the JVM is coming to an end.
Read this recently and agreed
1 Like
Many of the reasons it lists are more about to the JVM runtime, the standard library, third-party libraries, and the general Java ecosystem — and so apply in a large part to Kotlin (and to an extent to other JVM languages as well).
However, the article is careful not to mention any of that, and refers only to the Java language itself…
1 Like
Yes, Java is not going to die, people will still using it, but that is not true for Kotlin.
Kotlin is a JVM language, like Scala and Groovy, if Java improves there will be no reason for using Kotlin anymore, that is why I said Kotlin needs to stand on its own, and the future of Kotlin multiplatform is uncertain.
Do not make Kotlin hard to use thanks for Gradle and Java, plus give them an independent reason to use Kotlin, not something like a ‘better Java’.
What you showed is talking about Java and not Kotlin, Java improves so fast.
plus give them an independent reason to use Kotlin, not something like a ‘better Java’.
I don’t know about your use-cases but Kotlin is really a “better Java”, and it is often enough to adopt it.
If you have worked on large Java projects with larger teams, you know that Kotlin is a much expressive language, and it is easier to read Kotlin code than Java code. And because you can migrate to Kotlin incrementally, it is often worth the effort to do it.
Besides, there are many “independent reasons” to use Kotlin instead of Java, Jetbrains is working hard on it, for example:
- KMP
- official Android language (with Kotlin-only frameworks and libraries, like Compose)
- official Gradle language
- multiplatform with future-proof targets like WASM
- scripting
- Kotlin Jupyter kernel
- a wanna-be Python alternative (etc. for data science: Kotlin for data science | Kotlin Documentation)
- etc.
Do not underestimate the advantage that all your team members work more comfortably in all of these environments!
Do not make Kotlin hard to use thanks for Gradle and Java
However, the article is careful not to mention any of that, and refers only to the Java language itself…
In the context of Kotlin, when we talk about Java we often mean the “Java ecosystem”, so the JVM and the JVM-compatible libraries. So with its JVM support, Kotlin is not “harder” but it can be adopted more widely.
Gradle
If you are not building a trivial toy project then you need a standard build system.
Show me another build tool with Gradle’s flexibility and popularity, backed by a company focusing exclusively on their build tool (otherwise large companies will not use it).
I really hated Gradle with Groovy but since Gradle uses Kotlin by default, it is much-much better to use it.
Of course I admit that there are problems with it but these are known by both Gradle Inc. and Jetbrains, and they try to make it better, for example:
1 Like
I don’t know about your use-cases but Kotlin is really a “better Java”, and it is often enough to adopt it.
If you have worked on large Java projects with larger teams, you know that Kotlin is a much expressive language, and it is easier to read Kotlin code than Java code. And because you can migrate to Kotlin incrementally, it is often worth the effort to do it.
Yes, for now Kotlin is a better Java, but Java improves so fast (especially after Google announced that Kotlin is the official language for Android) so that actually not going to be true in the future, and non-Java programmers are not looking for a ‘better Java’, they are looking for a better programming language, what I see here that most of Kotlin programmer are ‘Java’ developers, on the other hand most non-Java programmers are learning something like Go or Rust, It is difficult to convince non-Java programmers to learn Kotlin mostly for two reasons, the JVM and Gradle.
Besides, there are many “independent reasons” to use Kotlin instead of Java, Jetbrains is working hard on it, for example:
- KMP
- official Android language (with Kotlin-only frameworks and libraries, like Compose)
- official Gradle language
- multiplatform with future-proof targets like WASM
- scripting
- Kotlin Jupyter kernel
- a wanna-be Python alternative (etc. for data science: Kotlin for data science | Kotlin Documentation)
-
KMP targets the JVM for desktop applications, and that is reason enough not to use it, and Jetbrains makes it difficult to use Kotlin and KMP without its paid ‘Fleet’ IDEA, so most people will going to use the-completely-free flutter instead.
-
Well, that is a good reason, but in this case, the scope of Kotlin’s use will be limited to Android applications, and most companies currently turning to cross-multiplatform techniques and the Native market is in continuous decline, unless Jetbrain makes KMP special and better than flutter (which is something hard, the community of flutter is strong and they push flutter even harder. ) and do not force people to use its Fleet, it will not have a chance.
-
I do not know how Gradle is “independent reason”, it could be a reason for Java developers, Groovy is also can be used and it’s already dead.
-
I do not know a programming language that is not targeting WASM actually, flutter will going to target wasm, Java also will going to do that, look at GraalVM.
-
I do not see scripting and Kotlin Jupyter are good reasons to learn a heavy language like Kotlin, and if you learn Kotlin, you will eventually have to deal with Gradle, JVM and Java.
-
If someone wants to learn a programming language for data science, it will be Mojo and python.
If you are not building a trivial toy project then you need a standard build system.
Show me another build tool with Gradle’s flexibility and popularity, backed by a company focusing exclusively on their build tool (otherwise large companies will not use it).
- Toy projects for real? And what I see that there is a lot of programmers who hate Gradle, in the first place why Amper was created? Most who left Kotlin left because of Gradle and the JVM.
From Java/Kotlin to Go(Golang). I’m moving from JVM to Go(Golang)! | by Denis Sazonov | Medium
Again, for you as a Java developer, Kotlin is a Joy (for me too actually, i love kotlin but I hate gradle and the JVM), but for non-Java developer there is no reason to learn it, if I want a good backend language, I will choose Go for sure, If I want a cross-platform language it will be dart and flutter, and if Java gets better (and it will happens thanks to Kotlin xd) there will be no reason for the ‘Java’ developers to learn Kotlin anymore, look at Scala and Groovy and you will see what is going to happen if they did not do anything about that.
Until Java has:
- extension functions
- better lambda syntax
- extension properties
- reified types
- coroutines
I’ll stick with Kotlin. IF Java adds all of the things I mentioned… well then I’d certainly consider switching to it, since IntelliJ seems a lot more responsive when coding Java, compared to coding Kotlin.
1 Like
I generally agree with you, but the question is if this is bad or maybe rather good. From the developer and the community perspective, if Java improves to the point Kotlin becomes kind of obsolete, then this is good, this is an improvement. I love Kotlin coroutines and I’ll be a little sad if one day Loom will make coroutines go away, but I’ll know this is actually good.
If Kotlin would decide to “stand on its own” specifically to not be eventually replaced by the Java or another JVM language, this sounds to me like a vendor lock-in - taking intentional actions to disallow people to easily migrate out. It could be good for Kotlin authors and language survivability, but probably bad for the community. For me a potential possibility to replace the Kotlin with another, better language in the future, is actually its huge advantage and one of reasons why I like to stick to JVM.
Also, I can’t say for sure what were reasons Scala and Groovy didn’t succeed that much, but at least for me it has nothing to do with being replaced with a better option. Scala was too “mathematical” and strange. Groovy just didn’t win my heart. I tried multiple JVM languages, but the Kotlin is the first one I got interested in. And FYI, I’m not an Android developer, but mostly backend where Kotlin didn’t get that much momentum.
2 Likes
Anyone who’s been following Java for some time (and I’ve been using it since 1997) will find that funny…
Sun and then Oracle have always taken a very conservative approach to changing Java (and that stability is arguably one of the reasons for its long-term popularity). Many of the new features which have been added have been compromises: the minimum possible change to achieve something vaguely like what people want. (Look for example at the problems it still has with the way generics were implemented using type erasure, and still supporting raw types; or the limiting and functional-interface-based approach to lambdas without real first-class functions.)
Of course, backwards-compatibility is very important in a technology used by large parts of the industry, and is necessary to gain trust. But Java has been very slow to change, more than necessary. And I have no doubt that without languages like Kotlin increasing people’s expectations — and taking market share — Oracle wouldn’t have increased their pace, and we wouldn’t be seeing many of Java’s current improvements either.
And Java is still playing catch-up. It still doesn’t match up to Kotlin in many ways. Sure, a tick-list of features may look fairly similar, but when you look into how those features are implemented you often find that Java is awkward, verbose, and very limited. (For example, Java’s null-safety, using Optionals, is verbose, inefficient, and doesn’t interact well with generics or with external code, while Kotlin’s is built right into the type system and pervades the language.)
Java is not a bad language. Despite the long time it has languished with only minimal improvements, it’s still a great language in many ways, and I’m very grateful to have used it professionally for 20-odd years. But Kotlin is better in so any ways; so many things that were awkward and hard work in Java (and so often got omitted) are a joy in Kotlin. In so many big and small ways, it’s more concise, easier to read, more expressive, and makes it easier to do the right thing — and many of those are things that Java will (unfortunately) never be able to copy.
3 Likes
I generally agree with you, but the question is if this is bad or maybe rather good. From the developer and the community perspective, if Java improves to the point Kotlin becomes kind of obsolete, then this is good, this is an improvement. I love Kotlin coroutines and I’ll be a little sad if one day Loom will make coroutines go away, but I’ll know this is actually good.
Well, It could be good for Java developers (java community), not Kotlin Developers or the language itself, I do not know Java (only fundamentals), and I do not want to learn it or use it, but on the other hand I love Kotlin and its syntax that is why i hope Kotlin becomes more popular and used more often in companies.
If Kotlin would decide to “stand on its own” specifically to not be eventually replaced by the Java or another JVM language, this sounds to me like a vendor lock-in
Well, in this case we can agree that all languages have a kind of “vendor lock-in”, It is not like I said that Kotlin should be the only option to do something, what I meant that Kotlin must have something to survive just like Java, C#, etc…, or It will be impossible for someone to use Kotlin in its day-to-day job.
We stick to java - I saw many companies GO back to java:)
Great article