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

51–60 of 106 posts

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

#51

Post by calibraxis »

damncabbage wrote: post #29
drewmck wrote: post #25

Earlier quoted context omitted.

I was speaking with a colleague about Node and he suggested using Coffeescript instead of JS directly for the exact reasons you mentioned. I'm also coming from Obj-C, C and Ruby background and recently read "Javascript: The Good Parts". I'm still looking for the good parts promised in the title and introduction.

dagw has the best response to this below: http://news.ycombinator.com/item?id=5054382 I agree; it's a shortcut for people who know JS, not for people who are learning it for the first time. As soon as you need to use or look into the internals of a library that isn't written in CoffeeScript, everything's going to get unstuck pretty quickly.

I personally happen to disagree. (I have production/team experience with both node.js and CoffeeScript.)

For many learning types, I'd guess it's preferable to leisurely learn JavaScript from the shores of CoffeeScript. Rather than having to deal with all of JavaScript's absurdity at once.

And when you need to read someone else's JavaScript code, you can usually get away with ignoring boilerplate.

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

#52

Post by antihero »

Say I'm a Python developer and I'm looking to write services that are fast. Would I likely be better off going down the route of node.js, Go, Haskell, Erlang? I mean they are all fantastic languages and I've dabbled in most of them but from what I've read, Go seems to be the best one to use if you don't want to shake your world up, but if you do, Haskell or Erlang are nice new paradigms to dive into. Is this true?

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

#53

Post by scott_s »

StavrosK wrote: post #39
exo762 wrote: post #37

Earlier quoted context omitted.

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.

Well, yes, there is. When implementing locks, it depends on how likely and how long contention is. If the expected cost of busy waiting is less than the expected cost of interacting with a heavier-weight scheduling system (which may mean crossing the kernel boundary), then busy waiting is better. This is, of course, for lower level codes. For example, spin locks (so-called because they spin - or, busy wait - on a status variable) are frequently used in kernel code, and I have used them in a memory allocator.

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

#54

Post by jerf »

StavrosK wrote: post #41
davidw wrote: post #36

Earlier quoted context omitted.

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.

Erlang does not have a problem reasoning about the program, because it doesn't share any data. They are actually independent from each other in the same ways that two OS processes are independent from each other (that is, there are still resource contention issues but abstract correctness don't unduly depend on each other).

I'm running out of polite ways to say this, but Node advocates really need to learn about other ways of doing things before advocating so confidently that Node's way is better. Cooperative multithreading does not have the reasoning advantage, which is one of the reasons why it has been abandoned for so long at the OS level. It's incredibly harder to work with that preemptive multithreading sorts of things, combined with other techniques that have been developed over the decades.

(Also, I said "Node advocates" and not StavrosK or "you" specifically; I mean that more generally than just your post here.)

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

#55

Post by jondot »

I am using a mix of Ruby, Node and Java in production but after some hard-learned lessons chose to minimize the Node usage to things I absolutely need.

My experience with the Node community:

- Great people (Substack!)

- Great attitude #node.js/freenode

- However, many hours spent on solving bugs in existing libraries.

My experience with maintaining production Node code:

- It may be more maintainable than EventMachine, but it's absolutely not more maintainable than Ruby.

- V8 garbage collection is a real pain when you do work that needs it (this also includes memory held by open sockets).

- Was V8 built for the server? (rhetorical)

In the end, I prefer threaded Ruby code to evented Node code. I try to offset the inefficiencies of "threads vs evented" or "Ruby vs Node" by using the JVM and JRuby.

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

#56

Post by voidlogic »

omarkj_ wrote: post #3
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…

There are other reasons for rewriting like getting to a more easily maintainable code or when a previous solution has simply outlived it's usefulness. Also, C is not the only language worth rewriting in.

"Also, C is not the only language worth rewriting in" Agreed!

I would really like to see someone write a node.js and Go back-end for the same front-end and do a head to head comparison.

As someone who spent a fair amount of time rewriting node.js prototypes in Go, I'm probably biased. I feel like javascript is a much less maintainable language. Perhaps is was the original node.js implementations (I don't think it was), but the Go versions were always faster, used less memory and IMHO were more readable.

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

#57

Post by pilgrim689 »

antihero wrote: post #52

Say I'm a Python developer and I'm looking to write services that are fast. Would I likely be better off going down the route of node.js, Go, Haskell, Erlang? I mean they are all fantastic languages and I've dabbled in most of them but from what I've read, Go seems to be the best one to use if you don't want to shake your world up, but if you do, Haskell or Erlang are nice new paradigms to dive into. Is this true?

Erlang has decades of use in fast, robust, large telecommunication systems. Haskell promises more robustness than any other platform as well as performance sometimes comparable to C. Its downside is just that steep learning curve though.

So if you want speed, I'd go for those two out of your list. Go and node.js are still infants in the game, so I don't think there is enough serious software out there built with these to properly judge their effective speeds.

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

#58

Post by marekmroz »

antihero wrote: post #52

Say I'm a Python developer and I'm looking to write services that are fast. Would I likely be better off going down the route of node.js, Go, Haskell, Erlang? I mean they are all fantastic languages and I've dabbled in most of them but from what I've read, Go seems to be the best one to use if you don't want to shake your world up, but if you do, Haskell or Erlang are nice new paradigms to dive into. Is this true?

Have you tried writing services in Python and running on gunicorn or gevent?

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

#59

Post by amikazmi »

julien wrote: post #4
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…

Well, the reason we rewrote was not to explode all benchmarks. The reason we rewrote was to be able to ease the maintenance of our code =)

What was the reason you choose to rewrite for ease the maintenance in node?

Couldn't you rewrite for ease the maintenance in ruby?

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

#60

Post by nkohari »

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…

Technology and business requirements move too fast to worry about writing software that will be around 10 years from now. Choosing the best technology for your particular use case, that will also allow your software to evolve over time, is much more important than trying to predict the future.

Also, I've gotta say, you completely undermined all 3 points of your argument by saying you'd choose Go.

Post reply on HN