A partial, limited list of reasons why kernel threads are much worse than an M:N green thread user space implementation:

* kernel space and time overhead is relatively gigantic * no cross-os usable kernel thread standard except fork() * when you are writing systems code, sometimes you either do not have a kernel, or are writing one * submitting to kernel threads means you must also give all cores over to the kernel as well, leading to competition between your program and others * still doesn't solve the core problem of cross-thread communication

> when you are writing systems code, sometimes you either do not have a kernel, or are writing one

If you're writing kernel code, you have to abandon most of Rust's standard library already, because there's lots of stuff that isn't available. This is one of the reasons why Rust's standard library is split into a bunch of different crates (that are all then re-exposed under the "libstd" facade), so you can pick and choose which bits of functionality you can actually use. If you're in the kernel, you probably can't use the user-space allocator, which means you have to drop liballoc, which means you have to drop most of the standard library. AIUI, kernels are pretty much constrained to using just libcore and then reimplementing other functionality as needed. Most relevant to this conversation, this generally means you have to drop the standard library's I/O and threading support entirely (userspace code that creates threads isn't really going to work in the kernel).

And at that point, there's absolutely nothing stopping you from implementing an actor model yourself. Heck, that's what the Rust standard library used to do! Although it used libuv, which presumably doesn't work in kernelspace, which means you wouldn't have even been able to use Rust's green threading from kernel code even if it was never dropped.

> submitting to kernel threads means you must also give all cores over to the kernel as well, leading to competition between your program and others

I'm not sure what you mean by this. A green threading implementation is built on top of OS threads anyway (using a small pool of threads roughly equivalent to one per core, with extra threads as necessary for the green threading implementation to do blocking tasks). There's nothing at all about green threading that lets you control a core all to yourself without sharing it with other processes. If your OS lets you request priority for a specific core, you can do that for OS threads just as well as you could with green threads.

I'm not sure how to square those statements with the ones eridius made up-thread that you replied to. There's some very specific downsides to implementing green threads laid out above, which you've done nothing to address.

> no cross-os usable kernel thread standard except fork()

Not to make your own point for you, but fork isn't available on every platform either. Windows has no fork. I'm not sure I consider forking analogous to threading anyways. They are both multiprocessing primitives, but I generally define threading (and it's derivatives) through how it's different than forking. That could easily just be me though.

I don't have the time at the moment to unpack all of his points; many of them are valid concerns, but I don't find any two of them especially convincing enough to abandon the objectively ( :) ) superior actor model.