Hacker News Reader

Comment by erickt | Hacker News Reader

No 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.

View on HN

Programming 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.

Python 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)

Software 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.

There 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!

In 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?

I'm not sure if it makes any sense to implement libc in anything other than C.

It 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.

This 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. :)

Reply on news.ycombinator.com