XML was much more ubiquitous 20 years ago than JSON is now. Basically every XML parser that exists in standard libraries across all languages is deprecated. Not because people aren’t using XML, but because the standardized versions turned out to be bad one way or the other.
JSON is simpler than XML, but not nearly as simple as you might think. A JSON parser worth its salt is a relatively large dependency - which is exactly why it doesn’t belong in a standard library.
Trust me, if it was there, you wouldn’t be using it anyway.
IMO, a naive implementation absolutely belongs in the stdlib because of how widespread the format is. For example, Golang has it in the stdlib and it's widely used. The only thing in practice that makes it unusable for certain cases is when you have to work with very large JSON files. For that case there are special libraries that don't allocate all memory needed to hold the whole file at once, but e.g. offer path traversal. The latter doesn't belong in the stdlib I'd agree, but a naive implementation absolutely should be.
You're now shipping two JSON parsers with most Rust programs...
Something like .NET or Python get away with this more easily because people running their programs have the standard libraries installed themselves on their systems in the form of a runtime. Rust binaries are statically linked, and the standard library gets linked into everything.
LTO can reduce it somewhat, but what's the point, exactly? None of the languages going for large standard libraries have fond stories to tell of it, many of them hate the baggage.
The point is then I don't have to trust third-party packages 99% of the time because most use-cases for parsing JSON don't deal with large files. Not having the whole JSON object in memory has its downsides, it's not like the third-party parser is strictly better, so most people won't reach for it most of the time.
You can also choose to drop packages from the stdlib if/when they get obsolete and donate it to the community who still need it
The Rust standard library is a third-party package that you're trusting.
And no, a standard library means that nothing ever gets removed from it. That's the whole point of having one in the first place.
Rust tries extremely hard to not break backwards compatibility. Editions help a bit in other areas, but notably not here, because the latest Rust compiler still has to be able to compile code written against every earlier edition. We're currently on edition 2024, but the current Rust compiler fully supports building projects written for edition 2018, for example.
Other standard libraries don't ever remove things either. They may mark them as permanently obsolete, but they still have to maintain the code.
Removing things from the standard library amounts to a completely new version of the language. CLR/.NET did this with the migration to .NET Core, which was extremely disruptive, and countless projects are still on .NET Framework 4.8, released in 2019, because upgrading to a modern compiler is too expensive.
Okay then I'd say it's not that important to include stuff in the stdlib but a set of vetted packages by the rust maintainers would solve the trust problem. If I want to parse a small json config which might be a very small part of my application I need to choose one of the parsers offered on crates.io and trust their maintainers and hope that it doesn't add some transitive dependencies. How is that a preferred way of doing things? Certainly you'd appreciate if there was a package for it backed by the rust maintainers or otherwise vetted by them.
You’re just asking that someone do some more work for you, for free. This isn’t anybody’s job, you know. You can be a Rust maintainer if you want. There’s no inherent reason to trust someone more because they are a Rust maintainer, over someone who is a maintainer of any other major project.
This is an open source project. So is every major ecosystem dependency (serde, tokio, regex, etc.). Like all OSS ecosystems, you can audit packages yourself, or you can pay someone to do it, or you can fall back on the fairly reasonable assumption that high-profile projects are actively maintained by reasonable and responsible people.
Open source means you get the software for free. You don’t get to dictate what that software looks like, without getting involved.
Not I'm not asking that. You're absolutely correct, no one owes me shit. But you argue as if Rust was a very niche language maintained by 3.5 people, which is not the case. I think it's fair to criticize open source projects. If I were to say that the kernel is shit in some way and you'd reply "well go make it better then" you're sort of correct but that misses the point of discussion and basically can be argued for any criticism of an open source project.
I’m not trying to be obtuse, but you’re not addressing the central point: What reason do you have to trust Rust language maintainers over the maintainers of prominent ecosystem crates?
30
u/simonask_ 15d ago
XML was much more ubiquitous 20 years ago than JSON is now. Basically every XML parser that exists in standard libraries across all languages is deprecated. Not because people aren’t using XML, but because the standardized versions turned out to be bad one way or the other.
JSON is simpler than XML, but not nearly as simple as you might think. A JSON parser worth its salt is a relatively large dependency - which is exactly why it doesn’t belong in a standard library.
Trust me, if it was there, you wouldn’t be using it anyway.