> The discussion is about large standard libraries vs. package managers. C and C++ are even older languages that had neither. Back then, the idea of having a large abstraction layer between the language and the OS wasn't even thinkable -- that idea didn't really appear before the 90s.

Agreed, but this is my point. I don’t think the distinction between “20th century vs 21st century” is particularly meaningful, but I’m responding to the assertion that 20th century languages are characterized by large standard libraries—how can that be the case if standard libraries didn’t really exist apart from a few languages in the very final years of the 20th century?

> If you don't know the size of Java's standard library in the 90s, it's maybe risky to imply that it must have been small. :) Kidding a bit. But to give a hint, it included two different incompatible GUI frameworks by 1998.

Fair enough.

> JavaScript is from the 90s, but wasn't a standalone programming language until Node.js, which was released in 2009.

No, but it had a standard library (browser APIs) long before NodeJS.

> C# is the newest non-Go language you mention with a large standard library. It was released in 2000 (so in the 20th century if we're being pedantic), and even it has moved a lot of stuff into Nuget packages that used to be built in. For example, the entirety of ASP.net.

But enough remains in the standard library for it to be considered “large”.

Anyway, if there are only a handful of 20th century languages with large standard libraries (all clustered around the turn of the millennium) and seemingly only one mainstream language in the 21st century with a small standard library (Rust), I think the original claim that Go is the exception among 21st century languages is incorrect.

You’re bending logic to the point where I have a very hard time assuming you’re arguing in good faith.

I assure you I’m not the one bending logic. Good day.

The idea was surely thinkable, just not for C, whose UNIX was basically its standard library.

Hence why everyone kind of expects POSIX to compensate for the anemic ISO C.

While ISO C++98 was built on the same anemic principle, due to its relation to C and UNIX, all major C++ compilers had rich frameworks, which unfortunately WG21 ignored.

But C isn’t tied to POSIX any more than it is tied to the Windows API. The standards working groups weren’t stupid, they just tried to specify things in a way that wouldn’t force an inefficient UNIX emulation layer on everyone else.

Yet we ended up with POSIX everywhere there is a C compiler, with exception of hardware that is worse than a PDP-11.

Even still, posix is pretty anemic by the standards we’re talking about.

Indeed, although it doesn't change the fact that C kind of needs to bring UNIX for the ride despite its portability sales pitch.

Agreed.