Rain is a Rust developer and author of cargo-nextest who writes about async Rust, Unix signals, type systems, and hardware.
HN commenters recommend her posts on async cancellation and cancel safety, and the nextest and Tokio post, calling the Tokio mutex section especially interesting.
In the spirit of "every non-trivial program will expand until ...", I think preemptively choosing async for anything much more complex than a throwaway script might be justified. In this case, the relevant thing isn't performance or expected number of concurrent users/connections, but whether the program is likely to become or include a non-trivial state machine. My primary influence on this topic is this post from @sunshowers: https://sunshowers.io/posts/nextest-and-tokio/
ECC is fully supported by consumer AMD processors (at least Ryzen 7000, and I think earlier ones too). You need to pick a matching motherboard, most boards from ASRock will do. And you need to find unbuffered ECC RAM, this is more difficult than the previous two and is why I had to give up on the whole idea.
Related post:
https://sunshowers.io/posts/am5-ryzen-7000-ecc-ram
Rain showed that not all may be as simple as it seems to do it correctly.
In her presentation on async cancellation in Rust, she spoke pretty extensively on cancel safety and correctness, and I would recommend giving it a watch or read.
https://sunshowers.io/posts/cancelling-async-rust/
Author here -- I'd recommend reading my blog post about how cargo-nextest uses Tokio + async Rust to handle very complex state machines: https://sunshowers.io/posts/nextest-and-tokio/
https://sunshowers.io/posts/cancelling-async-rust/#the-pain-of-tokio-mutexes was the most interesting part of this for me, as I can totally see making mistakes like this.
> He writes
They go by they/she
https://sunshowers.io/about/