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

71–80 of 106 posts

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

#71

Post by rdtsc »

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?

No.

It is funny you'd ask though, I just read this post yesterday:

How Erlang Does Scheduling :

http://jlouisramblings.blogspot.dk/2013/01/how-erlang-does-s...

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

#72

Post by rdtsc »

matthavener wrote: post #65
exo762 wrote: post #37

Earlier quoted context omitted.

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

Is it even possible to busy wait in Erlang?

Well do you mean per-process or for the whole node? You'd have to go out of your way in any case. For process you could create a tail recursive loop that just calls itself. It will run for 2000 reductions then the scheduler will kick it out and so on. But it own't block other processes.

To block a whole node'd have to perhaps write a native functions a (NIF) and do it there. Which is also a reason to be careful with NIFs, they can kill predictable latency under load, while initially in serial benchmarks they could show a performance improvement.

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

#73

Post by rdtsc »

davidw wrote: post #43
exo762 wrote: post #37

Earlier quoted context omitted.

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.

It is a magnitude easier in Node to block the whole OS process by doing anything CPU intensive. In Erlang, if not using C-bindings, there is nothing a single Erlang process can do to block the whole runtime.

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

#74

Post by brown9-2 »

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…

Beyond this, is there any part of the JavaScript language itself that is inherently asynchronous or enables the writing of asynchronous code?

I believe the answer is no - the async nature is provided by V8 and the core Node libraries.

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

#75

Post by mgkimsal »

LargeWu wrote: post #46
julien wrote: post #38

Earlier quoted context omitted.

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?

They might not be, but that doesn't matter as much as being able to report bugs and have them fixed now, while people are still actually developing/fixing things.

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

#76

Post by Peaker »

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…

My experience is the exact opposite.

Trying to make do with horrible code for long periods of time, suffering through bugs in every change... Until we finally rewrite it. I've never regretted a rewrite, and it has always ended up significantly better than the original (possibly because the horror threshold for rewriting is high, so that's not saying much).

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

#77

Post by voidlogic »

iends wrote: post #66
voidlogic wrote: post #56

Earlier quoted context omitted.

"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…

Any particular lessons learned rewriting from node to Go? I've got a small but growing node/socket.io app I figured I'd have to one day rewrite in go if I really wanted it to scale.

Nothing too unexpected, off the top of my head, I've noticed:

* Use Go tip; You can grab a snapshot review all the open issues for that snapshot (most are enhancements).

* Like any re-factor doing it sooner as opposed to later is less work :)

* Do some "from scratch" Go projects before doing re-factor projects to get your legs under you (if they are not already there)

* Write Go in Go, not C/Python/Java in Go. This is harder than you think when you get started, but, if you ask for help and people tell you you are fighting the system, carefully consider their advice.

* A lot of the Go community likes to use single letter variable names in contexts like receivers, struct state (just look at the stdlib), buck the system, don't do that, use short camel case names. The next guy / you in six months will be glad you did.

* If you have a Java/C++ background you might often write a single threaded version of a daemon and later multithread it later, this is generally an unnecessary step in Go.

* The Go versions really are not much larger (LOC)

* There is lots of useful Go code on github (don't be afraid to try them)

* If you are doing front-endy kind of stuff supplement "net/http" with Gorilla where needed whenever you can rather than rolling your own. ttp://www.gorillatoolkit.org/

* "go tool prof" is a great tool, know how to use it and its top20 / web commands. Even if you don't feel the pain, use it and you will learn what things you do are expensive and it will keep trouble from sneaking up on you.

* If you are using a SQL based store, use a driver that implements the interfaces in "database/sql" rather than providing its own interface. This will make your life very simple if you need to migrate between mySQL Postgre, etc

* LiteIDE is a nice lean cross platform Go IDE that includes syntax highlighing, autocomplete (with gocode) and debugging support. The only think I had to do was write my own syntax highlighting theme, based on Solarized, because I thought the included ones were gross.

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

#78

Post by rdtsc »

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?

I recommend Erlang. But you have to be careful what you mean by "fast".

There is serially fast. As in fast if you have a single client but that might not be "fast" when you have 10000 clients anymore. Erlang will make sure your system stays responsive under load.

Any of those languages will probably do that but I feel that Erlang is the one with most tooling and most practical experience behind its back.

Also, don't give up on Python. Python is an excellent language and when you don't need 5 nines or reliability or crazy scalability, a Python gevent or tornado based server might just do the job.

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

#79

Post by Peaker »

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?

Of that list, I'd recommend Haskell and Erlang. Haskell in particular is especially interesting if speed is of concern.

Haskell manages to combine the conciseness and elegance of good Python code with static safety not found in other mainstream languages. Speed-wise, it ranges from OK to great, depending on how skilled you are at optimizing Haskell. The tools for optimizing Haskell code are pretty great, though.

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

#80

Post by archangel_one »

brown9-2 wrote: post #74
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…

Beyond this, is there any part of the JavaScript language itself that is inherently asynchronous or enables the writing of asynchronous code? I believe the answer is no - the async nature is provided by V8 and the core Node libraries.

I would say yes, it's very easy to write inline anonymous functions which are very very nice for a primarily callback-driven model. I much prefer Python as a language overall, but I think writing code for "Node.py" would be an awful lot harder.
Post reply on HN