Rust, like Scala, is a complex ever evolving language that attracts curious minds. Look at the human side of the story. Yes, teams can build great software in Rust. But Rust also attracts many people interested in playing with fancy language features.
If I had a choice, I would have taken Go over Rust just because I need a different kind of people in my team.
Go often attracts similarly problematic people, who prefer to yolo 'script-like' code because it's 'simple' but becomes unmaintainable more quickly at scale.
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 big language features did Rust get in the last few years? What big changes have you seen that changed codebases directly? Cause I code in Rust and my Rust code these days looks very similar to what I was writing a few years ago. The biggest change to the language was async/await, which was introduced almost 5 years ago.
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?
Those are not new features. Those are relaxing limitations on existing features and making things more orthogonal. Rust already has had generics, now you can use them in more places consistently. Similar thing with `impl Trait` in traits.
If you know anything of the work that was required to ship those features, you know that "relaxing limitations" was not the difficult part.
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.
I’m not saying it was trivial to implement internally. But from the perspective of developers this is not a new feature, but a new ability to compose existing features.
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.
Neither of these features change much in how you code in Rust. Personally I have never used either of those since they came out and I'd expect that you rarely find them in most of the user facing apps. It's definitely super useful for library authors for designing APIs that are easier to use, but it's nowhere near the paradigm change of introducing generics as a whole new concept.
If I had a choice, I would have taken Go over Rust just because I need a different kind of people in my team.