Java is controlled by Oracle. It's not that different from Kotlin in that respect. Go is controlled by Google. Swift is controlled by Apple. Typescript, C#, F#, VB, etc. are Microsoft controlled things. It's not like the grass is that much greener next door. I don't think these things are show stoppers. A lot of this stuff is open source after all.

Jetbrains considered using Scala before they created Kotlin. I think they were right. With Kotlin they went for a bit more conservative approach. Mainly undoing things that aren't so great in Java language and unlikely to change for language compatibility reasons, and avoiding some of the pitfalls with Scala. I think Scala saw a bit of wild growth of features and frameworks that Kotlin largely avoided. For better or worse, there has been a bit of a Scala diaspora with people flocking to things like Rust, Elixir, and indeed some to Kotlin.

Weather people like it or not, Kotlin plays very nice with existing Java code bases. By design. It was designed as a drop in replacement. It's why it caught on with Android developers before it even was released. It's a bit different from Scala in that respect, which while it worked alright with Java code bases really nudged you away from that to the point where you'd be swapping out your build tools, frameworks, etc.

At this point Kotlin is arguably a better language to use with any of the popular Java frameworks. I'm not really aware of any exceptions to this. Spring is a good example (arguably the most popular server framework for Java and the JVM). IMHO you are missing out if you are not using that with Kotlin. The Spring people certainly seem to agree. They've invested lots of time and effort to make Kotlin a first class citizen in the ecosystem. Documentation is dual Kotlin/Java, the framework ships with lots of extension functions for Kotlin and Kotlin specific features, and expanded Kotlin support is one of the headline features for the upcoming major version. And it's not like the previous version was particularly lacking on that front. They've been supporting the Kotlin ecosystem for many years now.

▲

vbezhenar a day ago | parent | next [-]

I've used Kotlin quite a bit as a Java replacement in the past. However its roadmap was weird for me. I wanted Kotlin to be a thin layer upon Java, however Jetbrains ported it to JavaScript, to native. It felt like lack of focus. Another issue with Kotlin was, that its development did not 100% align with Java. Kotlin co-routines were invented, but Java went into green threads direction instead, so this feature feels like unnecessary complication of already complicated language.

Nowadays I prefer Java. It's not ideal, but it aligns 100% with JVM. Kotlin was good in Java 7 times, when Java development felt frozen.

▲

aarroyoc a day ago | parent [-]

One important focus for Kotlin is mobile app development. However if you're just a thin layer over Java you can't create iOS apps, that's the whole story behind Kotlin Native/Kotlin Multiplatform. Being able to have apps that share code between Android and iOS. On the other hand I think a good Kotlin Native backend could be a great language in the Go space. Scala Native and Jank (Clojure) show that some people want a JVM less version of them. But currently Native is less performant than the JVM version. And now there's GraalVM, which is the Java solution for AOT and Kotlin could use it too. But it was invented after Kotlin Native.

The same thing with coroutines and virtual threads. Or with Kotlin data classes and Java records. Kotlin was first, Java then implements something to solve the same issue but it's not the same way as Kotlin.

	▲	jillesvangurp a day ago \| parent [-]
		> I think a good Kotlin Native backend could be a great language in the Go space With Ktor there is the beginnings of that. It can actually compile to native; but with some limitations. There's also the web assembly compiler which would make sense for things like server less and edge computing type use cases. Both are a bit neglected from a server side perspective by Jetbrains. But the potential is there. And the whole Kotlin native path could be a lot easier and more lightweight than dealing with Graal. The weak spot for Kotlin native outside the IOS ecosystem is compiler maturity, the library ecosystem, and lack of support for system libraries (e.g. posix and WASI for wasm). Those are fixable problems. But it's only partially there currently and I would not recommend it for that reason. However, I think the whole effort with IOS native has moved things forward quite a bit in the last two years. Getting Kotlin to the level of Go in terms of compilers, tools, performance, and libraries on Linux and wasm would be similar in scope. But a few years of focus on that could make a lot of difference. IMHO, Kotlin could be perfect as a system programming language with some effort.

▲

elric 2 days ago | parent | prev | next [-]

> Java is controlled by Oracle.

That's factually incorrect. Oracle owns the trademarks, but the language proper is governed by the community, most development is done in the open as part of OpenJDK, which is the reference implementation.

	▲	jillesvangurp a day ago \| parent [-]
		Oracle employs most of the contributors and the OpenJDK leadership is Oracle as well. But it's true that companies like IBM/Red Hat (mainly) and a few others contribute as well and that decision making is community based. In practice, Oracle still wields a lot of influence over the roadmap and technical direction. But you are right that decision making is community based and meritocratic. Which in practice means Oracle has a large vote.

▲

p2detar a day ago | parent | prev [-]

After several years of using Kotlin, I've learned that while it's easy and often a pleasure to write, it can be a nightmare to read and I spend far more time reading code than writing it. I like the language and still use it, but for our flagship product I decided to stick with Java, and I'm glad I did now that it has accelerated the rollout of new language features.

edit: grammar