my issue with node is independent of the programming language. i came here neither to bury ted nor
to praise him. i don't care what he has written now. i found his original article funny and thought
that it had some truth in it. all the other "logical deductions" you're making, require axioms that
you have and i don't. i don't know this ryan guy either but if he's made a system so many people
(including yourself, who i admire sincerely) think so strongly about, he must be an all around great
guy. good for him.
as for me and this discussion, if node=asio and threads=avoid in your world, so be it, i'm ok with
that :)
> one nodejs process has replaced their two dozen Ruby processes and is serving out twice as many
> requests from the same box and they are impressed
that says a lot about Ruby (with which i have absolutely no experience)
@zohebv there are several errors in deduction here:
> a multithreaded environment eventually ends up introducing several blocking I/O functions
really? multi-threading and non blocking io are two separate tools and one doesn't have to choose one of them exclusively. they can be intertwined, boost::asio allows you to run a single async event processor on as many threads you want. all without doing any explicit locking. if you're averse to locking (which based on your experience seems to be the case) you're taking things too far by avoiding threads completely.
> You are basically asserting that async programming has no advantage over any other approach whatsoever
i don't think anyone's asserting that. the original argument made was - if all you have in one process is a tight loop dispatching non blocking io handlers then you can't handle computationally intensive tasks. of course, you can spawn 40 other process - but i don't like a model where that's your /only/ option. there are middle grounds and any system that discounts them is short sighted.
> Trying to say that async programming is useless
yet again. i don't see that being said anywhere.
> Node is an asynchronous programming framework bundled with a largely async library ... If you have done any kind of systems programming, you would know that availability of asynchronous I/O is a life saver
now, if you'd indulge me with my own escapades in logic and word play.
icing is sugar whipped in butter. if you have eaten any
desert, you'd know that sugar is nice and tastes very sweet. thus, conclusively, irrevocably, icing is good and we shall eat nothing else.
>> really?
> yes
ok.
> Can you describe the other options you want to try?
http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/exa.... See HTTP Server 1 to 4.
my issue with node is independent of the programming language. i came here neither to bury ted nor to praise him. i don't care what he has written now. i found his original article funny and thought that it had some truth in it. all the other "logical deductions" you're making, require axioms that you have and i don't. i don't know this ryan guy either but if he's made a system so many people (including yourself, who i admire sincerely) think so strongly about, he must be an all around great guy. good for him.
as for me and this discussion, if node=asio and threads=avoid in your world, so be it, i'm ok with that :)
> one nodejs process has replaced their two dozen Ruby processes and is serving out twice as many > requests from the same box and they are impressed
that says a lot about Ruby (with which i have absolutely no experience)