I hope they can do something about the RAM usage for Node/io.js programs.
Node and ARM
31–40 of 49 posts
Re: Node and ARM
#32"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!
That was part of Zed Shaw's "Rails is a Ghetto" rant years ago, that the best Rails developer was proud that his application only crashed like 80 times per minute.
Re: Node and ARM
#33"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.
Re: Node and ARM
#34What 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
[deleted]
Re: Node and ARM
#35Very nice summary on ARM but I don't really understand the pitch for node in this context, unless "small" is the overriding design criterion.
Re: Node and ARM
#36Earlier quoted context omitted.
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 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 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.
Re: Node and ARM
#37"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!
Our codebase (not Node-based) is over a million lines of code. It's going to crash at some point. Probably even a lot. Thus, it has been built so that it can be restarted without too much issue or ceremony.
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.
Re: Node and ARM
#38Earlier quoted context omitted.
It forces the developer to scale horizontally
So how does that meet the definition of better? By only creating one direction vs two?
It's a clear sour grapes scenario.
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.
Re: Node and ARM
#39So does this mean we'll get node.js on the arm64 port of Ubuntu soon?
https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/143546...
Re: Node and ARM
#40Interesting to see a high level comparison of languages without a comparison of the important numbers: performance.
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.