What is the roadmap on getting rid of the need for libc?
Given how terrible libc is, I personally would make that a high priority, though I guess in Linux you can't even start up a process without libc (maybe that is a misunderstanding?), which makes the situation less clean, but at least you could get to a point where you never call back into it after entry into main.
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.
You don't need a C standard library to run programs on Linux (nor any other system).
My guess is that the Rust team consider that relying on a well tested C codebase is safer than writing tons of unsafe platform-specific code, to replace the functionality offered by libc.
Anyway, I think the Redo project do have a Rust standard library that calls directly the OS and doesn’t need a C library, since they are writing a 100% Rust based stack.
> My guess is that the Rust team consider that relying on a well tested C codebase is safer than writing tons of unsafe platform-specific code, to replace the functionality offered by libc.
I'm copying that to my notes to use as a clear and concise explanation to people who want to work 'around' libc.
Do you suggest they should use raw system calls? On most systems your options are either calling standard C functions or doing raw calls (not portable).
And what about systems that don't have a stable interface below dynamically linking that platform's system-provided libc? Just let every program break when the system updates?
Ah. Well, right now, the standard library relies on a libc of some kind. If you use only core, then there's no reliance on a libc.
There has been some interest in making it easy to have stdlib without a libc; and some refactorings to std that may make it easier to do so, but those haven't come to fruition just yet.
