> Right now, it's not much to not many people. Looks like a lot to me: https://www.rust-lang.org/production/users https://www.rust-lang.org/production/users >

> Right now, it's not much to not many people. Looks like a lot to me: https://www.rust-lang.org/production/users https://www.rust-lang.org/production/users > These gaps stop many people using the language for production development. Every language has gaps. Rust had a lot more gaps two years ago than it does now. It's called progress. I personally don't see your particular use case being addressed any time soon. Oodles of people don't need everything developed by a single entity. The success of the Javascript ecosystem should at least make that clear. I freely recognize that some do though. > I'm not making up that XML library scenario as some sort of exercise. I didn't say you were? Your comments are so bloated and you keep rehashing every single point. > I got bogged down just trying to find an XML library that can handle OOXML in a standards compliant fashion, and is popular enough to be maintained going forward, and is consumable downstream We already covered this. Why do you keep repeating it? I literally addressed this in my very first comment to you. And you're still complaining about it. Why? I already told you: Rust doesn't have to be All Things to All People at All Times. Maybe instead of focusing on responding to that with some quip you think is clever, you could recognize it for what it is: an acknowledgment that Rust may not be ready for your use case. Why in the world is that so hard for you to accept? Like, this isn't rocket science. If you need a high quality XML parser, and Rust doesn't have one and you can't write one yourself, then the answer is pretty simple. The thousands of words you've had to write to express this point---and then repeat over and over---is just absolutely baffling. If instead you needed, say, a high quality JSON parser, then we wouldn't be having this conversation at all. You probably would have used `serde_json` and you would have been as happy as a pig in shit. > The advantage of a lean std lib is only to them, a small number of people. Definitely not true. In the Python ecosystem, the mindshare split between things like the standard library HTTP client and more popular third party projects like `requests` impacts everyone. > This is not an advantage to me, the consumer of the language. Of course it is. As a member of the Rust library team, I can tell you with absolute confidence that we had three choices given our timeline: 1) build a small high quality standard library that serves as a substrate on which high quality third party crates could be built, 2) build a large but low quality standard library that would likely have large pieces of it deprecated in the future as better third party options became available or 3) don't ship at all. Neither (2) nor (3) would be good for users. Now we could reverse course at this point and start bringing more into the standard library. I personally don't see that happening because our current strategy is working pretty well (bloviating HN commenters not withstanding). But sure, it could happen. You may be bloviating, but as I already acknowledged, having a big standard library definitely has its own benefits. You're right about that. Being able to trust one (or fewer) entities is a worthwhile proposition. But at this point of time, if that's what you need, then Rust isn't a good fit. I said this before too, and I don't know why you're still giving me shit about it. Why can't we be two reasonable people that accept reality and understand trade offs? "Oh yeah, that makes sense. I'll check back on Rust in a couple years then" would be a great reply. But no, instead I get speculation, rehashing previous points, more complaints and snide back-handed quips. I don't know why. Maybe you just needed an outlet to rant. Well, I'm not your personal punching bag, buddy. Back off.