Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree on generator<->async conversion.

I'm not an expert but I can't shake the thought that Rust had it backward with async and generator. Generator looks like a good bridge between sync and async. Before reading about implementing async executor and digging under what tokio and async-std is doing (it's been months and I haven't finished), I thought implementing async executor is just as easy as running looping a generator.resume() until it yields GeneratorState::Complete until I realize generator is still on nightly!

It may be because I'm a noob in Rust, but I can't write easily:

``` let some_handle_arc = Arc::new(some_handle); future::block_on([ // this future will stop running midway if some_handle is modified in some way make_future(some_handle_arc),

  // make_future_stopper will modify some_handle_arc when receiving
  // a certain input from a certain interface
  make_future_stopper(some_handle_arc)
]); ```

My initial intuition is if async is generator-based, there should be an escape hatch where the generator-runner just exit, drop the generator, without waiting for the generator to yield Generator::Complete. But again it might be from my noobness being a simple Rust hobbyist.

Sorry for the rant



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: