Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We switched to Node.js: the good and the not so good

blog.superfeedr.com

Post reply on HN
Print view View original

41–50 of 106 posts

Re: We switched to Node.js: the good and the not so good

#41

Post by StavrosK »

davidw wrote: post #36
StavrosK wrote: post #35

Earlier quoted context omitted.

Will a "while True" not lock up an Erlang thread?

No: Erlang has an internal scheduler that makes sure that no process can lock the whole thing up. It's not impossible to wedge Erlang, of course, it's just not quite so easy.

Ah, so it uses preemptive rather than cooperative multitasking. I find that locking the whole thread is usually an error, so preemptive multitasking wouldn't help much there, and I like how cooperative multitasking lets me reason about the program, but I can see the benefits in both approaches.

Re: We switched to Node.js: the good and the not so good

#42

Post by OriginalSyn »

gbog wrote: post #32
nkohari wrote: post #27

Earlier quoted context omitted.

Well that's just, like, your opinion man.

You have better ways to ask for explanations. Not the OP but I can give some reasons for Javascript and Node.js to not be the best option for a rewrite if the goal is longterm maintainability: - js / node.js is very young, it might fade out of fashion, and in 10 years it is not impossible that good coders in js will be hard to find. - Readability and simplicity are prominent in this context, and js has a syntax that…

I don't see how finding JavaScript programmers is going to be a problem in 10 years... even if they started now it would take, at least, that long to fully deprecate the language out of the browser. NodeJS may go away but I think betting on JavaScript going away are some pretty long odds.

Re: We switched to Node.js: the good and the not so good

#43

Post by davidw »

exo762 wrote: post #37
StavrosK wrote: post #35

Earlier quoted context omitted.

Will a "while True" not lock up an Erlang thread?

There are no reasons to use busy waiting in Erlang. Ever.

while(true) would be pretty bad form in a Node program too, and doesn't actually seem to be a big problem in practice for people.

Re: We switched to Node.js: the good and the not so good

#44

Post by rartichoke »

julien wrote: post #12
DoubleCluster wrote: post #10

Earlier quoted context omitted.

That's fine. Did the code become easier to maintain? It's not clear from the article. The "The good" section is relatively weak and the "The not-so-good" has some painful points about memory management and api instability. It sounds a bit like you guys rewrote it because node.js is hot and you then stuck with the rewrite because of sunk costs. Or am I imagining things? Thanks for sharing your experiences with us. I'm…

Well, we assumed everyone knew about the good... so yes, we're happy with the rewrite and will probably never go back. Also, a 25% saving in servers for us translate in several thousands of dollars saved monthly. Not negligible :)

Yeah but in your article you said you're not even sure if this is because of node. You made some architectural changes in your code base and hinted that might have been a reason for the speed boost too.

The article might as well be written as "we refactored our code and got a nice speed boost".

Re: We switched to Node.js: the good and the not so good

#45

Post by niggler »

The complaints were summarized well by Crockford http://www.crockford.com/javascript/javascript.html

Most of the people writing in JavaScript are not programmers. They lack the training and discipline to write good programs. JavaScript has so much expressive power that they are able to do useful things in it, anyway. This has given JavaScript a reputation of being strictly for the amateurs, that it is not suitable for professional programming. This is simply not the case.

Re: We switched to Node.js: the good and the not so good

#46

Post by LargeWu »

julien wrote: post #38
necrodome wrote: post #26

Earlier quoted context omitted.

what's different about node community from ruby community? are you sure that's not confirmation bias?

Well, again, most of the dependencies we used in Ruby did not see any update in the 3 years we've been using them. We also reported several bugs in those libraries/dependencies which were never fixed. This led us overtime to use our own branch of all the significant dependencies we had (including the MySQL gem for EM, the redis gem... and several other key ones). Most of node modules are still in active development.…

What leads you to believe all of these node modules that you now have dependencies on will still be in active development in 3 years?

Re: We switched to Node.js: the good and the not so good

#47

Post by jahewson »

nivertech wrote: post #31
DoubleCluster wrote: post #2

> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (t…

I think the reason they only got 25% gain is because they already used Async IO with Ruby eventmachine. Another reason might be, that their workload is IO-bounded, so faster VM like V8 doesn't help.

If the initial version was IO-bound wouldn't they get a 0% gain from re-writing?

Re: We switched to Node.js: the good and the not so good

#48

Post by oinksoft »

StavrosK wrote: post #35
davidw wrote: post #17

> What we liked the most of Javascript was the fact that it’s an asynchronous language ‘by default’. That's not strictly true - a "while (true)" will lock up a Node process as far as I can tell. I think a more accurate way of stating it would be that "Javascript API's and libraries tend to be written with asynchronous use in mind", with lots of callbacks. If you want something that's async at a deeper level, Erlang i…

Will a "while True" not lock up an Erlang thread?

It will block your process (just like a `receive' does), but a good Erlang/OTP system is generally comprised of a great many processes. If one process can block, your design is wrong, and the system itself is designed to be robust when things block like this. You expect your processes to be blocked, but you design things so that truly concurrent activities are being run in parallel.

Re: We switched to Node.js: the good and the not so good

#49

Post by niggler »

gbog wrote: post #32
nkohari wrote: post #27

Earlier quoted context omitted.

Well that's just, like, your opinion man.

You have better ways to ask for explanations. Not the OP but I can give some reasons for Javascript and Node.js to not be the best option for a rewrite if the goal is longterm maintainability: - js / node.js is very young, it might fade out of fashion, and in 10 years it is not impossible that good coders in js will be hard to find. - Readability and simplicity are prominent in this context, and js has a syntax that…

Node.js may be young but 98% of the code can be reused (and if you are careful, you probably wrote the fallbacks already). V8 can be built separately.

When you understand the zen of javascript and try to write in a consistent manner, JS is more readable than C. I equate these concerns with arguments about how lisp or scheme is unreadable.

The ecosystem for tooling is expanding, albeit slowly.

However, most of your code probably could be implemented in a way that can be run in browser (e.g. XLS parser: http://niggler.github.com/js-xls/) which is where I see the real value in node. Aligning the languages means fewer moving parts and potential points of failure (as opposed to having to worry about quirks in implementations of many languages and worrying about features supported in one context but not the other)

Re: We switched to Node.js: the good and the not so good

#50

Post by diroussel »

jahewson wrote: post #47
nivertech wrote: post #31

Earlier quoted context omitted.

I think the reason they only got 25% gain is because they already used Async IO with Ruby eventmachine. Another reason might be, that their workload is IO-bounded, so faster VM like V8 doesn't help.

If the initial version was IO-bound wouldn't they get a 0% gain from re-writing?

If my program reads a file one byte at a time, and it's IO-bound, can I improve performance by re-writing?
Post reply on HN