You are right that my statement was too generalized, though. Yes, there are sectors where the "gluing together lots of libraries" style is the most practical one and "few third party dependencies" is not practical. However, there are already languages for that, and nobody is waiting for Rust to replace Ruby.
As for Rust replacing Ruby, why not? It is a general-purpose language, it eschews a lot of the C/C++ verbosity, lack of memory safety and weak typing which make them such a pain. I could see it easily as a strong contender in the web platform department once it matures.
There are a bunch of us Rubyists in Rust-land, actually. My "Rust for Rubyists" was one of the biggest early community tutorials. And a Rust extension to Ruby in Tilde's Skylight product is the third production deployment of Rust ever.
Rust will not exactly 'replace' Ruby for me for a while, but I can see a day where that's true.
Presumably there's a significant amount of software that both is library-heavy and would benefit from being faster-than-Java, enough so to make some extra memory management worthwhile? If the reason that such software is getting written in Java etc. instead is because dependency management is too unpleasant in C++, well then that right there is the case for something C++-like but with good dependency management.
I think that's a terrific case of "that's my use case and therefore it should be everybody else's too". Try writing a complex web business application with "few third party dependencies" while not reinventing the wheel at the same time. There are many cases where having many third-party dependencies is necessary and the right thing to do, because your customer is emphatically not paying you for writing a web framework, a REST routing layer, an ORM, a full-text indexing system, a logging system and an AMQP client. Attempting to sweep the problem under the carpet by saying "just don't have dependencies" is silly. The only thing to do is to design a dependency system that works.