alt Hacker News> you lose out on any of the optimizations a libc has that you might not or didn't think about (like memoization of getpid() )
Not much of a big deal. These "optimizations" caused enough bugs that they actually got reverted.
https://www.man7.org/linux/man-pages/man2/getpid.2.html
Because of the aforementioned problems, since glibc 2.25,
the PID cache is removed: calls to getpid() always invoke
the actual system call, rather than returning a cached value.
> Get rid of libc and you gain the ability to have zero global state in exchange.
No you don't, you still have the global state the kernel is maintaining on your behalf. Open FDs, memory mappings, process & thread scheduling states, limits, the command line arguments, environment variables, etc... There's a shitload of global state in /proc/self/
Also the external connections to the process (eg, stdin/out/err) are still inherently global, regardless of however your runtime is pretending to treat them.
And it's not like you even managed to reduce duplicated state since every memory allocator is going to still track what regions it received from the kernel and recycle those.
> Freestanding C actually makes sense [..] No legacy nonsense to worry about
Except for, you know, the entire language :p