3 ms·

Rust does not require you to know how async works under the hood. Javascript async doing things automatically has been infinitely more confusing for me, frankl

Rust does not require you to know how async works under the hood. Javascript async doing things automatically has been infinitely more confusing for me, frankly. Async rust isn't hard, rust isn't hard - not for a lot of people at least. I don't know what gritty details you're referring to, you need to know the same rules you always know - move semantics, some concept of lifetimes maybe. Move of the time it's "add a `move` and clone before the async block".

thinkharderdev 4y ago
In general I agree that the difficulty and need to know the "gritty details" is overstated, but there is one aspect where that is true and I have found it confusing at times. Since it has to capture anything in scope of an await point, you will sometimes get somewhat non-obvious compiler errors about how "X is not Send" when it's not really obvious at all why it would need to be. So something like ``` let locked = std::sync::RwLock<Foo> = ...; let lock = locked.write().unwrap(); bar.doSomethingAsync().await ``` will complain because `std::sync::RwLockWriteGuard` is not send. Just looking at the code it is not really clear why it should need to be. To understand why, you need to understand how the compiler transforms this code into a state machine and capture everything in scope of an await point in Struct that must be send (since it can shift to new thread when resuming). It makes sense when you understand what's happening under the hood but can be a bit baffling when you are starting out.
- justinpombrio 4y ago
  That is tricky. It's also something you need to know when working with closures in Rust, which are for the same reason much harder to work with and understand than closures in other languages. I wonder whether it would have been better design for Rust closures to require an explicit capture list, like in C++, just to be more explicit about what is happening. (Not sure if/how that would translate to `await`.)
  - thinkharderdev 4y ago
    Yeah, I've been stung more than once by the `Fn/FnOnce` distinction
Groxx 4y ago
Fine-grained logic in async JavaScript can be a very special kind of pain. It's a rather specialized event loop, but the vast majority of articles treat it like "oh it's just a normal in-order event loop like every other". It ain't. Unless your logic has no order requirements between async components, or explicitly accounts for things like "microtasks", there's a chance it's wrong... and it depends on your runtime: https://bytefish.medium.com/the-execution-order-of-asynchronous-functions-in-the-event-loop-ff641dae4f09 https://bytefish.medium.com/the-execution-order-of-asynchron... (it's generally better to not depend on execution order in async systems anyway, but it's rather easy for it to sneak in sometimes. if it does, it may work on your machine but not on mine, or it might change based on what kinds of tasks other code spawns, if you press a button at a critical moment, etc)

thinkharderdev 4y ago

In general I agree that the difficulty and need to know the "gritty details" is overstated, but there is one aspect where that is true and I have found it confusing at times. Since it has to capture anything in scope of an await point, you will sometimes get somewhat non-obvious compiler errors about how "X is not Send" when it's not really obvious at all why it would need to be. So something like ``` let locked = std::sync::RwLock<Foo> = ...; let lock = locked.write().unwrap(); bar.doSomethingAsync().await ``` will complain because `std::sync::RwLockWriteGuard` is not send. Just looking at the code it is not really clear why it should need to be. To understand why, you need to understand how the compiler transforms this code into a state machine and capture everything in scope of an await point in Struct that must be send (since it can shift to new thread when resuming). It makes sense when you understand what's happening under the hood but can be a bit baffling when you are starting out.

justinpombrio 4y ago
That is tricky. It's also something you need to know when working with closures in Rust, which are for the same reason much harder to work with and understand than closures in other languages. I wonder whether it would have been better design for Rust closures to require an explicit capture list, like in C++, just to be more explicit about what is happening. (Not sure if/how that would translate to `await`.)
- thinkharderdev 4y ago
  Yeah, I've been stung more than once by the `Fn/FnOnce` distinction

Groxx 4y ago

Fine-grained logic in async JavaScript can be a very special kind of pain. It's a rather specialized event loop, but the vast majority of articles treat it like "oh it's just a normal in-order event loop like every other". It ain't. Unless your logic has no order requirements between async components, or explicitly accounts for things like "microtasks", there's a chance it's wrong... and it depends on your runtime: https://bytefish.medium.com/the-execution-order-of-asynchronous-functions-in-the-event-loop-ff641dae4f09 https://bytefish.medium.com/the-execution-order-of-asynchron... (it's generally better to not depend on execution order in async systems anyway, but it's rather easy for it to sneak in sometimes. if it does, it may work on your machine but not on mine, or it might change based on what kinds of tasks other code spawns, if you press a button at a critical moment, etc)