6 ms·

Rust – Coroutines support merged

111 points by adelarsq 9y ago

computerphage 9y ago
This is experimental so far: https://github.com/rust-lang/rfcs/pull/2033#issuecomment-309057591 https://github.com/rust-lang/rfcs/pull/2033#issuecomment-309... > The key point then is that the experimental RFC is not enough to stabilize something. For that, we need a proper RFC that lays out the plan. This RFC can be informed by the experience and working implementation, so we should have a lot of data to use. It's being merged into nightly (behind a flag) to gain understanding of how the feature would work. This isn't the day to celebrate Rust having fully-fledged co-routines coming soon to stable because there is no such guarantee yet. Edit: removed extra word
- steveklabnik 9y ago
  This is the first "experimental RFC", so that's also kind of fun.
pitaj 9y ago
Relevant RFC: https://github.com/rust-lang/rfcs/blob/master/text/2033-experimental-coroutines.md https://github.com/rust-lang/rfcs/blob/master/text/2033-expe... This looks like a huge win for Rust. The syntax seems to follow the C# and ES async/await syntaxes. With stuff like this, I can see Rust-based webdev becoming popular.
- jimktrains2 9y ago
  http://www.arewewebyet.org/ http://www.arewewebyet.org/ On a serious note, one of my middling priorities (unfortunately :( It always feels like you can't choose most your high priorities) is to build a rust-based website and a couple of other rust-based projects t get a feel for the language. It really dose feel like all the parts are there already and that as things get added, it'll just get easier and better.
  - foota 9y ago
    Maybe try to find ways to bring rust into the middle of your higher priorities?
    - reificator 9y ago
      I'm in the same boat as the GP, in that I want to use Rust for a lot of things that I think it would be good at, but I don't get to choose my high priority tasks. And for me at least, my high priority tasks are not the tasks that benefit from Rust over other languages. I could introduce it for the sake of my resume, or I could use the right tool. The former seems unprofessional and unproductive outside of jumping ship and leaving your co-workers with extra baggage.
    - jimktrains2 9y ago
      High priorities being family, house repairs, house maintenance, and work. Nothing extraordinary, and I guess one could argue house upkeep is chosen. I also have some personal programming projects I've been working on where I decided to value getting them out quickly vs learning a new language, and those are, all together, half done. I've also been debating learning modern C++ to open potentially open some doors to a slightly different career than web programming (railway signalling, probably a pipedream at this point, but). So, all in all, I love what rust represents, but it doesn't bring value right now. Once those personal projects wrap up my goal is to have a round of rust and C++ ones to do.
  - steveklabnik 9y ago
    That site is a bit out of date; I should send some PRs. "You can build stuff" is still a good summary, but lots of stuff has happened since this was last updated.
simonw 9y ago
Here's a rendered version of the documentation added in that commit: https://github.com/Zoxc/rust/blob/a996d5eec70ba6733e23f2e56e762f58e60bb4ff/src/doc/unstable-book/src/language-features/generators.md https://github.com/Zoxc/rust/blob/a996d5eec70ba6733e23f2e56e...
- steveklabnik 9y ago
  This will be located at https://doc.rust-lang.org/nightly/unstable-book/language-features/generators.html https://doc.rust-lang.org/nightly/unstable-book/language-fea... after the next nightly comes out in ~4 hours (I believe).
siscia 9y ago
Am I the only one who prefer epoll style concurrency than coroutines? Are coroutines more somehow more powerful?
- squiguy7 9y ago
  You will probably be interested in mio [1] then. [1]: https://github.com/carllerche/mio https://github.com/carllerche/mio
- stormbrew 9y ago
  They're orthogonal? Coroutines as built here are just sugar around building the state machines you necessarily build by hand if you're using something like epoll. They can also be used to model state machines in general, so long as there's a well defined progression of states in one direction. You would use these coroutines with tokio or mio, which are event driven frameworks that use epoll at their core on Linux.
Nelkins 9y ago
Trying to wrap my head around this...as someone coming from .NET land, maybe someone can explain it in terms I understand? In F#, the default method of asynchronous programming is the async computation expression. That is, there is a type Async<'T> which represents a computation that can be executed to return a result of type 'T. The computation itself is "lazy" in the sense that it isn't hot at the time of creation, and can be executed multiple times to produce a result. This is in contrast to the C# way of doing things, in which a function has a return type of Task<'T> which is (under normal circumstances) kicked off at time of creation and can only be run a single time. Is this proposal advocating for the more F#-y way of doing things, or the more C#-y way of doing things?
- kllrnohj 9y ago
  C# has what you've described as well in the form of yield return. It's largely the same thing to the compiler in that it needs to transform a method into a stack-less state machine. Whether or not the state machine is evaluated lazily on demand or concurrently is mostly irrelevant and just depends on the specific problem in question.
bkeroack 9y ago
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... Coroutines with "color" are problematic.
- steveklabnik 9y ago
  Sometimes, problems are inherent. Especially in a systems language.
