Hacker News Reader

Node isn't great when you need not only CPU-efficient but also multithreaded. The multi-threading or even multi-processing story in node is a clusterfuck. Other than running two full fat Node.js processes, your options are limited to a few APIs that have more chance to break your kneecaps than run the code.

Sure but that's the whole premise of Node, there doesn't _need_ to be multithreading. Whats wrong with spinning up multiple workers (in something like Docker/Swarm/K8S) that split up the work and report back to whatever collector or service that wants the end result?

So many problems have spawned out of the desire to thread everywhere that the safety of single-threadedness is a feature not a bug.

Multithreaded (or Multiprocess) can be done safely.

I write a lot of stuff in Rust these days, where (unless you use unsafe) it doesn't even let you do anything that would break under multi-threading, even if you don't use it.

As a result, it was incredibly easy to write a light-weight crawler that delivery results into a main worker queue and the data is processed by <cpu_cores> threads. The crawler largely uses async for IO advantages but the worker threads rely heavily on data crunching where your throughput is limited by CPU not by IO and async suffers a bit.

And since crawler and worker are on the same process, the latency between a page being grabbed and starting to be processed is incredibly low, any kind of networking would likely cut throughput by a factor of 10 or more. Not even mentioning having to serialize the data instead of relying on references to get read-only copies and only making minimal copies on the stack.

Ok, fair point Rust makes multithreading easier but one could easily make the argument that fighting Rust's borrow checker is a huge burden to development.

My point is Node isn't as bad as a server-side language as people claim. There are certain use cases where you can leverage Node's strengths and use another language somewhere else where its shines more.

I use Node heavily in my backend stack and have been extremely pleased with it's performance and library ecosystem.

You can do the things you do in Node, Async, in Rust too.

Futures and friends are in nightly and soon in Stable, which enable you to mix the best of both world; Multithreaded and Async.

Once you get used to Rust, you fight the borrow checker a lot less.

You can level "just use Rust" at any non-Rust ecosystem. It's kind of tired advice. You might as well be recommending Haskell or any other hobby horse language and then argue from a standpoint of technical superiority as if that's the only concern when choosing tools.

I use Rust all the time yet I'll still use Node for most HTTP-based applications and tools I start, and not because I'm an idiot or beginner, as many comments here will suggest. They are completely different languages and ecosystems and workflows that satisfy different goals.

This isn't "just use rust". This is "just use something more mature". And there are plenty of more mature ecosystems developing Async capability or that have a good Threading story.

Whats wrong with spinning up multiple workers (in something like Docker/Swarm/K8S) that split up the work and report back to whatever collector or service that wants the end result?

The "spinning up multiple workers" is what's wrong with that. Specifically a language/runtime that does support multi-processing handles it for you; ie gomaxprocs. Another example would be servers like apache forking off several workers during start up (depending on the mpm module). With node this has to be managed manually, as you describe, with Docker or whatever.

With a node async server, you're generally not cpu bound, so there's really no reason to try to utilize all the cores on the machine. Except if you are cpu bound, then you'd want to do that.

If you think there's nothing wrong with all the complexity that comes with running a distributed system for something that could be done trivially in a single process in a sensible language, I would like to sell you this hammer - you will find it very useful when you next need to screw something together.

> two full fat Node.js processes

Do you know about copy on write?

Starting up a second Node.js process gives you no CoW advantages, that would occur if you fork off the original node process. But Multiprocess support in Node is piss-poor at best.

https://nodejs.org/dist/latest-v12.x/docs/api/worker_threads...

Have you considered that workers in JS absolutely suck?

Have considered you that suck conditions race more with threads and shared memory parallelism?

If your counter-suggestion is Rust, have you considered.unwrap() that.unwrap() thinking.unwrap() about.unwrap() managing.unwrap() memory.unwrap() all the time might not be the wisest choice and that a GC is a useful abstraction to have?

unwrap() can very very often be avoided in favor of a simple ? operation, the amount of nesting you suggest does occur... but not in a single function so it's spread over many lines and functions. There are GC libraries for Rust if you need them. Or Python/Lua bindings that have it too.

Have you considered that avoiding race conditions isn't hard and you can't avoid having to avoid them even in JS?

"Race conditions of threads with shared memory parallelism" - yes you can avoid those in JS, the "yield" points are obvious in all code (await). Although its there if you need it (SharedArrayBuffer)

