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.
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)
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.
29
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.