Yes - Rust can be complicated. However it doesn't have to be. There's nobody forcing you to use Pin. Even async code doesn't do, if you just stick to using libr

Yes - Rust can be complicated. However it doesn't have to be. There's nobody forcing you to use Pin. Even async code doesn't do, if you just stick to using library functions, don't write any Future implementation manually and just stick to async-trait. There's even nobody forcing you to use async code. In fact it might be the wrong choice for > 99% of use-cases, since it adds complexity and limits on which functions can be called in certain places, adds limitations like not being able to perform recursive function calls, and can even lead to higher latencies (no preemption) and more memory usage (for `Future` state allocations) than the boring synchronous versions. I've worked together with multiple teams building > 30 applications/services in Rust and had seen even > 100 engineers in those teams picking up Rust successfully. So for me there's more than enough datapoints that it's complexity is manageable after an initial rampup period of 1-3 month. To be fair: What I definitely haven't found is engineers outside the Rust core group that really understands how async and Pin work - usually people just put async in function definitions and .await where the compiler asks and assume that will do it's job - which is mostly good enough. So yes, I definitely second that those details are hard. And even I - as someone who contributed to async/await standardization and was active in the async working group am giving up mentally in the new discussions around Pin/poll_fn safety. But as I said earlier - knowing Pin is not necessary to write programs successfully in Rust.