> I've programmed in both sync and async code, and neither is perfect. Node basically > has trade-offs - I get better performance [1] at the expense of a slightly cumbersome programming model.
I compared Node.js with "slow" Ruby on Rails and the result is that node.js is only 1.3 times faster. (maybe there's an error in my benchmark, but I can't find it so far). http://alex-craft.com/blog/2014/ruby-on-rails-vs-nodejs sources https://github.com/alexeypetrushin/web-frameworks-benchmarks > Your sync version doesn't handle errors at all I knew that someone would point to it. But actually it does handle errors. The whole request thread wrapped with try/catch (implicitly, inside of web framework code) - and it does handle errors. In node.js it's impossible to handle errors in such a way implicitly because there's no context there. You don't know which error belongs to which request and has to do it manually. On Tuesday, 23 September 2014 19:50:01 UTC+4, Matt Sergeant wrote: > > > On Tue, Sep 23, 2014 at 7:29 AM, Alexey Petrushin <[email protected] > <javascript:>> wrote: > >> Ha-ha, very good example, compare this async version it with the sync >> version below, and tell me that there's no problem with >> callbacks """if you know how to deal with it""" :D >> >> Not saying that in even such a simple code it's extremely >> easy to make small errors like missing `else` statements etc. >> >> Also it doesn't preserve the call stack - so when you see error in console >> you would have no context and no idea what happened... >> And it still doesn't catch the sync errors... >> And some of callbacks can be fired twice... >> And with streams there are lots of events fired and should be properly >> handled... >> >> And still many insist that it is "not a problem". >> > > I don't insist it's "not a problem", but programming is always going to > present challenges. I've programmed in both sync and async code, and > neither is perfect. Node basically has trade-offs - I get better > performance [1] at the expense of a slightly cumbersome programming model. > I could go even more cumbersome for even more performance if I switched to > C++ or Java. But I'm OK with where Node takes me for now. > > The flip side with sync code of course is that sync programming is often a > lot harder than people make it out to be. Your sync version doesn't handle > errors at all, for example. Error handling is very language/environment > specific and often an area of huge neglect. One thing Node got right was to > always use the "error first" callback approach, that makes things like > Streamline and Async.js possible. It's not perfect but all programming is > trade-offs. > > Matt. > > [1] Whoever was arguing that Ruby and/or Rails has equal performance > obviously has never ported a large project from Rails - I have and the > performance difference is staggering > -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/ef189a34-c7ae-49ab-97c9-48035cea8bd0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