Regarding whether its hard or not, yes, I have some first-hand (non-Rust) experience.

On second thought I agree with your original point. Node isn't great for CPU-efficient + multithreaded. But

* most platforms aren't (either not great because unsafe, non-cpu-efficient or both) * most of the time its not what you really need.

So a good question would be, what would you use shared memory parallelism for in typical back-end programming?

I've developed plenty of shared memory software. In 99% of cases, a well placed mutex lock will solve the problem entirely. Of the remaining percent, maybe 5% are the type where you can just not lock and it'll work out sufficiently often. Another 45% might benefit from designing a channel/queue. The reamining 50% need a specialized lock to run well.

But all shared memory problems can, without much difficulty, be solved by using a mutex. It might not be best performance but you'll likely not need that much performance in the first place (after all, you're coming from the JS ecosystem).

Memory barriers aren't particularly hard to understand either, I've written some systems using them that ran very stable. Same for lockless or atomic or reentrant algorithms. It's all very fun and doesn't take that much skill if you're willing to read into it.

And plenty of people have said otherwise, and have developed entire languages and formal method frameworks to better reason about these problems. (e.g. TLA+)

So anyway... what would you use shared memory parallelism for in typical back-end programming?

You use the advanced methods to squeeze out more performance, it is not necessary to actually build solutions.

There is plenty of reasons for shared memory in back-ends, workers queues with zero-copy messaging would be one example that a lot of applications can benefit from.

Zero-copy message queue would be an unnecessary micro-optimization for most backends I've worked on. I don't think its something you would normally do in typical back-end programming, unless your scale is bonkers-level or you're creating infrastructure for others to use (maybe if you're doing analytics for others? except there are other alternatives there...). Its definitely not a niche targeted by node.

I don't think it's a microptimization, it's not that terribly complicated if you are careful about the code you write and it's definitely fun.

> that would occur if you fork off the original node process.

Right, so why wouldn't you? Node has a "fork" where you can give it a path to a script to run. Yeah it has to JIT it, but the V8 and Node part isn't duplicated.

Because running fork() in Rust,C&Friends is more efficient? I don't have to reload the code image at all and I instantly share all data, including any configuration.

Plus you can more easily do shmem in those languages than JS which gives you another performance advantage over pipes.

assuming your code doesn't actually need to be multithreaded, but you want to take advantage of multicore:

1) you can use a launcher like pm2 to auto-fork your node app

2) you can horizontally scale (put your servers behind a load-balancer)

if you do need multithreading for computations, you are right that node probably isn't a very good choice, but you have some options:

1) use worker threads

2) offload your intensive computations to a separate process written in a different language.

Even without multithreading, Rust will soon regain advantages with Async being stabilized. You get the best of both worlds.

It's also a lot harder to write, and in most cases developer time costs a lot more than another instance or two.

It's not that much harder to write if you use modern practises and languages.

People have written about this at length many times, but I'll rehash some of the arguments.

Node is missing very basic features, leading to a million tiny modules like leftpad. That's annoying by itself because there's overhead in finding the best package for everything.

The other consequences of that issue are much worse. You have lots of easy opportunities for misleadingly-named packages with malware in them. Package hijacking is easier to miss. Security updates, if packages even get them, have to be applied seemingly every hour.

It's just a major problem to have a simple project with 500 dependencies.

And that doesn't even get me started on issues with the mess that module importing was/is.

I agree that JS is missing a lot of standard library features that libraries like lodash or underscore have tried to backfill and the proliferation of libraries in npm is a cause for concern but is that enough to call an entire runtime's ecosystem obsolete or unwanted?

I just find it hard (however biased I may be) that we can just say "Node has all these problems, let's throw it out" when it's helped lower the barrier to entry for new people programming at-large.

>I just find it hard (however biased I may be) that we can just say "Node has all these problems, let's throw it out" when it's helped lower the barrier to entry for new people programming at-large.

This seems to assume that it would be impossible to design a better package manager which also provides a low barrier to entry.

Bear in mind, however, that all you actually need to write javascript and learn programming with it at a basic level is a text editor. The low barrier that NPM provides is for publishing to NPM, which needn't be synonymous with "javascript development."

