A while ago I was pretty convinced Scala would be the next Java.  I’m now less sure and it’s mainly down to (a) skills – there’s a lot of Java about; and (b) [and very much related to (a)] there are too many languages around today for any one to gain critical mass, particularly with the cult followings that most languages seem to attract.  There was a similar situation in the late 1990s with C++, Smalltalk, Ada, Java, Pascal and older school Fortran, Cobol, LISP etc.  Today we’ve still got most of these and 100+ others.  What I think is clear is that the idea of a VM is here to stay and the JVM will host several languages on a typical project of the future.  We’ll argue for years about which is best for what but a typical project could be something like Java/Scala for the backend with Java used to integrate with very well established Java frameworks, Groovy for unit testing (I’ve seen this in action and it’s very cool) perhaps with some Groovy code creeping into the Java/Scala operational code and god knows what on the frontend.  I’d like to think JavaFX but I suspect it’s the Betamax of client-side technologies.  With JavaFX, Silverlight, Air, the re-emergence of Applets, rich-client technologies, further advances in AJAX and HTML and my relative inexperience with frontend stuff, I’m confused.  Then there’s the multi-core issue and the pressure we’ll see to get really good at parallelisation, which is going to be really tough.  You’re then into Haskell, Erlang and 20+ languages arguably targetting this space.

Anyway, the Scala session was very good and has convinced me that we should use it in a very staged way to initially get rid of a lot of our boiler plate code.  I was thinking of introducing Lombok once we’ve got many of the more important (for us at least) non-techie issues resolved, but now I think we should go for Scala.  I had a chat about a strategy with the presenter after the session and he thought it was a good plan and, without doing anything clever, we could reduce our source line count by 50%.  This would also get us used to the syntax and we could start to explore how we use Scala rather than simply port to it.  Not just yet though.  Here’s an example of what that might look like.  In Java we have an immutable class (I haven’t checked the syntax nor checked it compiles, it’s late and you get the idea):

class Person {
    private final String firstName;
    private final String lastName;

    public void Person(firstName : String, lastName: String) { .... etc};
    public void getFirstName() { .... etc};
    public void getLastName() { .... etc};
    public void equals ....
    public void hascode ....
    public void toString ....
}

becomes in Scala:

case class Person (firstName : String, lastName : String)

and that’s it!  It compiles to Java bytecode, we don’t have to write a load of boiler plate code (and perhaps mis-code equals … for example) nor test them, at least explicitly.  It seems pretty low risk to me and we’ve got a lot to gain … except supportability, by which I mean skills as ultimately this will be the client’s code.  Hmmm ….