DEV Community

loading...

Discussion on: Writing Rust the Elixir way

Collapse
benwtrent profile image
Benjamin Trent

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 :)

Collapse
wanton7 profile image
wanton7

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.

Collapse
benwtrent profile image
Benjamin Trent

You are right, I missed the "forest for the trees" :)

Collapse
kajmagnus profile image
KajMagnus

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.

Collapse
benwtrent profile image
Benjamin Trent

That sounds weird to me. If you look carefully in the article above: 2 000 real threads, Mac OS crash

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.

But 10 x more lightweight threads: Works fine. That can be real-life useful when designing a web framework for example.

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.

Thread Thread
kajmagnus profile image
KajMagnus

Ok, thanks for replying. Agreed that 2k CPU threads sounds a bit weird