Your comment also seems to assume that the barrier to entry everywhere else is prohibitively high, but plenty of people still learn with Ruby or Python or other languages. There are whole industries for teaching new programmers.

I actually disagree that it's lowered the barrier. JS is a hard language with lots of "wtf" behavior and weird runtime errors. You need lots of discipline to write code without tons of runtime errors, and beginners don't even know what they need to be disciplined about.

I'd argue that JS raises the barrier because lots of beginners now think it's normal to have a bizarre type system where null is an object, to have a complex Webpack/Babel setup just to use new-ish language features, and to have to constantly hit "run" to debug code.

Most previous-gen web languages also have lots of gotchas, but something like Go, Kotlin, or Dart would be a much more sane beginner language.

JavaScript has the functionality this module provides. You just have to know to use it instead of adding another dependency.

Node was far behind the ECMAScript standard for a long time, as were browsers.

>Can you provide any examples where Node does not provide a good ecosystem for backend programming?

A decent URL parsing/matching lib not tied to a full web framework ? Disclosure - haven't done serious node work in a while but ~2 years ago when I was building something in with it all the published libs for this were complete garbage - looking at the code for the packages made me realize what sort of crap gets published to NPM and then actually used/referenced by community.

I think it's better than PHP (took on a PHP integration job to help out a friend in trouble recently - that was going back to the dark ages with package management and module system). But it's the same tier in my eyes - filled with clueless newbies trying to lead other newbies - a community of blind leading the blind.

In my eyes a sane/mature language like Python beats Node any day of the week quality/productivity wise and so does stuff built on top of JVM/CLR. As much as C#/Java devs like to obfuscate code with useless patterns I'd take a random C#/Java package over a random Node package any time - at least the developer managed to convince the type system to compile his code - wouldn't say that the authors could do the same for some of the NPM packages I saw.

FYI a URL parser was actually added around 2 years ago in v8.0.0. It's based on the WHATWG standard and matches the implementation in modern browsers.

https://nodejs.org/api/url.html#url_url_parse_urlstring_pars...

Good to know. Maybe if I got back to it the core is more functional now.

My impression is that it's soo easy to publish to NPM and the ecosystem is newbie friendly - this is good but it also creates a lot of noise and popularity/usage is not a valid indicator of reliability/quality (compared to other platforms). And because the core was so barebones you need to use third party solutions a lot more often so it compounds the issues.

Any type system that allows null or any shouldn't be trusted any more than a dynamic language

It's not so much that I trust in the type system to prove correctness it's more that the type system and build system setup is a barrier to entry that puts a threshold on newbies publishing packages. Personally I've only seen such low quality code published and used in Node and PHP communities - because of the missing standard library and newbies creating noise with creating low quality libs or not knowing how to select/filter those and increasing their popularity. For example I recently had to deal with a grunt build system (could not chose a different task runner) and the quality of those plugins ...

"Backend programming" is a really broad class. It's safe to say that computationally intensive problems aren't best solved in node. For many server side "web service" type applications node is sufficient but there are a lot of tradeoffs being made that you may or may not be aware of.

By choosing node you are choosing single-threaded async IO as your primitive. You have to be ok without a threading model that supports shared memory (v8 objects don't pass between isolates, only certain types pass between web workers). And what's more, you have to be certain that your problem will fit these choices in the future.

Is it ever a good idea to hamstring a backend service with one narrow concurrency model? By comparison, golang offers you all of those things. If you need to write a backend service that performs well and can respond well to changing requirements, you have a much better chance of doing it with golang than node. I just can't promise any individual developer that they will enjoy writing the golang service more than the node one.

I don't want you to think I'm saying golang is better than node, we haven't even started to talk about the module system. I'm just saying fundamentally it is more flexible and can do everything that node does with at least the same level of performance, and generally it is "faster". Most things out of the box are faster. Benchmarking and performance is in the DNA of the go community and this isn't true for the node community.

> By choosing node you are choosing single-threaded async IO as your primitive

In node is it very easy to fork processes and have them communicate. Scripting languages for serving HTML and JSON aren't the place for threads.

Node now offers sync versions of most IO functions as well.

You just don't have shared memory at your disposal by forking processes. For example, having a rather large dictionary of translation strings which are read-only and static, you have to load these in every process as there is no copy on write property to these "forks".

If your JSON payloads are large, you can't have a forked process do the deserialization of it (because you would need to re-serialize across the communication boundary, which defeats the point).

I think it would be reasonable to have immutable data structures shared with web workers. I also think it would be reasonable to make it possible to pass complex objects (all primitive types supported by JSON) between workers without a serialization step.

Running multiple processes doesn’t solve the head of line blocking problem where a single large request causes all the small requests behind it to pile up increasing their latency too. When you have thread pools this is not a problem as each request is processed by the next available worker.

JS has nice fast runtimes, and crucially the ability to share code between client and server. I think there’s potential (even without threads) to have a JS server architecture that does not require the entirety of a request/response to be processed in a single thread but could break it up so it could be processed by a pool of workers at IO event boundaries. Either as one isolate per request or explicitly passing state for IO event callbacks.

Agree! There's a package for just about anything you could want. If you are in a small shop (I'm a 1 person team) it's so invaluable.

