3 ms·
> 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
by jiofih 6y ago
> 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.
- throwaway189262 6y agoMakes 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
- coldtea 6y ago>It's still not really concurrency Well, it also has Workers, which is.
- jiofih 6y agoConcurrency != 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.
- throwaway189262 6y agoVery 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.
- zurn 6y agoBy 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?)
- jiofih 6y agoAlmost 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.