It gives rust hate from many people. And once someone hates language it sticks. Also add to that the rust zealots who behave like sometimes like political preachers. "We are future, you are backwards" - says every ideologue. But conveniently does not say "in direction I want". When rust started political fight instead of language one they should expect that every rust porting will become political quagmire.

Also you are incorrect - because you are already making wrong assumption:

> crates are not libraries

"never provided a shared library interface" - it doesn't need to, it just need to USE library - distros will convert static one to shared one if that what is reasonable.

Now we have to have C library connected by C headers to (in future) rust application. Sure this somehow works - at cost of memory safety. So someone WILL suggest using rust crate instead of C library, and the problem will inevitably pop up.

You could only say it works correctly as platform stipulates if you did not use any rust crate, or used ones that only your app/lib uses, or trivial finished ones - and I do not see people use rust like that. Even then it is from most linux distributions perspective the distribution job to decide if it should be static or shared linked NOT app-developer.

SSL is something that is prime example of would it best to be written in memory safe language, with safe headers, provided that language makes stable ABI connections, so we can update 0-day not waiting for app developer.

Rust fails spectacularly at last point unless library uses C headers.

But at least it seems that OpenSSL is dynamically loaded after start so they are not changing that too soon.

When I decide to patch some library for my use case I may want to use such library in every instance in every program on the system. Rust crate makes this impossible - now I need to rebuild everything even if I could not reasonably touch ABI boundary in same C code.

Ultimately I think many of linux rust critics see it correctly as company-first/app-centered/containerized/not developement-aware user language (i.e user who can patch software for their specific needs who actively want to inspect every dependency in ONE way), and they prefer the known pro-community/pro-distro/pro-user-developer C/C++ paradigm instead. (At least fact that many criticism start immediately when GPL project get BSD rust rewrite does point it to free-software/open-source i.e pro-community/pro-company schism)

Many linux users especially developement-aware users just have enough of pip, cargo and every 'modern' stuff - they just want old good apt or pacman.

Then you have people that think slow development and no revolutionary changes should be IT priority in modern times.

Then you have people that do believe that any alternative should be better, easier and simpler than old stuff before it should be treated as even a alternative way.

And then you have contrarians.