←back to thread

Unexpected productivity boost of Rust

(lubeno.dev)
517 points bkolobara | 1 comments | 27 Aug 25 15:48 UTC | HN request time: 0.289s | source
Show context
Spivak ◴[27 Aug 25 16:26 UTC] No.45041771[source]▶
How do you encode the locking issue in the type system, it seems magical? Can you just never hold any locks when calling await, is it smart enough to know that this scheduler might move work between threads?
replies(5): >>45041806 #>>45041833 #>>45041852 #>>45041891 #>>45041898 #
jvanderbot ◴[27 Aug 25 16:28 UTC] No.45041806[source]▶
Yes Rust has ways of verifying single access to locks through the borrow checker and lifetimes.
replies(1): >>45041860 #
Spivak ◴[27 Aug 25 16:33 UTC] No.45041860[source]▶
Well yes but this seems more complicated. If the code was executed on a single thread it would be correct. The compiler somehow knows that await might move the work to another thread in which the code would still be correct if it weren't for the pesky undefined behavior. At all points it seems like it would be single access and yet it catches this.
replies(3): >>45042126 #>>45042240 #>>45042247 #
1. ViewTrick1002 ◴[27 Aug 25 17:05 UTC] No.45042240[source]▶
That comes from the where the tokio task is spawned annotating the future with send.

https://docs.rs/tokio/latest/tokio/task/fn.spawn.html

If you want to run everything on the same thread then localset enables that. See how the spawn function does not include the send bound.

https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html