4 ms·
It might be a bad choice on rust's part. IMO they should over time fold whatever ends up being the de-facto choice for things into the standard library. Otherw
by chikere232 2y ago
It might be a bad choice on rust's part.
IMO they should over time fold whatever ends up being the de-facto choice for things into the standard library. Otherwise this will forever be a barrier to entry, and a constant churn as ever new fashionable libraries to do the same basic thing pops up.
You don't need a dozen regex libraries, you just need one that's stable, widely used and likely to remain so.
- palata 2y agoAgreed. > and a constant churn as ever new fashionable libraries Isn't that the situation in Javascript? I don't work in Javascript but to me it feels like people migrate to a new cool framework every 2 months.
- LamaOfRuin 2y agoLess so than it once was, but more so than other languages/ecosystems. To be fair though, I'd argue the environment Javascript lives in also changes faster than any other.
- burntsushi 2y ago> You don't need a dozen regex libraries, you just need one that's stable, widely used and likely to remain so. That is the case today. Virtually everyone uses `regex`. There are others, like `fancy-regex`. But those would still exist even if `regex` was in std. But then actually it would suck, because then `fancy-regex` can't share dependencies with `regex`, which it does today. And because of that, you get a much smoother migration experience where you know that if your regexes are valid with `regex`, they'll work the same way in `fancy-regex`. A better example might be datetime handling, of which there are now 3 general purpose libraries one can reasonably choose. But it would have been an unmitigated disaster if we (I am on libs-api) had just added the first datetime library to std that arose in the ecosystem.