4 ms·

Because most webapps do not need to be optimized for performance, but rather for ease of maintenance. Asynchronous I/O is best suited for handling a large numb

by olegp 16y ago

Because most webapps do not need to be optimized for performance, but rather for ease of maintenance. Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives. At Akshell we're adding a Node based pubsub server with support for both server and browser based subscribers, allowing us to get the best of both worlds: a large number of concurrent connections combined with business logic & message processing using synchronous code.

sausagefeet 16y ago
> Because most webapps do not need to be optimized for performance, but rather for ease of maintenance. I don't see how this conflicts with asynchronous I/O unless you're limiting yourself to Twisted/Node. > Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives. This is exactly how you write an Erlang application. Erlang supports asynchronous I/O. Your viewpoint is accurate if you limit yourself to many of the mainstream languages that are simply terrible at concurrency, but I think this is only temporal. As more work goes onto web apps synchronous I/O simply isn't going to cut it (as many people running popular websites already know).
- olegp 16y ago
  Agreed on the first part, unfortunately most functional languages are difficult for most developers (read: non-academics or HN readers) to grasp. As somebody who taught me ML said: "if it's difficult to write, it should be difficult to read". Perhaps this will change, but it will be a while before we have a functional language that's as mainstream as JavaScript. Most big websites have asynchronous components to address their performance bottlenecks, but the bulk of the business logic uses synchronous I/O and unfashionable languages like PHP as per the 90/10 law: http://en.wikipedia.org/wiki/Program_optimization#Bottlenecks http://en.wikipedia.org/wiki/Program_optimization#Bottleneck...
  - sausagefeet 16y ago
    Brings me back to my original comment: > Erlang, Haskell, Mozart/Oz all do it superior to something like Node, people just haven't realized it yet so a language that people want to use can be built. Someday....someday...

by olegp 16y ago

sausagefeet 16y ago

> Because most webapps do not need to be optimized for performance, but rather for ease of maintenance. I don't see how this conflicts with asynchronous I/O unless you're limiting yourself to Twisted/Node. > Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives. This is exactly how you write an Erlang application. Erlang supports asynchronous I/O. Your viewpoint is accurate if you limit yourself to many of the mainstream languages that are simply terrible at concurrency, but I think this is only temporal. As more work goes onto web apps synchronous I/O simply isn't going to cut it (as many people running popular websites already know).

olegp 16y ago
Agreed on the first part, unfortunately most functional languages are difficult for most developers (read: non-academics or HN readers) to grasp. As somebody who taught me ML said: "if it's difficult to write, it should be difficult to read". Perhaps this will change, but it will be a while before we have a functional language that's as mainstream as JavaScript. Most big websites have asynchronous components to address their performance bottlenecks, but the bulk of the business logic uses synchronous I/O and unfashionable languages like PHP as per the 90/10 law: http://en.wikipedia.org/wiki/Program_optimization#Bottlenecks http://en.wikipedia.org/wiki/Program_optimization#Bottleneck...
- sausagefeet 16y ago
  Brings me back to my original comment: > Erlang, Haskell, Mozart/Oz all do it superior to something like Node, people just haven't realized it yet so a language that people want to use can be built. Someday....someday...