4 ms·

Let me be more precise then. Goroutines enable a fan out pattern in which each task, even small ones, is a separate asynchronous routine. Tasks fan out from a c

Let me be more precise then. Goroutines enable a fan out pattern in which each task, even small ones, is a separate asynchronous routine. Tasks fan out from a coordinator routine and their results fan back in: https://talks.golang.org/2012/concurrency.slide#46 https://talks.golang.org/2012/concurrency.slide#46 This is great for a couple reasons: It's automatically concurrent without explicit pooling and locking. The code flow remains sequential. No callback hell! It reduces concurrency errors. The locking pattern is naturally acyclic! Nothing races! Ah, but Go has a big runtime, you say! We can't have that in Rust! Well, here's the same thing in C and in C++: http://libmill.org/tutorial.html http://libmill.org/tutorial.html http://www.boost.org/doc/libs/1_59_0/libs/coroutine2/doc/html/coroutine2/motivation.html http://www.boost.org/doc/libs/1_59_0/libs/coroutine2/doc/htm... Coroutines are a wonderful tool for building concurrent applications, and I dearly hope we get them in Rust.

Manishearth 11y ago
Forget to update that 3 after fiddling with the channels? Deadlock. Forget to unlock a mutex when dealing with shared data? Deadlock (and Go doesn't have RAII mutexes, so it's very easy to do this). The pattern you put forth is possible in Rust too. Use mio if you want goroutine-like efficiency. Nothing new.
- acconsta 11y ago
  >Forget to update that 3 after fiddling with the channels? Deadlock To be fair, how long would that take to debug? >Forget to unlock a mutex when dealing with shared data? You'll note there are no mutexes. RAII mutexes are great (although less useful without exceptions). But the entire point of Go's concurrency model ("share by communicating") is that you don't need need to deal with them. >Use mio if you want goroutine-like efficiency For a personal project, I would. But will any commercial entity use an unstable, unportable library with a single maintainer for critical functionality in their app? Because that's the concurrent IO situation in Rust, now and for the foreseeable future.
  - 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.

Manishearth 11y ago

Forget to update that 3 after fiddling with the channels? Deadlock. Forget to unlock a mutex when dealing with shared data? Deadlock (and Go doesn't have RAII mutexes, so it's very easy to do this). The pattern you put forth is possible in Rust too. Use mio if you want goroutine-like efficiency. Nothing new.

acconsta 11y ago
>Forget to update that 3 after fiddling with the channels? Deadlock To be fair, how long would that take to debug? >Forget to unlock a mutex when dealing with shared data? You'll note there are no mutexes. RAII mutexes are great (although less useful without exceptions). But the entire point of Go's concurrency model ("share by communicating") is that you don't need need to deal with them. >Use mio if you want goroutine-like efficiency For a personal project, I would. But will any commercial entity use an unstable, unportable library with a single maintainer for critical functionality in their app? Because that's the concurrent IO situation in Rust, now and for the foreseeable future.
- 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.