With antithesis that’s all guaranteed of course since you’re running on a VM and the abstraction is a lot lower level.
I'm using DST in a personal project. My biggest issue is that significant parts of the ecosystem either require or prefer your runtime to be tokio. To deal with that, I re-implemented most of tokio's API on top of my DST runtime. Running my DST tests involves patching dependencies which can get messy.
In development, you import Loom's mutex. In production, you import a regular mutex. This of course has zero overhead, but the simulation testing itself is usually quite slow. Only one thread can execute at a time, and many iterations are required.
The article is about organizing a distributed/multithreaded system for deterministic execution and fault injection. It's like refactoring a codebase for unit testing. It shouldn't slow anything down and even if it does, the overhead should be laughably small.
droideqa•6mo ago
[0]: https://www.warpstream.com/blog/deterministic-simulation-tes...