We can and frequently do. Rust even seems to have one of the better packaging stories around building C++ libs, albeit with several heavyweight dependencies (C++ compiler + toolchain, libc, etc.). Granted, calling into it from Rust means we need a C ABI, but that's rarely a terrible problem.
> What novelty would a Rust version of the same thing bring really?
I find Rust easier to cross compile for starters. I still haven't tamed emscripten for compiling C++ as WASM - the Rust toolchains by comparison make compiling Rust to WASM trivial. Rust's larger stdlib, standard package manager, and healthy library ecosystem means whatever I'm cross compiling is less likely to need to resort to platform specific nonsense in need of manual porting.
But the main draw of Rust to me is the ability to write memory safe code and race-safe native code, reducing how many heisenbugs I encounter and the portion of the codebase where they might lurk. If your codebase is large, and mostly memory/race safe, this is a huge advantage. If your codebase is large, and only 50% memory/race safe, you're still frequently in debugging hell inside a large haystack.
If you take a super solid C++ dependency, maybe you kinda retain that advantage, but most C++ dependencies I take on don't meet that high bar (including those me and my coworkers write!) Alternatively, I could take on a relatively mediocre Rust dependency, and I'll probably still retain that memory/race-safety advantage. There are exceptions to this of course thanks to Rust's many opt-in escape hatches - but I also find it much easier to audit Rust code for their use and the possible problems they may cause, versus C++ where every array access is suspect.
That said there are plenty of reasons why they shouldn't just import c++ libraries, one of them being that c++ is not the same language as rust.
They do do a pretty damn good job of giving people this impression.
This mindset may be appeased by demonstrating why you don't believe your actions are actually a waste of effort.
If you wait long enough, any stable working solutions will be reinvented in its own Language.
It's completely unproductive. But there is reason to that: compatibility with the language toolchain and understandability.
If someone hadn't implemented the libpq protocol in Rust, I likely wouldn't have written in binary copy support on the dataframe in one afternoon.
This reduces the barrier for people to productively use their favourite languages. It might be unproductive at first, but we see the benefits as time goes on.
It is vastly unproductive to reproduce anything useful in 10 different language just because our cross-language tooling awfuly suxxe.
The lack of cross-language dev-oriented lead us in the ridiculous situation where every language has its own package manager and his completely unable to use a package made for an other language.
There is reasons to that... but much more political than technical and that's the sad state we are in.
Let me give you an example but this time with Groovy. Groovy runs on the JVM and that means it benefits from the existing JVM ecosystem, right? Well, of course you get the benefit of existing libraries but there was a crucial difference between using them through Groovy/Grails than natively through Java. There were lots of grails plugins that were very thin layers above the Java libraries yet somehow the usability increased a hundredfold. A small plugin with maybe 1000 lines of code ended up providing more value to our business than the part of the library that was written in Java.