We already know what Dan likes about using Scala, so I thought it would be interesting to hear the other side of the story. Here are Dan’s top five Scala challenges:
There is a fairly steep learning curve for imperative programmers (at least there was for me). Functional programming requires a bit of a mind-set shift that can be frustrating at first. However, since Scala does support imperative programming as well, you can make the transition at your own pace. I think that it is common for developers to start out using mostly imperative style and to gradually start incorporating functional concepts into their code as they become comfortable with them.
While Scala is a mature language, there are not a lot of developers with Scala experience. This can be an issue when you are trying to grow a development team. However, my impression is that interest in and use of Scala in the development community is growing so the pool of qualified candidates will increase over time. I also find that developers that like Scala enough to stick with it and learn it in depth are usually very passionate about the language and it’s benefits. So if you can find those types of developers, they are more likely to be excited about what they are working on and become strong contributors.
Scala is a very broad, comprehensive language with** lots of useful but sometimes complex features**. For an expert Scala programmer this is an advantage, but when starting out it can be pretty intimidating. It also can make it harder for new or intermediate level programmers to maintain code that uses these more esoteric language features.
The design of the language was heavily focused on reducing the amount of code (especially boiler plate code) that is needed when writing Scala programs. I think that this is a reasonable goal if not taken to the extreme, because it helps you write code more quickly. But I personally believe that there is a potential danger here in that it can make developers think that code with fewer lines (and even fewer characters) is always better. This can lead to things like using short non-descriptive variable names, leaving out type information, long chains of function calls, etc., all for the sake of reducing the number of characters you have to type. In most cases I believe that it is better to sacrifice a little bit of brevity to make it is easier for someone other than the original author to read the code. The good thing is that Scala does not prevent you from writing more “descriptive” code, because you can include type information if you want, avoid long function call chains, etc.
Currently Scala compilation can be slow due to the fact that it does more for you than the javac compiler (e.g. type inference, implicit conversions, etc). However, work is being done to improve the compilation speed, including things like incremental and parallel compilation, so I assume this will improve over time.
The bottom line of my analysis is that Scala is a comprehensive, powerful, full stack language that can be used to build highly reliable, scalable systems. The functional programming learning curve can be steep and at times frustrating, so you have to be prepared to feel a little lost for a while (at least I did). But I’m starting to feel more comfortable with the language and framework, and seeing the benefits it provides.
I also believe that the libraries, frameworks and tools built around Scala will continue to expand and improve which will only make this environment more compelling in the future. Overall I am very excited about the Scala eco-system and am confident that it will provide a great platform on which to build VictorOps’ services.
VictorOps helps you better coordinate incident response before, during, and after an outage. Sign up for a 14-day free trial to see how you can leverage VictorOps to improve crisis communication during an outage.