Both can be written in a Java like fashion to start, and have 100% interop with Java (you can mix the languages in projects) so the learning curve is pretty alright.
JDK 17 has most of the good features of Scala and Kotlin.
Scala seems to be designed so that you can write a short book with very fluent and natural looking demos. Make a small deviation from that and there is nothing fluent or natural about it.
Kotlin is OK but isn't sufficiently better than Java to be worth using when any Kotlin dev is going to have to know Java and Java-Kotlin mapping pretty well to use libraries. (It's a similar problem to Typescript.)
Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit. I'd point to Clojure as a language that is radically different from Java AND that takes advantage of the strengths of the JVM to be worth the cognitive load of having to know both a new and old language to be productive.
One of the big benefits of Kotlin is that if you know Java, you pretty much already know Kotlin, too. A good Java dev can get spun up on the basics in a day or two.
> Both Scala and Kotlin are sufficiently similiar to Java to provide no real benefit.
Kotlin provides a ton of ergonomic features that I absolutely adore. Named parameters and default parameter values alone save me tens or hundreds of lines of code.
I think of Kotlin as what would happen if a Java developer looked at Javascript and asked "okay, but what if this didn't suck?"
I think you mean "what if we took C# and put it on the JVM"? /s
Honestly, C# has had most of the features Kotlin "adds on" to Java for years, even decades.
I guess you could try to argue mobile is bad or something, but you get Kotlin not JDK on mobile.
Yes, Clojure is probably better, but on the flip side as a developer knowing Java 8 and Kotlin is better than knowing Clojure and JDK 17. Perhaps you can point to some salaries here but Java developers are not in short supply, if you wanted to play that game there are better languages for more lucrative payout (assuming you can even get them, these tend to be boutique shops not generally hiring publicly)
However they will most likely assign an intern to port it to Kotlin than improve Java's support on Android.
I'd be sooo happy if that were the case, but sadly, it's not. From the point of view of Scala, I still see many features missing. Roughly in the order of importance:
* Immutable persistent collections in the standard library (and thus lingua franca in the libraries). Just so much better than mutable collections. Way less headache. Once you start using them, you realize how rarely you actually need mutable ones.
* Pattern matching. Java will surely improve on what is currently available. But why wait? It may take a long time.
* Sophisticated string interpolation. It's powerful, and yet is still easy to read. Again, Java is on its way to get it, but with Scala you can have it right now.
* Type Classes. Sometimes it is very good design to separate data from functionality. Java designers (Brian Goetz IIRC) mention they would like to get this eventually. Scala has an interesting design of Type Classes -- "givens" -- which is also modular (in contrast to Haskell). Scala also has an elegant mechanism for Type Class derivation using the "derives" clause. https://docs.scala-lang.org/scala3/reference/contextual/deri...
* for-comprehension syntax and IO/Task/ZIO for async programming. Project Loom still hasn't delivered. But Scala has you covered. It gives you for-comprehension syntax, so that you don't have to suffer from nested callback hell. And there are many great libraries for async programming, like ZIO or Cats Effect. These are easier to work with, compared to other Futures from various Java libraries, because they're lazy, not eager. for-comprehension syntax is also useful for other things, it's just that async is the typical usecase.
Higher-kinded types. Not everything has to be super fancy higher-kinded type-level craziness. And very often one gets away without needing to use higher-kinded types and that's good (just as often a solution without parametric polymorphism aka generics is enough). But other times it's awesome to have this power of abstractions. Typically, but not only in libraries.
* Object. Sometimes you just need to have an object (which might implement an interface/class/trait). But Scala doesn't force you to create a whole class, if you only even want just one instance anyway. A small thing, but way more elegant.
But I'm really happy to see Java/JVM improve. The 17 release has brought some great features, but in the language level (records, embryonic pattern-matching, ...) and the VM level (GCs in particular). We all benefit more or less directly, one way or the other.
All in all, I do find using Scala can absolutely worth it, but I really don’t feel it with Kotlin. It feels like a watered down Scala, and add to that where modern Java currently is, I feel it is not needed.
Sorry but "no real benefit" seems to come from a position of ignorance.
I can only talk about Scala which I know pretty well.
While Clojure is a radical departure from Java, being a Lisp, Scala is a departure thanks to its type system and features that help you writing more functional (as in functional programming) code. And I mean this in a good way: it helps you avoid mutations and side-effects, while giving you the freedom to use good old OOP if you wish so. In general it provides tools that help you better express your intent that Java doesn't have.
I think that Java has too much baggage to ever become as good as Scala, especially on the type system side, and, in addition, Scala is also moving forward.
Also don't forget Scala.js [1], which is rock-solid and just plain amazing, and Scala Native [2].
I keep reading on HN that "Kotlin isn't much better than Java X". Having used Java and Kotlin (mainly targeting JVM) full-time for 6 years, this doesn't match my experience at all.
Here are some of my favorite Kotlin improvements over Java that I leverage all the time:
* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)
* Local variables are final by default ("val")
* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)
* Much improved collection API
* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)
* Extension functions (incredibly useful in practice)
* Much better DSL capabilities (great for UIs, generating HTML, etc.)
* Lazy properties (more generally: delegated properties)
* Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years)
* Great serialization support (kotlinx.serialization)
* Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate)
* Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)
Although I'm glad to see that Java is still improving, it will never get close to Kotlin. The most obvious reason is that many of Java's early design decisions were revised in Kotlin but are impossible or impractical to revise in Java. Also, Java carries the burden of being a platform language, whereas Kotlin can focus on being the best possible application language.
These days, I only use Java for libraries intended to be used from languages other than just Kotlin. In that case, I don't want to force Kotlin on users (stdlib dependency, debugging, etc.).
IMO if you're serious about using the JVM you should be using Java 17 and following the latest version. Kotlin is usable, but it doesn't bring that much more to that table other than longer compile times.
Or at least the perf advantages it brings. Java has nice stuff today maybe but one could argue that it is primarily defending market share that caused Oracle to move forward with its language updates.
I'm inclined to say the opposite, the more the JVM stays healthy and the stronger the third party ecosystem the more likely it doesn't become a 'dead' language like COBOL or FORTAN (not dead but in terms of marketshare).