> precisely why you don't run any more OS threads than the number of cores

It’s often worth running more than your number of cores, in order to keep execution units busy during memory fetches for example, or integer units busy while float units are a bottleneck otherwise. (Did a PhD partially on this kind of thing.)

That's what hyperthreading is for, which implies having the same number of threads as logical cores.

Hyperthreading and out of order execution are meant to accomplish keeping the execution units busy.

No it implies having the same number of OS threads as hardware threads, which is more than the number of hardware cores.

That's what logical cores means. Hardware threads / hyper threads are also called logical cores by the bios and OS.

You are obviously correct and I'm not sure why you are being downvoted.

You can still use Erlang style concurrency (or Go style as well) to truly parallelize CPU bound tasks. It’s a bit less efficient due to Erlangs design where you can’t readily share mutable data between processes but will still enable true parallel calculations on all cores. By default BEAM runs one execution thread per core. For example, it’d be trivial to write a true parallel merge sort in Erlang/Elixir.

Now NodeJS or Python Asio style concurrency _are_ truly limited by their VMs and can’t do native parallel computations in a single process.