Where are the numbers? In my experience node is very slow on ARM.
Spin up a http server on arm and check out the latency for it to return "".
Node and ARM
41–49 of 49 posts
Re: Node and ARM
#42Earlier 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.
Just the tend to take a simple function, then ship it as a package. There's overhead in having a manifest, a folder, a separate code file, tests maybe, readme.md, etc. (Or in some cases, an meme-related animated gif that's referenced in the readme, that's larger than the rest of the package combined. Neato!)
It's obviously dumb from a technical perspective to break out individual functions (or even 20-100 line code files) into separate modules. But I think some folks really enjoy it.
Just like the Java or C# folks that put every single type definition into its own file. So you get some lame IHasFoo with a single bool property - so really 1 or 2 lines of actual code. Along with comments and a file header etc. Same for groups of enums, etc.
Re: Node and ARM
#43Earlier quoted context omitted.
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 langua…
You can take Java out of the enterprise, but you can't take the Enterprise out of Java. What's sad is a bunch of us saw this coming the moment a J2EE spec first came out, and complained loudly that it was a trap, to no avail. Version 1 was written by grad students who had no idea what the 7 Fallacies were. Version 2 was so complicated only a few big companies could implement it. It was a sad trainwreck that was hard…
Version 1 was written by grad students who had no idea what the 7 Fallacies were.
At the risk of appearing a grad student, what were those?
Re: Node and ARM
#44What 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…
This is my experience as well. When there are a lot of small or even medium sized operations or connections being performed (almost all the time), node does extremely well. When dealing with big huge chunks of data at once its not great.
Re: Node and ARM
#45"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!
Or you can use a system designed to accomodate the occasional failure like Akka (running on the JVM they seem to hate so much) or Erlang.
This. So much this. We restart faster than X and therefore we're better? (not to mention all the other weird points of comparison the author chose to call out)
There's plenty of languages with runtimes that have fast start-up times. Does Node therefore suck because my Go application could potentially start-up faster? What about something Erlang on Xen where they're spinning up a brand new Xen domU to service a web request in the hundreds of milliseconds range? Brand new VM, can't really "crash" and need to be restarted because it's only ever there for a single request.
I'm not really sure what the end goal of the whole article is, but it seems woefully written in terms of being technically rigorous.
Re: Node and ARM
#46Earlier 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.
Why not make lots of simple single-purpose modules?
My policy is that if I find myself doing something over three times and it's easily isolated and contained, I'll make it into a module. Then I can write a few tests for that code, I know it'll always work, and I won't have to think about it again. Even if it's something that's not hard, you don't want to stop focusing on your main task to implement some helper that you've already done before.
There's also a really strong argument when it comes to browser support: supporting and testing lots of things on old browsers is hard. But if you break stuff out into small modules you can test it easily in isolation and know it works in all your test browsers.
Re: Node and ARM
#47Earlier quoted context omitted.
You can take Java out of the enterprise, but you can't take the Enterprise out of Java. What's sad is a bunch of us saw this coming the moment a J2EE spec first came out, and complained loudly that it was a trap, to no avail. Version 1 was written by grad students who had no idea what the 7 Fallacies were. Version 2 was so complicated only a few big companies could implement it. It was a sad trainwreck that was hard…
Version 1 was written by grad students who had no idea what the 7 Fallacies were. At the risk of appearing a grad student, what were those?
http://en.wikipedia.org/wiki/Fallacies_of_distributed_comput...
The interesting thing about the 7 fallacies is that we constantly find new ways to make the same mistakes. If we've been doing decentralized computing, someone thinks they can fix all of our problems by centralizing it. If we're in a centralized phase, someone thinks we can solve all our problems by decentralizing it.
Exactly like the node and microservices people are doing right now. If you want a front row seat to the next pendulum swing, start learning everything you can about centralized software models now. You'll be sitting pretty in three years when the backswing starts. Maybe we'll try software transactional memory again.
Re: Node and ARM
#48"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!
The argument here is that when things go sour you can restore a running process more quickly. Of course things should actually work and issues should be fixed, nobody is suggesting that.
Re: Node and ARM
#49Earlier quoted context omitted.
Version 1 was written by grad students who had no idea what the 7 Fallacies were. At the risk of appearing a grad student, what were those?
http://en.wikipedia.org/wiki/Fallacies_of_distributed_comput... The interesting thing about the 7 fallacies is that we constantly find new ways to make the same mistakes. If we've been doing decentralized computing, someone thinks they can fix all of our problems by centralizing it. If we're in a centralized phase, someone thinks we can solve all our problems by decentralizing it. Exactly like the node and microservi…
I think that breaking things apart can be very beneficial though... You can run microservices on the same system physically, and give preference to a local service. This does increase complexity of orchestration, but it's still beneficial. Most people wouldn't implement their own local database for a service that has to handle many thousands of simultaneous requests... yeilding to a RDBMS. By the same vein micro-services allow a similar distribution based on a type of work.
There's also a difference between writing a handful of microservices, which are a bit more broad vs. breaking every action into it's own service. Beyond this, if you can separate out of band actions via queues this can alleviate a lot.
One thing that does get me is how many services are using a SOAP or even REST interface over HTTP vs something lighter. In my current project the backend services operate over 0mq req/res interfaces, while the front-end will communicate over a REST composite interface. In this way there's less disconnect and overhead.
It's always a trade-off, but that doesn't mean an approach doesn't have merrit, it's just a matter of striking a balance. Which I would guess is the whole point of all of this.