Why did you decide “against” using Erlang?

Answer 1

I am not going to even look at Erlang.

Two blog posts nailed it for me:

1. Erlang machinery walks the whole list to figure out whether they have a message to process, and the only way to get message means walking the whole list (I suspect that filtering messages by pid also involves walking the whole message list)

   http://www.lshift.net/blog/2010/02/28/memory-matters-even-in-erlang

2. There are no miracles, indeed, Erlang does not provide too many services to deal with unavoidable overloads - e.g. it is still left to the application programmer to deal checking for available space in the message queue (supposedly by walking the queue to figure out the current length and I suppose there are no built-in mechanisms to ensure some fairness between senders).

   erlang - how to limit message queue or emulate it?

Both (1) and (2) are way below naive on my book, and I am sure there are more software "gems" of similar nature sitting inside Erlang machinery.

So, no Erlang for me.

It seems that once you have to deal with a large system that requires high performance under overload C++ + Boost is still the only game in town.

I am going to look at D next.