Hacker News Reader

Comment by jiofih | Hacker News Reader

> JS has an equally bad concurrency story as Ruby. Maybe even worse.

This is absolutely false. Yes, JS is single threaded, but all IO is async and happens via a worker pool. On top of that it is 3-10x faster than Ruby for most tasks due to the insane amount of development effort that went into the browser runtimes, it’s often within 50% of C speeds.

And then the entire ecosystem is async. This is why you’ll see JS frameworks near the top of TechEmpower benchmarks achieving massive concurrency numbers, and also why nobody recommends any kind of CPU-heavy workload in node.

Imagine Ruby came with Puma built-in, and all libraries only exported async interfaces.

View on HN

By JS do you mean Node here?

Node has both blocking and async versions of a lot of IO operations. But async IO is more commonly used certainly. The real question might be whether a thread pool backed async IO implementation makes your program do concurrent IO better than a GIL + blocking IO calls that release the GIL, it's not obvious to me.

(Doesn't Node have threads too nowadays?)

Almost no code uses node’s sync APIs unless explicitly asked to, its ingrained in developer practices to the same level as not polluting global scope.

Node’s threads are for cases you really want to do heavy computation without resorting to another language. All the I/O is still backed by LibUV and an event loop, threads don’t really offer any improvement there.

Makes sense. Better than Ruby I guess. It's still not really concurrency, it just handles being single threaded better.

JS is strange because of all the optimization. It's technically multi threaded with IO but in a way that you only control the "main thread". Reminds me of old UI work

>It's still not really concurrency

Well, it also has Workers, which is.

Concurrency != parallelism. You can of course run a multi-process cluster, but that’s besides the point (and these days it’s best to run a single process inside orchestration like k8s).

Basically almost every high performing server atm is running on some form of event loop / cooperative multi-tasking. Ruby Puma, Gunicorn, rust’s tokio and async/await, goroutines... Java is probably the big exception here (if you’re not using VertX et al) and we all know the pain of thread safety.

Very true. Go is an exception, and some day Java will be as well. They're both going route of userspace threads instead of reactive API's, thankfully.

Reply on news.ycombinator.com