[AaronO]

I don't think it's unfair to say that 1 man-hour equates to many machine-hours (in terms of dollar cost). Then in terms of per-core performance, modern JavaScript runtimes are nearly competitive with Go and per-core performance is ultimately what matters at scale since you'll load-balance between cores or VMs to saturate your compute.

[PaulHoule]

Per-core performance is one thing, realized performance on today's multi-core machines is something else.

I have been writing back ends in Java and C# for more than a decade and it is widespread for people to take advantage of multi-core systems in two ways if they can: (1) threads sharing data structures such as system configuration and caches (e.g. it is no problem to have 10 or 100 megabytes of configuration data for a Java-based system) and (2) using Executors to split up tasks into smaller pieces and running them concurrently.

In Node.js, Python, and other GIL languages you can't do the above and slow down from "configuration at the speed of RAM" to "parsing configuration over and over again", "configuration at the speed of the database", etc.

I see people using Node.js for build systems but I think it's still an unusual choice (like Python) for a back end for a commercial system.

[eatonphil]

I'm not disagreeing with you but I am curious: what's the effective difference for most people (concerning perf and utilization) between multicore support in Java and Go and just running multiple processes in Node (edit: let's just ignore Python to make this simpler) ?

[nicoburns]

> what's the effective difference for most people (concerning perf and utilization) between multicore support in Java and Go and just running multiple processes in Node

The perf difference here probably isn't that great (although Java/Go will likely still be faster), but if you're at the point of running multiple processes you may well find that it's less dev effort to write your code in Java/Go (assuming you are familiar with both).

[eatonphil]

Yes I agree, it's always been simpler for me to operate Go apps rather than Node ones (but also because of memory usage in callback- and streaming-heavy JavaScript).

[mnutt]

Multi-process in node.js web serving is doable but operationally more of a pain. The cluster module will let you spawn a bunch of processes all sharing the same listening port, but sharing caches, connection pools, etc become much more difficult. If some aspect is particularly CPU-bound you can use web workers, but for run-of-the-mill web requests I'm not sure it's worth it.

[pjmlp]

Processes eat more resources, and even taking them out of the equation, dynamic language runtimes have less opportunities for good JIT code optimization, at the same level as languages like Java and Go type systems allow for.

In regards to Node, as Python is anyway mostly CPython 99% of the deployments.

[eatonphil]

A fixed process pool of 1 process per core is truly overall more resource intensive than a goroutine per request model in Go?

It would kind of seem like a wash to me, naively.

[pjmlp]

Because you're missing the picture that a goroutine doesn't use the stack size, heap from OS data structures, or CPU context switches into kernel code, as a full blown process.

Let alone the detail that the goroutine is full blown native code, while the node/Python process is interpreted, and even if a JIT is used, many C2 level optimisations are out of reach for dynamic languages.

It is no wonder that even with the herculean effort that has gone into V8, for the ultimate performance it needs help from GPU shaders and WebAssembly, both typed.

[zachrip]

I will extend this question to things like fargate