Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node and ARM

medium.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Node and ARM

#11

Post by mooreds »

vezzy-fnord wrote: post #6

What exactly do they mean by "multi-process" in the context of an event loop like Node? I'm also not sure about their claims concerning clustering - Node has no SMP capabilities, nor is there any real mechanism for enabling location transparency out of the box. It's also interesting to note the conflict between the microservices and monolithic application camps. Both are just as adamant that theirs is the future and…

Wow. Are people defending the monolithic app? Maybe it is where I hang out, but I'm not seeing many.

See for example, Martin Fowler: http://martinfowler.com/articles/microservices.html

Re: Node and ARM

#13

Post by dmitrygr »

"we advise our clients to kill & quickly restart when their applications enter an unexpected-error state"

Wait, what?

Shouldn't your thing actually work. How unprofessional is it to advise clients to kill and restart things instead of fixing the issue that caused this to be needed?

Wow!

Re: Node and ARM

#14

Post by tracker1 »

vezzy-fnord wrote: post #6

What exactly do they mean by "multi-process" in the context of an event loop like Node? I'm also not sure about their claims concerning clustering - Node has no SMP capabilities, nor is there any real mechanism for enabling location transparency out of the box. It's also interesting to note the conflict between the microservices and monolithic application camps. Both are just as adamant that theirs is the future and…

Nodes I/O base actually uses a thread pool for the C++ bits that run in the background/waiting. For the most part, node/iojs is ideal in scenarios where you are I/O constrained, which is a surprising majority of them.

That said, I've run into issues actually using node for stream processing data... taking information from flat files, or sql record queries. In practice very few modules actually implement backpressure properly, and as a result it can/will eat through ram. Exposing GC and running it on every iteration in these instances helps, but once you hit 1-1.7GB of ram use, the process dies in a fiery inferno. That said, you are actually better off running the 32-bit engine in windows environments (not sure about linux, I haven't actually tried to compare).

This seems to be more of a puff piece on ARM than Node.js though... I like node a lot, but it does have it's limitations... if you need to process a LOT of data (imports/migrations) and can't chunk or otherwise break out your data, you may well run into issues. In my case, trying to run through 119m records would run out of memory faster than it could manage to push them into a message queue from node, ymmv.

Re: Node and ARM

#15

Post by MichaelGG »

pjc50 wrote: post #5
azinman2 wrote: post #3

The arguments against jvm vs node I'm not buying. You don't automatically get scalability for free with node any more than any other platform. If anything the JVM has been further optimized, particularly for servers, for years over v8. You also don't see ram helping node not because node is so much more efficient -- it's because the design of the v8 limits how much ram it can use. I'm not sure even why it serves to t…

The only real advantage to node is that it doesn't have all the "enterprise" baggage: the apps people build with it are a lot smaller and a lot more decoupled.

Eh the insanely small size of individual modules (6 lines, I've seen!) creating huge nested node_modules is it's own type of hell. Seems like some programmers love ceremony and boilerplate, no matter the language.

Re: Node and ARM

#16

Post by [deleted] »

dmitrygr wrote: post #13

"we advise our clients to kill & quickly restart when their applications enter an unexpected-error state" Wait, what? Shouldn't your thing actually work. How unprofessional is it to advise clients to kill and restart things instead of fixing the issue that caused this to be needed? Wow!

[deleted]

Re: Node and ARM

#18

Post by tracker1 »

gmas wrote: post #12

"Node applications are generally scalable by default." no bias there..

No kidding... look at the first pass of node applications written by people coming from .Net or Java... (I include myself)... it takes a while to get into the "node way" breaking your code down into discrete modules, and favoring functional flows over OO ones.

That said, once you get into it, some beautiful orchestration patterns emerge[1][2].

[1] https://twitter.com/tracker1/status/558390877563801601 [2] https://twitter.com/tracker1/status/593174888187240448

Re: Node and ARM

#19

Post by nickbauman »

azinman2 wrote: post #3

The arguments against jvm vs node I'm not buying. You don't automatically get scalability for free with node any more than any other platform. If anything the JVM has been further optimized, particularly for servers, for years over v8. You also don't see ram helping node not because node is so much more efficient -- it's because the design of the v8 limits how much ram it can use. I'm not sure even why it serves to t…

Right. How do node.js apps horizontally scale better?

Re: Node and ARM

#20

Post by tracker1 »

vonmoltke wrote: post #10
pjc50 wrote: post #5

Earlier quoted context omitted.

The only real advantage to node is that it doesn't have all the "enterprise" baggage: the apps people build with it are a lot smaller and a lot more decoupled.

That baggage is concentrated in one particular JVM language and is largely self-imposed. I write NLP software in Java without resorting to the AbstractFactoryFactory nonsense prevalent in the enterprise world.

It happens in both Java and the .Net world.. every time I see "Enterprise" with a product description it makes me cringe... A lot of those abstractions only serve to scenarios; 1) Unit Testing and 2) service/storage portability. In most cases, neither are actually done. In the first case, I find actually writing unit tests in JS to be SO MUCH* better than with .Net or Java. In the latter, YAGNI prevails in my mind.

IT's entirely possible to work with "enterprise" platforms without using the excessive design patterns and abstractions, most simply don't. Not to mention that async being an option with C# for YEARS but most code I've seen even running on newer runtimes doesn't use it at all.

Node works very well for I/O constrained loads, unless you're risking running out of memory. I actually prefer the node way, and when you favor functional flows over OO design patterns, it gets to be really nice.

Post reply on HN