4 ms·

Rust should have larger stdlib

25 points by synergy20 5y ago

jamincan 5y ago
It seems to me that while Rust has a stdlib, there is also a de facto set of "standard" libraries that the ecosystem consistently turns to. serde and regex are the two that stand out in my mind. I'm not sure that incorporating them into the standard library would bring anything to those crates now, while only bringing additional constraints. 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.
- deleted 5y ago
  [deleted]
- dureuill 5y ago
  The difference between the two is that "OnceCell" is more of a "vocabulary type" that is used to build other types and might get exported in public APIs, while regex is more of a "leaf type", if that makes sense. There's also something fundamental in "how do I build a static variable?".
pjmlp 5y ago
The issue of having a thin library is that one then ends like the relationship POSIX has with ISO C. 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".
- fivea 5y ago
  > The issue of having a thin library is that one then ends like the relationship POSIX has with ISO C. 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.
  - pjmlp 5y ago
    I know, yet from my point of view that is a mistake, they think they learned, yet the npm attack of today proves otherwise.
    - spoiler 5y ago
      Npm is the biggest and most active developer ecosystem out there. Statistically, mistakes/issues are going to happen. 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.
      - fivea 5y ago
        >>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. 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. https://www.boost.org/users/faq.html https://www.boost.org/users/faq.html
        spoiler 5y ago
        I write C++ (for better or worse), and I know Boost is an algamation of libraries and many hard working maintainers. I didn't mean to imply anything bad about boost. I think you misunderstood me because I gave a poor example. 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.
nonameiguess 5y ago
I think the size of the stdlib is a bit misplaced. If you look at many of the complaints, many of which I agree with, the real issue isn't whether something is part of the language distribution itself or provided externally. The problem is bloat in the dependency tree. Nobody wants to individually vet a thousand plus library authors and enterprise/government or just anyone who cares a lot about supply chain security is not likely to consider "number of downloads" on crates.io a reliable proxy of trustworthiness. 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.
- fivea 5y ago
  > The problem is bloat in the dependency tree. Nobody wants to individually vet a thousand plus library authors and enterprise/government or just anyone who cares a lot about supply chain security is not likely to consider "number of downloads" on crates.io a reliable proxy of trustworthiness. 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.
- hedora 5y ago
  Funny, boost and libcommons are my default examples of harmful dependency bloat. 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.
mrlonglong 5y ago
I feel that having a curated large standard library would mitigate the issues that are seen with crap like npm.
- synergy20 5y ago
  true, it does not seem deno is addressing the 'biggest' weakness in node.js though, I'm a bit disappointed.
  - rough-sea 5y ago
    https://deno.land/manual@v1.17.2/standard_library https://deno.land/manual@v1.17.2/standard_library
- pjmlp 5y ago
  To top that, cargo.io doesn't even have protection against crate squatting or namespace protection.
rwaksmunski 5y ago
Standard TLS, HTTP/1/2/3 and Async would be really nice.

25 points by synergy20 5y ago

It seems to me that while Rust has a stdlib, there is also a de facto set of "standard" libraries that the ecosystem consistently turns to. serde and regex are the two that stand out in my mind. I'm not sure that incorporating them into the standard library would bring anything to those crates now, while only bringing additional constraints. 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.

deleted 5y ago
[deleted]
dureuill 5y ago
The difference between the two is that "OnceCell" is more of a "vocabulary type" that is used to build other types and might get exported in public APIs, while regex is more of a "leaf type", if that makes sense. There's also something fundamental in "how do I build a static variable?".

pjmlp 5y ago

The issue of having a thin library is that one then ends like the relationship POSIX has with ISO C. 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".

fivea 5y ago
> The issue of having a thin library is that one then ends like the relationship POSIX has with ISO C. 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.
- pjmlp 5y ago
  I know, yet from my point of view that is a mistake, they think they learned, yet the npm attack of today proves otherwise.
  - spoiler 5y ago
    Npm is the biggest and most active developer ecosystem out there. Statistically, mistakes/issues are going to happen. 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.
    - fivea 5y ago
      >>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. 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. https://www.boost.org/users/faq.html https://www.boost.org/users/faq.html
      - spoiler 5y ago
        I write C++ (for better or worse), and I know Boost is an algamation of libraries and many hard working maintainers. I didn't mean to imply anything bad about boost. I think you misunderstood me because I gave a poor example. 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.

nonameiguess 5y ago

I think the size of the stdlib is a bit misplaced. If you look at many of the complaints, many of which I agree with, the real issue isn't whether something is part of the language distribution itself or provided externally. The problem is bloat in the dependency tree. Nobody wants to individually vet a thousand plus library authors and enterprise/government or just anyone who cares a lot about supply chain security is not likely to consider "number of downloads" on crates.io a reliable proxy of trustworthiness. 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.

fivea 5y ago
> The problem is bloat in the dependency tree. Nobody wants to individually vet a thousand plus library authors and enterprise/government or just anyone who cares a lot about supply chain security is not likely to consider "number of downloads" on crates.io a reliable proxy of trustworthiness. 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.
hedora 5y ago
Funny, boost and libcommons are my default examples of harmful dependency bloat. 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.

mrlonglong 5y ago

I feel that having a curated large standard library would mitigate the issues that are seen with crap like npm.

synergy20 5y ago
true, it does not seem deno is addressing the 'biggest' weakness in node.js though, I'm a bit disappointed.
- rough-sea 5y ago
  https://deno.land/manual@v1.17.2/standard_library https://deno.land/manual@v1.17.2/standard_library
pjmlp 5y ago
To top that, cargo.io doesn't even have protection against crate squatting or namespace protection.

rwaksmunski 5y ago

Standard TLS, HTTP/1/2/3 and Async would be really nice.