Another day, another Scala dispute
Lift creator David Pollak raises Scala versioning concerns
With the discussion regarding Scala's benefits and flaws ebbing away, a new debate, (without the flaming that came packaged with Round 1) has emerged over the language's fragile byte code.
David Pollak, creator of the Lift Framework which uses Scala wrote a piece entitled - Scala's versioning fragility makes the Enterprise argument near impossible, that documents his and Lift Team's experiences of using the language to build their web framework. After all, Pollak decided to create Lift because of his dissatisfaction with other languages (Ruby on Rails in particular) and seeing this new upstart's fresh take. Pollak said back in 2008, just as the Lift story was beginning:
I stumbled across Scala and instantly realised it was what I was looking for. Scala has all the language features that I like in Ruby and all the language features I like in Java. It was a "you've got your peanut butter in my chocolate" moment for me.
The crux of Pollak's argument rests upon Scala's compatibility issues with previous versions, thus meaning that a lot of modules in Lift that need to be cross-compiled and all must compiled against all the versions of Scala that Lift supports. This means that time is often lost for Lift as they can't test against a pre-release of Scala immediately. Pollak details his attempts to change this, towards a model of continuous integration through Fresh Scala - but this failed due to lack of volunteer time.
One nugget of opinion from Pollack regarding Scala's progression is particularly interesting and how it could be hindering the language's ambitions:
Scala is no longer exclusively an academic and community effort. Scala the language and some associated libraries are now part of an enterprise-targeted suite from TypeSafe. TypeSafe is a huge (20+ heads) venture funded company that is supposed to be bringing Scala to the enterprise. But Scala's version fragility creates two huge costs for complex enterprise-type systems:
- All dependencies must be compiled against the exact same version of Scala and every referenced Scala library which makes in-house builds when there are multiple teams amazingly complex or time-consuming
- External libraries (like Lift) cannot have multiple layers of dependencies because you need to match the exact version of every library and Scala version all the way down
...So, the Scala library and framework ecosystem is about as big as it can get given the Scala version fragility issue.
Pollak decided enough was enough after discussing the issue privately and unlike some previous detractors, offers solutions for how Scala can overcome the problem:
- We need something like Scala Fresh so that there's continuous integration across the major (and not-so-major) libraries and frameworks in the Scala ecosystem
- Something baked into the Scala compiler that makes the version fragility issue go away
- Blog about the issue and raise awareness about the version fragility issue and how it has impacted you
- Next time you're on a TypeSafe "what would you pay us money for?" call, please tell them that a vibrant Scala ecosystem is critical to wider adoption and the version fragility issue is significantly impacting both internal development efforts and ecosystem growth. In order for your company to consider buying anything commercial from TypeSafe, you need broader internal adoption of Scala and that comes from reducing the transaction costs of using Scala including eliminating the version fragility issue in the open source parts of Scala.
A fairly glum assessment you'd assume. But a response from Typesafe's Josh Suereth suggest that the recovery could be quicker than we expected. He says that Typesafe has been petitioning to break the binary compatibility problem and now with the publically available Migration Manager tool, this apparently solves most of Pollak's problem.
Secondly, Suereth mentions his plans towards restarting Scala Fresh (essentially enabling a place where community libraries will be built and deployed against the latest version of Scala) which can only be good news! You can find project here.
Perhaps Scala is actually combatting the problems which have been stunting its enterprise developement already? Through greater public awareness, we may have already been aware that Scala has been changing its ways behind the scenes