My favorite example of this is how Python has not one, not two, but four ways to do string formatting. You have the old-school
% formatting, then you have
$-interpolation, then you have
str.format which Rust borrows heavily from, and now you also have f-strings which are similar to
str.format but are baked in to the parser and can interpolate arbitrary expressions. And of course that’s in addition to the host of third-party string templating libraries that came into existence because the standard library is inadequate for one reason or another, but can’t be changed because its API and behavior is fixed.
(For the record, Python is one of my top 2 favorite languages and the “batteries included” stdlib really shines for things I use Python for. But I think the minimal stdlib approach is better for Rust.)
Others have already responded to this, and you’ve said you won’t keep posting, but I find it curious that you consider this a reason to put it into
std. If anything, I think it cuts the other way: surely it would be better to have a mature, time-tested crate first, and then migrate it into
std, than to create a new, immature implementation and then fix it “forever” (well, until deprecation) as a part of
I don’t object to the idea of putting concurrent collections in
std; I’d just rather it be done right than done right now.