> http://www.ckwop.me.uk/Why-Exceptions-Suck.html
That's just another theoretical talk. You may find tons of such stuff explaining how J2EE is a superior next-generation technology or whatever other nonsense. You may even find articles insisting that explicit error checks in Go "is the right way". Instead of theoretical debates it is more interesting to compare the actual code. You can compare the async and sync versions of code above, so you can judge by yourself which is simpler and easier. > Yes, like all benchmarks this one is horribly flawed. That's very convenient point of view. If benchmark shows something you don't like just say that it's flawed and proves nothing. About the multicore - yes that maybe the case, but it can be run on single core machines - like AWC EC2 or something similar to see how it perform on single core. > Alexey, that's an interesting comparison. Your benchmark does almost no work in the node/ruby code itself. Exactly. "No work" is the use case node.js is designed for - to be work-less network router. So, it is the case node.js should shine. And, instead it turned out that """"webserver that is based on lightweight threads""" provides almost the same performance. P.S. I will try to run benchmark on single core machine. On Tuesday, 23 September 2014 23:45:34 UTC+4, Matt Sergeant wrote: > > > On Tue, Sep 23, 2014 at 3:14 PM, Alexey Petrushin <[email protected] > <javascript:>> wrote: > >> > 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 >> > > Yes, like all benchmarks this one is horribly flawed. The simplest reason > being your Rails server (using Puma) uses all cores. Your Node version is > using one core. But that's beside the point - minor benchmarks like this > show absolutely nothing of value. > > Try porting a real application. I did. > > >> > 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. >> > > http://www.ckwop.me.uk/Why-Exceptions-Suck.html > > Besides that, not all ruby functions/methods throw exceptions on errors > (thankfully - in fact I'd venture to say that most don't), so you have to > handle them locally/manually anyway, same as you do in Node. > > Matt. > -- 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/cde1c269-72b6-41b3-b599-8a0ec90aa290%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
