> Rust forces you to either (a) re-invent the wheel (yet again !)

This is inherent to the domain of systems programming. One-size-fits-all solutions only suffice until you need extreme performance. So, for example, Rust provides a basic hashmap in the stdlib, and as a generalist hashmap it's quite close to state-of-the-art. But as a generalist hashmap it's also beaten in specific applications by specialist datastructures, and Rust needs to provide support for building those specialist datastructures in a way that makes them feel just as first-class as what the stdlib provides.

Go gets away with what it does because it's for domains where it's acceptable to trade uniformity for performance. This is not a bad thing! Go is quite performant. But Rust ultimately isn't competing with Go, it's competing with C.

And note that I say all this as someone who is, in fact, a stdlib maximalist. But I also say all this as someone who is conscientious and informed of the realities of what it takes to design and maintain a secure, high-performance stdlib.

Yeah, not long ago on HN I read into somebody who really wanted a type that's a list of blocks which expands and shrinks only by whole blocks. Such a type would have amortized O(1) push at one end, like Vec, and also amortized O(1) pop - but with much smaller and more frequent allocations, and the index access is horrible, but it would only ever be over-allocating by a bounded amount, this is a relatively inconvenient type for a lot of purposes which is why AFAIK nobody provides this out of the box, but it did suit their needs.

Lest people imagine Rust has so few collections because nobody offered any others, Aria has a rant in her Linked Lists "tutorial" where she explains that pre Rust 1.0 she was cleaning out all the miscellaneous collection types few people need - and she tried but failed to remove the linked list type. There's some very niche types in her list, things I've heard of but never used in decades of professional software engineering.