Another day, another Scala dispute

Lift creator David Pollak raises Scala versioning concerns

Chris Mayer

Does Scala need fundamental changes to move forward as a language? Or did Typesafe already see the gloomy forecast?

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
, 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

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
– 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:
  1. All dependencies must be compiled against the exact same
    version of Scala and every referenced Scala
     which makes in-house builds when there are
    multiple teams amazingly complex or time-consuming
  2. 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:

What we need:
  1. 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
  2. Something baked into the Scala compiler that makes the version
    fragility issue go away
What you can do:
  1. Blog about the issue and raise awareness about the version
    fragility issue and how it has impacted you
  2. 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
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

comments powered by Disqus