> in a way a Go program is "closer to the metal" than a C program.
It's amusing how often people try to one-up C with their favorite language, and how these attempts are almost never successful.
You can write C that doesn't use libc, that has no access to any system services, or indeed that runs under no operating system at all. For example, an operating system kernel itself. In no way is a Go program "closer to the metal" than a C program.
I was referring to a 'standard' program using the language's corresponding stdlib. And while not as useful this days C's "stdlib" is incredibly thick and complex. Go's stdlib is probably comparable to Plan 9's basic C libraries in complexity, but is portable and provides much more functionality.
Also note that Go can do all the things you mention, including writing a 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.
And the people who suggest glib is the answer to C's library needs are scary and depressing, glib just adds another layer of (very unportable!) crud on top of libc for no real gain other than keeping people from learning how to properly write C (data structures in particular).
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.
It's amusing how often people try to one-up C with their favorite language, and how these attempts are almost never successful.
You can write C that doesn't use libc, that has no access to any system services, or indeed that runs under no operating system at all. For example, an operating system kernel itself. In no way is a Go program "closer to the metal" than a C program.