Q&A with Mathias Doenitz: Scala User Group – Berlin Brandenburg
Scala has been a much talked about programming language since its adoption in such companies as Twitter, LinkedIn, Foursquare and many others. It’s based on Java Virtual Machine (JVM) and the main principle is to be a SCAlable LAnguage which means it’s good for both small and huge projects and also a tool of choice for scalable applications to accommodate growth in the world of Big Data. Scala’s syntax is concise to the point of resembling a scripting language and yet, while being quite conventional, it is a feature rich language with strong object-oriented instruments, first-class functions, a library with efficient immutable data structures, and a general preference of immutability over mutation. At the meetup of Scala User Group – Berlin Brandenburg at Fyber’s Berlin headquarters last week, we had the pleasure of welcoming Mathias Doenitz, lead developer of spray.io and an outspoken, passionate Scala-ist. Mathias presented a talk on “Reactive Streams & Akka HTTP” as part of his European tour of Scala user groups. We caught up with Mathias Doenitz during the break and asked some questions about Scala usage in general and Reactive Streams & AKKA HTTP in particular.
Could you tell us about how you started with Scala and why you created Spray? How do you feel about Scala constantly evolving in the years you used it. What did you like in the beginning, what do you like now?
I started using Scala in 2010, so that’s almost five years ago. I was in some way frustrated with using Java for many projects for many years. I felt like I wasn’t moving forward anymore as a developer. It was the same thing over and over again; you know the patterns, apply them. There wasn’t really any learning happening anymore. So I was looking into new stuff and saw Scala and really liked it, because of the conciseness of language. Of course, in the beginning in 2010 the ecosystem wasn’t as mature as it is now, the IDE support was a lot less mature and that was sometimes painful but the benefit of being so concise and expressive immediately outweighed the problems by far. After 2 or 3 months I decided that my next project was going to be completely in Scala, just to learn it, from then on it was a huge learning curve for me. I entered a completely new world with very interesting things that I hadn’t seen before, the whole functional aspect was completely new to me. I was slowly seeing all the benefits of immutability, purity and so on. What I like about Scala is that you don’t have to use all of its features right away, but instead use more and more features as you grow as a developer. So in the beginning you might use “Option” instead of “null”. Very easy to understand and with immediate benefits. Then you realize that there are many cool methods that can be found in “Option” but also in collections – so whats the common path here? You can slowly teach yourself completely different ways of programming. On the other hand, you don’t have to adopt the idiomatic Scala style, you can write the exact same code as before but in 10% of the lines. I really like that. What I also really like is the fast pace of innovation in the Scala ecosystem. That was something completely unheard of in Java. New features coming out every half a year, developed by incredibly smart and innovative people. The conferences were small, they felt like family gatherings, you could really get to know the people who would have great influence on Scala’s development. You could talk to them at a conference directly, Martin Odersky was right there with 50 other people. It just felt like a nice world of highly motivated and very talented people to be working with.
As somebody who has moved from Ruby to Scala, what are your tips for Ruby developers to get started with Scala?
The nice thing about Ruby is that it is very concise, too. You can say a lot in a few lines. With Scala, it’s the same. Also, because of the type inference, you don’t have your types in your face all the time. You can actually leave them out when you don’t need them. So that’s also something that makes it easier for Ruby guys. In the beginning you don’t need to know all the rules of where exactly you need to put in a type annotation. You just let the compiler figure out if it doesn’t do it. One main benefit when you come from a dynamically typed language like Ruby is that you can just catch so many more bugs right before your program is actually run for the first time, that takes a lot of the pressure out of your tests. Its actually quite easy for Ruby guys to move on to Scala – especially compared to, say, moving from Ruby onto Java, which must be a complete pain.
Many companies in the mobile space who process large amounts of data – for example, Twitter – made the transition from Ruby to Scala. As a company who is in this this transition right now, what advice would you give Fyber’s Developers, Architects, and Programmers who used to program with Ruby as they roll out Scala and Akka?
It depends on the goals that you want to achieve. If its mostly performance, I wouldn’t immediately do a full migration. I would try to chop up your architecture and concentrate on small chunks, and then attempt to put in a parallel version that does something similar to what your existing system already does. And then bring that up, try to integrate it, have it run in production. Once this is successful, you can apply this technique to other components. Depending on how micro-service architectured Fyber already is, you can do this transition step by step. Of course you would want to first concentrate on the components that are most critical to performance.
What editor or IDE do you use?
I have always been an IntelliJ IDEA fan. I still use it. I know JetBrains makes a Ruby IDE, so when people already use that, the transition to the Scala plugin for IntelliJ is probably not gonna be that hard. In the end I don’t really think it matters, – it’s a matter of taste and what you feel most connected to.
Akka introduced persistent storage so that messages can be sent in a more reliable way, can you tell us more about it?
One thing that is great if you use Scala is that you are on the JVM and you have full interoperability with everything in the Java ecosystem, which is huge. Whatever database you choose, there is probably going to be a binding from Java that you can use for Scala. Scala itself is a language. So there is no direct connection to any type of storage system. Akka on the other hand is a library that tries to give you everything you need in order to be able to work with highly concurrent, distributed applications. One major aspect that is becoming more and more important is Event Sourcing. If you want to go down that new way of organizing your application, then Akka and the Akka Persistence module might be something that you want to look into. Its not a relational database, it’s a completely different way of organizing your applications. If you are looking for a new kind of more message driven compatible storage solution, take a look at Akka Persistence, which is great but it would require you to adopt something like Event Sourcing, which is something you can’t roll out immediately across your whole system. But starting with smaller bits of your total architecture and realizing what benefits lie in something like Event Sourcing might help you gradually accept it and transition into it, which I am sure is going to be very exciting. So the next application that I want to build is going to be completely event sourced because I think it’s a nice approach and I like the idea of not throwing away data that I have and having a log containing everything that I have ever seen. Why should I delete stuff – hard disk space is cheap, and being able to roll back at any time to anything is great. I don’t want to overwrite anything in an immutable database.
What about fault tolerance for reactive streams? TCP has an algorithm to deal with the loss of messages or duplication of messages. Is there anything like that planned with Akka Streams? Because fault tolerance is like one of the cornerstones of Akka and it would be strange to not have it.
Absolutely, there needs to be something there. If we talk about the network and the TCP protocol, it makes sure that we won’t lose intermediate messages. We can still lose the connection, but that’s just going to end up in an error in the stream, and there is no way that you will ever have a dropped message on a TCP stream. So that’s good and inside of a JVM we can also assume that we have not lost an element. But you you are right, the question of “Fault Tolerance” in terms of “what happens if a stream stage dies?” is a good one. Currently that just means that an error is going to be propagating through the stream and terminate your stream. In the future, we will probably have something like the equivalent of an Akka Router, where you have automatic scaling of one stage across several threads or actors. If they are implemented with actors, then there is going to be supervision there, meaning crashed things shouldn’t bring down the complete stream. You can just restart that component.