> think most people who use JSON don't want strong typing or to use schemas. If you do, you just use a different serialization format: JSON is designed to be a generic, human-readable way to basically represent any kind of data structure (since it deserializes to JS objects). So everything about JSON is working against you if you do try to enforce type/schemas on it.
I have been using serde without issues, and never resorted to `serde::Value`[0], the untyped option, so far.
I have yet to experience anything working against me.
They can be unordered, e.g. when reshuffling data into a new buffer based on a permutation that was computed separately. How do you avoid locking the output buffer in rust?
> Rust's package management and lack of stable, high-quality libraries maintained by professional or even just generally known entities are a pretty big problem.
IMHO, Rusts package management is the opposite of a problem.
And a lot of stable high quality crates exist, such as Tokio, thiserror, chrono, axum, .......
I have nothing but respect and warm feelings for developers who choose to create and maintain software packages and make them available for others.
The problem is that I need to be able to trust my dependencies' provenance. Not just that the developer is good, but that this particular version is good, and that all their dependencies are good and that their versions are good. If there is a security issue in something I use, I need to know that the people responsible for maintaining it have the time and resources to be aware of the problem, quickly patch it, and make the fix available to me; because of that, I also need to regularly check my dependencies' new versions for security fixes and upgrade to them as patches roll out. But I don't have the time to closely review or investigate all of those, so I need to trust that they're handling it without knowing them personally.
Worse, if there is only a single or small group of part-time maintainers handling a package, it would be very easy for a malicious release to be made either unilaterally for financial gain, or unintentionally by some credential hijack (some script pushes a new minor version, they might not notice), or a supply chain hack (eg their build environment got pwned->the software they distribute is not the software they intended to send).
So I prefer to only use 1P packages, dependencies from a well-resourced brand or known figure with something to lose, or dependencies I know very well (and I only have time to know a small number very well). Has nothing to do with the quality of the packages or the developers' skill.
> But I don't have the time to closely review or investigate all of those, so I need to trust that they're handling it without knowing them personally.
so either you pay someone to do the work for you or you hope that someone does it for free?
yeah that's basically my point. People who maintain crates don't work for me and it wouldn't be reasonable to assume any kind of responsibility for keeping my stuff secure, unless there was some big fancy standard library or runtime pushed by a major corporation or public figure that was committed and capable of doing so. So I implement my own rust libraries (just the parts I need, mostly asking agents to do it) because it's the most cost effective way for me to trust my supply chain.
But I wouldn't have to do that as much in languages with larger standard libraries or more established libraries/tools/ecosystems (eg abseil in C++, numpy and tensorflow in python).
The other option has been tried 100 years ago and didn't go so well.
> If you want people to vote for other parties then those parties should chagne to serve the people again instead of trying to make the people serve them.
This doesn't work when the party doesn't serve the people in the first place.
reply