[embedding-shape]

326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal.

Takes what, maybe 15 seconds to compile on a high-core machine from scratch? Isn't the end of the world.

Worse is the scope to have to review all those things, if you'd like to use it for your main passwords, that'd be my biggest worry. Luckily most are well established already as far as I can tell.

[dijit]

Why are you talking about compile times in a thread about supply chain security.

326 packages is approximately 326 more packages than I will ever fully audit to a point where my employer would be comfortable with me making that decision (I do it because many eyes make bugs shallow).

It's also approximately 300 more than the community will audit, because it will only be "the big ones" that get audited, like serde and tokio.

I don't see people rushing to audit `zmij` (v1.0.19), despite it having just as much potential to backdoor my systems as tokio does.

[elAhmo]

"326 seems large, but not abnormal" was the state of JS in the past as well.

Chance of someone auditing all of them is virtually zero, and in practice no one audits anything, so you are still effectively blindly trusting that none of those 326 got compromised.

[seanw444]

It is baffling to me that a language that is as focused on safety/security as Rust decided to take the JavaScript approach to their ecosystem. I find it rather contradictory.

[embedding-shape]

That's because you're mixing things. "Rust the language" isn't the one starting new projects and add new dependencies that have hundreds of dependencies of their own, this is the doing of developers. The developers who built Rust with a focus on safety and security is not the same developers mentioned before.

[mort96]

Rust and Cargo are, if not inseparable, at least tightly connected. Rust and Rust's stdlib are inseparable.

Cargo is modeled after NPM. It works more or less identically, and makes adding thousands of transient dependencies effortless, just like NPM.

Rust's stdlib is pretty anemic. It's significantly smaller than node's.

These are decisions made by the bodies governing Rust. It has predictable results.

[array_key_first]

Rust's stdlib is fine, it's similar to C++ and C++ never had this problem.

It's just that it you give developers tools, they will absolutely abuse them to the highest extent. The problem with cargo is it's too good, so of course devs are gonna be pulling hundreds of dependencies. It's also why things like Claude Code have so much potential for shitty outcomes. Developers are lazy to the n-th degree. In fact, being a developer is predicated on being lazy. Laziness is the whole motivation behind software!

[nathanmills]

ohh noo, the devs gave users a choice instead of forcing their hand..

[mort96]

Design decisions have predictable consequences. Large masses of people, who make up an ecosystem like the that of a programming language community, respond predictably to their environment. Each individual programmer has a choice, sure, but you can't just "individual responsibility" your way out of the predictable consequences of incentive structures.

[seanw444]

That's true. But it does seem like a logic result of having no real standard library. That lone fact has kept me away from Rust for real projects, because I don't want to pull in a bunch of defacto-standard-but-not-officially dependencies for simple tasks. That's probably a large contributor to the current state of dependency bloat.

[embedding-shape]

Yeah, it does require you to be meticulous about what you depend on. Personally I stick with libraries that don't use 100s of other crates, and tried and reviewed various libraries over the year, so you have your "toolkit" of libraries you know are well built and you know how they work internally.

Ultimately in any language you get the sort of experience you build for yourself with the environment you setup, it is possible in most languages to be more conservative and minimal even if the ecosystem at large is not, but it does require more care and time.

[wongarsu]

'no real standard library' doesn't seem entirely fair. Rust has a huge standard library. What it does have is the policy to only include "mature" things with little expected API evolution in the standard libary, which leaves gaping holes where a json parser, a http client or a logging library should be. Those are all those defacto-standard-but-not-officially dependencies

[NetMageSCW]

Perhaps that’s just a sign Rust isn’t suitable for those type of projects.

[pdimitar]

So you only use languages that have a built-in HTTP client, JSON / CSV / XML parsers, and such?

[latexr]

I’m not the person you asked, but given the choice I avoid a language without JSON parsing officially supported because I need that frequently. It’s the reason I never picked up Lua, despite being interested in it.

[DarkUranium]

I think there's actually a decent compromise one could make here (not that Rust did, mind), and it's what I'm planning for my own language, in big part to avoid the Rust/NPM/etc situation.

TL;DR, the official libraries are going to be split into three parts:

---

1) `core.*` (or maybe `lang.*` or `$MYLANGUAGE.*` or w/e, you get the point) this is the only part that's "blessed" to be known by the compiler, and in a sense, part of the compiler, not a library. It's stuff like core type definitions, interfaces, that sort of stuff. I may or may not put various intrinsics here too (e.g. bit count or ilog2), but I don't know yet.

Reserved by the compiler; it will not allow you to add custom stuff to it.

There is technically also a "pseudo-package" of `debug.*` ("pseudo" in the sense that you must always use it in the full prefixed form, you can't import it), which is just going to be my version of `__LINE__` and similar. Obviously blessed by compiler by necessity, but think stuff like `debug.file` (`__FILE__`), `debug.line` (`__LINE__`), `debug.compiler.{vendor,version}` (`__GNUC__`, `_MSC_VER`, and friends). `debug` is a keyword, which makes it de-facto non-overridable by users (and also easy for both IDEs and compiler to reason about). Of course I'll provide ways of overriding these, as to not leak file paths to end users in release builds, etc.

(side-note: since I want reproducible builds to be the default, I'm internally debating even having a `debug.build.datetime` or similar ... one idea would be to allow it but require explicitly specifying a datetime [as build option] in such cases, lest it either errors out, or defaults to e.g. 1970-01-01 or 2000-01-01 or whatever for reproducibility)

---

2) `std.*`, which is minimal, 100% portable (to the point where it'd probably even work in embedded [in the microcontroller sense, not "embedded Linux" sense] systems and such --- though those targets are, at least for now, not a primary goal), and basically provides some core tooling.

Unlike #1, this is not special to the compiler ... the `std.*` package is de jure reserved, but that's not actually enforced at a technical level. It's bundled with the language, and included/compiled by default.

As a rule (of thumb, admittedly), code in it needs to be inherently portable, with maybe a few exceptions here or there (e.g. for some very basic I/O, which you kind of need for debugging). Code is also required to have no external (read: native/upstream) dependencies whatsoever (other than maybe libc, libdl, libm, and similar things that are really more part of the OS than any particular library).

All of `std.*` also needs to be trivially sandboxable --- a program using only `core.*` & `std.*` should not be able to, in any way, affect anything outside of whatever the host/parent system told it that it can.

---

3) `etc.*`, which actually work a lot like Rust/Cargo crates or npm packages in the sense that they're not installed by default ..... except that they're officially blessed. They likely will be part of a default source distribution, but not linked to by default (in other words: included with your source download, but you can't use them unless you explicitly specify).

This is much wider in scope, and I'm expecting it to have things like sockets, file I/O (hopefully async, though it's still a bit of a nightmare to make it portable), downloads, etc. External dependencies are allowed here --- to that end, a downloads API could link to libcurl, async I/O could link to libuv, etc.

---

Essentially, `core.*` is the "minimal runtime", `std.*` is roughly a C-esque (in terms of feature count, or at least dependencies) stdlib, and `etc.*` are the Python-esque batteries.

Or to put it differently: `core.*` is the minimum to make the language run/compile, `std.*` is the minimum to make it do something useful, and `etc.*` is the stuff to make common things faster to make. (roughly speaking, since you can always technically reimplement `std.*` and such)

I figured keeping them separate allows me to provide for a "batteries included, but you have to put them in yourself" approach, plus clearly signaling which parts are dependency-free & ultra-sandbox-friendly (which is important for embedding in the Lua/JavaScript sense), plus it allows me to version them independently in cases of security issues (which I expect there to be more of, given the nature of sockets, HTTP downloads, maybe XML handling, etc).

[jeroenhd]

I doubt Microsoft's kernel/system Rust code is pulling in a lot of crates. The Linux kernel sure isn't, and Android's Bluetooth stack doesn't seem to either.

Using crates is a choice. You can write fully independent C++ or you can pull in Boost + Qt + whatever libraries you need. Even for C programs, I find my package manager downloading tons of dependencies for some programs, including things like full XML parsers to support a feature I never plan to use.

Javascript was one of the first languages to highlight this problem with things like left-pad, but the xz backdoor showed that it's also perfectly possible to do the same attack on highly-audited programs written in a system language that doesn't even have a package manager.

[atdt]

What exactly would you have done differently?

Cargo made its debut in 2014, a year before the infamous left-pad incident, and three years before the first large-scale malicious typosquatting attacks hit PyPI and NPM. The risks were not as well-understood then as they are today. And even today it is very far from being a solved problem.

[Ferret7446]

Yet Go is half a decade older and seems to have handled the situation much better.

[pdimitar]

How does it handle better, exactly?

[mayama]

You can write simple http server or rest client with stdlib in Go. No need to include tokio, serde and hundred other cargos which constantly break things. I have apps written in Go more than a decade ago work the same now with recent version of Go. Where as, I had issues with getting few year old github apps in rust compiling and working in rust.

[cromka]

Same here.

[Ferret7446]

> 326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal.

That's a damning indictment of Rust. Something as big as Chrome has IIRC a few thousand dependencies. If a simple password manager CLI has hundreds, something has gone wrong. I'd expect only a few dozen

[gtest]

> 326 packages right now when doing a build. Seems large in general, but for a Rust project, not abnormal.

How many are third-party?