A lot of good stuff in there

That wasn't C, that was C++.

Not really. Rust attracted C++ developers when that wasn't in initial plan at all.

It's just people use languages differently… and very often not in a way their creators intended these languages to be used!

Rob Pike (and his team) saw C++ as hugely complex, convoluted beast… and “solved” that problem by creating simpler language… that moved error detection from compile time to runtime to achieve that… of course C++ developers would shun that! But for Python and Ruby developers… who were fed up with types mismatch runtime errors… it was perfect fit.

Similarly with Rust: what was a tiny side-story initially, not even central part of the language design… solved issues that C++ (and most other languages have) – and that made it popular among people who were fed up with endless fights against invalidated pointers and iterators… in all languages… but not among the ones who don't see anything wrong with what they are doing and think the fact that certain error-handling paths contain mistakes is not reason good enough to raise all that racket with “Rewrite it in Rust”.

Believe me, C++ have more data structures than you can list. And Rust can implement all the data structures that you may ever imagine. There are [inclusive lists](https://docs.rs/intrusive-collections/latest/intrusive_collections/), [arenas](https://docs.rs/bumpalo/latest/bumpalo/), [self-referential data structures](https://docs.rs/ouroboros/latest/ouroboros/) and many other things… No, the problem is different, this time, again.

Problem lies on C side, not Rust side, this time. In most languages (be it C++, Ada, Java or even Go) it's relatively easy to separate data structures from the “business logic” – but C (especially “C used as portable assembler”) doesn't give you such luxury. That's why natural inclination of C user is not to import implementation of some data structure, but to reimplement them. In ad-hoc fashion. Hey, that could be more efficient and I wouldn't have to rely on someone's else work!

“We code for the hardware” mindset. “C as portable assembler” is really as high as you can push it. And even that starts falling apart with modern compilers. Higher-level language means that you have to give up that control and, in particular, would start using data structures prepared by someone else. That's flat-out unacceptable for these guys (hardware don't have any pre-canned structures means their code should have them, either) even if it's easy to see that alternatives wouldn't work: most bugs that fuzzers and other tools find in kernel are precisely in implementation of ad-hoc data structures and it wouldn't be practical to write them in any language.

Even if you use WUFFS that makes, in theory, possible to write ad-hoc implementations… you quickly find out that writing all these ad-hoc implementation and all these ad-hoc correctness annotations… it's too painful to not reuse code.