Erlang has two things that are relevant to this discussion: user level threads (aka green threads), and asynchronous message passing.
User level threads reduce the memory footprint of threads, and possibly the context switch time (depending on implementation) but they are not without drawbacks. Heck, Java 1.1 had green threads but they dropped them for kernel threads in later releases (http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_...).
The main issue is balancing work on multicore machines. With kernel threads the OS will automatically balance them. With green threads you are reliant on the user level scheduler to do this work. It is more difficult to get right without the level of information the OS has. If you want to give the programmer control over scheduling you need to provide some access to kernel level threads.
Other issues include: not all the OS IO primitives have non-blocking equivalents you can use (typically you have to use a pool of kernel threads for these operations; the runtime may hide this.) and you still pay some context switch time with you don't actually have at all in a simple epoll / kqueue based system.
I'm running out of time, so I'll just note that asynchronous message passing is hard to reason about.
User level threads reduce the memory footprint of threads, and possibly the context switch time (depending on implementation) but they are not without drawbacks. Heck, Java 1.1 had green threads but they dropped them for kernel threads in later releases (http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_...).
The main issue is balancing work on multicore machines. With kernel threads the OS will automatically balance them. With green threads you are reliant on the user level scheduler to do this work. It is more difficult to get right without the level of information the OS has. If you want to give the programmer control over scheduling you need to provide some access to kernel level threads.
Other issues include: not all the OS IO primitives have non-blocking equivalents you can use (typically you have to use a pool of kernel threads for these operations; the runtime may hide this.) and you still pay some context switch time with you don't actually have at all in a simple epoll / kqueue based system.
I'm running out of time, so I'll just note that asynchronous message passing is hard to reason about.