Why Scala? Because C#

Strange as it may sound this isn't a post about promoting the adoption of Scala but if its a conversation you're already having there may be some points here that might help. I often hear rationale for Scala over Java based around the functional style, immutability and slightly better concurrency model baked in but I've always found there is a simpler point to be made. Time will tell wether the recent release of Java 8 will add enough to old faithful to slow the adoption of Scala.

I often get asked by people I'm introducing to Scala, "Why Scala and why not Java" and more often that not the topic turns to comparisons between Scala and C#. Its not just me either. Last year I was involved in a few rounds of procurement, interviewing prospective IT companies and team and a common pattern that came out of those interviews was people would be offering us teams composed of their C# developers over their Java developers. Scala experience was, at that time, still a bit light on the ground and yes you could argue that the general trend toward fully open source stacks in many markets was squeezing the amount of available work for MS folks but the message most people delivered was their C# developers were generally more capable of transitioning to Scala than their Java people. I can't necessarily dispute this either because I certainly feel my background in C# helped me ramp up on my first Scala project much faster than my Java experience had.

Allow me a little example (ripped right out of my Scala for C# Developers talk)

"CHRISTMAS".makeChristmasy
// => ***CHRISTMAS***

There are three important things to know here

1. The String class in Java is final and can't be extended.
2. The String class in Scala is final and can't be extended (it is the Java String class)
3. The String class in C# is sealed and can't be extended

Yet we just called a function on it that isn't part of Strings signature (it's common knowledge Scala has a lot of bells and whistles but trust me the String class doesn't normally have a makeChristmasy method)

To implement this we can make use of Scalas Implicit Classes. We can write a class that wraps a class, String in our case,

implicit class FancyString(val s: String) {
 def makeChristmasy = "***" + s + "***"
}

Import this into our namespace and voila our String variables and values have the makeChristmasy method available to them. Under the hood the Scala compiler is auto wrapping the String instances with FancyString where necessary. Kinda like this,

new FancyString("CHRISTMAS").makeChristmasy

Sure its essentially a bit of syntactic sugar but it can, when used wisely, help make code clearer.

C# can do this too. C# has extension methods,

public static class FancyString
{
    public static int MakeChristmasy(this String s)
    {
        return "***" + s + "***";
    }
}

So what? Scala has a feature that C# has and Java doesn't. Hell lets do the same in Ruby,

class String
  def make_christmasy
    "***#{self}***""
  end  
end 

So now can Ruby developers transition to Scala faster than Java devs? No, well maybe I'm not sure, stop confusing me, besides open classes in Ruby are a vastly different and scarier thing than extension methods and implicit classes.

Your point being...?

There is a certain power and flexibiltiy that a feature like implicits offer. An ability to coerce the underlying language into something that makes more sense in the given context. Yeah its open for abuse but we're supposed to be grown ups here people. Lets not force people to use plastic knives to cut steak just in case they stab themselves. Of course its not just implicits - the language is simply a richer language.

What Scala offers is somewhat like C# on the JVM. Java fell behind C# a long time ago and even with the release of Java 8 it is still not quite there. There is a degree of expressiveness in C# that enabled me in my .NET days to produce better, more grokable systems in C# than anything I produced in Java. I found the same with Scala. Sure there are many, many dark corners in Scala but they can be avoided be that through a common understanding, peer review, automated checks like Sonar or even through the use of Scalas in-progress ability to add/remove language features through modular design. "Scala: The Good Parts" as Thoughtworks termed it in their tech radar is a theoretical subset of the language that offers better collection support, terser syntax and a reduction in the need for pattern boilerplate without having to upgrade your JVM.

So while the gap between Java and Scala has lessened it's still there and given the cycle time for new Java releases it's not going to shorten any time soon. Perhaps you think there are times when you want your language to be a constraint on your team. I'd be suprised if you've never encountered a room full of mad language scientists trying to golf some operation down to 3 convoluted lines because "FUNCTIONAL PROGRAMMING YAY". But imposing artificial constraints because of a team problem is just going to frustrate the "good" people and frankly instead of an unmaintainable mess due to bonkers code golf you'll probably get an unmaintainable mess due to over application of EVERY PATTERN BECAUSE OBJECTS!

So why Scala? Because there is a core feature set in the language that enables people to produce nice clean straightforward code with less boilerplate and enough power and flexibility to make the intent of the resulting code clearer. Like C#.