Scala Versioning Fragility Rant May 8, 2015
Yes, a Rant
And this morning, I'm ranting.
Recently, I've discovered the joys of dual-language (Scala and Clojure) projects... I even did a presentation on it at QCon.
Yesterday, I was playing around with putting a Reagent front end on a Lift app that talks to Apache Flink. Why? Because Reagent can support multi-hundred-thousand row scrolling grids seamlessly, even on my iPad, Lift is the best web framework I've ever used (yeah, I'm biased), and Flink seems to be well considered.
But the problem was Scala's version fragility...
The error manifest itself as:
NoSuchMethodError scala.collection.immutable.HashSet$.empty()Lscala/collection/immutable/HashSet; akka.actor.ActorCell$.<init> (ActorCell.scala:336)
It took me a few minutes to remember that this meant that there were libraries compiled against different versions of Scala in my project and Scala has binary incompatibility between "dot" releases.
Yep... Flink is compiled against Scala 2.10. Lift 3 is compiled against Scala 2.11. And they cannot, CANNOT, CANNOT work together in the same project.
You may be saying, "Yo, @dpp, why not make Lift compile against Scala 2.10?" Good question. Answer: some of the Lift 3 features are take advantage of Scala 2.11.
More broadly... Scala (and Clojure) are great "systems languages". They are great languages for library authors to write very excellent libraries that also expose Java interfaces such that they can be used by Java programmers. We see this in Flink and Spark and Storm and a fair number of other open source projects.
But that's not going to work for Scala if the Scala team doesn't fix the binary fragility issue. If I can't mix two different Scala-based Apache libraries in the same project because one is compiled against Scala 2.x and the other is compiled against Scala 2.(x+1), then the libraries are useless.
Dunno. It's not like it makes any difference. But it sure makes me feel better.