fixup! status-quo story: Alan needs async in traits

Author: zeenix

src/vision/status_quo/alan_needs_async_in_traits.md

@@ -10,15 +10,15 @@ If you would like to expand on this story, or adjust the answers to the FAQ, fee
 
 Alan is working on a project with Barbara which has already gotten off to a [somewhat rocky start](./barbara_anguishes_over_http.md). He is working on abstracting away the HTTP implementation the library uses so that users can provide their own. He wants the user to implement an async trait called `HttpClient` which has one method `perform(request: Request) -> Response`. Alan tries to create the async trait:
 
-```rust,ignore
+```rust
 trait HttpClient {
     async fn perform(request: Request) -> Response;
 }
 ```
 
 When Alan tries to compile this, he gets an error:
 
-```ignore
+```
  --> src/lib.rs:2:5
   |
 2 |     async fn perform(request: Request) -> Response;
@@ -31,27 +31,30 @@ When Alan tries to compile this, he gets an error:
 ```
 
 Alan, who has been using Rust for a little while now, has learned to follow compiler error messages and adds `async-trait` to his `Cargo.toml`. Alan follows the README of `async-trait` and comes up with the following code:
-'''rust
+
+```rust
 #[async_trait]
 trait HttpClient {
     async fn perform(request: Request) -> Response;
 }
-'''
+```
+
 Alan's code now compiles, but he also finds that his compile times have gone from under a second to around 6s, at least for a clean build.
 
-**TODO::** Maybe add representive pre and post trait compile times here.
+After Alan finishes adding the new trait, he shows his work off to Barbara and mentions he's happy with the work but is a little sad that compile times have worsened. Barbara, an experienced Rust developer, knows that using `async-trait` comes with some additional issues. In this particular case she is especially worried about tying their public API to a third-party dependency. Even though it is technically possible to implement traits annotated with `async_trait` without using `async_trait`, doing so in practice is very painful. For example `async_trait`:
+
+* handles lifetimes for you if the returned future is tied to the lifetime of some inputs.
+* boxes and pins the futures for you.
 
-After Alan finishes adding the new trait, he shows his work off to Barbara and mentions he's happy with the work but is a little sad that compile times have worsened. Barbara, an experienced Rust developer, knows that using `async-trait` comes with some issues and in this case is especially worried about tying their public API to a third-party dependency. She decides to not worry Alan with this right now. Alan and Barbara are pretty happy with the results and go on to publish their crate which gets lots of users.
+which implementer will have to manually handle if they don't use `async_trait`. She decides to not worry Alan with this right now. Alan and Barbara are pretty happy with the results and go on to publish their crate which gets lots of users.
 
 Later on, a potential user of the library wants to use their library in a `no_std` context where they will be providing a custom HTTP stack. Alan and Barbara have done a pretty good job of limiting the use of standard library features and think it might be possible to support this use case. However, they quickly run into a show stopper: `async-trait` boxes all of the futures returned from a async trait function. They report this to Alan through an issue.
 
 Alan, feeling (over-) confident in his Rust skills, decides to try to see if he can implement async traits without using `async-trait`. 
 
 ```rust 
-struct Request(String);
-
 trait HttpClient {
-   type Response: Future<Output = ()>;
+   type Response: Future<Output = Response>;
 
    fn perform(request: Request) -> Self::Response; 
 }
@@ -61,15 +64,15 @@ Alan seems to have something working, but when he goes to update the examples of
 
 * use trait object:
 
-  ```rust,ignore
+  ```rust
   struct ClientImpl;
 
   impl HttpClient for ClientImpl {
-      type Response = Pin<Box<dyn Future<Output = ()>>>;
+      type Response = Pin<Box<dyn Future<Output = Response>>>;
 
       fn perform(request: Request) -> Self::Response {
           Box::pin(async move {
-              println!("{}", request.0);
+              // Some async work here creating Reponse
           })
 	  }
   }
@@ -79,7 +82,7 @@ Alan seems to have something working, but when he goes to update the examples of
 
 * implement `Future` trait manually, which isn't particulary easy/straight-forward for non-trivial cases, especially if it involves making other async calls (likely).
 
-**TODO::** Would make sense for Alan to reach out to Barbara at this point and she should be able to give some good advice.
+After a lot of thinking and discussion, Alan and Barbara accept that they won't be able to support `no_std` users of their library and add mention of this in crate documentation.
 
 ## 🤔 Frequently Asked Questions
 
@@ -88,7 +91,6 @@ Alan seems to have something working, but when he goes to update the examples of
 * `async-trait` is awesome, but has some drawbacks
     * compile time increases
     * performance cost of boxing and dynamic dispatch
-    * lack of control over whether futures are `Send` or `Sync`
     * not a standard solution so when this comes to language, it might break things
 * Trying to have a more efficient implementation than `async-trait` is likely not possible. 
 
@@ -97,7 +99,7 @@ Alan seems to have something working, but when he goes to update the examples of
 * [Zeeshan](https://github.com/zeenix/) is looking for a way to implement async version of the [service-side zbus API](https://docs.rs/zbus/1.9.1/zbus/trait.Interface.html).
 * [Ryan](https://github.com/rylev) had to use `async-trait` in an internal project.
 
-## **Why did you choose Alan to tell this story?**
+### **Why did you choose Alan to tell this story?**
 
 We could have used Barbara here but she'd probably know some of the work-arounds (likely even the details on why they're needed) and wouldn't need help so it wouldn't make for a good story. Having said that, Barbara is involved in the story still so it's not a pure Alan story.