As I still run in to glibc version issues a little now and then (admittedly not very often, thankss to containers), I hope to see rust getting rid of libc one day. But I don't expect that in the near future, because as the author mentions, libc is very mature, so replacing it must be done with a lot of caution. But this really looks like a step in the right direction.
this post was submitted on 26 Sep 2023
18 points (100.0% liked)
Rust
5981 readers
45 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
Funny you should mention that. Recently, glibc 2.38 was released with broken performance in its allocator API. Hell, one of the developers tried to argue the regression is good to force people to stop using the regressed API unnecessarily (the argument didn't go far, regressions got fixed).
Reports in the wild:
https://github.com/mpv-player/mpv/issues/12076
https://bugs.archlinux.org/task/79300
Links to the libc-alpha relevant threads can be found there.
Speaking of libc allocators, musl's allocator is also shit. That's why some Rust projects use another global allocator in their musl builds. Some of them probably haven't noticed yet that those builds are not static anymore because of that ๐ .
Hmm now it would be interesting how eyra fares for allocating. And also why does musl not implement a faster allocator? I get that it should be backwards compatible but the gap to glibc seems to be really large.