- dbrgn 9y ago
  There are already "Result" colored and "Future" colored functions right now. Async/await just adds syntactical sugar.
- laurencerowe 9y ago
  Implicit coroutines are also problematic: https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html. As applied to Go: https://blog.mozilla.org/services/2014/03/12/sane-concurrency-with-go/ https://blog.mozilla.org/services/2014/03/12/sane-concurrenc...
pc2g4d 9y ago
Looks exciting. I'm interested in how this might relate to the following use of generators from Python: def gen(*items): for x in items: if x > 5: yield x for y in gen(1,2,3,4,5,6,7,8,9): print(y) Should print: 6 7 8 9 Does this new RFC support that kind of usage? I guess I'm not clear enough on how Futures work to figure it out myself.
- ekimekim 9y ago
  Part of the RFC is the intent to use these to create iterators, so yes I believe that kind of usage would be covered.
first_amendment 9y ago
async/await is nice duct tape to integrate cooperative concurrency into a thread-based concurrency model but it has the drawback of creating an incompatible sub-language for functions within the parent language. Now every time you call a function, you have to check if it is a "coroutine"/ returns a promise or if it's a synchronous function. This divides the language ecosystem and makes it hard for library writers to support both concurrency models. Ask anyone who has done significant async/await coding in C#/Python. It gets messy fast. Async/Await works a little better in JS because it always has had a cooperative concurrency model, standard library functions usually don't block (except sometimes in Node). Though it's still annoying to have to check whether a function returns a promise or not. Languages that do this right are Haskell and Go and probably Elixer/Erlang. This usually requires eschewing LibC (which usually assumes a threaded concurrency model) and writing your own runtime.
- steveklabnik 9y ago
  Yes, this is all discussed in the eRFC (which admittedly isn't what is linked here, but is the first link in the description, https://github.com/rust-lang/rfcs/pull/2033 https://github.com/rust-lang/rfcs/pull/2033) and various threads on internals before it. > writing your own runtime. This is not a cost that Rust can bear, and so that option is just not possible. Unfortunately, there's no such thing as a free lunch.
  - first_amendment 9y ago
    I wonder if Rust could support pluggable concurrency models (with the accompanying runtime support). That's what Haskell does and it seems to work. At the outset that seems like a better approach than creating an incompatible sub-language. The rust-facing side of the standard library already abstracts away many platform details.
    - steveklabnik 9y ago
      Trying this was in fact one of the reasons that Rust ditched its runtime years ago; it doesn't work. Well, it didn't work for Rust at least. The RFC that made this change https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

111 points by adelarsq 9y ago

This is experimental so far: https://github.com/rust-lang/rfcs/pull/2033#issuecomment-309057591 https://github.com/rust-lang/rfcs/pull/2033#issuecomment-309... > The key point then is that the experimental RFC is not enough to stabilize something. For that, we need a proper RFC that lays out the plan. This RFC can be informed by the experience and working implementation, so we should have a lot of data to use. It's being merged into nightly (behind a flag) to gain understanding of how the feature would work. This isn't the day to celebrate Rust having fully-fledged co-routines coming soon to stable because there is no such guarantee yet. Edit: removed extra word

steveklabnik 9y ago
This is the first "experimental RFC", so that's also kind of fun.

pitaj 9y ago

Relevant RFC: https://github.com/rust-lang/rfcs/blob/master/text/2033-experimental-coroutines.md https://github.com/rust-lang/rfcs/blob/master/text/2033-expe... This looks like a huge win for Rust. The syntax seems to follow the C# and ES async/await syntaxes. With stuff like this, I can see Rust-based webdev becoming popular.

jimktrains2 9y ago
http://www.arewewebyet.org/ http://www.arewewebyet.org/ On a serious note, one of my middling priorities (unfortunately :( It always feels like you can't choose most your high priorities) is to build a rust-based website and a couple of other rust-based projects t get a feel for the language. It really dose feel like all the parts are there already and that as things get added, it'll just get easier and better.
- foota 9y ago
  Maybe try to find ways to bring rust into the middle of your higher priorities?
  - reificator 9y ago
    I'm in the same boat as the GP, in that I want to use Rust for a lot of things that I think it would be good at, but I don't get to choose my high priority tasks. And for me at least, my high priority tasks are not the tasks that benefit from Rust over other languages. I could introduce it for the sake of my resume, or I could use the right tool. The former seems unprofessional and unproductive outside of jumping ship and leaving your co-workers with extra baggage.
  - jimktrains2 9y ago
    High priorities being family, house repairs, house maintenance, and work. Nothing extraordinary, and I guess one could argue house upkeep is chosen. I also have some personal programming projects I've been working on where I decided to value getting them out quickly vs learning a new language, and those are, all together, half done. I've also been debating learning modern C++ to open potentially open some doors to a slightly different career than web programming (railway signalling, probably a pipedream at this point, but). So, all in all, I love what rust represents, but it doesn't bring value right now. Once those personal projects wrap up my goal is to have a round of rust and C++ ones to do.
- steveklabnik 9y ago
  That site is a bit out of date; I should send some PRs. "You can build stuff" is still a good summary, but lots of stuff has happened since this was last updated.

simonw 9y ago

Here's a rendered version of the documentation added in that commit: https://github.com/Zoxc/rust/blob/a996d5eec70ba6733e23f2e56e762f58e60bb4ff/src/doc/unstable-book/src/language-features/generators.md https://github.com/Zoxc/rust/blob/a996d5eec70ba6733e23f2e56e...

steveklabnik 9y ago
This will be located at https://doc.rust-lang.org/nightly/unstable-book/language-features/generators.html https://doc.rust-lang.org/nightly/unstable-book/language-fea... after the next nightly comes out in ~4 hours (I believe).

siscia 9y ago

Am I the only one who prefer epoll style concurrency than coroutines? Are coroutines more somehow more powerful?

squiguy7 9y ago
You will probably be interested in mio [1] then. [1]: https://github.com/carllerche/mio https://github.com/carllerche/mio
stormbrew 9y ago
They're orthogonal? Coroutines as built here are just sugar around building the state machines you necessarily build by hand if you're using something like epoll. They can also be used to model state machines in general, so long as there's a well defined progression of states in one direction. You would use these coroutines with tokio or mio, which are event driven frameworks that use epoll at their core on Linux.

Nelkins 9y ago

Trying to wrap my head around this...as someone coming from .NET land, maybe someone can explain it in terms I understand? In F#, the default method of asynchronous programming is the async computation expression. That is, there is a type Async<'T> which represents a computation that can be executed to return a result of type 'T. The computation itself is "lazy" in the sense that it isn't hot at the time of creation, and can be executed multiple times to produce a result. This is in contrast to the C# way of doing things, in which a function has a return type of Task<'T> which is (under normal circumstances) kicked off at time of creation and can only be run a single time. Is this proposal advocating for the more F#-y way of doing things, or the more C#-y way of doing things?

kllrnohj 9y ago
C# has what you've described as well in the form of yield return. It's largely the same thing to the compiler in that it needs to transform a method into a stack-less state machine. Whether or not the state machine is evaluated lazily on demand or concurrently is mostly irrelevant and just depends on the specific problem in question.

bkeroack 9y ago

http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... Coroutines with "color" are problematic.

steveklabnik 9y ago
Sometimes, problems are inherent. Especially in a systems language.
dbrgn 9y ago
There are already "Result" colored and "Future" colored functions right now. Async/await just adds syntactical sugar.
laurencerowe 9y ago
Implicit coroutines are also problematic: https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html. As applied to Go: https://blog.mozilla.org/services/2014/03/12/sane-concurrency-with-go/ https://blog.mozilla.org/services/2014/03/12/sane-concurrenc...

pc2g4d 9y ago

Looks exciting. I'm interested in how this might relate to the following use of generators from Python: def gen(*items): for x in items: if x > 5: yield x for y in gen(1,2,3,4,5,6,7,8,9): print(y) Should print: 6 7 8 9 Does this new RFC support that kind of usage? I guess I'm not clear enough on how Futures work to figure it out myself.

ekimekim 9y ago
Part of the RFC is the intent to use these to create iterators, so yes I believe that kind of usage would be covered.

first_amendment 9y ago

async/await is nice duct tape to integrate cooperative concurrency into a thread-based concurrency model but it has the drawback of creating an incompatible sub-language for functions within the parent language. Now every time you call a function, you have to check if it is a "coroutine"/ returns a promise or if it's a synchronous function. This divides the language ecosystem and makes it hard for library writers to support both concurrency models. Ask anyone who has done significant async/await coding in C#/Python. It gets messy fast. Async/Await works a little better in JS because it always has had a cooperative concurrency model, standard library functions usually don't block (except sometimes in Node). Though it's still annoying to have to check whether a function returns a promise or not. Languages that do this right are Haskell and Go and probably Elixer/Erlang. This usually requires eschewing LibC (which usually assumes a threaded concurrency model) and writing your own runtime.

steveklabnik 9y ago
Yes, this is all discussed in the eRFC (which admittedly isn't what is linked here, but is the first link in the description, https://github.com/rust-lang/rfcs/pull/2033 https://github.com/rust-lang/rfcs/pull/2033) and various threads on internals before it. > writing your own runtime. This is not a cost that Rust can bear, and so that option is just not possible. Unfortunately, there's no such thing as a free lunch.
- first_amendment 9y ago
  I wonder if Rust could support pluggable concurrency models (with the accompanying runtime support). That's what Haskell does and it seems to work. At the outset that seems like a better approach than creating an incompatible sub-language. The rust-facing side of the standard library already abstracts away many platform details.
  - steveklabnik 9y ago
    Trying this was in fact one of the reasons that Rust ditched its runtime years ago; it doesn't work. Well, it didn't work for Rust at least. The RFC that made this change https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...