4 ms·

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 n

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.

mahmud 17y ago
Weird isn't it? Those who do not understand Unix systems programming are doomed to go language hopping for years. High scalability and network performance is not a language or a library feature, it's a kernel feature.
- viraptor 17y ago
  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? 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?
  - mahmud 17y ago
    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/ http://xkcd.com/386/
    - viraptor 17y ago
      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.
      - mahmud 17y ago
        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.

mahmud 17y ago

Weird isn't it? Those who do not understand Unix systems programming are doomed to go language hopping for years. High scalability and network performance is not a language or a library feature, it's a kernel feature.

viraptor 17y ago
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? 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?
- mahmud 17y ago
  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/ http://xkcd.com/386/
  - viraptor 17y ago
    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.
    - mahmud 17y ago
      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.