While this code looks cool (I am a fan of Elixer + Erlang). The Rust reasons for not natively supporting green threads are valid (native interop, runtime complexities, not real threads, etc.).
Using green threads for parallel compute doesn't make sense as the OS can handle only a specific amount of work. “Massive” concurrency is only valuable if you are I/O bound. The mental demarcation between async/await and threads is very valuable when you consider this limitation.
Building a green thread implementation might encourage naive implementers to use them for compute.
Is there anything in the implementation that discourages massive paralleled compute in these green threads?
Again, I think this project is cool and is some interesting code :)
Personally I'm glad to see Erlang and Elexir ideas happening in Rust too — and even better — the within-processes-only crashes for example.
Using green threads for parallel compute doesn't make sense as the OS can handle only a specific amount of work.
That sounds weird to me. If you look carefully in the article above: 2 000 real threads, Mac OS crash. But 10 x more lightweight threads: Works fine. That can be real-life useful when designing a web framework for example.
I know this article uses Rust but if you look closer at Lunatic project its about WASM not just Rust so in future it can support any language that compiles down to WASM. If you go to Lunatic GitHub repo first things written there is this "It is heavily inspired by Erlang and can be targeted from any language that can compile to WebAssembly. Currently there are only bindings for Rust available.".
I also find this project very interesting and maybe in future it can be alternative to Erlang VM.
While this code looks cool (I am a fan of Elixer + Erlang). The Rust reasons for not natively supporting green threads are valid (native interop, runtime complexities, not real threads, etc.).
Using green threads for parallel compute doesn't make sense as the OS can handle only a specific amount of work. “Massive” concurrency is only valuable if you are I/O bound. The mental demarcation between async/await and threads is very valuable when you consider this limitation.
Building a green thread implementation might encourage naive implementers to use them for compute.
Is there anything in the implementation that discourages massive paralleled compute in these green threads?
Again, I think this project is cool and is some interesting code :)
Personally I'm glad to see Erlang and Elexir ideas happening in Rust too — and even better — the within-processes-only crashes for example.
That sounds weird to me. If you look carefully in the article above: 2 000 real threads, Mac OS crash. But 10 x more lightweight threads: Works fine. That can be real-life useful when designing a web framework for example.
2,000 real threads doesn't make sense for parallel compute. i9 intel processors don't have 2,000 threads.
Now, 2,000+ "threads" or better yet async code DOES make sense for I/O. Because there is not real "work" being done.
But if you are doing compute bound work, 2k+ CPU threads makes no sense on a personal computer.
100%, if your work is I/O bound, it is exceedingly useful. That is the point of my comment.
The example of the TCP echo server is a great example of I/O bound work.
Ok, thanks for replying. Agreed that 2k CPU threads sounds a bit weird
I know this article uses Rust but if you look closer at Lunatic project its about WASM not just Rust so in future it can support any language that compiles down to WASM. If you go to Lunatic GitHub repo first things written there is this "It is heavily inspired by Erlang and can be targeted from any language that can compile to WebAssembly. Currently there are only bindings for Rust available.".
I also find this project very interesting and maybe in future it can be alternative to Erlang VM.
You are right, I missed the "forest for the trees" :)