Recently I got the chance to evaluate possible approaches for greenfield development of some cloud services that eventually have to scale to Twitter’s scale. “Greenfield” meaning that no code has been written yet, there was little existing infrastructure, and most hires were not done either. So an ideal situation for doing an evaluation of technologies on the merits, rather than on the legacy or the knowledge of the team.
Among other things, I checked out Scala and the Akka Framework. What I found is not what I expected, so I’m blogging this:
- Scala fixes a number of long-standing annoyances with Java. Top of my list: there are default values for method parameters, and you can specify values for method parameters by parameter name, like in Python. You can also get the equivalent of a Java Bean in about a quarter of the code, which is nice and completely unnecessarily repetitive in Java.
- Scala is not actually a functional programming language, as everybody says it is. It would better be described as a multi-paradigm language. It can do functional, but it can also do object-oriented, and I would say there is enough in there that it also qualifies as a rules/pattern matching language.
- Beyond that, it has a flexible-enough syntax that you can build your own kind of programming language, using nothing else than valid Scala constructs. Which is really kind of cool.
- So if you think that makes it a complex beast, you’d be right. For one, it contains all of Java as a subset, and it’s not a large subset. So learning just the basics of the language will take you a lot longer than some other languages.
- The Scala tooling is still pretty bad. There is “the” (which implies something!) Scala IDE — basically Eclipse with a few more plugins. I could not even get it to go to the implementation of a method when clicked on it — that bad. So think of having to write complex code with a plain text editor, not an IDE, which is not great.
- Akka, as a framework, has great promise. But: it suffers from a lack of documentation, and when I attempted to make a JSON web service work that used its own JSON serialization scheme, I got completely stuck. I could not figure out where to insert something like a custom serialization class into the framework.
- This is where all the nice domain-specific language stuff, with insufficient tooling, really starts to hurt: It’s great if you can express things in just a few lines that would usually take lots of code, but you lose the ability to answer the question “what they heck does this code actually do”? At least I did, and not for a lack of trying.
- I felt teleported back into the early days of C++ precompilers, and me going through reams of generated C to figure out just where in the world the compiler bug was. Debugging domain-specific language stuff in Scala is just like that.
- “implicit” objects — don’t even get me started on this. It sounds all nice, in theory: adding methods to objects without having to change the class. The trouble is: you have some kind of method in some code you are looking at (and it might be called %~~%, for example, just to make matters worse) but it’s completely unclear in which class to look for its declaration or implementation. It might be up your current object’s inheritance hierarchy, or it might be anywhere up the inheritance hierarchy of any number of other objects. I’m sorry, but that is a sure way to drive programmers with deadlines insane.
I can image that Akka can be highly productive for a extremely bright team, working on the same code base day in and day out. Where everybody knows where things are and how they work. (Akka has a Java version, but the documentation was insufficient to get any of my non-ovious questions answered.)
James Gosling, the original Java architect, once described a key design goal for Java as being extremely easy to read. (Which isn’t as true any more as it was before Annotations, but it’s still quite true.) Scala is the opposite.
If you think C++ is confusing with overloaded operators (something Java disallows for that reason), Scala is 10 times that. So if somebody gives you a piece of Scala which you did not write but have to fix or extend, good luck, I don’t envy you.
In my experience, this is a far more likely scenario than being part of a tight group of super bright people working day in and day out on the same code. So, many of Scala’s advantages will likely turn out to be disadvantages for many people in practice. As it would be in this project.
So I’ll pass.