Comment by cookiecaper | Hacker News Reader

Comment by cookiecaper | Hacker News Reader

Parent Full thread

I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats.

Kotlin's biggest strength is that it brings near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle.

Boutique languages on the JVM are old hat by now, and they're neato and everything, but most people do not have the luxury of getting to choose to base their company on one of them. Kotlin is so compatible with Java that you can mix Java and Kotlin code freely in the same project, allowing people to move to adopt Kotlin gradually, without throwing away their extant business logic or requiring the wholesale sign-off of everyone in the org all at once.

Kotlin may not be the most theoretically pure language, but it lets you hit the ground running while shedding many of the crusty, obnoxious parts of the Java language. We've badly needed a semi-modern JVM language for the working man, something that doesn't get in the way and makes the business of doing software simpler. That's why Kotlin has had such an ecstatic reception.

> I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats.

SBT is indeed a wreck, just ignore it (at least to start with) and keep using whatever you were using (Maven or Gradle or what-have-you). In maven and eclipse/scala-ide with the m2eclipse-scala plugin installed I always found it "just worked": add the scala plugin to the pom, let eclipse notice that it's Scala, create a Scala class in the project and keep going. The IntelliJ experience is only very slightly more involved (have to manually tell IntelliJ to update the project config with Scala nature).

> while it's ostensibly interoperable with Java, there are many caveats.

> Kotlin's biggest strength is that it brings a reasonable amount of modernity with near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle.

This is the Kotlin narrative but I don't think it's actually supported by the facts. In the early days Scala looked perfectly interoperable with Java, but as we started writing more substantial things in Scala and a native-to-Scala library ecosystem developed it became clear that there was more to interop than being able to call methods directly, as nice as the latter is. As Scala became a full-fledged language with its own idioms we started needing idiomatic wrappers or native-to-Scala libraries. This is happening in Kotlin too, e.g. look at how http://arturdryomov.online/posts/kotlin-the-problem-with-nul... talks about having to consider whether calls are into Java libraries or not and treat them differently if they are.

And if anything I'd say this is getting worse for Kotlin with "modern" Java code: Java 8 is seeing more use of Optionals (particularly in streams) which correspond directly to Scala but are more difficult to interoperate with in Kotlin with its null-oriented design.

Why do you see options vs nulls as the same kind of interoperability issue as, say, Scala's completely incompatible collections library? That seems a little disingenuous.

Taken in isolation they're exactly the same kind of interoperability issue; the difference is that Scala has the language facilities (typeclasses and implicit conversions) to solve that kind of interoperability problem and Kotlin does not. In Scala it's straightforward to write methods that work with both Java and Scala collections (either at a syntactic level by using implicit conversions or in a "true" way by using typeclasses); in Kotlin it's simply impossible to write a method that will work with both options and nullables.

Having to work with Optionals in Kotlin means just using their Java API. Having to work with Scala collections means having to convert them back and forth every time you interop with Java. The performance implications of the latter are much higher.

Almost all JVM projects are much more tightly constrained on development time than on compute time - and those where compute time is the limiting factor are unlikely to consider either Kotlin or Scala.

But in the vanishingly rare case where you have a performance-critical codepath that needs to zigzag back and forth between Java and Scala... it's still not a problem, because it's easy to work with the Java collections in Scala. The absolute worst case is "just using their Java API" (the same thing you dismiss about using Optionals in Kotlin). But since Scala has typeclasses we can actually do much better than that.

The ironic thing us that Scala could have just implemented java.lang.Iterable and/or java.util.Iterator, instead of rolling their own interfaces with largely the same methods with identical signatures.

Reply on news.ycombinator.com