This post originated from an RSS feed registered with Scala Buzz
by Alex Blewitt.
Original Post: Will Scala ever be enterprise ready?
Feed Title: AlBlue's Weblog (Scala feed)
Feed URL: http://alblue.bandlem.com/Tag/scala/atom.xml
Feed Description: Scala related posts on AlBlue's Weblog
In June's ScalaDays keynote, Rod Johnson put forward his view of the
future when Scala has fixed all its problems and has become the de-facto
language on the JVM.
The presentation is available on
Parleys,
and it's instructive to view both the video as well as the comments beneath.
Needless to say, his talk didn't go down well with the Scalarati. Having said
that, few can receive constructive criticism without being affected by it, so
it's not entirely surprising.
There were two key arguments made as to how Scala needs to evolve in order
to become the de-facto language in five years time:
The community needs to become more friendly and welcoming
The backwards incompatibility between releases has to stop
The former has certainly shown improvement over the years, but the fact of
the matter is that as more complex programs/algorithms/types are used, the
level of discourse involved on the mailing lists becomes accordingly
polarized. The same thing happeend with C++ over its lifetime, with wisend
C++ wizards looking down at their C neophytes with distain.
Things are changing, and slowly for the better. Some of the more poisonous
Scala community members -- and you probably know who they are -- have moved
on or at least become more muted. Generally everyone tries to be helpful,
but teaching new concepts at the same time as growing adoption is a hard
problem.
As for the backwards incompatibility ... well, that's the same as it always
has been. This comes up time and time again -- usually after a major release --
and the answer is always the same; to preseve innovation and flexibility,
the past can't constrain the future.
As a result, a program compiled against an older version (and by older this
includes past major revisions, not just minor bugfixes against the current
one) just fails to run with libraries compiled for a newer version. There
has never been a Scala release where it's been possible to compile and run
an older library with a newer version of a program. Although the Scala Universe
never took off, library developers still punt out versions of their libraries
for the current and past releases; or worse still, just the current release.
Compare and contrast this with virtually any other library or language. Even
C, which is platform specific, had a defined ABI that could allow other
programs to link against -- and bumping the C compiler version didn't
invalidate all the libraries that you have on your system. Java, of course,
is the poster child of compatibility; programs compiled against the 1.0 days
can still be used on a recent JVM.
The thing is this: for Scala to become the de-facto standard, it needs to
settle down, or at least have a migration plan between releases so enterprises
don't have to update the world every six months. Java, even if it is old and
untrendy, manages this very well. Arguably the work going into Java's lambdas
will have a far greater impact and lifetime than Scala, simply because once
released developers will be able to rely on them.
Rod's view was set 5 years into the future, when Scala has solved these
problems. By 2018 was the claim, Scala will be the main language on the JVM.
The only problem is that these problems were known 5 years ago, and still
haven't been fixed.
Almost four years ago, I posited
Is Scala ready for the enterprise?,
in which I asked whether Scala was ready for the enterprise or not. This
was when Scala 2.8 was about to be released (breaking backwards compatibility
with Scala 2.7; and let's not forget that Scala 2.7 was backwardly
incompatible with 2.6 as well). It became clear fairly early on that Scala
was not ready then.
What has happened over the last four years?
Nothing.
Well, not strictly nothing; but as far as improving backward compatibility,
growing a community, building rock solid foundation for the future, we are in
exactly the same position now as we were then. There were the avid fans of
Scala who refused to listen to anything that wasn't 100% complimentary --
in fact, a similar set of people who refused to take on board the points
that Rod was making in his speech. Yet most of these people have not gone
through a Scala version switch, or seen the pain that it can cause, or
extrapolated that out thinking what it will do for future releases.
In essence, Rod's vision of "In five years Scala will become the de-facto
standard" is still as far away as it was four or five years ago. Scala's
half-life is about two years; each time it goes through a new release, it
manages to kill off some vested interests whilst at the same time recruiting
new apostles for the future.
This self-limiting process means that Scala will never truly die out; at any
point, there are still more people who are new to Scala than people who have
been burnt by it, so there's always a fresh supply of people willing to
believe that it can't happen to them. The same is true of smokers, of course.
But what it does mean is that Scala will never truly find a home in Enterprise
environments, nor become the de-facto language for the JVM. There will always
be populist stories of successes in small IT teams -- arguably where Scala
will be most successful -- because they can often aford to be more agile
and do a stop-the-world migration to the latest-and-greatest every couple
of years.
Ironically, with Java 8's release in the next 8 months, it may well be that
Java 8 is the new Java, not Scala.