Gotchas from Two Years with Node • Hacker News Board

Re: Gotchas from Two Years with Node

#71

Post by falcolas » Tue, Apr 14, 2015, 1:00 PM UTC

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.

Re: Gotchas from Two Years with Node

#72

Post by fennecfoxen » Tue, Apr 14, 2015, 1:01 PM UTC

ExpiredLink wrote: post #29

Why not Java EE? Everything out of the box. Tried, proven, standardized. Well suited for startups: http://www.adam-bien.com/roller/abien/entry/a_java_ee_startu...

Ah, yes, Java... the language that doesn't have niceties like hash literals, so the ecosystem adopted XML instead, and you'd use complex difficult-to-debug XML documents to metaprogram your frameworks because it was actually the least-painful way of doing things. (It's moved on slightly: annotations are the new XML. cough Jersey cough)

I mean, there's plenty of good stuff too, but... let's just not pretend that it's a choice without downsides, shall we?

Re: Gotchas from Two Years with Node

#73

Post by vkjv » Tue, Apr 14, 2015, 1:05 PM UTC

I've had some similar experiences as we've scaled from internal only applications a couple years ago, to handling thousands of requests a second at peak.

1. Event loop. Yep, always be careful not to block it. But, I think this is more of a tuning thing. If you're using Java, you figure out how many requests you can reasonably handle and make that your water mark. Do the same thing in node, if you take too many connections, start refusing them fast and not queuing them forever.

2. Exceptions. Honestly this has never been an issue. We've used Promises for async flow from the beginning. This means that there is nearly zero code that is not inside of a promise chain and hence inside of a try {} catch {}. We just don't have this problem and we don't crash.

3 / 4. Oddly enough, I found streams to be a solution to this problem and not a cause, if using back pressure properly. I highly recommend highland.js.

Re: Gotchas from Two Years with Node

#74

Post by wpietri » Tue, Apr 14, 2015, 1:11 PM UTC

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'm entirely in favor of that. At least in a startup context, you can't possibly know what the correct great technology is until later. Great technologies are great because they are optimized for some particular problem, which naturally means they're not as good at other things.

That all successful apps have a lot of traffic doesn't matter, because most apps are not successful. Building for scale from day 1 wastes resources better spent on making something people actually want, because that's what increases the chance of getting to where scale actually matters.

I think the real trick people should learn is to stop building monoliths, so that when item X is problematic it can be easily swapped out. But even that only makes sense if the cost of a more modular approach is relatively low. It would be great to see good early-stage toolkits that encourage novices to build more modularly.

Re: Gotchas from Two Years with Node

#75

Post by jestar_jokin » Tue, Apr 14, 2015, 1:12 PM UTC

al2o3cr wrote: post #63

jestar_jokin wrote: post #28

Earlier quoted context omitted.

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…

"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." On the flip side, over-engineering before launch means time spent NOT MAKING ANY MONEY because you haven't launched yet. It means pouring engineering effort into something whose success is still hypothetical. If the biz folks wa…

I absolutely think there's value in prototyping to explore business opportunities, or to evaluate choice of technology. I think problems arise when you try to do both at once.

Also, once the business gets hold of a prototype, it can sometimes be hard to convince them to pay to replace the prototype with a new codebase which seemingly does exactly the same thing; after all, what they've got works, right? (For some definition of "works".)

It can also be difficult to work out exactly what needs to be kept from the prototype; how do you tell what functionality is intended, and what is just a non-essential byproduct of the implementation? Yes, you can formalise the specification, but this takes time, and customers will complain about any changes to functionality.

You'll be served in good stead if you pick a tech that can support all the normal boring stuff that a robust web app needs, while also providing rapid development capabilities.

Re: Gotchas from Two Years with Node

#76

Post by wpietri » Tue, Apr 14, 2015, 1:24 PM UTC

Rapzid wrote: post #55

mjburgess wrote: post #31

Earlier quoted context omitted.

> If you ran Go as a single thread, you would also run into similar issues. Yes, if you hobbled yourself, you would be hobbled. The inability to do concurrency properly is not a feature, it's a missing feature. The whole point of node was to be a node .

I'm also unsure about this comment. It reads to me as "The main advantage of Go is.. that it makes it really easy to not have this problem." The OP talks about single core being an issue. It is not for Go due to the cooperative goroutine scheduling and function call pre-empting. You can still shoot yourself in the foot, but it's really easy to create an escape hatch by just making a function call or occasionally yiel…

> really easy to create an escape hatch by just making a function call or occasionally yielding to the scheduler...

Having dealt with cooperative multitasking back in the dark ages, I definitely don't believe it is easy. With proper threads, you just write your code in a straightforward manner. With cooperative multitasking, you now have to be continuously imagining performance and sprinkling in otherwise useless calls every time you think something might take a while. When you get that wrong, which will be a fair bit, you have to go back and re-sprinkle. And then when the character of your input changes, you get to re-sprinkle again.

I was ok with it in the dark ages; there wasn't an alternative given the hardware of the time. But now? Even watches are multi-core. I want to use languages that make parallelization easy.

Re: Gotchas from Two Years with Node

#77

Post by vkjv » Tue, Apr 14, 2015, 1:27 PM UTC

pjmlp wrote: post #56

aikah wrote: post #41

Earlier quoted context omitted.

why? PHP/ruby/python are successful too in the server space. Javascript,especially ES6, isn't worse than the formers. Devs should know by now that the dumbest tool that is good enough has good chances of being successful today. All these tech won't replace enterprise techs, but enterprise dev is a tiny percentage of all devs outthere.

> PHP/ruby/python are successful too in the server space. Again, from the perspective of someone that worked in a startup using TCL for server applications, I also don't get it. Other than being attractive to developers without formal education, and after a certain scale it becomes too costly to re-write. The work we developed at that company teached me never to use a technology stack without a JIT or AOT compiler fo…

> "...developers without a formal education..."

I think it's more about developers without experience. If you have experience doing something successfully, you are more likely to reach for the same tool set when doing it again. And someone who has done something successfully once is less likely to make naive mistakes when doing again.

I think most issues, like the ones in this article, are much more likely to be attributed to these two facts than to node.js as a language.

Contrived analogy: An experienced builder sets out to build a home. He grabs a Stanley hammer and successfully builds a home. Another person, who has never built anything, grabs a DeWalt hammer and fails miserably. Does this mean that only Stanley hammers are appropriate for building a house?

Re: Gotchas from Two Years with Node

#78

Post by jonpress » Tue, Apr 14, 2015, 1:28 PM UTC

wpietri wrote: post #69

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…

> 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. I find that approach troubling. Process boundaries are expensive, because you have to serialize and everything each time you cross a boundary. I also haven't used Go, but I think you can get great clarity with something like Akka's A…

Yes, socket/pipe-based IPC is more expensive than shared memory up to a point, but it's more scalable since you don't have to deal with locking (mutexes, semaphores) and the limits this imposes.

Re: Gotchas from Two Years with Node

#79

Post by vezzy-fnord » Tue, Apr 14, 2015, 1:29 PM UTC

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…

RAILS or Node are easier and faster to handle compare to Scala or Erlang

I don't know about Scala, but if one were to start from tabula rasa, I'd argue Erlang is easier to handle than Node. You have a standard set of patterns embedded in OTP and a well-defined process model purveying the entire language, whereas Node at its core being a reactor-based event loop means that you're bombarded by a variety of concurrency patterns that are all lacking in some way. This is besides all the advantages of location transparent distributed nodes, the Eshell in general, multi-core scaling (modulo Amdahl) and a pattern matching engine like none else.

Rails isn't an adequate comparison, as that's a framework. Nitrogen/N20 + BossDB or Chicago Boss would be close competitors.

Re: Gotchas from Two Years with Node

#80

Post by davidw » Tue, Apr 14, 2015, 1:42 PM UTC

vezzy-fnord wrote: post #79

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…

RAILS or Node are easier and faster to handle compare to Scala or Erlang I don't know about Scala, but if one were to start from tabula rasa , I'd argue Erlang is easier to handle than Node. You have a standard set of patterns embedded in OTP and a well-defined process model purveying the entire language, whereas Node at its core being a reactor-based event loop means that you're bombarded by a variety of concurrency…

> Chicago Boss would be close competitors.

I have commit access to Chicago Boss, and while it's a really cool effort, and is well suited to some niches like the one I'm using it for, it is very, very far away from being a competitor in terms of the flexibility and oodles of gems you get out of the box.