Rust should have larger stdlib
users.rust-lang.org
users.rust-lang.org
That said, some projects that had a similar status, like once_cell, are being incorporated into the Rust standard library, while others, like regex are now owned by the Rust team, but still managed as a separate crate. I'm not really sure why they have taken different approaches between the two.
Large collections of libraries that can often be pulled in as a single dependency, like boost, apache-commons, or all of the C libraries provided for free by a GNU system, are a nice middle ground. They're trusted, large enterprises will let you use them, you don't need to separately download every single library, but the core language maintainers don't need to maintain these collections themselves and they don't have to be subject to hard backwards compatibility guarantees provided by a built-in std.
But, of course, that also means you can't ask the core language maintainers to create this for you. These are community efforts. Also, I don't believe any of them existed within 11 years of the language first being released. Curated, dependable library collections that become ubiquitous as part of a language ecosystem take time to come about.
That problem does not magically go away with a bloated stdlib. Take Java, for example, with it's colossal list of standard modules, with which Rust cannot possibly match or even rival. Yet, any reasonably sized Java project still ends up dragging in dozens of third-party modules to the point that not using a dependency management system is unheard of.
The main problem with both is that they have some narrow functionality I actually want, but they also contain millions of lines of brain damaged garbage. (Which, at least for boost, is by design, since it’s a proving ground for stuff destined for the C++ standard library.)
The second they’re available, junior devs find the worst corners of them, and build in hard dependencies while no one’s looking.
I prefer the curated distribution approach that Debian takes: Fine grained dependencies are widely available, but gated behind some sort of reputation-based quality assurance process.
As the standard library is very anaemic, and cannot be guaranteed to be everywhere one has a compiler available, one brings half-UNIX implementation along for the ride.
And when it isn't available, everyone complains the C code isn't "portable".
It should be noted that the vast majority of participants on that thread do advocate against bloating Rusty's stdlib, and they point out a very thorough and convincing list of prior experiences from other programming languages that justifies this stance.
It's as if they learned from other people's mistakes and bad experiences.
Given its popularity, it's easy to talk shit about npm, but rarely do people say anything actionable.
C++/boost could have a bad actor upload malicious code. The only difference is that people probably wouldn't notice for months, because everyone's running decades old versions of boost anyway. Not because they're mindful of security, but because nobody can bother to update it unless the need becomes dire.
Now, a favourite of mine (often preached by CPP Deva): if you're a good enough developer, you don't have these problems.
Were the npm problems avoidable? Yeah, if "yOu aRe a GoOd eNoUgH dEvElOpEr" and use lock files (generated by default) and only install from it (eg `npm ci` being the simplest method).
Disclaimer: I used to be an everyday npm user, and I'm not a fan of it by any metric, but the npm shit-slinging edgyness hype is so last year's trend. Jesus Christ.
This baseless assertion is quite wrong and completely detached from reality. Boost is not a one-man show which is a git commit away from disaster. Boost is a commmunity-driven project where any change to an existing package is subjected to a public review and proposals for new components are performed through a submission process.
I'm talking about the general/average mindset of the C++ community when it comes to updating dependencies. Also the way dependencies are "managed" (or lack of it) in virtually every project.
The HN crowd isn't considered "average" in that dimension, probably. So even if you yourself have a culture of keeping things updated with Conan or whatever, it's definitely not the status quo.
If you're referring to the colors package in NPM, that is not an attack at all nor did it proved what you think it proved. If anything, the colors package episode just showed that there are companies mindlessly ingesting dependencies without a shred of due diligence.
You're confusing a service where anyone can distribute their half-assed package with the dependencies you adopt for your package.
It's not the job of crates.io nor npm to vend dependencies. That job is on you and on anyone who wants to consume a third-party package.
It's weird how some people complain that they are not obligated to perform any form of due diligence at all on basic things like be responsible for the crap they decide to mix with their work. I mean, the protest release of the colors package was done with a very obvious and very glaring major version bump, and people just swallowed it whole without any check at all? That's a problem of your own making, not npm or crates.io.