Regardless of the algorithm, antithesis specifically can make sure your implementation is correct. You started this thread by claiming that that’s needed less in Rust because the type system helps you avoid bugs. I’m highlighting classes of problems that Antithesis is targeting to help you test and Rust’s type system cannot help you with. Raft vs Paxos doesn’t matter
1. many things antithesis finds in go, kotling, cpp just do not exist in rust. that i less needed case. these people like antithesis.
2. i mentioned tooling, also in other thread i mentioned ecosystem
- https://github.com/BurtonQin/Awesome-Rust-Checker
- add link for dozen of tools for cfg feature(product lines) eng here (compile time conditional composeability) and const expressions
- add link to dozen of tools to audit deps and decide on panic safety and first class crash hooks crates
- mix with nix which many (way many compared to go, kotlin, cpp) rust projects use (and sri cargo.lock out box)
- and qemu/mozilla/no rr tools (no determinism to get seed, and run slower hosts things w that seed)
- and add here clusterfuzz eco (supports all oss fuzzers, and these do proper search https://camshaft.github.io/bolero/features/unified-interface..., and rust adapters allow for manual macro based fuzz narrowing in rust)
- https://quint-lang.org/docs/model-checkers
- several ongoing projects formalizing rust std and lang
SO, why i need antithesis?
To get Raft, will do sans-io with full typed rust covered by proofs for state(machine) and macro generator for glue(from state machine).
I need only prop/fuzz test to test small integration sans-io part. I do not need antithesis.
check this https://news.ycombinator.com/item?id=45264789 , antitesis feels like set of bash scripts thb