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

21–30 of 49 posts

Re: Node and ARM

#21

Post by tracker1 »

StillBored wrote: post #8

"Node is nimble; for example, we advise our clients to kill & quickly restart when their applications enter an unexpected-error state. You can’t do this with a runtime that takes minutes to properly start and warm-up." Hmmm. I'm running tiddlywiki (node.js app) on an ARM, and it probably takes a good ~30 seconds to start up.. Not good for an application that weighs in at 20k lines of code, 3/4 of which isn't even jav…

I am surprised that your application takes 30 seconds to start up in node. I have several utility scripts that run via babel-node instead of pre-build that don't take that long to start. When running pre-built JS, even using next generation syntax in source the start up is usually well under a second... Most of the lag time is in initializing database connection pools.

That said, how large is your application? Can it be broken up in to more right-sized services? Are you maintaining a lot of instantiated objects in scope? Are you using OO or FP orchestration? What kind of application is it?

(edited to be less abbrasive)

Re: Node and ARM

#22

Post by tracker1 »

sylvinus wrote: post #7

Smaller ARM servers are an interesting trend, see https://www.scaleway.com/

I've looked at them... but the performance still doesn't match even the relatively small VMs that are offered from cloud providers in terms of raw throughput. Part of the issue is the system builders for ARM based server boards simply aren't at near the scale.

Re: Node and ARM

#23

Post by wlievens »

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.

Same here! It's perfectly possible to write quality Java code, without trying to cram everything into Spring.

Re: Node and ARM

#24

Post by woah »

MichaelGG wrote: post #15
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.

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.

What's the boilerplate involved with nested node_modules? Theoretically, it's a waste of hard drive space, but that's rarely a concern.

Re: Node and ARM

#25

Post by woah »

nickbauman wrote: post #19
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?

It forces the developer to scale horizontally

Re: Node and ARM

#26

Post by TheAceOfHearts »

mooreds wrote: post #11
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

I think it depends on what kind of application you're building, as well as other factors like team size, experience, and time. Microservices aren't magic pixie dust you sprinkle over your applications to suddenly make them simpler and "web-scale". They have a cost in management and maintenance. You can end up taking microservices too far, just as you can end up making the monolith too monolithic.

Having your core API all be part of a single application is great. It's my impression that for a lot of applications you can't really achieve good decoupling of resources, so trying to break it up into multiple services ends up bringing you a lot of pain. Maybe this is my lack of experience showing, I'd love to be proven wrong.

I'm currently a fan of having a big/medium app that does everything that cannot be decoupled easily, and breaking everything else into services. This is a happy medium, because you don't have to worry about managing tons of services, but you also don't have to worry about having an absurdly complicated monolith.

Re: Node and ARM

#27

Post by vonmoltke »

wlievens wrote: post #23
vonmoltke wrote: post #10

Earlier quoted context omitted.

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.

Same here! It's perfectly possible to write quality Java code, without trying to cram everything into Spring.

Or treating the GoF book as a bible, which is my personal pet peeve.

Re: Node and ARM

#28

Post by vonmoltke »

tracker1 wrote: post #20
vonmoltke wrote: post #10

Earlier quoted context omitted.

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

Java certainly has its warts, but I still think nearly all of what you describe is cultural rather than technical. Whether it's slavish adherence to GoF patterns, or obsession with code coverage metrics, or religious devotion to OO purity it's about the culture of the developer and the team. Java and C#, unfortunately, are the predominant choices of the developers and teams who share this culture. It gives the languages an unfairly bad rap, one which I agreed with until I started my current job.

Re: Node and ARM

#30

Post by iends »

woah wrote: post #24
MichaelGG wrote: post #15

Earlier quoted context omitted.

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.

What's the boilerplate involved with nested node_modules? Theoretically, it's a waste of hard drive space, but that's rarely a concern.

Are you also loading multiple versions of the same library in memory, or multiple versions with only a small minor version difference?

There are also legacy windows bugs that make long file names not work when you have a bunch of nested node_modules folders.

Post reply on HN