-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
status quo: Alan started trusting the Rust compiler #70
Conversation
Created a new status quo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this story! I'm really happy somebody tried to write about this part of the experience. I left a bunch of suggestions. I think my main theme here is that I think it would be great if we can make the story more specific and detailed. I realize you were trying to be generic but I think the story will read better and have more impact if it's actually telling us precisely what Alan did and how it impacted him -- like, he comes from Go, he used async-std, the library he tried to add was foo and it required tokio, etc. We can use the FAQ to indicate what it might look like if he came from JS instead, say.
src/vision/status_quo/alan_started_trusting_the_rust_compiler.md
Outdated
Show resolved
Hide resolved
src/vision/status_quo/alan_started_trusting_the_rust_compiler.md
Outdated
Show resolved
Hide resolved
src/vision/status_quo/alan_started_trusting_the_rust_compiler.md
Outdated
Show resolved
Hide resolved
src/vision/status_quo/alan_started_trusting_the_rust_compiler.md
Outdated
Show resolved
Hide resolved
src/vision/status_quo/alan_started_trusting_the_rust_compiler.md
Outdated
Show resolved
Hide resolved
src/vision/status_quo/alan_started_trusting_the_rust_compiler.md
Outdated
Show resolved
Hide resolved
src/vision/status_quo/alan_started_trusting_the_rust_compiler.md
Outdated
Show resolved
Hide resolved
He runs his project but is suddenly greeted with a runtime error? How is this even possible? His project doesn't contain any out-of-bounds accesses, he never uses `.unwrap` or `.expect`? | ||
At the top of the error message he sees: `This async thing needs to run in the context of this other async library, and not the one you are using.` | ||
|
||
Coming from a "simpler" async country, he now learns about Executors, Wakers, `Pin`,... Things he had not need to heed in _GC'd language_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does he learn about those things? I guess he is reading some docs? What docs is he reading and how did he find them?
Also, it's interesting that Pin
is in this list, because it's not really relevant to the problem. This isn't to say it shouldn't be there, I think the moral to call out is that just from this one little error, Alan started to get a firehose of information that is kind of overwhelming and he doesn't know which bits are relevant and which are not.
I realize this also sounds pretty similar to #48 -- maybe we can reference the story -- e.g. to say "if you'd like to learn more about the confusion from that, well, that's another story" and link to it.
|
||
But now he realizes that there is a whole new area of runtime problems that he did not have to deal with in _GC'd language_, but he does in Rust. | ||
Can he even trust the Rust compiler anymore? What other kinds of runtime problems can occur in Rust that can't in _GC'd language_? | ||
If his projects keep increasing in complexity, will other new kinds of runtime problems keep popping up? Maybe it's better to stick with _GC'd language_, since Alan |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/vision/status_quo/alan_started_trusting_the_rust_compiler.md
Outdated
Show resolved
Hide resolved
I feel a lot like Alan. An annoying situation which is happening to me in async Rust is having to handle dependencies which needs different versions of the same runtime (tokio's transition to 1.0). I feel like "doing cargo's work" when I have to find the right combination of features and versions on my dependencies just to be able to run my code without panics. |
@eduardocanellas Hmm, that's interesting, and it'd be helpful to have a story about that. It feels a bit like a distinct story from this one, I think? I will open an issue based on your comment, I think. EDIT: Opened #79 |
Checking in: @MidasLamb, how are you feeling about the various suggestions here? Do you think you'll have time to do some revisions to the story? :) |
@nikomatsakis I've briefly scanned through them and it's very good feedback. I'm trying to find the time to sit down and read them thoroughly and incorporate it, but I'm struggling with finding that spare time atm. Hopefully somewhere the coming days or at least the coming weekend! |
Great, no rush. Thanks! |
@@ -0,0 +1,104 @@ | |||
# 😱 Status quo stories: Alan started trusting the Rust compiler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This title made me think this story would be a happy one with Alan reaching a point where he trusts the compiler. In fact, the opposite is true.
Perhaps another title would be more descriptive: "Multiple Async Runtimes Erode Alan's Trust in the Rust Compiler"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand what you mean, but I think that your suggestion misses the build up of trust that I personally went through.
What do you think about:
- "Alan started trusting the Rust compiler, but then he encountered async"
or - "Alan started trusting the Rust compiler, but then... async"
I think that that captures the build up as well as already showing that this isn't going to be a story with a happy ending
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like those
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd run with the second one, myself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remember the story isn't over, this is just where async is now. Alan trusts there will a shiny future where async programming is as gotcha free as it can be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just read the latest draft -- the code examples really help bring the story to life, thank you! The only thing I think this needs before merging is to tweak the FAQs. Thanks @MidasLamb!
This somewhat addresses issue #47 |
Also added an extra section on the positive effects that trying to get into async Rust had on Alan.
Merge upstream
@rylev, I think the angle of approach is different. I think it boils down to:
Does this make sense? I'm not quite sure how to articulate it well what I'm trying to get across |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice :)
src/vision/status_quo/alan_started_trusting_the_rust_compiler_but_then_async.md
Outdated
Show resolved
Hide resolved
…but_then_async.md Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks ready to merge to me -- I left one nit or two.
src/vision/status_quo/alan_started_trusting_the_rust_compiler_but_then_async.md
Outdated
Show resolved
Hide resolved
He runs his project but is suddenly greeted with a runtime error? How is this even possible? His project doesn't contain any out-of-bounds accesses, he never uses `.unwrap` or `.expect`? | ||
At the top of the error message he sees: `thread 'main' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime'` | ||
|
||
He searches what "Tokio" is in Rust, and he finds that it also provides an attribute to put on `main`, namely `[tokio::main]`, but what is the difference with `[async_std::main]`? His curiosity leads him to watch videos/read blogs/scour reddit,... on why there are multiple runtimes in Rust. This leads him into a rabbit hole and now he learns about Executors, Wakers, `Pin`,... He has a basic grasp of what they are, but does not have a good understanding of them or how they all fit together exactly. These are all things he had not need to know nor heed in C#. (Note: there is another story about troubles/confusion that might arise when learning all these things about async: [Alan hates writing a `Stream`](./alan_hates_writing_a_stream.md)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<3 the cross ref
…but_then_async.md Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
Thanks @MidasLamb, this is great! |
No problem! I'm just happy to help! 😄 |
Rendered