I read an interesting blog from Cedric Beust on Erlang: the verdict . Since, Joe Armstrong’s book, Erlang has come to the spotlight whether it’s ready or not. Cedric is well known in Java community and I have used his tools such as EJBGen that he wrote in late 90s and TestNG: a testing framework. Here is summary of objections that he raised on Erlang and my thoughts:
Object Oriented
His first objection is that Joe is biased against OO and Erlang is not an object oriented language. I can’t say having OO is must for every good language. Erlang is fundamentally functional language with good support for concurrent programming. And as I wrote earlier on Polymorphism in Erlang, Erlang is based on Actor model, where each object has a mailbox associated that receives messages. In this model, the message passing takes literal form rather than method invocation. Also, according to GoF author Ralph Johnson sequential Erlang is functional and concurrent Erlang is object oriented. And I admit method invocation based object oriented is easier than message passing, but it’s just matter of style. I believe abstraction, encapsulation, separation of concerns are more important than inheritance or combination of state/behavior.
Scalability
His second objection is Erlang claims to be scalable, but it only provides primitives to build scalable systems. Though, I agree building scalable systems requires scalable architecture and just using Erlang will not make your system scalable. Also, I agree that you can build scalable systems in any language. I have been building distributed systems for over ten years and I have used CORBA, EJB, messaging middlewares, JINI and all kind of RPC or Web Services. In a lot of ways OTP gives you comparable features, but all that is well integrated into Erlang platform. Also, one of basic requirement for distributed systems is building monitoring and fault tolerant system. Back in 90s when I worked on CORBA, I build pretty complexed monitoring system that allowed sysadmins to watch all servers on machines and see their health. The system also provided ability to automatic and manual start/stop of processes when they crashed. All that was a lot of work, but OTP gives you that capability right away. These days you can also get similar features from application servers and commercial monitoring systems, though open source app servers still lack in that area.
Performance
Cedric also raised recent performance problem that Tim Bray had processing large files in Erlang. Erlang was built for telecommunication systems and though it’s now being marketed as general purpose language, but it still lacks many of the features for general purpose language. Slow I/O or slow regular expression is one of them. I hear a lot of people dismiss performance by just saying computing cycles are cheap and human cycles matter more, and just throw another box. I think CPU cycles still count, especially when difference is in the order of magnitude than other solutions. I also heard from Ebay architect Dan Pritchett, how building large data centers are running into a wall because of power demands. Erlang works best when your application is not CPU-bound, so in that case I would not recommend using it. I think now that Erlang is under spotlight, the future releases of Erlang will address slow I/O, regular expressions and commonly used primitives.
Five 9s
In Erlang fault tolerance is very different from traditional approach in Java, where server tries to handle exceptions and keep running. In Erlang when an error occurs the process simply dies (if it chooses) and supervisor can restart it. Again, this can be built in any language. Erlang provides nice primitives for building fault tolerant systems, though I agree that Erlang does not give this for free, but you still have to build it. Cedric omitted hot code swap, which I have seen only in commercial application servers such as Weblogic and Websphere.
Lock free programming
I have been writing multi-threaded applications for over ten years and I like Erlang’s approach because I have spent too much time in fixing locking and synchronization problems. Cedric complains that Erlang uses locking internally and I am fine with that as long as it’s not exposed to the APIs. Though, I admit in certain cases locking can be useful. For example, one of the exercise from Joe’s book asks reader to implement a correct way to register a process when multiple processes trying to do that simultaneously. And I have seen a lot of clever solutions for that, which would have been easier with locking. I don’t like clever code because it becomes maintenance and debugging hell, so I would have liked simple locking in that case.
Distributed Data
In conclusion, Cedric mentions how distributing data is easier than distributing code. I agree and that is why I like Mnesia instead of centralized database approach. Our CTO Werner Vogels at Amazon has been talking for a while on CAP principle and how databases don’t scale. In one of the system we actually had a database that could not scale and was replaced by a collection of distributed berkley databases. Erlang gives you that capability with Mnesia.
Conclusion
I think Erlang is a specialized language that may not be suitable for all applications, and I have been trying to learn it myself and writing a few applications. I like skepticism that Cedric showed, I think it’s important to have a healthy skepticism when trying new thing. I see too often, a new thing is simply marketed as a Silver Bullet. Also, the authors or makers of new product have their own agenda. Though, you cannot judge or give a verdict just by reading a book. You have to try it yourself in a real project. I like a quote from Matrix movie: “You do not know someone until you fight them.” You can only learn something by trying its limits and not by just reading a book. That is what I am trying to do, and despite the cryptic error messages in Erlang I will stick with it. I think the new era of application development is multi-language, where you use right language for the right task and Erlang is just another tool that will only work for the kind of problems that it inherently was designed to support. Finally, as Fred Brooks wrote there aren’t Silver Bullets, but I see all the time, people are quick to hail new language, methodology or software as that. I believe with good people you can do everything and build the best systems with any language, methodology or process.