To view parent comment, click here.
To read all comments associated with this story, please click here.
That's a pretty broad statement.
I've done programming with threads in C++, Java and even Python. Some of it could have been done in Erlang and other things I wouldn't dream of doing in Erlang.
If I concurrency was only about getting the best performance out of your machine at any cost, then you might be right, but there are lots of situations where it's just not worth it to use a tool like Erlang.
That's a pretty broad statement.
Yes, indeed. I did of course not mean the obvious; attempting to write the next Crytek engine in Erlang just to be able to peak all your cores, and then let it borrow some from your friends as your machine just isn't cutting it. For some things, there simply is no replacement for C++. The same goes for Erlang.
*Yawn*, call me when game are written in Erlang..
Erlang in an UP is slow (roughly half the speed of C/C++), so a part of Erlang's scalability is "wasted" in catching with UP performance .. when it scales!
I remember a benchmark in which Erlang had IO limitation issue where the performance was much worse than C/C++ and where Erlang *didn't* scale.
So yes Erlang has some strong points in concurrency (it's syntax suck I agree) but it's hardly the magical cure you make it..





Member since:
2008-09-08
Right tool for the right job. For concurrency, the right tool just happens to be called "Erlang".
But I won't argue with anyone over the somewhat strange syntax of Erlang. But it sure does work.