Slightly disagree.

Needing the managers permission is more of a "wartime" mode.

For peacetime the management should set a culture of peer review and data and logic driven discussion. The culture would ideally have a Rust lover sit there and think "would love to do this in Rust but...." because they know their peers will be affected by this decision.

The problem with management approval required is it usually meams no or bias towards management pressures. A management veto that is occasionally used may be better.

Disclosure: not a Rust programmer but pretty neutral on it. It is on my radar if I get a problem Node or Go can't solve.

I'd agree with ndndjdjdn in that management getting involved should be the last resort, and potentially only to veto a very bad decision.

I think the main issue here is having a single dev going for Rust. Ideally someone interested in a new technology would pitch it to the team, and they'd discuss if they want to have a shot a it and if they can justify the investment for the whole team. That's where a tech that doesn't fit would be discussed and rejected, potentially with a proposition for a better option that devs are also interested in.

Even if it starts with just a prototype, if it touches production the other members of the team should be able to review it and maintain if needed.

That's this whole bit missing, and the team looking at it as a thing of life, that makes me think they're not focused on pushing things forward anymore at an org level.