Gotchas from Two Years with Node • Hacker News Board

Re: Gotchas from Two Years with Node

#21

Post by 72deluxe » Tue, Apr 14, 2015, 8:35 AM UTC

toxicFork wrote: post #18

klodolph wrote: post #11

> Plenty of times, there will be an uncaught exception which–through no fault of your own–bubbles up and kills the whole process. Really? I'm just a beginner with node.js, and I've been deeply frustrated by error handling, but if this is true, that's pretty damning. In just about every other web framework under the sun, you can go wild with exceptions and the worst you'll get is a 500 response for that request. (Yes,…

Same happens with Java, C++, and many other languages. There are web server packages on node that do catch errors that happen in synchronous code. For async, you can use promises, which take errors into consideration. I'm not sure what happens on unhandled async errors on other languages, I guess in Java you could have a dangling request (happened to me before) or it could crash the app (also happened to me before).…

C++ - couldn't you just put a catch(...) within your request handler and return 500 if that is hit?

Re: Gotchas from Two Years with Node

#22

Post by Kurtz79 » Tue, Apr 14, 2015, 8:35 AM UTC

mhogomchungu wrote: post #8

eva1984 wrote: post #6

Just curious though, I have seem quite a number of posts in the past year mentioned the switch from Node to Go, is there a pattern here?Why Go in particular?

> Why Go in particular? Its the new shiny thing.

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.

Re: Gotchas from Two Years with Node

#23

Post by toxicFork » Tue, Apr 14, 2015, 8:36 AM UTC

72deluxe wrote: post #21

toxicFork wrote: post #18

Earlier quoted context omitted.

Same happens with Java, C++, and many other languages. There are web server packages on node that do catch errors that happen in synchronous code. For async, you can use promises, which take errors into consideration. I'm not sure what happens on unhandled async errors on other languages, I guess in Java you could have a dangling request (happened to me before) or it could crash the app (also happened to me before).…

C++ - couldn't you just put a catch(...) within your request handler and return 500 if that is hit?

And you can do the same on node :)

Re: Gotchas from Two Years with Node

#24

Post by onion2k » Tue, Apr 14, 2015, 8:39 AM UTC

[deleted] wrote: post #20

toxicFork wrote: post #18

Earlier quoted context omitted.

Same happens with Java, C++, and many other languages. There are web server packages on node that do catch errors that happen in synchronous code. For async, you can use promises, which take errors into consideration. I'm not sure what happens on unhandled async errors on other languages, I guess in Java you could have a dangling request (happened to me before) or it could crash the app (also happened to me before).…

[deleted]

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.

Re: Gotchas from Two Years with Node

#25

Post by [deleted] » Tue, Apr 14, 2015, 8:55 AM UTC

toxicFork wrote: post #23

72deluxe wrote: post #21

Earlier quoted context omitted.

C++ - couldn't you just put a catch(...) within your request handler and return 500 if that is hit?

And you can do the same on node :)

[deleted]

Re: Gotchas from Two Years with Node

#26

Post by swang » Tue, Apr 14, 2015, 8:56 AM UTC

I wonder why they don't use a stream JSON parser like oboe.js?

Re: Gotchas from Two Years with Node

#27

Post by jonpress » Tue, Apr 14, 2015, 8:57 AM UTC

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 issue is disingenuous.

If you ran Go as a single thread, you would also run into similar issues. The main advantage of Go is that it makes it easier to parallelize your code thanks to goroutines and channels (a single source file can encapsulate the logic of multiple concurrent processes).

That said, I find that this 'ease of concurrency' makes Go code less readable. In Node.js, it's really easy to identify process boundaries since the child_process module forces you to put code into different files and communicate via loosely coupled IPC channels.

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.

Re: Gotchas from Two Years with Node

#28

Post by jestar_jokin » Tue, Apr 14, 2015, 9:00 AM UTC

hayksaakian wrote: post #13

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…

I think it makes sense, early on you're still "figuring it out" so a flexible framework thats easy to dive into is advantageous. I don't see anything wrong with planning a rewrite X months into a product, since 90% of things don't make it to month X.

A code rewrite means time spent working on stuff that isn't delivering features, which means your business could be stagnating, making customers dissatisfied, giving competitors an opening.

As an example, I recently migrated a Node app from MongoDB to Postgres. This ended up taking two and a half weeks, due to re-writing a fair portion of the server-side code. That's a long time to go without delivering new features or fixes. We justified it because we had inexplicable data loss (not pinpointed on MongoDB, but a poor reputation is a hard thing to remedy) and our data model did not suit a document store. But you have to then accept it when the business folks say "well, why didn't you get it right the first time? Aren't you supposed to be the expert?".

As technologists, of course we find it fun to try new technologies. But outside of the main tech hubs, a large proportion of developers aren't working for tech companies whose main product consists of web services/APIs, in which case we need to always consider the costs/benefits of any tech switch. If it's not justified, you're stuck supporting flakey apps until you can move on to the next gig / learning experience.