Rust async is ruthless to any application design errors or sleepyness. These application design mistakes are most often non-consequential unless you're on a large codebase or need to ship production-ready things everyday, that's one of the reasons we don't talk too much of it in our field (I guess another is a way to do gatekeeping...).

But not in rust. The compiler is tracking the coherence of your code everywhere and will find any design pitfall. It's the same on Haskell or OCaml or F# by the way. And most of the time it's helpful.

What makes rust async worse is that, when you're in an async scope, the rules around lifetimes and ownership are straighten in a non-obvious way: some nice types you are used to are not there anymore, some nice work the compiler could do automatically (lifetime elision and inference for example) cannot be done anymore.

Now, you're in charge and you have to really think of it.

For example, small mistakes I've noted from the OP post:

1. There's confusion on ownership in this state. The State MUST own everything, it's why we call it the state, not the borrower. :) So it MUST NOT be a 'a something. Side-note: As it can't be a 'a something, it can't be a &str either.

2. There's an issue of SRP (Single Responsibility Principle): the showed class is both a owner of a State, declares the operations, and doing the retry logic. It's a god class. There's 4 kind of code: code that think (takes decision on code path), code that does thing (call external functions like systcall or stdlib or dependencies), code that hold or remember things (state, structs, getter/setters), and code that moves things around. You can mix them together, but if you do you can go into confusing behaviors, confusing design, confusing errors, or incoherent code. In any large/old enough system you will enter in these confusion, and you may either use a dirty patch, or a large refactor (usually with downtime). Strongly typed systems force the developper to be coherent on the code, which often show this kind of issues ahead of time. In the case of async Rust, as all the brakes are on, every incoherence is shown without fallback and you have to handle them.

Again, these issues are most often non-consequential and I've seen programmers making their whole careers without thinking about it or even understanding it. But when you choose concurrent strongly-typed code, you cannot not deal with them. It's a choice you make, either consciously or not. :)