Zig competes with C instead of depending on it. The Zig Standard Library does not depend on libc.
That's an interesting choice. I'm sure there are other semi-recent languages that have made the same choice, it would be interesting to hear the benefits and problems of that approach.
I say semi-recent, because there are of course many from before C or that competed with C and Unix initially, but unless they are still used much (Lisp?) it's not necessarily the best for a comparison of modern issues.
A useful thing of this is also the portability story. Go for example is pretty good as far as I'm aware of cross-compiling to a different target. The main problem would probably be the extra implementation needed, instead of just writing a binding to libc. It also is more popular lately to prefer static linking vs. dynamic for deployment ease too, which not requiring linking to libc may help.
For zig it is not all or nothing of course. It is pretty easy to link and use c if wanted. The following for example asks the compiler to link against libc.
zig build_exe main.zig --library c
One other benefit that zig gets is more compile-time execution opportunity. The math library for example being written in zig means that we can determine `math.log(7)` and use it for compile calculations when using libm we couldn't.
it would be interesting to hear the benefits and problems of
that approach.
A big problem is that libc interfaces are more stable, which means with libc you don't need to recompile as much when the system is upgraded, if ever.
Solaris and Linux work hard to keep their kernel interfaces stable, so it's less of an issue there. But Apple, for example, very explicitly says that kernel interfaces (Unix syscalls and Mach ports) are unstable and unsupported, generally speaking. Consumable interfaces are provided via the userland runtime (e.g. libc). Notably, Apple's toolchains don't even support static compilation.
A system like OpenBSD isn't so gratuitous as Apple in terms of breaking compatibility, but because they're focused on improving and simplifying a cohesive system, they don't flinch about breaking compatibility when needed. For various reasons that happens more often with kernel interfaces than with libc interfaces.
Are you sure? I'm seeing reports that go sometimes wouldn't run with musl instead of GNU libc, with a runtime segfault[1]. That seems to depend on libc. Are you saying that Go's standard library primitives are not shims (or more complex structures) built on top of libc?
Go uses libc optionally (for some things like DNS resolving). You can build Go programs which do not utilize libc by disabling cgo and building static binaries. By default the biggest part of Gos stdlib isn't based on libc, but some small parts are.
That's an interesting choice. I'm sure there are other semi-recent languages that have made the same choice, it would be interesting to hear the benefits and problems of that approach.
I say semi-recent, because there are of course many from before C or that competed with C and Unix initially, but unless they are still used much (Lisp?) it's not necessarily the best for a comparison of modern issues.