As the title itself reflects, this is a highly opinionated post.
Why I choose Scala then?
The lead designer of Scala, Martin Odersky, has been involved in Java since 1995 and contributed to the current Java Compiler and Generics introduced in version 1.5.
Around 2001, at the École Polytechnique Fédérale de Lausanne (EPFL), he started to investigate the next challenges in software programming and he thought that unifying OO & FP would address those challenges.
The outcome was Scala (acronym for Scalable Language), in 2003. In 2011 he and other collaborators founded Typesafe Inc. (Lightbend as of Feb. 2016), a company to support and promote Scala.
Dynamically typed languages have their place as well, they are versatile and have plenty of use cases where they shine. And of course, that's not only the case for Javascript (see Ruby, Python or Groovy, just to name some of them).
When talking about building an enterprise application though, type-safety is a must to me. That piece of software will be used to encode and manage business rules, and it'll be developed and maintained by many developers during its life which, in this context, should be rather a long time.
Coming from the Java ecosystem, transitioning to Scala is easier. It runs on the JVM so all you know about it prevails (memory management, configuration, fine tuning, etc). You can integrate Java libraries, frameworks and tools in a Scala application. Moreover, Java and Scala classes can be freely mixed.
The Scala community is an important part of the Java ecosystem.
Functional Programming is on the rise nowadays. Beyond the hype, FP principles make it easier to reduce the complexity of a system by setting a clear separation between functions (pure functions) and side effects.
As Moseley and Marks described in Out of the Tar Pit:
Complexity is the root cause of the vast majority of problems with software today...
... it is our belief that the single biggest remaining cause of complexity in most contemporary large systems is state, and the more we can do to limit and manage state, the better.
The deterministic nature of pure functions along with the type system significantly reduce the cognitive load required to reason about them. The lack of nulls, thrown exceptions and mutability (accidental complexity) lets you focus on the important logic of the application (essential complexity).
Unlike many other FP languages, Scala allows a gradual, easy migration to a more FP style. You can start to use it as Java without semicolons and evolve it over time.
Besides the benefits of FP, Scala's features can boost development productivity even if used in a OOP fashion.
Immutable objects and methods without side-effects make concurrent programming easier & thread-safe.
As Joshua Bloch stated in his book Effective Java:
Classes should be immutable unless there's a very good reason to make them mutable
In Scala, immutable is the default.
==In contrast to Java, in Scala == is not a built-in operator but a method that can be overridden. For example, String class overrides it to compare the content of the strings.
A tuple is an immutable sequence of values of multiple types.
A null value is often abused to represent an absent optional value. This means the null value is bubbling up the hierarchy call. Sometimes this just leads to an exception much higher in the hierarchy, where some piece of code isn't that null-friendly.
In Scala there's the Option type, and it represents values that might or might not be present. Instances of Option are either an instance of Some or None.
In Java, defining an immutable (for fairness in the comparison) POJO requires explicit declaration of the type members, constructor, getters and overriding the hashCode, equals and toString methods.
In Scala you get all that just by defining a class as a case class:
A case class is a regular class with reduced boilerplate by the compiler:
toString, equals and hashCode are defined based on the constructor fieldsstatic methods in Java) containing:
apply constructor based on the class constructorThe methods in the companion object allow to perform pattern matching on instances of the case class (see next section).
Scala has a built-in general pattern matching mechanism. It allows to match on any sort of data with a first-match policy:
As you can see it can match values as well as data structures. This is of great use when in combination with case classes. With a small amount of code we can define an expression writer:
Another useful scenario is pattern matching Option:
The Scala collections API provides plenty of methods to simplify manipulating data:
A function in Scala is a first-class value. Like any other value, it may be passed as a parameter or returned as a result. Functions which take other functions as parameters or return them as results are called higher-order functions.
Traits are like Java interfaces but they can be partially implemented. This enables multiple inheritance (a mixin):
(Example taken from the official Scala Documentation)
Scala's Future[T] provides asynchronous, non-blocking computations that will eventually result in a value of type T. The future will either succeed or fail:
The Scala community is increasing and it's more active every day, with many well known companies using it (LinkedIn, Twitter, Foursquare, Netflix, Tumblr, Soundcloud, Coursera, ...).
Lightbend (formerly Typesafe) is the most influential actor in the community. They are actively contributing to the Scala programming language and some frameworks on top of it. Their reactive platform is consists of the following components:
Typelevel is another company which provides pure functional programming libraries for Scala. The more relevant ones are:
Akka deserves a dedicated section on its own merits. I am by no means an expert in Akka but I'd like to outline the most relevant features about it:
I plan to write a post about it at some point but, in the meantime, refer to the Akka documentation for more information about it.
I find Scala a great choice, especially as a step forward for Java developers eager to embrace functional programming. It's not only about purity, category theory, functors, monads or higher-kinded types, these will be the logical consequences of shifting to the FP paradigm. In this context, Scala is flexible enough to accommodate developers in all stages of FP adoption.
On the other hand, for a Java company, moving to Scala it's an acceptable risk due to their compatibility and shared runtime. For this to succeed, it's important that at least one or two developers can take responsibility for its adoption, motivating, training and assisting the rest of the team, while periodically assessing the potential risks of generating knowledge silos.
Therefore, it's a win-win scenario: reasonable risk and happier developers.
If you want to learn more about Scala, these are some useful resources:
Would you like to leave a comment? Since this blog is hosted on GitHub Pages there's no straightforward way to do so.
Instead, you can add a comment in this GitHub issue. If you'd like to see it here, refresh this page after posting the comment.