(Same thing with Groovy, but that one is even worse than Kotlin)
On the other hand Scala looks nice.
Other than Android, there are no reasons for additional complexity in development tooling.
> Kotlin adds Jetbrains only as IDE
Not true, you can use any IDE you want. Of course IntelliJ is the "blessed" IDE, but really, Kotlin is just a bunch of libs, any IDE will work.
> additional build plugins
I don't see why this would matter. Any non-trivial build is going to use a bunch of plugins.
> an ecosystem of Kotlin libraries for more idiomatic code
Which are optional.
> stack traces completly unrelated to Kotlin as JVM only understands Java
I don't know what you mean. The stack traces are from bytecode, which Kotlin compiles to just like Java. The stacks are identical...
> needs plenty of boilerplate to emulate co-routines and functions in JVM bytecodes
You do not write the boilerplate though. That's the difference. Of course all higher level languages with High Order functions are going to suffer this same issue. It's abstractions all the way down..
You probably already use Kotlin and don't even know it. The popular okHttp library from Square is Kotlin - but you'd never know that if you just used it in your Java project.
This is the biggest issue, in my opinion. Although, if you have a java developer that really likes the higher order features that are being added, Kotlin might be a very easy switch (after some basic syntax learning).
The nice part is everything you already know about JVM performance still applies within Kotlin. So you're not starting over from square-one like you might assume.
No I can't, because InteliJ is the only one that actually supports Kotlin.
Otherwise I would just be using Notepad++.
> I don't see why this would matter. Any non-trivial build is going to use a bunch of plugins.
It shows you don't work as build engineer.
> I don't know what you mean. The stack traces are from bytecode, which Kotlin compiles to just like Java. The stacks are identical...
Try to debug a Kotlin stacktrace with free functions and co-routines, and then try to tell the world it looks like what the Java compiler would generate.
> You probably already use Kotlin and don't even know it. The popular okHttp library from Square is Kotlin - but you'd never know that if you just used it in your Java project.
No I don't, because at my level libraries are validated and only internal repos are allowed in the CI/CD pipeline.
Also I no longer do native Android for work, other than mobile Web.
You can indeed use notepad++ to write Kotlin. Nothing is stopping you.
Kotlin is not limited to mobile development either.
And even despite of it, they were forced to update Android Java to keep up with the JVM ecosystem.
> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.
-- https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
Subjectively, a lot of Kotlin features are implemented in a kind of ad-hoc way because they're designed to be as easy to use up-front as possible, at the cost of consistency. So the language has a kind of "technical debt" - it's hard to evolve it in the future. Add in the fact that the language lacks the higher-level abstraction facilities that would let you work around these incompatibilities (e.g. Scala has its own Option that's different from Java Optional - but this isn't a big problem because you can write a generic function that works on both. But you can't write a function Kotlin that works on both Java Optionals and Kotlin nullable types), and I'm really skeptical about its future.
An extension value clears this up in my Kotlin code, something like:
val <T> Optional<T>.value: T? get() = orElse(null)
repository
.findByFoo(bar)
.value
?.doSomething()
Regarding project loom and coroutines - I don't see why loom won't work in Kotlin codebases as-is. The change would be made in the corountines library, not user codebase.
You can convert at a boundary, which is fine if you have a line between Java and Kotlin parts of your codebase. But you can't seamlessly mix Java and Kotlin and use the same functions with both, which is what some Kotlin advocates try to claim.
> Regarding project loom and coroutines - I don't see why loom won't work in Kotlin codebases as-is. The change would be made in the corountines library, not user codebase.
I would bet they'll need incompatible changes, because there are subtle differences in the models. (Or they could keep the same API but with subtly different thread safety guarantees - but that would be a whole lot worse, breaking existing code in nondeterministic ways).
This was by design for Kotlin, and is probably their smartest/best feature. All existing Java code/libs just work in Kotlin. Conversely, most Kotlin code/libs just work in Java, although some care needs to be made there.
Kotlin is amazing to use and read. For most things, the Kotlin version is easier to read and comprehend than the Java version in my experience.
As Java adds language features, Kotlin either gets them for free or already had them (and now can use native features instead of their own custom features).