The feature just makes it run identically to the last run. It's useful for reproducing bugs; if you encounter a bug, just start the program in "replay" mode, supply the recording from the last run, and fire up the debugger, and watch as the bug is reproduced perfectly.
It's kind of like a time-traveling debugger, but with stronger guarantees.
I'm particularly excited about combining this with concurrency, we'll never have to spend hours hunting down mysterious race conditions ever again!
1. Don't allow any undefined behavior or `unsafe` code in the language.
2. Record all inputs from FFI.
3. Carefully track the orderings of interactions across threads.
The article goes into the first two, but the third one is the most interesting IMO:
When we unlock a mutex or send a message, we assign a "sequence number" (similar to what we see in TCP packets).
Whenever we lock a mutex or receive a message, we read the sequence number and record it to this thread's "recording".
When replaying, we use that sequence number and that file to make sure we're reading in the same order as the previous execution.