3 ms·
Your example is tiny and trivial, the same thing written with locks/whatever would be equally easy to debug. Problems in a more complicated application would be
by dbaupp 11y ago
Your example is tiny and trivial, the same thing written with locks/whatever would be equally easy to debug. Problems in a more complicated application would be harder to debug, no matter if you use either channels or locks.
> But the entire point of Go's concurrency model ("share by communicating") is that you don't need need to deal with them.
Exactly the same thing works in Rust, and works "better": the lack of other sharing (except by message passing) is enforced at compile time. Rust ensures that other options are available with as much help for correctness as possible.
> But will any commercial entity use an unstable, unportable library with a single maintainer for critical functionality in their app?
Concurrent IO is inherently unportable, and mio has support for the major platforms (OSX, Linux and Windows, with tests run on all) so I don't know what you mean by that. mio won't be the first or last lib with a single maintainer that a commercial entity uses.
(Unstability is of course a perfectly reasonable criticism, and I'm sure it'll disappear as the library ages.)
- acconsta 11y ago>Your example is tiny and trivial, the same thing written with locks/whatever would be equally easy to debug. Write the version with explicit locks and condition variables and we'll see if it's as easy to debug. :P >Exactly the same thing works in Rust, and works "better": the lack of other sharing (except by message passing) is enforced at compile time. Which is one of the reasons why Rust can (should) eat Go's lunch. All it's missing are lightweight coroutines and concurrent IO. And I didn't know Mio supports Windows now — that's good news! If Mio stabilizes and Rust gets lightweight coroutines (probably requiring compiler support), Rust could be the best of all worlds.