Indeed, it has no bearing on binary size at all, because none of it will be included. If you are coming from the perspective where the standard library is entirely unusable to begin with, then improving the standard library is irrelevant at best. It also likely means that at least some time and effort will be taken away from improving the things that you can use to be spent on improving a bunch of things that you can't use.
I feel like this is an organizational problem much more than a technical one, though. Rust can be different things to different people, without necessarily forcing one group to compromise overmuch. But some tension is probably inevitable.
> Indeed, it has no bearing on binary size at all, because none of it will be included.
That depends on the language. In an interpreted language (including JIT), or a language that depends on a dynamically linked runtime (ex c and c++), it isn't directly included in your app because it is part of the runtime. But you need the runtime installed, and if your app is the only thing that uses that runtime, then the runtime size is effectively adds to your installation size.
In languages that statically link the standard library, like go and rust, it absolutely does impact binary size, although the compiler might use some methods to try to avoid including parts of the standard library that aren't used.
Embedded Rust usually means no_std Rust, in which case no, neither the standard library nor any runtime to support it get included in the resulting binary. This isn't getting externalized either; no_std code simply cannot use any of the features that std provides. It is roughly equivalent to freestanding C.
What you say is true enough for external-runtime languages and Go, though TinyGo is available for resource-constrained environments.
Well, Rust's standard library has three components, named core, alloc and std
The no_std Rust only has core but this is indeed a library of code, and freestanding C does not provide such a thing = freestanding C stdlib provides no functions, just type definitions and other stuff which evaporates when compiled.
Two concrete examples to be going along with: Suppose we have a mutable foo, it's maybe foo: [i32; 40]; (forty 32-bit signed integers) or in C maybe they're int foo[40];.
In freestanding C that's fine, but we're not provided with any library code to do anything with foo, we can use the core language features to write it outselves, but nothing is provided.
Rust will happily foo.sort_unstable(); this is a fast custom in-place sort, roughly a modern form of introspective sort written for Rust by its creators and because it's in core, that code just goes into your resulting embedded firmware or whatever.
Now, suppose we want to perform a filter-map operation over that array. In C once again you're left to figure out how to write that in C, in Rust foo impl IntoIterator so you can use all the nice iterator features, the algorithms just get baked into your firmware during compilation.
I feel like this is an organizational problem much more than a technical one, though. Rust can be different things to different people, without necessarily forcing one group to compromise overmuch. But some tension is probably inevitable.