It is a signal that this will be easy to build, easy to deploy (because it is compiled into a single binary in general), memory safe, and likely to be written by a someone that cares about performance and efficiency.
I think those are all valuable hints.
That's an incorrect assumption if you haven't audited the code.
> likely to be written by a someone that cares about performance and efficiency
Ah, the stamp of approval that comes from signalling to the "right people". Reminds me of the preamble to almost every C++ Boost library -- "written with performance in mind".
Even without an audit, the odds of a Rust project being memory safe are so much higher than in comparable languages.
Furthermore, Rust makes auditing so much easier by allowing you to concentrate on unsafe blocks.
GC'd languages (Java, Go, Haskell etc) are safer than Rust by default, you just have the tradeoff of GC. Note that this isn't always a tradeoff as GCs can outperform static allocation in scenarios like large dynamic heaps.
Haskell is the safest for concurrency because of the strictly typed functional semantics.
> That's an incorrect assumption if you haven't audited the code.
Audit the code? Simply `grep unsafe`.