Great post, but if you put things into practice like "write them as gen_servers", the resulting code will be way more verbose than something like Ruby.
I think some way of creating 'object processes' with methods and state would greatly benefit Erlang. I mean, if it's such a common pattern, why not make it simpler, easier and possible with less boilerplate.
I think when selling Erlang it is best not to oversell the concision. Writing something in Erlang can be concise, but where you get the benefit is when you write something in Erlang that really benefits from the libraries and message passing. A gen_server may look somewhat verbose, but remember you're getting the supervisor tree, code upgrading, and a variety of other things with that. If you have to implement that in C it's going to really cost you.
But if you're just sitting there writing "algorithmic" code, well, maybe it's a 2x or 3x advantage over C because you're not managing memory and the pattern matching can be nice, but it's no Ruby or Python. You really only get the 5x-10x advantage over C(++) if you're playing to Erlang's strengths, it does not have the generic ability to cut down code like well-written Ruby, Python, Haskell, or other languages that pride themselves on being concise. In fact Erlang's metaprogramming facilities are frustratingly thin if you're used to having some around.
If you're interested, consider Lisp-Flavored Erlang, but I have no direct experience with that. (That's because my primary Erlang is actually using it at work, and while it's perfectly OK that I'm using it, I see it as advantageous not to make it necessary for my successors to have to learn both Erlang and Lisp to work on my stuff. If I ever have a home project with Erlang I suspect I'd lay one of the syntax replacements like LFE on top of it, if only to play with it.)
> If you have to implement that in C it's going to really cost you.
I'm not sure C is a good language to compare Erlang with. I think the competition these days goes from Ruby and Python to Scala and Java. I mean, if you're not beating C in terms of verbosity (which Erlang does handily, comparing apples to apples), and you're much slower, what's the point...
I think some way of creating 'object processes' with methods and state would greatly benefit Erlang. I mean, if it's such a common pattern, why not make it simpler, easier and possible with less boilerplate.