In my latest meanderings across the Net, I came across this blog by Patrick Lenz, a Ruby on Rails application scaling guru. This blog has a 4 article series describing the mind-boggling effort it has taken Patrick and his team to scale the backend of eins.de, a popular German social networking site.
This site originally had 50,000 lines of PHP code, and it was transformed into 5,000 lines of Rails code (some features were left out). This speaks very well for Rails's boost to developer productivity, but that's not so shocking anymore.
It sounds like the coding was the easy part. It took Patrick and his team months of hard work to find the bottlenecks in and optimize the numerious components that drive comprise application's backend: Lighttpd, proxy server, Rails, Linux, MySQL, memcached. Many of the hidden bottlenecks came from impenetrable issues surrounding issues with Rails dispatchers in Lighttpd, difficulties in estimating the right sizes for thread pools, and poor multi-master replication performance in MySQL.
During this whole time, the site suffered from poor performance.
It doesn't seem like the problems came from Rails per se, but with the unimaginably complex set of auxiliary tools needed to support such a high-volume Rails application.
It must have been a very expensive project, and that's without counting the hidden cost of user dissatisfaction.
I'd bet it would have been much easier to scale this site if it were written in Erlang. The concurrency bottlenecks would have gone away, native compilation with Hipe would have outperformed Ruby, and the number of moving parts would have been much smaller: it would require Yaws for the web server, Mnesia for replicated live session data and MySQL/Postgres for large volume data.
If (when?) Mnesia will be made to handle very large data volumes better, the need for an external DBMS will vanish, and even a high-volume website could be powered by not much more than Yaws + Mnesia. Even putting aside Erlang's proven scalability and fault tolerance in commercial phone switches, when your application has few moving parts, bottlenecks are easier to identify and fix.
Another nice feature and Erlang backend has is that experimenting with different configurations would require no downtime: Erlang has hot code swapping (you can even hack Yaws while it's running -- try that with Lighttpd), and Mnesia can be reconfigured without taking it offline. This is not surprising considering that Erlang was designed from the ground up for applications that target %99.9999999 (yes, that's nine nines!) availability.
The main downside with Erlang web development is that Erlang doesn't have as many libraries are Rails. However, when you consider the tremendous efforts saved due to much better scaling, the productivity equation starts looking different.
It's strange that you don't hear of people using Erlang as their backend language for real-world websites. Is it because of a language barrier due to Erlang's functional nature? Poor PR? I can attest that Erlang web development is quite fun and productive, and I think many people would agree with me that saving hundereds of thousands of dollars on optimization efforts doesn't suck at all.
If more people used Erlang, web-centric libraries would be more abundant as well. This will happen. It's only a matter of time. Erlang is too good to remain unnoticed by the web developer community.