With #Java's evolution (discriminated unions, pattern matching, virtual threads), are #Scala / #Kotlin still worth it?
Scala & Kotlin have a culture of doing things at compile-time, the former more so than the latter.
This yields safety & expressiveness, and is reflected in features that Java will never implement, in platforms that it will never target well, or in paradigms it will never embrace.
Java is still Java, and you're stuck with Spring, Hibernate, and Jackson, sorry.
@alexelcu I'm enjoying Kotlin, but I have to venture into Java just as often, and I can say I still appreciate developments there. I once heard Brian Goetz explain InvokeDynamic in the JVM at a DevOxx congress, which was instrumental for Lambda expressions, and I was impressed with how they make these feature puzzles, with Java acting as a custodian of compatibility.
@kerfuffle invokeDynamic doesn't yield much benefit for static languages, but I agree with you, as improvements in the JVM lifts all boats. And I also appreciate Java's backward-compatibility.
@alexelcu Hmm you're right. I misremembered the part it played in allowing other languages on the JVM. Probably because Kotlin and Java 7 came out roughly the same time.
@kerfuffle invokeDynamic was awesome for JRuby, and it yielded some optimisations for Clojure, too.
Scala is making use of invokeDynamic since version 2.12, when it dropped support for Java 6/7. And I think they did it to reduce the generate JAR size, but I'm not sure.
@alexelcu that sounds rather ominous 😄
Jokes apart, in terms of expressiveness I fully agree. But what about the features that will never be implemented? Getting pattern matching, for example, on Java seemed already an astronomical leap forward. So what could be the ones that will never make it?
@IsomorphicDude I don't think we'll ever see Scala's implicit parameters or metaprogramming facilities. Or Kotlin's context receivers, or compiler plugins.
This is because Java prefers runtime reflection, and even though GraalVM's native-image is now a problem, they'll rather do something to make runtime reflection more compatible, instead of introducing new ways of doing things.
The more Java evolves, the more it stays the same. This is a strength (backwards compat 💪), but also a weakness.
@IsomorphicDude And you can infer Java's direction from its history.
Java, for better or worse, evolved in tandem with the runtime. This is in many ways a strength. E.g., Java's records have a semantic for the runtime that Scala's case classes cannot have. Virtual threads leave the language untouched, etc.
Java is tied to the JVM, JVM improvements lift all boats, but Scala & Kotlin are free to directly target other platforms (JS, wasm, native), which also pushes them to compile-time solutions.
Add comment