Yep agree with all you said. Nowadays new job every year people at work are scaring me with their enthusiasm to replace decades old solid Java applications which are performant and working fine with Kotlin and what not.
Java programmers will have only a small learning curve before feeling productive, and can gradually get more comfortable with idomatic Kotlin as they progress through their journey.
Kotlin, as a language, was very well through out, letting you use as much or as little of it as you are comfortable with.
I don't see any value in Kotlin outside Android shops.
Developer experience is important to some people - not just devs, but those who seek to recruit and retain good ones.
Of course, if you're looking to hire massive numbers of butts-in-seats (gov work, large enterprise shops, etc) I suppose Java is probably the ideal choice.
Kotlin libraries are interoperable with Java and vice versa. In some specific cases, a Kotlin library needs a little syntactic sugar to make it work with Java like a Java developer would expect, but it's easy to do. Going the other direction though - Java library used in Kotlin, zero issues, it just works. Some Java developers don't even realize they're already using Kotlin - take a look at OKHttp and friends...
Lastly, there's Kotlin support is all major IDE's, including IntelliJ of course, but also Eclipse and likely whatever editor/ide you prefer. Kotlin is basically just a bunch of libs.
I would argue Kotlin is better outside of Android than in Android. For backend work, particularly when coupled with Spring/Boot, it's freaking amazing. The Spring team has put in an impressive amount of work to make Kotlin a first-class language within the ecosystem, and it really shows.
Telling me there is Kotlin support in Eclipse only tells me you never actually tried it, specially after JetBrains ramped down the team that was doing the now stale plugin.
Coroutines are a specific paradigm within Kotlin, and should not be in library code anyway. With the addition of JVM Virtual Threads, the need for Coroutines is significantly diminished anyway.
It's anecdata, yes, but I've written a lot of Kotlin code and do not use coroutines. Kotlin really just lets you do what you want - as much or as little idomatic code as you need.
Kotlin on the backend is amazing. You really should give it a try. Java sucks badly, in comparison (I say that as a former Java nerd...)
[1] https://marketplace.eclipse.org/content/kotlin-plugin-eclips...
After installation of the Kotlin plugin the Java plugin is not running anymore. I cannot open a Java project anymore.
The log file says:
!MESSAGE org/eclipse/jdt/internal/ui/refactoring/actions/RenameJavaElementAction$AjcClosure1
!STACK 0
java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/ui/refactoring/actions/RenameJavaElementAction$AjcClosure1
at org.eclipse.jdt.ui.actions.RenameAction.<init>(RenameAction.java:60)
at org.eclipse.jdt.ui.actions.RefactorActionGroup.<init>(RefactorActionGroup.java:372)
at org.eclipse.jdt.ui.actions.RefactorActionGroup.<init>(RefactorActionGroup.java:206)
at org.eclipse.jdt.internal.ui.packageview.PackageExplorerActionGroup.<init>(PackageExplorerActionGroup.java:139)
at ...The beauty of Eclipse is the ecosystem. If that official Jetbrains plugin doesn't do it for you for some reason, then use another one[1].
[1] https://marketplace.eclipse.org/content/enhanced-kotlin-ecli...
Prove me wrong.
There's nothing special about Kotlin. It's a bunch of libraries for runtime and compile time... like anything else you use.
There is a difference between supporting a language with a Notepad++ like experience, and what JetBrains was doing before ramping down the Eclipse plugin team, as means to sell more InteliJ licenses instead.
It compiles fine with Maven or Gradle, it provides auto-prompt/complete/hints. It just works.
And above all, no crashes left and right.
Kotlin is plugins for Maven/Gradle, and classpath libraries. There is no magic going on here...
All that to say, I believe that Kotlin has a lot of value, independently of Android.
I say this as a Clojure fan, there are many instances where I'd probably choose Kotlin nowadays. You can also mix JVM languages within the same application; I've found it rather useful to sprinkle some Clojure into a Java/Spring application for certain tasks. Maven and Gradle both have tooling to handle it :)
Unlike C++ though, one day the powers that be will just remove features as part of yet-another framework rewrite and you'll just have to deal with it.
The other issue is just how tightly coupled C# as a language is to the .NET framework/platform. Some of the things people like C# for are actually framework things and they don't realize it because that separation isn't as clear as with Java and say, JavaEE or Spring or $X.
If you talk to a C# developer - of course they're using .NET and of course they're using Entity Framework - to them, there's no other way. It's inconceivable that any other library or framework might do it better than Microsoft's official offering... and then you'll find the official offering to be lacking in fundamental ways.
Talk with a Java developer and you'll find there's a lot more diversity of frameworks and libraries being used - so there's a lot more differing opinions on priorities and a lot more good ideas being tried out or implemented everywhere. The communities are vastly different in that regard.
There is a "roles" proposal and investigation team. This roles proposal is going to unlock so much potential it is bonkers.
It's yet another double down on object initializers instead of writing constructors and factories, and unlike using a factory you have to fully express the result type of the collection instead of having it inferred (they are "target typed", another feature that probably should not have been added).
I've read the proposal, design meeting notes, and GH conversations. Not seeing a compelling counter argument here.
Like what?
I'll give you nullable types, though I personally don't struggle with null at all.
I think Kotlin is at risk, though, of having the JVM force them to support two competing models to accomplish the same thing - coroutines and virtual threads is a good example (although Java still doesn’t have language level structured concurrency). This could really make things messy.
I just don't think any feature of the language of Kotlin is that much better than Java's implementation. I'm also a big supporter of brevity != clarity when it comes to code.
What language feature in Kotlin do you think is that much better?
It's weird being on the other side of the fence now - hearing the same things I used to say.
Kotlin was a gateway drug out of not just Java, but OO/Solid and into FP for me (FP being another thing I used to not "get"). The beauty of Kotlin is you don't have to ever write FP code if you don't want to - but you will want to before too long.
I would recommend trying it out for yourself. It's Spring integration is amazing, and you'll have a great time. Write even a little Kotlin and you'll have an "ah ha!" moment and everything will forever be different.
It's one of those things where you need to experience it for yourself before you actually understand how great it is. There is no argument you will hear that will convince you, sadly. I was the same once...
- Having to remember the difference between "Function", "Consumer", "Predicate" and "Supplier" is weird. In Kotlin (and basically every other typed FP language that I know), I just write the type signature the natural way.
- Having to use streams in order to use map, etc., is noisy. Why weren't these APIs retrofitted to collections?
- Checked exceptions are a pain with functional code, e.g. map.
- Mutability is still the default behaviour of almost everything in Java, save records (and strings).
etc.
Sure, methods along the lines of the following could have been added:
public <R> List<R> map(Function<? super E, ? extends R> mapper) {
return stream().map(mapper).toList();
}
- I don’t think this is really that big of a deal.
- Using streams is actually preferred so you don’t cause a performance nightmare and kotlin you has to use asSequence anyway.
- I thought checked error handling was all the rage nowadays?
- Mutability is absolutely fine if you’re not going over a thread boundary.
And checked exceptions are widely seen as an anti-feature - I don't think any other language has them, with the possible exception of Swift (see below), and for good reason. Other languages encode errors (more or less ergonomically) in the type system (e.g. Rust, Haskell, and to an extent it's what Kotlin advocates as well), and that has the advantage of playing well together with other language mechanisms - e.g. no extra allowances need to be made so that map works with them.
But for the sake of the argument: Swift also has something similar to checked exceptions, but only in the sense that functions can either throw or not throw. However, Swift also at least has constructs like "rethrows", which lets you say that a function such as map should throw iff the higher order function it wraps throws.
Java simply decided that it doesn't need to deal with this problem at all (for whatever reason - they simply could have added something like "rethrows") and now it's up to callers to deal with the incredible awkwardness that is using FP with Java library code that makes heavy use of checked exceptions.
var, records, sealed types, and pattern matching make a huge difference in how Java is written. A lot has changed since 8.
I left the Java world for the C# world around 2008 and then returned to the Java world last year. C#/.NET changed much more significantly much faster. Almost all of the significant differences in day to day life with respect to the Java language and standard libraries that occurred between 2008 and 2022 are due to changes introduced with Java 8.
I don't think it's that good an example, though there's some merit to it. Kotlin coroutines, to me, target three main use cases:
1. An abstraction over an underlying threading model. Get threaded execution without having to explicitly deal with thread pools and such. I'd consider structured concurrency to be part of this use case.
2. A way to write non-blocking code that is structured as if it were blocking. (Incidentally: I love Kotlin's decision to make "await" opt-out instead of opt-in.)
3. A way to write code that generates sequences of values without having to either write an explicit class that maintains state across calls or use callbacks/CPS. Or in other words, a way to use the "yield" function.
Use case 1 still makes sense with virtual threads. Run your coroutines on an executor that uses a virtual thread pool instead of a platform thread pool. If you prefer the coroutines API, you can still use it for structured concurrency and such.
Use case 2 is much less interesting in the presence of virtual threads; you can just write blocking code directly, no need for the language to turn it into async code for you.
Use case 3 has nothing to do with threads to begin with, so it remains exactly as valuable as before and there's no reason to change any existing code at all.
Do coroutines get less useful in the presence of virtual threads? Absolutely. But they aren't competing with virtual threads; there are substantial non-overlapping use cases that make them a worthwhile language feature.
Tying down a value to a name only if you have something meaningful to say in the name, and only when the value is actually finished instead of being a work in progress, that gives me great piece of mind and frees up mental resources for other things. I wish every language had a "kotlinized" sibling that simply added the scope functions on syntax level (or a subset of the scope functions, not sure you need a zoo that size)