4 ms·

The Rust team prioritized keeping the standard library small, and allowing important but inessential functionality to live outside the stdlib and keep their own

The Rust team prioritized keeping the standard library small, and allowing important but inessential functionality to live outside the stdlib and keep their own release schedule. MS has massive resources and can align the many many modules of .NET into major releases. The Rust project does not.

noisy_boy 3y ago
I wonder if there is a scope for a "opt" / "extras" type level where libraries for stuff super commonly used, like JSON/YAML/ssl etc can be placed. It doesn't have to cover everything the defacto third party libraries do (that will be too much and not practical), just including happy paths should be enough for most people to just include the meta package and get the most generally used features instead of including a ton of third-party libraries. My knowledge about Rust's library system isn't great so there are probably several gaps in my argument.
- steveklabnik 3y ago
  Several people have tried to create such a thing over the years, but the ecosystem never uses them. People objectively prefer to pick their own set of packages.
thesuperbigfrog 3y ago
>> The Rust team prioritized keeping the standard library small, and allowing important but inessential functionality to live outside the stdlib and keep their own release schedule. There are crate "recommendation lists" like this: https://blessed.rs/crates https://blessed.rs/crates While these help, Rust's small standard library has slowed Rust adoption where I work because our IT security team must approve all third-party packages before we can use them. (Who blindly downloads code from the Internet and incorporates it in their software?) This means that unless there is a compelling need to use Rust, most teams will use C# because .NET is approved and has almost everything. I prefer Rust to C#, but we are not using it that widely yet. It's not a fair comparison, but it is how things currently are.
- Aissen 3y ago
  blessed.rs is fairly new. And if you look for yaml on this page, it links to serde; and serde_yaml being deprecated (with no blessed fork yet) is precisely part of the issue discussed in the parent article: https://lib.rs/crates/serde_yaml https://lib.rs/crates/serde_yaml ; and that's perfectly fine for the maintainers to declare, it was all open source with no warranty whatsoever.
- marcosdumay 3y ago
  > our IT security team must approve all third-party packages before we can use them Do they also review the original tooling? Why would one single out third-party packages?
  - thesuperbigfrog 3y ago
    >> Do they also review the original tooling? Why would one single out third-party packages? Everything used for software development is explicitly approved. This includes programming languages, compilers, debuggers, IDEs, etc. We are primarily a Microsoft shop, so the majority of our development tools follow that direction. For FLOSS libraries, the approval process covers both IT security review, a source code scan / static analysis, as well as a legal review of the package's license to ensure it is not on the prohibited list. This makes management happy since it prevents potential security and legal issues. It keeps our customers happy since they get quality software made from fully traceable components.
    - keybored 3y ago
      It sounds like you download software blindly from the Internet with the extra preliminary steps that make your customers happy.
      - thesuperbigfrog 3y ago
        It's less blind than other places I have worked. When a CVE is announced, we know immediately if we are impacted and what will need to be fixed. Some places have no idea what their dependencies are. I am sure there are lots of log4j horror stories from Java shops that were not so careful.

noisy_boy 3y ago

I wonder if there is a scope for a "opt" / "extras" type level where libraries for stuff super commonly used, like JSON/YAML/ssl etc can be placed. It doesn't have to cover everything the defacto third party libraries do (that will be too much and not practical), just including happy paths should be enough for most people to just include the meta package and get the most generally used features instead of including a ton of third-party libraries. My knowledge about Rust's library system isn't great so there are probably several gaps in my argument.

steveklabnik 3y ago
Several people have tried to create such a thing over the years, but the ecosystem never uses them. People objectively prefer to pick their own set of packages.

thesuperbigfrog 3y ago

>> The Rust team prioritized keeping the standard library small, and allowing important but inessential functionality to live outside the stdlib and keep their own release schedule. There are crate "recommendation lists" like this: https://blessed.rs/crates https://blessed.rs/crates While these help, Rust's small standard library has slowed Rust adoption where I work because our IT security team must approve all third-party packages before we can use them. (Who blindly downloads code from the Internet and incorporates it in their software?) This means that unless there is a compelling need to use Rust, most teams will use C# because .NET is approved and has almost everything. I prefer Rust to C#, but we are not using it that widely yet. It's not a fair comparison, but it is how things currently are.

Aissen 3y ago
blessed.rs is fairly new. And if you look for yaml on this page, it links to serde; and serde_yaml being deprecated (with no blessed fork yet) is precisely part of the issue discussed in the parent article: https://lib.rs/crates/serde_yaml https://lib.rs/crates/serde_yaml ; and that's perfectly fine for the maintainers to declare, it was all open source with no warranty whatsoever.
marcosdumay 3y ago
> our IT security team must approve all third-party packages before we can use them Do they also review the original tooling? Why would one single out third-party packages?
- thesuperbigfrog 3y ago
  >> Do they also review the original tooling? Why would one single out third-party packages? Everything used for software development is explicitly approved. This includes programming languages, compilers, debuggers, IDEs, etc. We are primarily a Microsoft shop, so the majority of our development tools follow that direction. For FLOSS libraries, the approval process covers both IT security review, a source code scan / static analysis, as well as a legal review of the package's license to ensure it is not on the prohibited list. This makes management happy since it prevents potential security and legal issues. It keeps our customers happy since they get quality software made from fully traceable components.
  - keybored 3y ago
    It sounds like you download software blindly from the Internet with the extra preliminary steps that make your customers happy.
    - thesuperbigfrog 3y ago
      It's less blind than other places I have worked. When a CVE is announced, we know immediately if we are impacted and what will need to be fixed. Some places have no idea what their dependencies are. I am sure there are lots of log4j horror stories from Java shops that were not so careful.