Going Round and Round

Just like I've previously had Haskell, Java-sucks and Lisp moments, I think I'm now having an Erlang moment.

I've been working on my personal project, and I've now hit the part that's been looming for a couple of years, and it requires concurrency. So I've been writing a class, it's a simple class, it just happens to receive calls from all over the place. It's got its own thread. Concurrency is hard. So, brainwave! All incoming method calls will create an internal message object to queue for execution on the object's thread. And! I'll create an internal state object; therefore incoming method calls won't be able to change the thread local state, even if they (incorrectly) wanted to. Brilliant!

So, I start my typing, and it's C++, and I'm creating functors, and object wrappers, and helper functions, and I haven't actually started writing any of the interesting parts of the class yet and, and...

I should be using Erlang!

This a good design, and a good implementation. But none of this code should even exist. This is precisely what Erlang gives you for free. As I keep seeing half the great ideas for how to solve the irritating, small, major and show-stopping bugs that can creep into C++, Java and C# applications have already been permanently solved in some 'esoteric' language.

Of course, if you can call the language that runs most of Europe's telco infrastructure esoteric...

So, tell me again why it isn't ready for us to use? And why aren't I using it? How well can it talk to Ruby...