Scala In 5 Years – My Prediction

It is no surprise that Scala is a hot topic these days from the business perspective and we’ve got two different investors asking me pretty much the same question: where Scala will be in 5 years?

Why 5 years? Well, that’s the typical exit horizon for the VCs and they all want to know our own take on what will Scala be then.

We’ve been using Scala at GridGain for almost two years by now and have been very active evangelist of it. In fact, our distributed computing DSL is second to none by a huge margin in Scala world (there’s simply nothing like that a all) and our commitment to Scala is larger than just technical curiosity or language enthusiast fetish – we’ve developed entire management and monitoring technology for GridGain using Scala as well.

We’ve been with Scala since when IDEA and Eclipse were unusable and time of daily compiler errors – but we’ve soldered on and gained invaluable experience and perspective on large enterprise project development using Scala.

50/20/20/10

In short – this is my undoubtedly highly approximated take on how JVM-based language eco-system will look in some 5 years (for enterprise development):

  • 50% of enterprise systems will be done in Java 7/8
  • 20% of enterprise systems will use Groovy
  • 20% of enterprise systems will use Scala
  • 10% of enterprise systems will use either Clojure, JRuby, Ceylon, or whatever else.

NOTE: I only assume JVM-based languages and only enterprise applications.

Let me explain my idea through several critical observations (everything IMHO, of course).

  • JVM is here to stay. There’s frankly very little that is wrong with JVM and replacing it will take a tectonic shift in computing. If you reading this blog – you will probably retire developing application that run on JVM
  • Despite my genuine love and deep appreciation of almost algebra-like simplicity and deep elegance of Scala as a language – I don’t see it having enough difference to displace Java or even pull even. 


    This is a hard statement to make… Scala is so much better than Java as a language that many of us in Scala circle tend to outright proclaim that it will take over Java in no time. Indeed, how can it fail when it’s so obviously superior in every regard?

    True – but it is only a language. There is no paradigm shift like it was with Java when I started with it in 1994. Combination of JVM and Java over predominant C++ back then was a tectonic shift – and Java never looked back.


    Scala for many is just a better, much better, Java, something that Java should have been matured to number of years ago but never did – preferring pragmatism of stability and compatibility over language changes. And this pragmatism only solidified its grip on the enterprise market over time.

    And so Scala is filling that gap for some of us who can blissfully ignore the language compatibility today. But tectonic change – it is not…

  • Despite being almost 10 years old project Scala hasn’t produce anything remarkable from framework perspective that would make Java or Groovy developers want to switch. Lift, akka, sbt, scalaz, ScalaTest – are all popular and great niche projects but generally result in yawning from Java audience. Done that, been there…

    

In Java we’ve had J2EE, Spring, JBoss, Tomcat, ESBs, AWT/Swing – and regardless of their eventual successes or failures they were pieces of technology that drove massive *and* wide-range Java adoption.



    I’ve argued recently that Scala doesn’t need killer app to succeed and I believe so deeply. In the same time a break through framework showing the best of what Scala could offer would be invaluable. ScalaTest and Specs, for example, can do that – but they a niche and rather specialized tools to gain massive following. So is GridGain’s DSL.

  • Scalaz – is a beautiful curse of Scala. It is its la femme fatale, if you will :) You show it to someone who deeply appreciates language design, FP and have knowledge of Haskell – they will marvel it (I do). Show it to typical enterprise developer/architect – they will make sure to never touch Scala again.

    

The obvious problem with this is that the later outnumber the former like 10000 to 1.


  • There is little that attracts Groovy (2nd most popular language on JVM after Java itself) crowd to Scala… yet Groovy market is probably 10x of Scala at least today. It is really hard for Scala to gain more traction without “stealing” at least some of mindset of Groovy crowd – and I just don’t see it.



    With Grails, Groovy++ and VMWare commitment to Grails/Groovy overall I simply don’t see too many people migrating to Scala.


  • The entire pitch of Scala as a language for “new age” distributed programming is rather flawed and starts to rot in Scala community. Having earned authority on this subject I can clearly say that Scala has nothing special comparatively to Java to make it easier or simpler for distributed programming (this is NOT a negative statement but rather testament to Java original design):
    • Scala shares the same class loading and resulting distributed class semantics
    • Immutability is (can be) present in both languages (Scala is obviously supporting it more cleanly)
    • Local concurrency and concurrency unification is largely the same – or equally facing the same fundamental problems



    In the end – understanding of CAS-based concurrency or knowing all your primitives in java.util.concurrent just as equally important in Scala as in Java – for any serious programmer.

DSL – The Reason for Those 20%

