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 polarised. The same thing happened with C++ over its lifetime, with wizened 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 preserve 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 afford 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.