I may have significant input on a green field project, which is generically a web use case, but performance will be a factor. I'm interested in pitching it, as I know other teammates will be be, but none of us are particularly skilled in writing Rust. For instance, the largest thing I've written is still half baked which happens to be a basic REST API for a personal project. I have only begun to see some of the benefits you explain in your article.
I'm curious if you feel that it's necessary to have an "expert" or experienced Rust developer on the team for it to be the technology of choice; or do you think Rust has sufficient guard rails for a team with basic understanding of mature packages and overall senior experience? The reason I ask is because I've known several teams pick up Go because of their interest in it, ultimately being happy with the choice, but have strong opinions about their initial implementations.
Perhaps that's just the nature of software, but I would love your opinion.
No worries, here's my opinion (lots of lang-war stuff, so note "opinion"):
I would say that it depends on your comfort with async code in Rust since much of the web ecosystem is built that way.
If you're comfortable writing async Rust then go for it, the guard rails are there. People complain (especially here) but it's fine. Our entire web backend and our scheduler applications are overwhelmingly async. We have not hit the weird stuff you read about with lifetimes even once.
However, it does expect you to know how it works. You need to understand what the async runtime does otherwise it will add friction. If you're not yet proficient with this part of Rust then you will benefit from having an "expert" on the team as you say, since they can guide the rest.
Our team were all experienced in Rust already when hired so we didn't hit this. If you're uncomfortable then simply choose the language your team already knows. That's the pragmatic choice.
I'm curious if you feel that it's necessary to have an "expert" or experienced Rust developer on the team for it to be the technology of choice; or do you think Rust has sufficient guard rails for a team with basic understanding of mature packages and overall senior experience? The reason I ask is because I've known several teams pick up Go because of their interest in it, ultimately being happy with the choice, but have strong opinions about their initial implementations.
Perhaps that's just the nature of software, but I would love your opinion.