I think there is one overriding reasons (a localized tectonic change, if you will) that will drive (some if not most of) adoption and growth of Scala short term – its ability to produce extremely elegant, powerfully expressive, and statically type safe DSLs.

DSL will play a role of a new kind of programming abstraction that will further simplify development of applications for complex domains.

Just look at the latest crop of Scala-based DSLs to see the future:

  • Specs2
  • GridGain’s Scalar
  • ScalaTest
  • Casbah

just to name a few…

All of them offer powerful abstractions over a complex underlying domain problem. All of them dramatically simplify the usage and application of that underlying model. The DSLs with these qualities (expressiveness, safety of static typing, and uncompromised performance and usability) are simply impossible in other language that I know of.

And that’s worth 20% in my book going forward.

18 responses

  1. You say “Lift, akka, sbt, scalaz, ScalaTest – are all popular and great niche projects but generally result in yawning from Java audience. Done that, been there…”

    Akka will be the killer enterprise framework. I’m not aware of anything mainstream Java that takes advantage of the 100-core CPU’s that will be here before we know it. It’s a framework that finally brings the right abstractions to parallelism – non-blocking, message passing, futures, STM, etc. No more locks, semaphores, thread synchronization… all that low-level BS.

    • My personal take is that this is very misguided… Again, this IMHO. We, for examples, could not have found **any** place in GridGain to use Actors (Akka or standard ones in Scala). Practically, any time you need a fine tune control over concurrency – Actors fall apart. This is not an isolated observation… Just look at http://clojure.org/state

      • First of all, Akka is not just Actors, it also supports the same STM model Clojure uses for shared state. Akka is not really a framework in the true sense of the word – it’s more of a bag of tools for different concurrency problems. Actors aren’t the solution for all concurrency problems to be sure. You need to be more specific than “any time you need a fine tune control over concurrency – Actors fall apart”, because that statement only tells me you don’t really understand Akka at all.

    • “Akka will be the killer enterprise framework. I’m not aware of anything mainstream Java that takes advantage of the 100-core CPU’s that will be here before we know it.”

      Just wanted to mention that Akka isn’t going to push people to Scala; Akka has a Java API too.

  2. I think Clojure paragraph on concurrency said it quite well – actors were initially designed for distributed programming. As a matter of fact, GridGain does use Actor analogy for message sending. The point Nikita was trying to make is that implementing message sending itself in Java or in Scala, where lot’s of concurrency and fine-tuning comes into play, is really cumbersome using actors.

    –Best

  3. Nikita, as a programmer familiar with haskell, why would a FP enthusiast (first and foremost scala audience) chose scala over haskell for the job, given that all necessary haskell libraries are available ?

    I found that with time more and more great libraries (especially for web development) become available for haskell. And now i am starting huge migration project from legacy delphi system to haskell based web application. And it works out great.

    • I like Haskel but I think a general purpose language these days can’t avoid solid OOP foundation. The original attractiveness of Scala was that 1) it combined OOP and FP for the first in a sane and workable way, and 2) it was statically typed meaning that there were no lazy shortcuts taken in its design. For the most parts 1) and 2) worked out perfectly.

      Needless to say that Scala enjoy enormous Java eco-system as its host environment.

      Haskel is an older language and it’s adoption curve (or lack of thereof) is probably speaking for itself on whether it will remain an extremely niche language.

  4. That is an interesting prediction. The only thing I’d argue is sticking on Java 7/8 and give them 50%. Java 7 hasn’t been released yet, afaik (I mean final build or how do they call it), and looking at the current state of enterprise software, you still can come across 1.4 applications. So in my opinion, 50% is a real figure if talking about native Java, without versions.

  5. I think that 5 years is a little to optimistic, Java is still by far most popular JVM language. It is taught in schools everywhere I can think of and enterprise community is afraid of “new” technologies. I know some enterprise developers that twitches when they see annotations or generics.

  6. Hey JVM guys,

    Groovy is now breaking the trade-off “dynamic x performance”.

    By this now well-known innovation rule, it’s definetly the most innovative language in Java by now.

    Please see this benchmarks:

    1. Groovy 1.8: http://regispires.wordpress.com/2010/10/23/comparacao-de-performance/
    2. Grails (full-stack with uses Groovy): http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

    And Groovy nowadays the king for DSLs and metaprogramming (AST, MOP). See it by yourself, not by me.

    My prediction for new JVM systems for eternity :-)

    – 80% Groovy (long tail)
    – 20% Java, Scala, Clojure, JRuby, Ceylon, whatever… (very specific contexts)

    I’m serious about that! (Joker)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,361 other followers

%d bloggers like this: