Small binaries has nothing to do with the reason for that. Build tools will only include what's needed either way, so e.g. your Hello World program will have parts of std::io and std::fmt, and not really anything beyond that. So you "pay for what you use", regardless of whether it's part of the standard library or an external library.

I think in Rust the choice is more one that originally prioritized viability of long-term maintenance of the project by keeping the volume and surface of the standard library small. For all more recent inclusion the inclusion criteria seem to be either "small ecosystem functionality that everybody is using and has proven to be valuable" (e.g. once_cell) or "what is close-to-optimal solution for critical parts of the ecosystem that we have to include to minimize ecosystem splintering" (e.g. the work around std::future). I wouldn't be surprised if there are actual written down criteria for std inclusion somewhere.

> I wouldn't be surprised if there are actual written down criteria for std inclusion somewhere.

I’m not aware of the current state, but in the old days, it was roughly:

1. Is this useful in virtually every Rust program?

2. Is this something (data structures, mostly) that requires a lot of unsafe to implement?

3. Is this a vocabulary type?

Any of these is a slam dunk, anything else is more subjective.

>1. Is this useful in virtually every Rust program?

That's too strict a criterion for a standard library!

Sure, different people can have different opinions. But it’s also not literally true, in the sense that it’s only one of three criteria, but also because it’s more of a conceptual framing than something to be taken exactly. There’s just a high bar of usefulness required.

You can tell that this isn’t literally true just by looking at the contents of the standard library.

That doesn’t make sense, you don’t link against the entire rust stdlib, you compile directly against its source. You don’t get more than what you call.

You don’t compile the Rust standard library from source, you link against a pre-built one. There is an unstable option to compile the standard library from source.

That said, you’re right that “to keep binary size down” isn’t why the standard library is small. Heck, that you don’t compile from source means sometimes binaries are larger than they have to be, even with LTO! It is largely because anything that’s there has to be supported exactly as is forever, interface wise, and for many things, we did not have the confidence on what the right interface would be. Furthermore, it’s harder to maintain the standard library than it is a package out of tree for a variety of reasons.

Thank you for the correction. My confusion comes from being able to command-click on standard library types and methods, and being taken to their implementation, not just a declaration. I realize these aren't really concepts in Rust the same way they are in e.g. C/C++, but I figured if the source is present, the compiler is smart enough to not be over-compiling unused symbols.

Yeah, it's all good. Rustup will also distribute the source:

  ~> rustup component list | rg src
  rust-src (installed)

But this is so that that workflow works well, not because the compiler actually uses it during the build.

> the compiler is smart enough to not be over-compiling unused symbols.

This is true even without the source, mind you, but the devil is just in the details. Stuff like the panic and/or formatting machinery is known to creep in even if you don't think you're using it, because some edge case might. This only truly matters for embedded and similar, but it's still a thing.

Actually, this is not correct at present. Compiling the stdlib as part of building a project is only supported as a special option in nightly rust.