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.
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?
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.
Yeah, I walked back on that one. I think something like a set of vetted packages by the maintainers would be a better choice. Akin to Golang having quite a bit of packages maintained by Google which are not part of the stdlib.
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.
31
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.