3 ms·

Rust one you mention is multiple-producer single-consumer. And it is not nearly as feature rich as a channel in Go. By the time one deals with tokio, async/awai

by harikb 6y ago

Rust one you mention is multiple-producer single-consumer. And it is not nearly as feature rich as a channel in Go. By the time one deals with tokio, async/await, passing the (rx,tx) to the right thread with clone()/copy(), the developer would be tired. There is a huge difference in library implementations of channel vs native language support

monocasa 6y ago
You don't need any tokio or async/await to use mpsc. It's in the standard library and works just fine with a thread spawned with a closure to work on. It's split into a read half and a write half so you don't have to worry about copy or clone, as an execution context will only have one or the other. I guess you clone the write half to give it to multiple producers, but that's not a huge deal. The example here for instance doesn't look any more complicated than using go channels, and it's a full executable example you can start by clicking the run button. https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html
masklinn 6y ago
> Rust one you mention is multiple-producer single-consumer. And it is not nearly as feature rich as a channel in Go. By the time one deals with tokio, async/await, passing the (rx,tx) to the right thread with clone()/copy(), the developer would be tired. tokio and async/await have little to do with channels (other than having their own async-aware versions). If you need a real mpmc channel, crossbeam[0] provides one. The interface is similar to the stdlib's, but you can clone the receiver as well as the sender. [0] https://docs.rs/crossbeam/0.8.0/crossbeam/channel/index.html https://docs.rs/crossbeam/0.8.0/crossbeam/channel/index.html
- harikb 6y ago
  tokio use is often not by choice. web service might need hyper.rs, which uses tokio underneath. Put a crossbeam non-async call in between and one would bring concurrency to a stop.

by harikb 6y ago

monocasa 6y ago

You don't need any tokio or async/await to use mpsc. It's in the standard library and works just fine with a thread spawned with a closure to work on. It's split into a read half and a write half so you don't have to worry about copy or clone, as an execution context will only have one or the other. I guess you clone the write half to give it to multiple producers, but that's not a huge deal. The example here for instance doesn't look any more complicated than using go channels, and it's a full executable example you can start by clicking the run button. https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html

masklinn 6y ago

> Rust one you mention is multiple-producer single-consumer. And it is not nearly as feature rich as a channel in Go. By the time one deals with tokio, async/await, passing the (rx,tx) to the right thread with clone()/copy(), the developer would be tired. tokio and async/await have little to do with channels (other than having their own async-aware versions). If you need a real mpmc channel, crossbeam[0] provides one. The interface is similar to the stdlib's, but you can clone the receiver as well as the sender. [0] https://docs.rs/crossbeam/0.8.0/crossbeam/channel/index.html https://docs.rs/crossbeam/0.8.0/crossbeam/channel/index.html

harikb 6y ago
tokio use is often not by choice. web service might need hyper.rs, which uses tokio underneath. Put a crossbeam non-async call in between and one would bring concurrency to a stop.