&gt; That&#x27;s a valid philosophy, but also one that leads to problems with fragmentation, quality, portability, dependency management, and compiler support.<p>No, not necessarily. We would like for the standard library to remain minimal, but one of its important functions is to collect common interfaces to maximize interoperability between crates. This has worked well in practice so far.<p>Similarly, the standard library provides <i>portable</i> facades on top of platform specific APIs, for example, for performing IO. Crates can take advantage of this so that they can be portable themselves. Moreover, crates themselves can also provide portable facades over platform specific APIs, so I&#x27;m not convinced that this will be a problem in practice.<p>Dependency management is handled quite well by Cargo. It has been a wonderful tool to have at our disposal and is really the crux of what makes a small standard library possible.<p>Compiler support is a good argument, but one that I hope becomes weaker in time as we stabilize more functionality.<p>To be clear, I agree that a small standard library has its own downsides. In particular, <i>quality</i> is IMO on of the best arguments against a small standard library. Fortunately, we trying to mitigate this by adopting officially blessed libraries into the `rust-lang` organization: <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;blob&#x2F;master&#x2F;text&#x2F;1242-rust-lang-crates.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;blob&#x2F;master&#x2F;text&#x2F;1242-rust...</a> --- This allows us to avoid the problems with a big standard library (too much stuff that is hard to evolve because of stability) while still providing quality with crates that we promise to maintain.