Thirty years after it's inception, Java is still one of the most popular programming languages. Mainly used in the Enterprise space, it has evolved into one of the most controversial languages. Some love it for it's stability and maturity, others hate it for being verbose, and among the architects of the greatest of programming crimes... 'NULL'.
Regardless of the opinion that you have on Java, it is objective reality that the underlying engine, the JVM is a masterpiece of engineering, and a modern miracle, and it has grown to be a vibrant ecosystem, harboring many, sometimes objectively better, languages. Groovy, Clojure, Scala, and of course, Java's little brother – Kotlin.
Kotlin started as a humble experiment behind closed doors inside the Jetbrains laboratory. Jetbrains, now famous for some of the most powerful IDEs in existence, built the language from scratch to be a better Java. More concise syntax, explicit null handling, best-in-class concurrency, all that while not losing the best that Java has to offer, the JVM. A single platform that allows the language to run anywhere, as a simple, drop-in, interoperable replacement for it's bigger brother.
Now, more than ten years after it's release, Kotlin has grown a lot, building an ecosystem on top of the ecosystem that allowed it to exist in the first place. Kotlin Multiplatform as a competitor to Flutter and React Native; Kotlin/JS and Kotlin/WASM as web-native stacks to use it in the browser; Kotlin/Native, an attempt to use c-interoperability and LLVM to bring it into your CLI and onto your desktop, with near-native performance. That's just the tip of the iceberg that is Kotlin's ecosystem, and it's immediately very familiar, in that there is another language in the same domain that delivers the same promises, of one language for everything – C#.
Jetbrains, a scrappy start-up from Czechia, originally just working on some IDEs, competing against the behemoth that is Microsoft, created a better programming language with better DX, but did they create a better ecosystem?
The Premise
Gone are the days where a programming language is good at one thing. In a modern world, it is of utmost importance that the language you learn can be used to build a backend, a frontend, support every standard under the sun, repair your HVAC, and do your taxes for you. JavaScript escaped the browser, C# escaped Windows, Kotlin escaped Android. While Kotlin is the de-facto standard for writing Android apps in 2026. If you search your preferred search engine for "Android Development", you will very quickly end up looking at a number of tutorials featuring the primetime technology, Jetpack Compose. This is not an accident, it's a deliberate effort to modernize the mobile stack, away from the old times where you would use good old XML files to describe your UIs, instead moving towards a declarative approach, not unlike what you would do in Flutter or Swift. This has spawned a number of smaller side-projects inside the Jetbrains machine to churn out compatibility for every platform in existence. And, while it is a nice sentiment, the question is whether this approach is sustainable in the long run, and Jetbrains is not the only offender.
Years ago, the gold standard for writing desktop apps were either C and C++, or any languages that supported bindings towards them, allowing you to use the vast ecosystem of existing technologies to build what you wanted to build. Nowadays, programming languages come with their own rendering in order to make it as easy as possible to use the language for whatever you want to do. It is unsurprising that more and more people pivot to just using Electron, or React Native to build any kind of application. HTML and CSS are the gold standard for building UIs, and JavaScript is the engine that was built to, at first make them interactive, now to get them everywhere. So, the fundamental question that we have to ask ourselves is the following: 'Is it actually good that every party working on a programming language is trying to create the one language, to rule them all?'
Focus
There is a number of examples of programming languages that work, not because they were built to do everything, but they were built to do one thing very well. Zig as a replacement for C, that moves fast enough to be legitimately usable, but slow enough to be thoughtful with the features it supports, and with seamless interoperability allowing you to just drop it in; Odin as the replacement for C++ in the video game industry, with more readable, sensible syntax and a feature-set geared at doing it's one job better than anyone else. These are two rare examples of languages that set out with a specific goal in mind, and communities have built around the mind-set. That is not to say that it is necessarily bad if a programming language supports building UIs, or supports being compiled into WASM, but those features are expensive, they cost resources.
The Cost of Making a Language
Making a programming language is hard work, making a good programming language is borderline insane. Every language comes with trade-offs precisely for that reason. Go is fast to build and fast to write, but it's syntax is minimalist at best; Rust is the gold standard when it comes to memory safety, but it's steep learning curve and long build times make it not worth learning unless you intend to use it; C++ is fast and powerful, but you will shoot yourself in the foot.
On paper, Kotlin looks like the perfect programming language. It gets rid of most of the boilerplate traditionally associated with Java, it has lean modern syntax that make sense to read if you've written anything C-adjacent before. It even imports ideas from functional programming without being functional itself, providing you the flexibility to write code in a variety of styles, allowing you to settle for what works for you. You also get built-in concurrency that is, while not as easy to use as Go's solution, powerful and expressive in exactly the right way.
But, like every one of it's peers, it also comes with trade-offs. Two Kotlin codebases can look very different from each other; it sometimes forces you to be too "intellectual" when writing code, causing you to lose time in unimportant details, and historically, it was built around the ecosystem it was born in.
Addressing the Chimaera in the Room
The "historically" part is doing heavy lifting, because Jetbrains has been working on expanding the platform support of Kotlin bit by bit over many years at this point. Some of the earlier mentioned technologies, transpiling into JavaScript, compiling into WASM, and c-interoperability have been in development for a while, and to a degree they are already usable, but only to a degree, and that is the problem.
It seems as though Jetbrains had hoped to that they could more effectively utilize motion created by their userbase. Kotlin is open-source and can be contributed to by anyone, which seems like a good idea on the surface, because compared to the behemoth that is Microsoft, a company like Jetbrains cannot afford to hire enough staff to maintain their products and create such a varied ecosystem. And it also gives them a level of control that would not be possible with relying purely on open-source community solutions that are created for the language, instead of with the language.
Regardless of how you look at it, what was originally a good idea, has become a liability, because, these technologies that are supposed to be first-party, with proper support in a unified ecosystem, somehow feel off. It feels as though, despite the features being driven by Jetbrains, nothing really fits together. The configurations you need to engage with differ in awkward way depending on what you are working with. New IDE plugins are rolled out that don't fully replace old ones, so depending on your platform, you have to engage with old deprecated plugins, or web-UIs that are hard to navigate, and worst of all, you have to make sense of documentation, written by a company that is famous for being horrible at documenting their products. So either you have to figure things out, or hope that someone else did the work for you.
All this, while the underlying engine of it all, was never meant for what Jetbrains is trying to achieve here. Gradle, is an awfully complex, buggy build tool that moved from Android Development, to driving server builds. Now it is being used to drive the cross-technology builds that are supposed to deliver binaries for every platform in existence. It is no surprise that with Amper, Jetbrains is trying to homogenize what so far is one of the biggest hurdle to aligning all of their efforts. But in doing so, they are making yet another tool, working on yet another technology, spreading themselves even thinner, making it even more likely that their project will end up as an artifact of history instead of a mainstay, the way they intended.
Wasted potential
It is unfortunate that Kotlin is in the situation it is in. It is by far my favourite programming language. Every time I use it, it just feels good to write, and the small bits and pieces just make sense. But regardless of how I feel personally about the language itself, the tooling has grown in ways that make it feel like they will always be a step away from being good. While I would be excited to have Kotlin as the one language to do whatever I want, I regularly fall back to using Go instead. Because Go, in it's simplicity, created an environment where writing a simple CLI application doesn't require me to initialize a Gradle project, or writing a web-server is as simple as importing net/http. All while it can easily be compiled for any target platform. I almost exclusively use Kotlin for writing heavy backend applications because that's what you do in an enterprise environment, and I personally believe that it is really good at that, and maybe Jetbrains should've taken that as their win, and moved on.