Node and ARM
medium.com
medium.com
I'm not sure even why it serves to try and make this comparison if you're talking about node running well on modern arm processors.
There are a number of arm hosts out there now, but none seem to have caught on big. Perhaps in a generation of processor or two someone like aws will start to offer it and there might be a plausible shift.
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.
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 to watch. And then Spring was supposed to save us all, and now it's more complicated than any of the things it replaced.
Which is why I do a lot of front-end code these days.
At the risk of appearing a grad student, what were those?
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.
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.
There are also legacy windows bugs that make long file names not work when you have a bunch of nested node_modules folders.
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.
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.
They can't have a solution to shared state anyway, because of the semantics of Javascript, so they go with the idea that shared state is an attractive hazard. Which it absolutely is, but the one isn't sufficient to justify the other.
Erlang seems to have this right. You can have all the shared state you want but it can't cross component boundaries, and therefore you can multiprocess your little hearts out.
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 javascript. Worse yet, it has noticeable delays during operation, including about a 15 second delay if it hasn't been accessed in a few hours. I might blame it on a big dataset, but frankly it has less than a 100 tiddlers, and everthing is hosted on a SSD. This on a machine that generally is quite responsive, and capable (although its about 1/5 as fast as my desktop in some benchmarks I ran). It sure doesn't take that long to start apache/php on the same machine and start serving pages.
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)
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!
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.
This is doubly helpful because, as a side-effect, you can spin up or down new instances pretty easily because that operation is highly similar to crash recovery via restarting.
>This means that Node applications scale as easily across clusters of servers as they do within a single server.
Yeah, the loss of efficiency that occurs by starting up an entirely separate V8 VM on the same machine is equal to starting one on two separate machines... But how is that a plus? Especially if you want to start more than one thread on a machine.
Also, that part had nothing to do with Node. Perhaps Node may be optimized for ARM, but that really isn't informative in how it performs compared against (say) Java on the same platform. Java's optimized for ARM, too...
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 the other is awful. I'm sympathetic to KISS personally, but is there any real consensus forming?
See for example, Martin Fowler: http://martinfowler.com/articles/microservices.html
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.
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.
I love developing with node.js, but this doesn't sound right at all.
I know that Java performance is pretty crap on RPis due to the poorer Java ARM support, and I'd imagine that it's largely identical for node. All those millions that went into optimising JS performance can't help if the code generated is hobbled.
I've found little evidence to either prove or disprove my view, apart from this fairly devastating graph from a year ago, where a Pi is perhaps 100 times slower than an Intel dual core from nearly a decade ago.
http://smartmobilestudio.com/wp-content/uploads/2014/01/node...
I'm not convinced that ARM will be the architecture of the server, except in specialised markets (statistical multiplexing will give a big advantage to the >64 core Xeon servers that are popping up all around the place), but I'm totally convinced that this press piece is not particularly informative.
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
https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/143546...
Spin up a http server on arm and check out the latency for it to return "".