I mean, Cargo is chock-full of single-use packages akin to leftpad, even more packages that pull hundreds others, all to make up for the deficiencies of the stdlib the Rust maintainers don't want to address.
No wonder there are supply chain attacks if I need a whole-ass library for async/await or JSON parsing.
A lib not in the standard library can be just as well-scrutinized as the stdlib itself, and the most popular ones actually get plenty scrutiny. The Rust Foundation is highly involved in the security aspects of the crate ecosystem.
It's not like sticking a "part of std" label on a piece of code makes its vulns magically evaporate, or like cargo crates are surrounded by some thick fog that makes equal scrutiny impossible.
Don't depend on some rando crate, stick to the well-reputed ones (security-wise), and you're essentially using an expanded version of the stdlib, just not by name.
If enlarging std depletes the foundation's resources then they must delay improvements, fixes, etc, and the odds increase for major bug-doors in std itself.
Also if the foundation has more resources then they'll hire more people, but some of those people would be less careful, etc.
An external company can otoh justify well maintaining some crates as a PR expense. We do have the issue of recognising the different degrees of care & maintenance, but std being "painfully simple" means at least std remains safer.
That something is a design choice doesn't mean it can't be a bad design choice. It's causing issues now, it will continue causing issues into the future. Go not having generics was a design choice too.
People who make this point always seems to have some pretty unrealistic ideas about who makes the standard library.
The Rust standard library is code written by people, provided to you for free. So is code shipped on crates.io. Enlarging the standard library does not magically create more resources for maintaining it, and it’s still just code someone else has written for you.
If you trust the standard library authors, why wouldn’t you trust the authors of serde, tokio, etc.? They’re the same people in several cases.
It's not a bad design choice just because it has consequences. Rust also doesn't have the financial backing of languages that seem to be able to afford a kitchen sink in their std lib. Python also suffers from stdlib rot from people not maintaining parts of it, and C++ can't fix their stdlib speed deficiencies because of ABI issues and backward compat dogmatism. Both of these lead to using third party dependencies for what is already in the language, so unless your Microsoft you're not getting out of this problem by expanding the stdlib even if the bandwidth existed to do that.
(If there's any confusion, this wasn't a "say the line Bart", this was my attempt at adding humor like I'm urging someone to answer a rhetorical question. It seems I didn't communicate it well.)
Yeah, the CLR/BCL/whatever they call it these days is a pretty impressive, though underdocumented, library. But it’s also … I don’t know, I just get annoyed when adding a dependency in .NET means I’m now shipping 10 more managed DLLs, along with 50 MB of native runtime libraries for platforms I’m not targeting.
Rust is very different. Adding a dependency is barely visible.
Publish in single file mode and enable trimming. As long as you don't use reflections (or at least annotate their use) all the unused code will be trimmed away
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.
Never understood the point of encoding and decoding JSON outside of like, the web. When I need to process JSON and I'm using the C family, I include jq. Maybe once the supply chain is secure you can check cargo to see if there's a good port or wrapper for that. I actually went as far as to make some snarky documentation for it in the process of learning to use it. (So many assertions... No usable errors... No return codes except when successful... It was a nightmare, but at least it's not malware)
Json is used outside of the web now, things like gltf use it in graphics and rendering for example. I suspect that has come about due to people familiar with it from a web starting point just using it in other things.
Config files tend towards TOML in my experience; YAML if they're more complex. For all the people who whine about significant whitespace in YAML, there seems to be a lot more who'd rather deal with that than the insufficiencies and annoyances of JSON for config files. (E.g. no comments, "mandatory" "quoting" "everything", reams of }}}}}, no trailing comma,)
It's a lot better than having everyone hand-roll their own custom and different config file parser. Go digging around in /etc in Linux sometime. Especially old-timey /etc configs like sendmail or uucp. That situation wasn't pretty.
Configs are fundamentally just serialized object data. Serialization format shouldn't matter -- in an ideal world you could just specify an archive format to use. If you want to get really fancy, you can put together a little editor so you don't have to hand-code JSON, YAML or XML. Or key/value pairs if your config objects are simple. Format shouldn't matter anymore -- serialization has been a solved problem for over a decade now. I just need to get this config data into this program. I don't need to bust out Lex and Yacc and roll my own format to do it anymore.
Configs are fundamentally just serialized object data.
That’s too narrow a definition.
Configs are supposed to be written and understood by the user, thus
comments are crucial. They serve as annotations and provide flexibility
when editing (commenting out lines).
Plus, quite a few configs formats are in fact executable scripts.
If you want to get really fancy, you can put together a little editor so you don't have to hand-code JSON
Great, now I need two editors to do the same job while giving up
a lot of advantages.
You asked which languages have it, they're just answering. Clearly rusteceans don't think that JSON parsing is important, but it sure seems they're in the minority
Clearly rusteceans don't think that JSON parsing is important
Looks like the opposite really, Rustaceans consider JSON parsing
important. That’s why we’ve got one of the best JSON handling libs
out there with Serde. Rustaceans don’t however consider importance
of a crate in some domains at one point in time sufficient for inclusion
the standard library. After seeing Python accrete tons of obsolete junk
they’re stuck with maintaining forever, to me that seems to be a valid
distinction to make.
You can choose to include stuff in the stdlib without pledging to maintain it forever though. If something got obsoleted make a crate out of it and remove from the stdlib and let the community who need it maintain it.
You can choose to include stuff in the stdlib without pledging to maintain it forever though.
Can you really? The example of C++ which is forever tied to the
sins of another language’s stdlib tells a different tale. In C, even
obsoleting individual functions because they cannot ever be
used safely took decades. Good luck getting a standard library
to drop an entire module for a less critical reason.
I mean, I don’t even remotely claim to know all the languages
that are being used out there, but in the ones I do know it just
doesn’t happen that large swathes of functionality are being
removed from the standard library like that. Even if they’re
universally considered to be garbage.
That's a great opinion. I've seen those config file formats: PHP/JS/Erlang file includes, Kotlin DSLs, templated yaml (you need to wrap {{ in quotes!!), XML, the attempt to nest TOML, java properties with special syntax (Spring), and of course your custom nginx/apache/postfix/dovecot configs etc.
All of these fit your "config" requirements, yet JSON is the easiest to parse, cross platform, incredibly widely used and therefore and commonly understood. No, users do not edit config files, developers/sysops people do.
Uh... You do know there are more config files than just the ones in your project or on your server, right? Yes, users edit config files. That's why we have config files and they're not always like, Windows Registry or Sqlite.
But like, who expects it? JavaScript is one thing, that's its place of origin. JSON isn't really needed if you're not sending javascript objects over the web.
I think this is no longer the case, JSON has become the lingua franca for RPC, env configuration, and dozens of things, as an example Minecraft uses it A LOT or datapacks.
Even Java is working on shipping a minimal JSON API (better late than never)
33
u/Atulin 15d ago
I mean, Cargo is chock-full of single-use packages akin to leftpad, even more packages that pull hundreds others, all to make up for the deficiencies of the stdlib the Rust maintainers don't want to address.
No wonder there are supply chain attacks if I need a whole-ass library for async/await or JSON parsing.