You may want to avoid the “big ball of mud” enum error antipattern if the different errors need to be handled in different ways. This post goes into a lot more detail, but the main point is that you give up the benefits of exhaustive pattern matching and increase the chances of mishandling errors when mixed concerns go into a single enum. This doesn’t matter so much for CLI tools where you always want to bail if anything goes wrong (just unwrap and panic is often fine in those cases) but for stateful systems that expect to encounter a variety of errors over a normal process lifetime, this starts to matter a lot more.
Awesome thanks for the feedback. I’ll read that article. I’ve also got your simulation blog post on my read list.
Welcome to the Rust DB eng world :)
Simulation is one of those things that becomes about 10x more expensive to pull off if you start a project without targeting it from the beginning - which for distributed systems more or less guarantees that the time to discover bugs goes up significantly, as well as the effort to reproduce them. Folks like FoundationDB & Basho really improved the quality of their systems significantly by using this technique, and it’s always surprising to me how it still seems to be so rarely applied in the distributed systems community.