If I had a choice, I would have taken Go over Rust just because I need a different kind of people in my team.
Both languages are becoming far more mainstream, but they are still in the realms of people wanting to play with 'new' languages.
The correct answer is to choose a language that is maintainable by most engineers you have, and if you need something else for technical reasons, hire the new engineers first - never impose a new language on engineers without very good reason, and definitely not because "It's simple".
It's often not the language that's the problem, but all of the 'clever' ways the 'clever' devs use it.
What if you compare it to Go that fairly recently got a massive new feature that can change how you write code drastically, ie. generics?
const generics, generic associated types
I know they did ship in multiple stages, and some of those were relaxing limitations (once edge cases were accounted for), but a lot of the work was refactoring large portions of the trait solver and related machinery in order to be able to express completely new concepts (const generics are not just "generics in more places", even though monomorphization may make it seem that way).
The reason why they don't necessarily feel like new features is because they fit neatly into existing features, which is a good thing (we don't need another PHP). But they both took years to implement and were huge pain points for a very long time.
Also, their existence does not change how you write idiomatic code. Existing code still compiles and doesn’t need changes. Those features are pretty niche.
This will be true forever, because of Rust's stability guarantees. By this logic, Rust will never have any new features.