4 ms·
Realistically? Never. If you're running on a UNIX system, libc is your only portable interface to the system. You can use the syscall layer on some NIX-like pl
by binarycrusader 11y ago
Realistically? Never. If you're running on a UNIX system, libc is your only portable interface to the system. You can use the syscall layer on some NIX-like platforms (such as Linux), but it will leave you to replicate a lot of the work that it already does.
On Solaris, as one example, there is no stable syscall layer -- libc is your only interface to the system. There's good reason for that too; on Solaris, libc is updated with security and performance improvements on a regular basis for each new hardware generation and other improvements in the operating system. It automatically accounts for things that might cause pipeline stalls (think memcpy, etc.) in newer processor generations, and so on.
Now with that said, what you could advocate is that libc, etc. be rewritten in RUST, but exposed via the "C" ABI convention that RUST provides. It wouldn't be as great as native RUST, but it would still be an improvement.
There are no compelling arguments for getting rid of libc that I've heard yet for platforms where libc is well-maintained. On Solaris, there are strict compatibility guarantees for every interface, so applications can assume changes in libc will never break them as long as the interface they're using lists an appropriate stability level in the manual page.
A world where every language implements its own version of libc seems like it would increase the number of defects, not decrease them. We could of course argue that those implementations might be better than libc, but I think whatever possible benefit there might be there is lost in the likelihood that each language will have its own flaws in its implementation.
I believe the best view of an operating system is as a fully-integrated set of components. Everything from the kernel up to the system libraries should look and act consistently, and that's impractical to do if every component is viewed as interchangeable. Integration from top to bottom in an OS stack can produce incredibly great results and provide unparalleled reliability, availability, and performance.
- _ph_ 11y agoMost of the Go codebase is portable across systems without using libc, so being libc free is definitely possible.
- binarycrusader 11y agoNo, on Solaris Go uses libc. I know because I am one of the people that worked on the port. Windows is similar in that regard to a degree as well.