←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.208s | 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. veber-alex ◴[27 Aug 25 17:06 UTC] No.45042247[source]▶
The compiler doesn't know anything about threads.

The compiler knows the Future doesn't implement the Send trait because MutexGuard is not Send and it crosses await points.

Then, tokio the aysnc runtime requires that futures that it runs are Send because it can move them to another thread.

This is how Rust safety works. The internals of std, tokio and other low level libraries are unsafe but they expose interfaces that are impossible to misuse.