4 ms·
As an avid Go user, I think async/await is probably a nicer construct for most usecases. But Go channels work fine as long as you keep to the basics and documen
by liampulles 2y ago
As an avid Go user, I think async/await is probably a nicer construct for most usecases. But Go channels work fine as long as you keep to the basics and documented patterns.
I can recommend making a utility function which accepts a set of anonymous functions and a concurrency factor. I've since extended this function with a version which accepts a rate limiter, jitter factor, and retry count. This handles most cases where I need concurrency (batches) in a simple and safe way.
- adastra22 2y agoI guess the grass is always greener on the other side. As a Rust user, I’m constantly thinking “why didn’t they just give us go channels instead of this crazy async/await nonsense?”
- steveklabnik 2y agoRust has one form of channels in the standard library. More kinds available from crates.io. If you prefer channels, use them!
- adastra22 2y agoBecause one crate uses one channel implementation, and another crate uses a different one… this is really something that should be solved at the language / stdlib level, as Go does, but Rust falls a little bit short. There mpmc and the Send trait, but they alone are insufficient. So instead we get crate dependency hell that is only somewhat mitigated by cargo, and colored functions due to the async implementation.
- brianolson 2y agoRust async/await is less nice than Go coroutines. There are things you can't do and weird rules around Rust async code. Every Go chan allows multiple readers and multiple writers, but Rust stdlib and tokio default to single-reader queues.
- initplus 2y agoChannels and async/await aren’t really equivalent features. Beyond the fact that they both deal with concurrency. You can do channels (message passing) on top of async await.