Erlang, Go, and Rust all claim in one way or another that they support concurrent programming with cheap "threads"/coroutines. The Go FAQ states:
It is practical to create hundreds of thousands of goroutines in the same address space.
The Rust Tutorial says:
Because tasks are significantly cheaper to create than traditional threads, Rust can create hundreds of thousands of concurrent tasks on a typical 32-bit system.
Erlang's documentation says:
The default initial heap size of 233 words is quite conservative in order to support Erlang systems with hundreds of thousands or even millions of processes.
My question: what sort of application requires so many concurrent threads of execution? Only the busiest of web servers receive even thousands of simultaneous visitors. Boss-worker/job-dispatching type applications I've written hit diminishing returns when the number of threads/processes is much greater than the number of physical cores. I suppose it might make sense for numerical applications, but in reality most people delegates parallelism to third party libraries written in Fortran/C/C++, not these newer generation languages.