Digging into Dan's Mind: Why Scala?

Tara Calihman June 05, 2013

When starting a company, there are so many different things to think about. One of my first questions was about how Victor Ops decided which programming language to use. One of the others was about where they stored the beer. Asking hard questions like these will always lead you to Dan.

Here’s what he had to say about Scala and why he made the choice he did…

One of the things that really excited me about starting VictorOps was the chance to build a new software platform from scratch. Given that there are a lot of great new languages and frameworks available now, I wanted to take this opportunity to select the best technologies and tools available that would allow us to build a highly reliable platform quickly, that would be performant and incrementally scalable as we grow. The first decision to be made was which programming language(s) to use.

I have used many different programming languages during my career such as C, C++, Java, Perl, Python, and been exposed to others like C#, Ruby, Javascript. All of these have their advantages, disadvantages, quirks, etc. While I have my own opinions about each of these, I try not to get wrapped up in “religious” arguments about which is better, but instead view them all as potential tools, and pick the best one(s) for the job at hand.

One approach that I have seen before and that I’m not a big fan of is to create a software platform that uses many disparate languages for different parts of the system and then tries to glue them all together. This is certainly possible (and some might say reasonable) if you are developing a loosely coupled architecture in which the components communicate through well-defined API’s (e.g. a Service Oriented Architecture - SOA). In that case it would be totally valid to choose a different language for each component as long as appropriate language bindings existed for the API.

However, in my experience the choice to use different languages in a software platform is often driven more by the personal preferences of individual developers, and/or their desire to try out the newest trendy language or technology. The problem with this approach is that either the developers need to know and work with several different languages across the product or they end up being siloed into the components where they are comfortable with the language being used.

That is one of the things that appealed to me about Scala. It is a full stack language that includes a Web Framework (Play), as well as a highly scalable backend framework (Akka). There is a definite learning curve for people like me that do not have experience in functional programming, but once you learn Scala you can work in any area of the backend server using the same language.

Other full stack languages exist, but none of them seemed to fit just right:

  1. Java – I really like Java and most of my programming experience is in Java. It is a powerful language with a very rich set of open source and third party libraries that you can use and build upon. However, my main issue with java as a full stack language is that java-based web frameworks are typically overly complex in regards to setup, configuration, ease of development, etc. This would not be a showstopper if there were no good alternatives, but I don’t think that is the case.

  2. C# and .net – I also really like the C# language and the .net framework provides a very full featured, well-integrated platform with a lot of great tools. However, this requires that you buy into the Microsoft platform both philosophically and financially. It is also limiting in terms of the ability to use open source libraries and frameworks, which is something that should not be taken lightly.

  3. Ruby (Rails)/Python/PHP/etc. – There are many other “scripting” languages that can be used as full stack languages, and each of these has its strengths and weaknesses. However, ultimately my concern with them is that they are not compiled, statically typed languages. While it is a matter of opinion whether this is important, I am a firm believer that it is.

So this lead me to take a closer look at Scala, and the more I looked, the more I liked what I saw.

Ready to get started?

Let us help you make on-call suck less.