Live data from Hacker News

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

blog.superfeedr.com

31–40 of 106 posts

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

#31

> 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.

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

#32
post #27

Earlier quoted context omitted.

If ease of long-term maintenance is a goal, then JavaScript is the wrong approach.

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 is less than optimal in this regard.

- Maintenance tooling may be lacking.

If I were to choose a language for a project that I new will be big and will need care in 10 or 20 years, I'd hesitate, and maybe choose Java (which I hate) or Python (which I hate less). If in a risk-things mood, I'd give Go a try.

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

#33
post #18

Earlier quoted context omitted.

[1] can give you some insight on the dark side of JS. Also, avoiding JS in some way or another is not that hard, esp. since there're a lot of languages which compile to JS, most notably CoffeeScript and ClojureScript. * [1] http://wtfjs.com * [2] https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

As much as I love CoffeeScript, it's not a substitution for learning JavaScript. CoffeeScript is basically just JavaScript with a prettier syntax and if you don't understand JavaScript you won't understand CoffeeScript.

Very true. I love CoffeeScript very, very much. It's my favorite language - I like it even better than ruby, if you believe me! I like using indentation instead of stupid 'end's that only God knows are ending a loop or a def or something else, I like the use of ... instead of * (for splats), and a few other things.

But, as much as I like CS and hate (really hate) JS, I have to agree with you wholeheartedly. You must know JavaScript well. Variable/function hoisting won't bite you in CS, but other JS idiocies will.

Read Douglas Crockford's "JavaScript: The Good Parts" at least twice (and take a lot of notes). It's the best no-bullshit book on JavaScript (the language, not "how to use JavaScript in Node/front-end web design") around.

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

#34

Earlier quoted context omitted.

Coming from Objective-C first, which is generally a rather sensible language, I think you'll be surprised at how stupid, unnecessary and inexcusable many of JavaScript's problems are. People who only have a PHP background, for instance, have become accustomed to such stupidity. They think it's "normal", solely because they don't really know any better. Those coming from C, C++, Java, C#, Ruby, Python or most other la…

It's not that JavaScript is a bad language, it's just easy to write bad code in JavaScript. I don't get it why most people coming from languages you mentioned like to bash JS so much, I used most of these languages in the past or use them currently (mainly Java and Python) and I like JavaScript the most. The problem is most people just don't want to learn JS, they write shitty code because it's easier and than compla…

Unless you are lucky enough to work on only your own code, that it's so easy to write bad code is a massive problem.

My big beef with js is that there's no 'right' way to lay out your code. Trying to figure out how a js module works is always a unnecessarily massive pita.

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

#35
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?

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

#36
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?

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.

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

#37
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?

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

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

#38
post #24

Earlier quoted context omitted.

It's not the language, it's the people, the community.

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. As I've stated in the blog post, that's a pro and con, but we estimated that the pro was greater than the con :)

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

#39
post #37

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.

There are no reasons to use busy waiting anywhere. This isn't what we're discussing, though.

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

#40
post #18

Earlier quoted context omitted.

[1] can give you some insight on the dark side of JS. Also, avoiding JS in some way or another is not that hard, esp. since there're a lot of languages which compile to JS, most notably CoffeeScript and ClojureScript. * [1] http://wtfjs.com * [2] https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

As much as I love CoffeeScript, it's not a substitution for learning JavaScript. CoffeeScript is basically just JavaScript with a prettier syntax and if you don't understand JavaScript you won't understand CoffeeScript.

That is completely true, you can't treat CoffeeScript as a replacement for learning Javascript in fact I'd say you need to have a pretty strong understanding of JavaScript to really use CoffeeScript well. That said CoffeeScript does some nice things to prevent typical small js errors for newer devs.
Post reply on HN