NPM's module selection is so wide that it's sometimes hard to find the best one. Too many choices! I would rather have that problem than lack of any choice.

Overall I'd guess to get a functional product, NPM's modules saved me about 50% of my time.

Personally I love C#, but can't use that for backend because of the lack of module ecosystem.

Just curious, what is missing from C# for you?

just the lack of module ecosystem.

Is that not nuget?

Better read on on NuGET, FAKE, COM and Assemblies.

> I'd go as far as saying Node lends itself to certain layers of the backend stack because of it's history being more CPU-efficient then other server-side runtimes.

If you're talking about async I/O, TCL (among others) has offered that for more than 20 years (from AOLServer on), and in a much better-designed language than JS.

Is the design better in some fundamental way, or is it just about equality comparison and other shallow "wtfs"?

I'm not a Node expert, but my understanding is that if any code throws an error, the server crashes and has to be restarted. That prompted a serious WTF from me when I read about it.

While Tcl is running as a server in an event loop, if an error is thrown while processing an event it is reported via a background error API, and the server keeps going.

That is true, and node's official advice in this regard is bad. It comes from previous bad designs of error handling and leaking resources (file descriptors mostly) caused by domains. However, modern node code typically uses promises and you can use slightly more old-fashioned methods of managing resources: https://stackoverflow.com/a/19540907/110271

You can go a step further and fully isolate "crash-assuming" code from "non-crash-assuming" (promise based code): https://gist.github.com/spion/ed8deb7a3b4add0a6d727dc78fe635...

I don't know what you consider a deep part of programming language design. E.g. I would consider prototypal inheritance and non-lexical scope to be deep language design mistakes in JavaScript. But even beyond that TCL is a particularly elegant design (rather lisplike in a way) - e.g. Guido van Rossum cites it as an inspiration.

Why do you believe that JavaScript isn't lexical? My understanding is that it is. Do you mean the behavior of `this`? Its similar to Lua in that `this` is actually an implicit function argument (passed left of the dot) but thats definitely very different from say, dynamic scope

Prototypical inheritance isn't a "deep" design mistake in so far that its not actually used as such (its mostly used as classical inheritance). Classical inheritance could be argued a design mistake, but one that most mainstream languages make, so I wouldn't go as far as to call it a deep one.

> Why do you believe that JavaScript isn't lexical? My understanding is that it is. Do you mean the behavior of `this`? Its similar to Lua in that `this` is actually an implicit function argument (passed left of the dot) but thats definitely very different from say, dynamic scope

`this` but also hoisting - variables get hoisted out of blocks where they are declared, so their scope is not what it looks like lexically.

> Prototypical inheritance isn't a "deep" design mistake in so far that its not actually used as such (its mostly used as classical inheritance).

I'd argue that even if it's not being used it still adds complexity when reading or debugging.

Hoisting is still lexical, except the scope is function level. But the point is moot, since we have `let` which behaves "normally" now.

`this` is not non-lexical scope, its argument passing. Its the most confusing wart in JS but its actually not a fundamental design flaw, just a syntactic wart: https://gist.github.com/spion/7180482

> I'd argue that even if it's not being used it still adds complexity when reading or debugging.

I disagree, it barely adds a couple of bits of noise here and there. Definitely not a deep flaw.

The worst JS flaws are in its anemic standard library and the pre-promises backend standard library included with node. They are overdue for a refresh.

Node being more CPU efficient than Java, .NET, C++, Go?!?