# Deep dive notes: futures-concurrency Links to documents: * Presentation https://docs.google.com/presentation/d/1Gycr7ztat4aXEn0f5oxWtatrOhvvGSCiQl-qymRhMrE/edit * API docs https://docs.rs/futures-concurrency/latest/futures_concurrency/ ###### tags: `deep-dive` Leave questions, observations, discussion topics below. --- ## Topic name: prompt --- eholk: Does it make more sense to most futures-concurrency under rust-lang, or just piece-wise migrate all of it into std and skip the rust-lang step? yosh: We could do that, valid option. Skip it if it's controversial. Might be useful because e.g. AsyncIterator is not ready to stabilize. But people are using async now, with Stream. --- tmandry: Anyone using it? yosh: Microsoft, phil-opp, a few. --- tmandry: What have you not included? yosh: Focused on bounded concurrency: tuples, arrays. Lots of work to be done on dynamic concurrency. Might be in scope, but want to narrow it down. The join RFC will be further narrowed down to just that. --- (continued from above question) yosh: Parallelism. [`tasky`](https://docs.rs/tasky) investigates this more. * Stops thinking of a task an async version of a thread, but as a parallelizable version of a Future. * Doesn't start until you await it. * This gives you a handle that propagates errors and cancellation. tmandry: Also adopted a Task handle API by default on fuchsia executor, with a `.detach()` escape hatch. eholk: Unix processes work the same way. yosh: What about zombie processes? yosh: I suspect we can use new patterns to avoid needing `.detach()` --- tmandry: Why not `.join()`? :) yosh: `[]::join` already exists -_-. Just use IntoFuture? eholk: `.await_all`? yosh: Swift's `async let` is really interesting. You can be binding multiple things at once. ``` async let a = b() async let c = d() // b, d can run concurrently at this point ``` Infers the await graph for you! ---