I do not really know. I heard that it's generally perceived as a good option, but I don't know if any teams are actively using it for any missions.
My suspicion is that once it's generally accepted as part of the kernel, things may change.
If the rust community wants rust to be used in safety-critical, my personal view is that they need to prioritize robustness and stability of the rust ecosystem as a whole over frequent changes to the language or libraries to save 1-2 lines of code.
Breaking changes to APIs and tool changes are a big issue in general, so they are best avoided (almost every time some introduces a breaking change that we are forced to adopt, we have to spend thousands of dollars (in time) to adapt). It's best to take longer to release a tool, but when you do it, make sure it'll work for a long time.
We recently had this case with a tool and our project was delayed by several weeks because someone replaced a version of a tool in homebrew that introduced a breaking change. We hit multiple bugs during the upgrade.
A mission that flies won't depend on homebrew, but it would be very plausible for a bug to be fixed in a version that pulls a dependency with a higher version number, and for it to be impossible or impractical to upgrade only one or two packages. In particular (and I don't "speak" rust), if your compiler comes with core libraries that necessarily need a version of the compiler to work, you want those to be de-coupled and the core API not to change.
Please be aware that this is just my personal opinion. I don't speak on behalf of any agencies.
My suspicion is that once it's generally accepted as part of the kernel, things may change.
If the rust community wants rust to be used in safety-critical, my personal view is that they need to prioritize robustness and stability of the rust ecosystem as a whole over frequent changes to the language or libraries to save 1-2 lines of code.
Breaking changes to APIs and tool changes are a big issue in general, so they are best avoided (almost every time some introduces a breaking change that we are forced to adopt, we have to spend thousands of dollars (in time) to adapt). It's best to take longer to release a tool, but when you do it, make sure it'll work for a long time.
We recently had this case with a tool and our project was delayed by several weeks because someone replaced a version of a tool in homebrew that introduced a breaking change. We hit multiple bugs during the upgrade.
A mission that flies won't depend on homebrew, but it would be very plausible for a bug to be fixed in a version that pulls a dependency with a higher version number, and for it to be impossible or impractical to upgrade only one or two packages. In particular (and I don't "speak" rust), if your compiler comes with core libraries that necessarily need a version of the compiler to work, you want those to be de-coupled and the core API not to change.
Please be aware that this is just my personal opinion. I don't speak on behalf of any agencies.