"If you write code in rust, you may link to a library in your code. I think this is somehow unique to rust, but I have no experience in software development. That makes rust more challenging in Enterprise environments."
The standard Rust competitor is C++. That has a very different design choice - the standard library is huge, ancient and ever expanding and basically requires backwards compatibility. However, that also means that you know that your compiler vendor or specific standard library vendor has to provide those functions for certification and that there's some basic level of support and responsibility for the contents. Likely similar to or related to the level you get for the compiler.
With Rust's choice you get a very different set of trade offs, one we are much less experienced with. Perl is probably the most similar language which has become old and we can see real maintenance problems with the libraries, partly caused by standard bit rot, but mostly caused by a dysfunctional community which hasn't even allowed the language to increase it's version number properly. Since Rust is making the same kind of choices that Perl made for libraries, it might be legitimate to wonder whether there might come a time in future when similar problems happen to Rust crates as are happening to Perl libraries.
Given that the North American Enterprise Linux vendor is giving up their leadership of the Linux community and given that Linux is starting to use Rust seriously in the kernel as well as in user space, having an actual sensible distro vendor directly influencing how rust packages are maintained and how the Rust community prioritizes them may actually be pretty important and useful.