Hacker News Reader

Comment by maxfurman | Hacker News Reader

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.

View on HN

>> 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

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.

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 ; and that's perfectly fine for the maintainers to declare, it was all open source with no warranty whatsoever.

> 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?

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

It sounds like you download software blindly from the Internet with the extra preliminary steps that make your customers happy.

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.

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.

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.

Reply on news.ycombinator.com