I'm not sure that poker is a game that's amenable to being "massively multiplayer" in the usual sense. Server sharding is easy and obvious with poker, unlike with MMOs where everyone can (potentially) interact with everyone else.
For a very particular definition of "low" I suppose.
It's worth noting that he spent 9 months writing and rewriting his server in 5 different languages. It's not often you write something with that level of understanding of the problem.
I don't think you know what he was writing about. High scalability was a language feature in this case.
Kernel doesn't provide an interface to send a message in an unified way to any of (decided during runtime) - local pid, local process name, process on another machine. Erlang VM does exactly that. Sure, you can implement everything yourself - along with process control, notifications, distributed database, live code reloading and put it inside kernel, but I doubt that's what you really want... Erlang provides all that stuff out of box using - yeah - unix system programming. If they spent more than a decade getting that right, why should anyone redo it from scratch?
- fault tolerance (writing code as FSMs, ability to get information from remote nodes, notification about a node in a network going down) - language feature, not kernel
- load balancing (i.e. erlang's Distributed Named Process Groups) - language/library feature
You can of course deploy your own system of connection fault reporting, etc. But why do it, if erlang provides a node monitor and simply sends you a message when that node goes down?
Yet for some reason, the great majority of the world's network applications do fine without Erlang VM.
[Edit: keep in mind that his application was a poker game server when you re-read that article. "Even" in 2005, the technology to do that was available, without Erlang.]
I have more to say about this but I am afraid I will end up spending the rest of the day proving someone "wrong".
Sure they work without Erlang VM. A lot of them also do fine without UNIX. That doesn't prove anything or anyone wrong or right.
He simply described his experience in writing a highly distributed system and proved it can be robust. He also did write it in 6 weeks, which I think is a big achievement for any (working) distributed system in any language. But saying he was language hopping because he "[didn't] understand Unix systems programming" is a bit silly. If he claims it made the experience better, I don't understand why you imply he doesn't program in a proper Unix way. He used the right tool for the right job.
I agree with you completely; Erlang is indeed the best tool for the job, if you know it well. But my point is that none of the other tools he glossed-over make high-performance server programming impossible; in fact, it's trivial in most of them.
As a matter of fact, Erlang is the only one in that list that has a bondage-and-discipline evaluation model and runtime; all others allow you to interface with native system calls and you will get your requests the instant they arrive and you can process them in $HLL of your choice.
His application domain does not at all suggest a requirement for seamless distribution. A poker server! And if you look closely at the languages of his choice, you see that he didn't have a clear idea; Delphi?
He could have easily "distributed" the application with primitive load balancing. Have a single server handle requests and player signups up to a certain high water mark. I mean, how many players are in a given poker table anyway? Then direct new requests to your standby backup server. Repeat, in round-robin fashion.
By the way, I remember him from comp.lang.lisp; and my memory might have tainted my judgment of the article.
Also, a lot of $HLL programmers have this weird prejudice about C and proper systems programming. They want to do everything in $HLL, down to <insert lowest threshold>. That's silly, C is the native language of most OSes, use it for its power, but only just where necessary.
I wish there was a neat way to keep all game-related code in a more approachable language than Erlang. It would be great to have the difficult bits of the server in Erlang, with the relatively simple game code being maintained in e.g. Java by programmers that don't need to be experts.
