No, it's not like Go, you have to opt into async. (There was a time before 1.0 where it was, but that was removed.)
My reading is that, since their technique was to learn something and then immediately apply it to their project, they began making it async before they realized it was better of without it. Seems like a good learning experience to me, I think this approach is good.
Yes, I had some feature in an earlier version that I wanted to add and the example code I was looking at was async and that made me think that I have to go to that route and also include an async runtime (Tokio). Once I was there, I ended up using async versions of some other dependencies as well.
Later on I then realized that in my CLI app I’m not gaining anything from it as there is no need for any parallel prosessing. It was just making my code more complex.
"When I learned about async programming, I realized that for my CLI-based project, I didn’t really need async. So, I removed all async code and the Tokio runtime, which significantly simplified the code."
This implies that you used async before learning it. Does async come along for the ride with "standard" constructs in Rust, such that you have to make an active effort to avoid it?
Forgive my ignorance about Rust if this is a dumb question.