Gotchas from Two Years with Node • Hacker News Board

Re: Gotchas from Two Years with Node

#111

Post by wpietri » Tue, Apr 14, 2015, 9:00 PM UTC

EGreg wrote: post #45

nemothekid wrote: post #36

Earlier quoted context omitted.

> Most of the Node.js vs Go arguments are weak. It's surprising that Node.js is still outpacing Go in popularity in spite of all this slander. Thats a rather defensive position for node in what is a very rare use case for the language. It's unsurprising Node.js is still outpacing Go, given the large number of JS developers and the fact that Go is pretty much worthless for hosting front end web applications (you won't…

Every language requires you to be careful. C makes you do array out of bounds checks. Javascript makes you worry about tying up your event loop with eg massive string processing. Just get a friggin asynchronous JSON parser if you're running it on untrusted client input (ie any client input). It's not that hard. Maybe node should provide a "tainted" feature for modules to mark variables that are "untrusted" and provid…

I think good languages require you to care about things that matter for your domain. For example, C's bounds checks are a consequence of demanding fine-grained control.

The problem for me with Node here is that whole cooperative-multitasking thing doesn't directly buy you anything. It's a historical accident, not a necessary downside of an otherwise-positive choice. That's distinct from a browser or a GUI environment, where letting a single thread control the display and events really does buy you things you care about.

Re: Gotchas from Two Years with Node

#112

Post by Touche » Tue, Apr 14, 2015, 9:00 PM UTC

galfarragem wrote: post #46

bontoJR wrote: post #10

The switch from Node to Go seems quite popular right now and it honestly makes me thing there's something wrong with the general perception of Node. We are currently in a world where we have a huge amount of traffic on almost every web app with just a discrete success, but we still make the mistake to pick a technology that seems "good enough", instead to pick a "great one" because looks slightly harder to manage/lea…

> The switch from Node to Go seems quite popular right now TJ Holowaychuk desertion was a strong hit on Node troops' morale. https://news.ycombinator.com/item?id=7987146

TJ had already written every module possible in Node so he moved on to rewrite them all again in Go. He'll do the same once he's exhausted all Go modules there are to write.

Suffice to say his exit hasn't changed anything, his efforts have been taken over by others and NPM is still growing at a fast rate.

Re: Gotchas from Two Years with Node

#113

Post by taternuts » Tue, Apr 14, 2015, 9:18 PM UTC

Kiro wrote: post #104

taternuts wrote: post #99

Earlier quoted context omitted.

I believe what happens is it registers the functions callback on the event-loop which it'll check the next time around to see if it's done, then pushes the work to be handled in a separate pool of threads that libuv manages. When it's done, the next event-loop tick or the next time around it will execute the callback with the results. This is how asynchronous functions work anyways, but some functions are actually sy…

Thanks. So Node is actually using multiple threads behind the scenes or did I read that wrong? How do I know which kind of operations are pushed there by libuv?

Yeah, there's a pool of non-blocking C++ threads that do the work behind the scenes. Any async operation gets pushed out, and honestly most functions will behave asynchronously. JSON parsing is a sync operation that usually doesn't block for very long because it will be a small operation 99.9% of the time, so it's kind of a pitfall because you almost never see this blocking issue unless your parsing huge JSON objects. In nodeland things are kind of expected to be asynchronous, and if they are not they should be labeled as such so that everyone using it knows. Checkout the FileSystem (fs) nodejs lib, you'll see calls explicitly labeled as "sync" to denote that they are blocking.

Re: Gotchas from Two Years with Node

#114

Post by aioprisan » Tue, Apr 14, 2015, 9:22 PM UTC

Event loop debugging is key and I'm glad that there are some interesting offering profiling services on this level, especially for frameworks like Meteor: https://kadira.io/

Re: Gotchas from Two Years with Node

#115

Post by lobster_johnson » Tue, Apr 14, 2015, 9:28 PM UTC

Anyone else thinking this sort of blog post is actually really bad PR?

There are some very obvious architectural issues here, issues that aren't tied to the choice of Node.js. I wouldn't want to use a provider whose stack was this immature, to be perfectly blunt.

For example, an API shouldn't do any of the processing they describe. The API's role is to handle submitted requests as fast as possible, so it must off-load the actual work to a queue that can be processed elsewhere.

I'm also skeptical of solutions like YAL, at least the way it seems to be used here. IMHO you'll want local spooling via something like rsyslog, so that you're impervious to network failures. Logging directly to a remote server means you become completely reliant on that server.

Re: Gotchas from Two Years with Node

#116

Post by spion » Tue, Apr 14, 2015, 11:28 PM UTC

xhrpost wrote: post #93

spion wrote: post #89

All these problems are solvable (streams by ditching built-in streams and replacing them with something decent, errors with promises + typescript, event loop blocking with a streaming JSON parser). But that still means that out of the box node is a pretty unsatisfying experience all around. It took us a year to arrive at the solutions above, and many prominent members of the community scoffed at a number of them. Som…

> "ditching built-in streams and replacing them with something decent" What have you found sufficient for this?

We have an inhouse solution which is basically a set of external functions that work with built in streams in a way that avoids frustration.

Some of them can be found in https://github.com/spion/promise-streams - the others we haven't extracted to an npm module yet. (Promise streams also has a minimal extension of built in streams to make them work better with promises).

We never managed to find a full replacement though. Probably not worth the effort either given that it will always have to wrap existing streams, and the only drawback of external functions is that you cannot invoke them as methods. Although, one contender that I have hopes for is WHATWG streams [1].

note: to replace event emitters we built https://github.com/doxout/promise-observer which gives you a lot more power and control in terms of execution order and goes away with the "multiple events per object" stringy design that makes things harder for typesystems like typescript/flow.

[1]: https://github.com/whatwg/streams

Re: Gotchas from Two Years with Node

#117

Post by onion2k » Wed, Apr 15, 2015, 5:22 AM UTC

hearwa wrote: post #49

onion2k wrote: post #24

Earlier quoted context omitted.

There's nothing in PHP that stops it sending correct HTTP error codes. Incompetent developers might write things that throw blank pages or stack traces, but that's true of any language.

I've run into issues with php where it always outputs the warning as a table. Recently I was working on an in house project that used the mysqli extension. It's being deprecated for PDO and outputs a warning of this as an html table. I didn't have time to port this to the new library. I had to disable deprecated warnings to get rid of this, but I'm left fearing there might be other warnings somewhere else in the proj…

If you've set PDO::ATTR_ERRMODE to throw exceptions and you're still seeing warnings then yes, that's a bug in PHP. Perhaps you could submit it.

Re: Gotchas from Two Years with Node

#118

Post by Kurtz79 » Wed, Apr 15, 2015, 5:46 AM UTC

Macha wrote: post #103

Kurtz79 wrote: post #22

Earlier quoted context omitted.

I think go and node are more or less of the same "age" and "shininess"? EDIT: Very much so, they were actually released to the public in 2009.

Ruby was first released in the mid 90s and became the shiny new thing in around 2005 when ten years old. Sometimes the shiny newness is in the public eye rather than absolute terms.

Not really, Ruby ON RAILS became the shiny new thing, and was released in 2005.

Re: Gotchas from Two Years with Node

#119

Post by Roboprog » Wed, Apr 15, 2015, 6:37 AM UTC

falcolas wrote: post #71

jonpress wrote: post #27

The root of the eventloop issue is not Node-specific. The real underlying issue here is that one CPU core is given too much work while others are more or less idle. Offloading some of the work to another process naturally solves this issue - It doesn't really matter that this other process is a Go program or a Node.js one - Both approaches would have solved the problem. Attributing credit to Go itself for solving the…

> The main advantage of Go is that it makes it easier to parallelize your code thanks to goroutines and channels Well, that and Go is not bounded by a VM (jit or no), and will simply be faster than JavaScript, given the exact same logic. Don't discount the cost of running on a VM, and all of the abstractions which are thrown on top of plain JavaScript to help manage the callback complexity.

Given enough money, a JIT can be made arbitrarily fast, it seems (e.g. - JVM, LLVM bitcode interpreter)

Given time, don't assume any particular language implementation will always be faster. Go might only run faster than Javascript on the odd years, depending on corporate budgets for compiler / VM tuning the previous year.

Re: Gotchas from Two Years with Node

#120

Post by glibgil » Wed, Apr 15, 2015, 6:39 AM UTC

juliangregorian wrote: post #105

glibgil wrote: post #95

Earlier quoted context omitted.

They just told you: Bluebird and streams 3. Did you get bored and stop reading?

Ooh, swing and a miss. Bluebird is not a streams replacement, streams 3 IS the built-in streams. Maybe save the snark for situations where you actually have a clue.

Bluebird is for promises. Mentioned above if you read.