I personally wouldn't go for anything but Java (on JVM, that is) for anything that isn't a pet project.
I personally wouldn't go for anything but Java (on JVM, that is) for anything that isn't a pet project.
Another huge advantage Kotlin has over Scala is tooling, which is basically all thanks to an IDE company creating the language. Tooling will never fall behind because they are in the business of selling tools.
(You could say the same thing about Sun/Oracle...risks all around.)
Not sure I'd agree with this. Kotlin's ties to JetBrains means that you're basically hosed if you don't use IntelliJ. Scala's tooling works pretty much everywhere (LSP/Metals, ENSIME, IntelliJ, Eclipse/Scala-IDE).
[1] https://medium.com/@fommil/hide-your-real-name-in-open-sourc...
Scala's tooling also pretty much sucks everywhere (interestingly the least sucking IDE for Scala is guess what ... Intellij!)
In your opinion.
Personally I almost get depressed when I have to switch from Emacs+Metals to Android Studio for Kotlin stuff.
The parts where IntelliJ has always fallen down on Scala seem to be precisely the parts that are missing from Kotlin. I can't help feeling that the JetBrains team just "doesn't get" higher-kinded types at all. Which is a shame, because there is a lot of good stuff in Kotlin otherwise.
As far as JetBrains, I am big fan, I have a license for R# that I gladly pay for, but JetBrains is just one company whose core set of products are rapidly being encroached upon by free alternatives.
Jetbrains is even lagging behind, look at vscode remote capabilities which is way ahead jetbrains remote features.
Best of all, I can use Java in any Java IDE.
Needs additional configuration for what the others do out of the box, like Javadoc tooltips.
Requires ten finger shortcuts.
It is also the only Java IDE unable to do mixed language debugging, Java/C/C++.
This has been true for almost two decades now - Eclipse first shipped in 2001, and it competes directly against IntelliJ, which was JetBrains' main product at the time.
And yet, they're still around.
It's being maintained. A new version (3 iirc) is about to come out. But it's not a hot bed of innovation.
I think Kotlin now already has a lot more mindshare and corporate interest behind it than Groovy ever did.
Those of us that are part of the Java world since the early days, have been through this multiple times.
Right, history repeats itself all the time ... until it doesn't. 10 years ago is not now, Kotlin is not Groovy ...
Just like C on UNIX, JavaScript on the browser, ....
The hype curve is definitely in the past, but Groovy is living on quite well as a small but viable option in the plateau of productivity. In some ways that is more important because while in the hype phase it is really hard to judge the true value of a technology. The true value emerges when the hype is over.
The problem is, there isn't really a better scripting option for the JVM. While in theory lots of JVM languages (JRuby, Jython ... etc) could fill that gap, they all have ugly impedance mismatches which Groovy doesn't, so companies continue to deploy it as a scripting and DSL implementation still. I tried to substitute Kotlin for a bit and went back to Groovy because Kotlin still lacks standard scripting constructs such map and list literals etc.
As for Valhalla, it remains to be seen how it's usable from Java, let alone anything else. But Kotlin already has a form of value type (inline classes) so perhaps it'll be an extension of that.
One cannot just change their semantics after the fact.
case class Foo(x: Int) extends AnyVal {
def square: Int = x * x
}
val bar: Foo = Foo(5)
println(bar.square) // => 25
Compiles down to (the moral equivalent of) object Foo {
def square(x: Int): Int = x * x
}
val bar: Int = 5
println(Foo.square(bar)) // => 25
If the inner value (x, in this case) can be stack-allocated or stored in registers then `Foo(x): Foo` will as well. `Foo(x): Bar` (where Bar is a supertype of Foo) will be autoboxed, but that also applies to primitive types (`5: Any` becomes a java.lang.Integer in memory). inline class { ... ]
Which is guaranteed to be always stack-allocated or stored in registers, again you cannot retrofit semantics, specially when passing those classes to binary libraries.There is also precedence for this, Scala 2.12 changed the encoding of lambdas from anonymous classes to Java 8's invokedynamic.