4 ms·
Why does rust need a libc? Im still new to rust, so forgive me if this is a stupid question.
by miffe 11y ago
Why does rust need a libc?
Im still new to rust, so forgive me if this is a stupid question.
- erickt 11y agoNo it's not a stupid question. libc (or CRT on windows) really is the library that exposes all the user space system libraries. It contains the functions to do IO, sockets, threads, and etc. So we use it to expose that functionality to rust users. Now there are some languages, namely Go, that skip libc and just implement directly against the syscall interface. Go has the advantage of being able to draw from Google's vast experience interacting deep within the system, so it was comparatively cheap for them to do this. For rust, it never really felt like it was worth the effort for the benefit we'd get out of it. It was more important to get the language done.
- noir_lord 11y agoIn theory you could later implement libc (libcrust. calling it now) in Rust as well so you get the best of both worlds couldn't you?
- vezzy-fnord 11y agoI'm not sure if it makes any sense to implement libc in anything other than C.
- yellowapple 11y agoIt would be an interesting experiment, seeing as how Rust code can be called from C and vice versa. There's already been some tinkering on various operating system kernels written in Rust (even if they don't do much besides printing "Hello, world!" quite yet), so I figure a pure-Rust standard library is the next step in that.
- kibwen 11y agoThis is actually a project I have considered with in the past, though not very seriously. Theoretically you could completely replace libc with a Rust implementation and use it system-wide, and the rest of your programs would be none the wiser. It's a non-trivial amount of effort, however. :)
- barrkel 11y agoProgramming languages on Windows other than C and C++ typically link with kernel32.dll and so on, and not a C runtime. This gives a stable interface at a slightly higher level of abstraction than syscalls. Relying on libc is more a Unixism; without duplicating a bunch of the work in libc, you simply can't use many system services in ways the end user expects - network name resolution comes to mind (NSS), but other things, like threads, don't have portable standards at a lower level.
- maxerickson 11y agoPython links the VC runtime (so not even the system CRT). MinGW links the system CRT by default, which is one reason that it can be fussy to compile Python extensions with it. (I'm more curious about what a survey would reveal than I am trying to argue with you about what you said)
- barrkel 11y agoSoftware originating on posix systems is most easily ported at the libc interface level, so it's natural to target some libc on Windows. But it usually creates awkwardness, either because of version dependencies, or the system libc not having everything they need and using some specific VC runtime, like you say. I was a developer on the Delphi compiler for some years. Statically linked, a minimal Delphi executable had no dependencies other than the *32.dll libraries. And there is no system functionality that requires use of some libc, or significant duplication of effort. The Win32 API doesn't even use the C calling convention.
- barosl 11y agoThere have been some efforts to make Rust utilize the native Windows API instead of libc on Windows. While this is ongoing, the lack of experienced Windows developers participating the Rust project has been slowing down the progress. We'll be very happy to get your contribution!