Unexpected productivity boost of Rust

Regarding the ~80k errors. Yeah, nothing to do here besides slowly grinding away and adding type annotations and fixes until it's resolved.

For the code example pyright gives some hint towards variance but yes it can be confusing.

https://pyright-play.net/?pyrightVersion=1.1.403&code=GYJw9g...

Love this.

It's not true you can't build reliable software in python. People have. There's proof of it everywhere. Tons of examples of reliable software written in python which is not the safest language.

I think the real thing here is more of a skill issue. You don't know how to build reliable software in a language that doesn't have full type coverage. That's just your lack of ability.

I'm not trying to be insulting here. Just stating the logic:

   A. You claim python can't build reliable software.
   B. Reliable Software for python actually exists, therefore your claim is incorrect
   C. You therefore must not have experience with building any software with python and must have your hand held and be baby-sitted by rusts type checker.

In Rust lifetimes for references are part of the type, so &'a str and &'b str could be different types, even though they're both string slice references.

Beyond that, Rust tracks two important "thread safety" properties called Sync and Send, and so if your Thing ends up needing to be Send (because another thread gets given this type) but it's not Send, that's a type error just as surely as if it lacked some other needed property needed for whatever you do with the Thing, like it's not totally ordered (Ord) or it can't be turned into an iterator (IntoIterator)

- The return type of Mutex::lock() is a MutexGuard, which is a smart pointer type that 1) implements Deref so it can be dereferenced to access the underlying data, 2) implements Drop to unlock the mutex when the guard goes out of scope, and 3) implements !Send so the compiler knows it is unsafe to send between threads: https://doc.rust-lang.org/std/sync/struct.MutexGuard.html

- Rust's implementation of async/await works by transforming an async function into a state machine object implementing the Future trait. The compiler generates an enum that stores the current state of the state machine and all the local variables that need to live across yield points, with a poll function that (synchronously) advances the coroutine to the next yield point: https://doc.rust-lang.org/std/future/trait.Future.html

- In Rust, a composite type like a struct or enum automatically implements Send if all of its members implement Send.

- An async runtime that can move tasks between threads requires task futures to implement Send.

So, in the example here: because the author held a lock across an await point, the compiler must store the MutexGuard smart pointer as a field of the Future state machine object. Since MutexGuard is !Send, the future also is !Send, which means it cannot be used with an async runtime that moves tasks between threads.

If the author releases the lock (i.e. drops the lock guard) before awaiting, then the guard does not live across yield points and thus does not need to be persisted as part of the state machine object -- it will be created and destroyed entirely within the span of one call to Future::poll(). Thus, the future object can be Send, meaning the task can be migrated between 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.

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