# ~~Reading~~ Watching notes: Trio: Async concurrency for mere mortals

Link to document: https://www.youtube.com/watch?v=oLkfnc_UMcE

###### tags: `reading-club`

Leave questions, observations, discussion topics below.

---

## Topic

name: prompt

---

### Does trio expose more concurrency operators now?

Happy eye-balls seems to implement "try race" / "race ok" semantics, implemented by for example [`futures_concurrency::future::RaceOk`](https://docs.rs/futures-concurrency/latest/futures_concurrency/future/trait.RaceOk.html) in Rust or in JS [`Promise.any`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/any). The `trio` talk is from 2018, has trio gained more vocabulary to express concurrency control flow?

Nathaniel: It turns out that you can write anything with this, so we stick with that and let other people write utilities on top if they want.

This makes it possible to say "I'm going to teach you all of concurrency in 20 minutes"! A good way to design an API is to start by going to write the docs for it.

Simple implementation of happy eyeballs in a talk is a success

Rust is struggling with this... "first we have to tell you about Pin!"

### Nathaniel's ideas and suggestions on async Rust

Impressed by the current state of async Rust; has advantages over other approaches.

Can go really far with this approach until you hit problems, but then maybe you have "more to unwind".

Rust took kind of a hill-climbing approach (maybe the only approach)... started with Futures, which was a nice model but not good enough, but then we add more features and complexity to the language itself to accommodate.

A lot of complexity comes from directly exposing future objects to the user.
* Combinators, have to document those
* Dropping a future cancels it - can't have run-to-completion semantics or cooperative cancellation

Trio/Python uses a very similar model actually.. an async function returns a coroutine object, Python has Awaitable objects... but we don't mention it at all because we can get away with that. (Except magic `trio.run()` at the top)

Can't change async/await but

#### Strawman proposal

Fiber functions - don't have to use `await`, you don't get to see future objects
* Or you have to write an `await` and it's an error not to

Need to be able to pass one of these to the nursery start function. Adapter that takes one of them and implements the `Future` trait.

---

Yosh: Is it accurate to say that Trio async functions start eagerly?

njs: In Python, if you want to make things that don't start eagerly you make a data structure that contains callables

---

https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/undroppable.20async.20fns

fiber fn = async fn, BUT no .await when calling another fiber fn
new intrinsics: fiber fn suspend() -> causes poll to return
to_future(FiberFnOnce() -> T) -> Future<T>

fiber fn with_cancel_scope(FiberFnOnce(cancel_scope) -> T) -> T

"Cancellation should be ambient (no special token) and delimited", described in a blog post – https://vorpus.org/blog/timeouts-and-cancellation-for-humans/

With an exception-based approach it can be unclear when you should stop propagating the cancellation. If you call `cancel` on a task which triggers an exception, how do you know where to stop propagating the exception? both cancel scopes (trio) and drop-based cancellation (rust) have this property