Eh, that's a bit problematic — there's no standardization in what's in a standard library. Some languages have stdlibs that just contain "stuff everybody needs

Eh, that's a bit problematic — there's no standardization in what's in a standard library. Some languages have stdlibs that just contain "stuff everybody needs" — stuff every app or library written in the language will use (common data structures, concurrency primitives, etc.), such that anyone who "knows the language" would also be expected/required to know (or at least know of) those components, if they have any hope of being productive in the language. But other languages have huge stdlibs, that include a bunch of stuff that almost nobody is even aware of, such that most developers won't actually need to know about it in order to effectively maintain other people's code in the language. These are essentially just weird niche libraries that happen to ship with the runtime for some reason. Examples of weird niche libraries that are technically "stdlib": • PHP has an Ingres driver built in. That's Ingres, the predecessor to Postgres. • Ruby ships with a CJK character-normalization CLI utility. • Erlang/OTP has "Megaco" (http://erlang.org/doc/apps/megaco/megaco_intro.html http://erlang.org/doc/apps/megaco/megaco_intro.html) — an H.248 media gateway daemon library. Admittedly, languages do tend to gradually factor these weird niche bits out into separate packages. (Ruby just moved almost all of its stdlib into ecosystem packages in 3.0. Some ecosystem packages are just now install-by-default — but maybe won't be in the future.) Also, the behavior of these weird niche bits is not usually specified as part of the language's spec... but that doesn't mean much, as often, these languages don't even have specs. In those cases, the reference implementation is the spec — and so, if the reference impl includes these libs, "the language" includes these libs.