But I think the main strength of Kotlin is it being so damn developer-friendly. Just compare it with Scala which is another JVM language.
KTor [0] is the 'native' web framework for Kotlin, and there's also a full-stack framework built around it that just hit version 1.0, KWeb [1].
[0] https://ktor.io [1] https://kweb.io
Of course, I have checked Ktor before, but I don't know if I particularly fancy the way they are structuring stuff.
My main issue with the java ecosystem is that it's way to enterprisy for my taste. Everything is so unnecessary complex and hard to reason about, but I will take a good hard look at Kotlin before making my decision. The thing is that I am really interested in the native compilation that Kotlin offers that would be very beneficial for me and the only reason behind picking Python otherwise would be that it is a nice language and already installed on the linux environments it will run in.
Basically I will have a big api and drop (preferrably) a single binary to some machines that will talk to the api. These machines will generally be outside of my control. I have looked a bit on Rust but it seems a bit too low level and hard to work with. I have looked at Deno because it can compile down to a binary but using javascript for this project seems like a bad choice. So I chose Python at first because it seemed easy to get going with, had great tooling and is already installed in the environments I will be dropping a script in.
It has great Kotlin support, including Coroutines. I've introduced it into our team for a major rewrite and we are very happy about 18 months in.
I prefer having one decent tool thats used across almost all projects like asp net for web
instead of 5 things with their own quirks and pros cons
Its annoying to have to relearn boring things on company change
Like orms, web frameworks, etc.
When you need custom solutions then you gotta put effort anyway
The only thing I'd worry about is Java overtaking it.
Do you remember Coffeescript? There was a point in time where it had impressive adoption, and quite a bit of buzz. But then Javascript added features, and all of a sudden the tooling burden associated with Coffeescript just didn't make sense any more.
With Oracle's 6 month release schedule, that's a distinct possibility. Especially since Java can no longer rest on its laurels as a language (if Oracle doesn't want it to become Cobol 2).
ECMA 6 copied all the good parts out of both CoffeeScript and jQuery, effectively obsoleting both. Modern JavaScript is almost unrecognisably different from what it used to be, and that's a very good thing.
Ultimately, improvements to JS came along and took the wind out of CoffeeScript's sails. Then TypeScript came along and killed whatever interest remained.
And no, they serve totally different purposes. Coffeescript tried to make JS syntax and variable scoping behavior non-shit, while Typescript adds static typing while changing very little about the core language syntax.
* Android is a massive platform, and Android is basically stuck on JDK8 (or JDK11 with desugaring, wooo).
* iOS compatibility-ish. KMM is not ideal and mostly generates ObjC compatible objects (so generics are mostly screwed for Swift and writing iOS code is not ideal, but even being able to define common and enforced contracts is cool. iOS benefiting from projects like SQLDelight is super cool)
* Jetbrains hedged their bets, and Kotlin/Multiplatform is a solid option. Coupled with Jetbrains Compose for UIs as well as having the entire Java ecosystem available is very solid. Compilation for so many platforms, directly to native executables is cool.
* Java is still very slow to evolve. Kotlin has had data classes for a long time, Java recently added records. Inline classes offer some nice type safety at basically zero costs. Coroutines and structured concurrency are a beautiful way to work, and Project Loom would only build the foundations of that. Context extensions (while terrifying in the potential for spaghetti code they offer) are a useful feature, reified generics have some great potential.
Now, Kotlin has its disadvantages too. Compilation times are not that great (hopefully K2 fixes this partly), but it's relatively safe and is kind of more than just a JVM language by now.)
I don’t know how well it works, but we have seen these kinds of projects, and they seldom work as is. Not sure how well Scala Native works, even though it predates Kotlin’s try. (Though scala.js is surprisingly good!)
But do you really think that a relatively young language like Kotlin with minuscule adoption (compared to java) will be better at this game then Java?
Java has a very good compiler to Js maintained and used heavily by Google (j2cl, part of their closure compiler toolkit), which can also output obj-c code. These are/were used heavily for porting their shared libs between basically all platforms.
For native, Graal is a very cool way forward benefiting all JVM languages (as well as scripting languages, its polyglot features are insane).
> Java is still very slow to evolve
Is it a problem? The majority of developers don’t like running after the language, even though it may seem so based on online hype circles.
Well enough, provided you stay within the known bounds. Hell, some people at Touchlab even went as far as porting Jetpack Compose to work on iOS (which, uh, I would not recommend in its current state), and it technically works. I probably wouldn't recommend writing all of your app logic in Kotlin, but being able to share the data layer is amazing.
>But do you really think that a relatively young language like Kotlin with minuscule adoption (compared to java) will be better at this game then Java?
It depends on where you're looking. Most modern android development will most likely be done in Kotlin. Backend work, for things started relatively recently, Kotlin is not surprising. But mostly, Java does not make iOS compatibility a goal. Java tell you "get a JVM and run our shit" (or get GraalVM and have basically an embedded JVM). Kotlin has two sides, and Kotlin/Native does not depend on the JVM.
>Java has a very good compiler to Js maintained and used heavily by Google (j2cl, part of their closure compiler toolkit), which can also output obj-c code. These are/were used heavily for porting their shared libs between basically all platforms.
j2cl still brings in a light JVM to the Web. Kotlin does not. It provides interop to the JS APIs as well as its own tech, but it's not meant to take your Kotlin code and immediately run it on the web (which is an awful, awful idea). You're still meant to write your browser specific code, your android specific code, your x86 specific code, etc. In any language you want, even! Write it in Kotlin/JS, or let your typescript consume the Kotlin/JS bindings. However, you can have a common base that'll work everywhere.
> For native, Graal is a very cool way forward benefiting all JVM languages (as well as scripting languages, its polyglot features are insane).
Graal is an extremely cool project, but with different goals. Write once, run everywhere is a lofty goal, but it only works on very similar platforms (Windows/Linux/OSX). Kotlin has taken a Write once, specialize what is needed approach.
Well, Gluon promises the same for JavaFX apps and there is a sample app actually downloadable from the AppStore.
> j2cl still brings in a light JVM to the Web
Not at all, it compiles to very optimized Javascript. Oh, and I forgot to mention that there is also teavm, which is not a VM contrary to its name -- this latter transforms java byte code so it works with guest languages as well.
> but being able to share the data layer is amazing.
adding kotlin native adds huge depenencies relative to the tiny benefit of a datamodel that can be auto generated to native code imo
Which dependencies ? If you already have Android devs, on the iOS side it adds a single swift package, and similarly so on Android.
> It does not handle repositories, data fetching, caching and combining, it does not handle a SQLite database.
> Which dependencies ? If you already have Android devs, on the iOS side it adds a single swift package, and similarly so on Android.
New Java versions are cut every six months since 2017 and since then has added a significant amount of new features, syntactical sugar, APIs, et cetera. Not only that, but they've also have been pretty aggressive IMO in deprecating and removing legacy. Very very different than the Java I remember working in years ago.
Kotlin is truly a pleasant language, both when you don't know it (although it can look a bit symbol soup-y at times for juniors), and when you fully know it.
And yet, the overwhelming majority of the Java community are still using JRE8 with none of these new features.
There are some that love this new pace of language development, but very few are actually using new features in production code.
We are migrating Java 8 -> 17 now and it’s been a right royal pain. I’m glad we didn’t jump to 11 LTS, and instead make one big leap. It might be a very long time before we do another LTS upgrade if they keep making poor migration choices.
Which likely means touching a pretty significant portion of your codebase for the upgrade, and then who knows what 3rd party libraries you depend on are expecting...
So it may be as simple as Find/Replace for some folks, for others, it might be a deep dark rabbit hole.
Not breaking things used to be Java's MO. Yes, that means a ton of legacy cruft built up over the years... but we used to be able to depend on Java to "Just Work".
Perhaps some of this is necessary. After all, the C# folks seem to have no problem breaking everything to add new features... but I'd assert the Java community as a whole is much less tolerant of breaking changes and rapid deployment of features.
There’s plenty of dependencies that provide javax implementations as well as jakarta.
The real difficulty for us was upgrading the Play framework since the Scala community likes to make breaking changes with every release.
I think a fixed N month release schedule is much healthier than what Java did before, which was wait until everyone was on the bus in order to ship, which resulted in multi-year delays.
The thing is, they're all optional. You're never going to use any of these features if you don't need them. Your code can stay as a nested list of calls. But put them all together, and you can have code that is super explicit about what it needs to do, without having to re-pass things that are already there.
Even if it makes things better only for, say, 10% of users, but doesn't make it worse for the other 90%... the users will take that every N months for as long as the language authors can do it.
> having the entire Java ecosystem available
and, in the same point:
> Compilation for so many platforms, directly to native executables
Does this mean you can compile pretty much any Java libraries to non-JVM executables?
If you your target is JavaScript, you can use JavaScript dependencies (sort of: they won't have any type bindings so you will need to code then yourself) but you can't use any JVM libraries on it.
So yeah, I can see Java potentially overtaking Kotlin.
Scala had a massive much more prominent project to rely on - Spark.
Kotlin is getting traction because of Android.
Kotlin is seeing major adoption on the server.
So in a sense, from a tooling and compiler perspective, they're orthogonal products, similar (I guess) to C# and F# on the .NET CLR VM.
I think Oracle is catching up slower than Kotlin has been evolving in terms of new language features. Most of the stuff they add to Java (including most of the stuff they are talking about adding), Kotlin has been doing for quite some time. Kotlin is pushing out minor releases about every 3-4 months and major ones pretty much every year. Basically, they do 2-3 minor versions in between major ones. The pace is relentless.
If anything, Kotlin could use an LTS release because it's actually getting hard to keep up with the ecosystem.
A slower pace might be helpful with that. The main issue with frequent releases is that many libraries take weeks or even months to update and don't necessarily work well (or at all) with newer Kotlin versions. I've had repeated issues with e.g. code generation plugins requiring specific version of Kotlin breaking because some other library suddenly requiring something newer. So that then starts blocking a lot of library updates. We've actually put some effort in unblocking some of this for some of the dependencies we have by creating pull requests.
But I'm excited about the next 1-2 years. I expect Kotlin native to stabilize and grow beyond just being a thing for IOS. I also expect wasm support will become usable in that time frame. I hope to be able to use it with WASI for edge networking or serverless stuff. And maybe even some command line tools. IMHO Kotlin has potential for data engineering as well. There is actually jupyter support for Kotlin. And some machine learning frameworks. It's becoming a proper full stack language.
Both Scala and Kotlin can reuse Java tools, but with Scala it's awkward (and some tricky generics simply don't compile with Scala).
E.g. if I need to parse something, I search for "how to parse that in Java", not "... in Kotlin".
What? Do you have any example that wasn't fixed years ago?
Any non-trivial Scala app will consume dozens if not hundreds of Java libraries, without any issue.
I cannot find the issue now, but I remember I was trying to use gae-mapreduce-java library (built on top of Hadoop interfaces). It couldn't compile with Scala.
I would assume such a bug was fixed in Scala 2.x given the prevalence of the language in the hadoop ecosystem and big data frameworks.
Moreover Scala 3, was the opportunity to fix many previously-unfixable corner cases.
That would be always. Tooling makes or breaks pretty much every language. Language itself is just a syntax that you write in.
Sometimes, the tooling is even more important than language features IMO. It makes developers move quicker, find bugs easier and so on. I like the idea of Kotlin, that it can compile to jvm bytecode, javascript and native.
So in essence, I can use the same language everywhere in the true meaning of the word.