> I was referring to a 'standard' program Though you probably didn't mean "standard" literally, writing C programs that have no access to the standard library

> I was referring to a 'standard' program Though you probably didn't mean "standard" literally, writing C programs that have no access to the standard library is explicitly mentioned in the standard, which calls this a "freestanding implementation." > Also note that Go can do all the things you mention, including writing a kernel. You can't write memory management code in a language that provides automatic memory management. You just can't. And while I can believe that people who like Go are experimenting with using Go for most of an OS kernel (with a C kernel underneath it to handle things like memory management and probably interrupts), it's not the same as C where the whole kernel can be in C with the exception of highly hardware-specific code (booting, context switching code, syscall gates, etc). Aside from that, I don't think the performance of GC will ever be acceptable for a high-performance kernel. > Just to be clear, the real issue with C is not the language so much as the horrible libraries that have been built over decades of clumsily piling up complexity. Wait, now C is bad because some people wrote some bad libraries for it? Then don't use those libraries? No one's forcing you to use glib.