Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
They’re very similar, but with very different ergonomics. Go channels are part of the language, so libraries use them frequently, whereas tokio is a separate library and not nearly as ubiquitous. So you’ll get stuff like this:
c := make(chan bool)
go func () {
time.Sleep(time.Second*2)
c <- true
} ()
select {
case val := <-c:
case _ := <-time.After(time.Second)
}
This lets you implement a simple timeout for a channel read. So the barrier to using them is really low, so they get used a ton.
I haven’t looked at the implementation of tokio channels, so I don’t know if there’s something subtly different, but they do have the same high level functionality.
To be fair, a lot of that is because the scheduler detects blocking IO and context switches.
Rust could get really far with Go-style channels.
Are Go-style channels different from what Tokio provides? https://tokio.rs/tokio/tutorial/channels
They’re very similar, but with very different ergonomics. Go channels are part of the language, so libraries use them frequently, whereas tokio is a separate library and not nearly as ubiquitous. So you’ll get stuff like this:
This lets you implement a simple timeout for a channel read. So the barrier to using them is really low, so they get used a ton.
I haven’t looked at the implementation of tokio channels, so I don’t know if there’s something subtly different, but they do have the same high level functionality.