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.
Comments
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".
http://xkcd.com/386/
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.