Writing Low-Pain Massively Scalable Multiplayer Servers
devmaster.net
devmaster.net
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.
High scalability and network performance is not a language or a library feature, it's a kernel feature.
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?
His points:
- scalability (multi-master distributed database) - library feature
- 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?
[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".
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.
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.