Well, by "loves Rust", they mean "no Rust standard library, no external dependencies, and no Rust anywhere but leaf binaries." Which, if that brings them joy, more power to them.
I mean, that's Rust too. I love my bells-and-whistles Rust with Cargo and crates.io and all that, but I also love that those are not mandatory. You can fit Rust into all sorts of more constrained environments and get all the benefits of the language (albeit not of the ecosystem).
They love "Rust, the language" like the Linux kernel Rust developers or the various embedded developers singing Rust's praises do.
I've written Rust "shell scripts" where they don't really depend on the ecosystem and are purely there so that I can have APIs that return Option<T> or Result<T, E> instead of things like Python's os.getcwd documentation just assuming Everyone Knows™ that getcwd is unavoidably fallible at the kernel level, or bash being annoying with its opt-out whitespace splitting and retrofitted array support.
That's loosely analogous to what they're doing with their internal alternative to calling libc functions. Using "Rust, the means of having a nicer type system".
Generally lean compiled binaries I manage, because I find Cargo's too eager to find excuses to do a rebuild with an invalidated build cache. Using rust-analyzer, bacon, and --release in the same project? You're on borrowed time. rustup update? That's a rebuild. Compiling both the host app and the WASIp2 plugins for it without forcing separate target directories? Yup. etc. etc. etc.
Once the nightly cargo scripts feature is stabilized and rust-analyzer supports it, I'l re-evaluate something like https://rust-script.org/ since the main place I still use Python (aside from stuff where the Rust ecosystem isn't there yet like memory-safe Qt QWidgets bindings, SQL databasing with Django ORM/SQLAlchemy+Alembic "derive is authoritative and will be diffed against the in-database schema"-style autogeneration of draft migrations and abstracting over SQLite's limited ALTER TABLE, and Django's ecosystem of reusable apps) is truly "too simple for me to be motivated to manage a new project folder" things.
I mean, they're not necessarily doing anything wrong. But core is basically bare metal and compiler intrinsics. There's no way to allocate memory or really do anything at all. It's perfectly sensible for kernel-level code where you don't have a memory allocator until you build one. (The one thing you do get is a lot of iterator machinery, including over byte slices.)
And while Rust is neat at that low a level, it's just barely recognizable as normal Rust.
Also, this means that they're committing to rebuilding all their own collection types on top of custom fallible allocation routines and unsafe. Which means that they may not have as much security auditing as the Rust std library. std isn't perfect, but it's frequently used as a testbed for people's theorem provers. Which has flushed some bugs in the past.
To be clear, I'm not criticizing them. I'm just pointing out that they're choosing to throw away pretty much everything but the borrow checker and iterators, and build from scratch, which likely requires lots of unsafe. So they won't see the same cost/benefit tradeoffs as "normal" Rust projects. Which may make sense.
(EDIT: Looking at some of their code, they seem to have already rebuilt an entire standard library using their own abstractions. But they've made it far enough to start seeing many of the benefits of Rust at higher levels, by that point. But that was a lot of code to rewrite.)
that sounds like there was a hole in the ecosystem for a more constrained standard library, and they are filling it in. hopefully some of the community will be interested in polishing it up as its own thing other people can use in similar situations.
A growable array on the heap, like alloc::vec::Vec but without the paths that abort when memory runs out: whatever may allocate returns an error instead.
So indeed they are not reimplementing things for the sake of it, there are important API differences.
What stands out to me from that quote (and checking the rest of the linked code) is that that entire file is LLM-generated, including the SAFETY: comments that are meant to explain why the unsafe Rust is valid (!).
At least in my experience writing unsafe Rust can be quite subtle (there's a whole book about it for a reason!), so that strategy strikes me as kind of insane. Then again, if they're using LLMs for their C maybe it's about as insane as what they were already doing...
Oh, that's most unfortunate. There are already several popular Rust crates which implement standard collections with fallible allocation semantics, crates which are widely used in embedded and small kernel contexts.
Apparently they just decided to vibe slop a bunch of unsafe code instead of taking a dependency on a popular, well-established crate that does one thing (with almost no transitive dependencies)? That's certainly a choice.
emk | a day ago
Well, by "loves Rust", they mean "no Rust standard library, no external dependencies, and no Rust anywhere but leaf binaries." Which, if that brings them joy, more power to them.
muvlon | 23 hours ago
I mean, that's Rust too. I love my bells-and-whistles Rust with Cargo and crates.io and all that, but I also love that those are not mandatory. You can fit Rust into all sorts of more constrained environments and get all the benefits of the language (albeit not of the ecosystem).
ssokolow | 22 hours ago
They love "Rust, the language" like the Linux kernel Rust developers or the various embedded developers singing Rust's praises do.
I've written Rust "shell scripts" where they don't really depend on the ecosystem and are purely there so that I can have APIs that return
Option<T>orResult<T, E>instead of things like Python'sos.getcwddocumentation just assuming Everyone Knows™ thatgetcwdis unavoidably fallible at the kernel level, or bash being annoying with its opt-out whitespace splitting and retrofitted array support.That's loosely analogous to what they're doing with their internal alternative to calling libc functions. Using "Rust, the means of having a nicer type system".
gnyeki | 15 hours ago
Do you run them with
cargo run? Or they are just very lean compiled binaries that you manage?hjvt | 15 hours ago
There's a nightly cargo feature on track for stabilization for this usecase: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#script
ssokolow | 15 hours ago
Generally lean compiled binaries I manage, because I find Cargo's too eager to find excuses to do a rebuild with an invalidated build cache. Using rust-analyzer, bacon, and
--releasein the same project? You're on borrowed time.rustup update? That's a rebuild. Compiling both the host app and the WASIp2 plugins for it without forcing separate target directories? Yup. etc. etc. etc.Once the nightly cargo scripts feature is stabilized and rust-analyzer supports it, I'l re-evaluate something like https://rust-script.org/ since the main place I still use Python (aside from stuff where the Rust ecosystem isn't there yet like memory-safe Qt QWidgets bindings, SQL databasing with Django ORM/SQLAlchemy+Alembic "
deriveis authoritative and will be diffed against the in-database schema"-style autogeneration of draft migrations and abstracting over SQLite's limitedALTER TABLE, and Django's ecosystem of reusable apps) is truly "too simple for me to be motivated to manage a new project folder" things.gignico | a day ago
It makes sense to enforce the usage of project-level abstractions. I suppose they mean
no_stdbut still usecoreemk | 23 hours ago
I mean, they're not necessarily doing anything wrong. But
coreis basically bare metal and compiler intrinsics. There's no way to allocate memory or really do anything at all. It's perfectly sensible for kernel-level code where you don't have a memory allocator until you build one. (The one thing you do get is a lot of iterator machinery, including over byte slices.)And while Rust is neat at that low a level, it's just barely recognizable as normal Rust.
Also, this means that they're committing to rebuilding all their own collection types on top of custom fallible allocation routines and
unsafe. Which means that they may not have as much security auditing as the Ruststdlibrary.stdisn't perfect, but it's frequently used as a testbed for people's theorem provers. Which has flushed some bugs in the past.To be clear, I'm not criticizing them. I'm just pointing out that they're choosing to throw away pretty much everything but the borrow checker and iterators, and build from scratch, which likely requires lots of
unsafe. So they won't see the same cost/benefit tradeoffs as "normal" Rust projects. Which may make sense.(EDIT: Looking at some of their code, they seem to have already rebuilt an entire standard library using their own abstractions. But they've made it far enough to start seeing many of the benefits of Rust at higher levels, by that point. But that was a lot of code to rewrite.)
zem | 20 hours ago
that sounds like there was a hole in the ecosystem for a more constrained standard library, and they are filling it in. hopefully some of the community will be interested in polishing it up as its own thing other people can use in similar situations.
gignico | 21 hours ago
Did they rewrite things like
Vecand similar? I supposed they wanted to implement interfaces to the data structures already present in the C code.[OP] lorenzleutgeb | 21 hours ago
There is a
systemd_shared::alloc::Vecatsrc/rust/systemd-shared/alloc.rs:362-370, see also commit626261b.gignico | 21 hours ago
Interesting. Quote from there:
So indeed they are not reimplementing things for the sake of it, there are important API differences.
eta | 19 hours ago
What stands out to me from that quote (and checking the rest of the linked code) is that that entire file is LLM-generated, including the
SAFETY:comments that are meant to explain why the unsafe Rust is valid (!).At least in my experience writing unsafe Rust can be quite subtle (there's a whole book about it for a reason!), so that strategy strikes me as kind of insane. Then again, if they're using LLMs for their C maybe it's about as insane as what they were already doing...
emk | 13 hours ago
Oh, that's most unfortunate. There are already several popular Rust crates which implement standard collections with fallible allocation semantics, crates which are widely used in embedded and small kernel contexts.
Apparently they just decided to vibe slop a bunch of
unsafecode instead of taking a dependency on a popular, well-established crate that does one thing (with almost no transitive dependencies)? That's certainly a choice.gignico | 9 hours ago
Interesting, what’s the name of the crate you’re talking about?
gignico | 19 hours ago
I didn’t realise that it was AI-written. Yes that’s pretty insane for a fundamental software like
systemdbut that’s life nowadays I guess…[OP] lorenzleutgeb | 23 hours ago
Yes, to me
keyring-setup.rs(for example) looks like that's what they are doing.I guess they gotta start somewhere ☺️
greg_loscombe | 22 hours ago
I dont even want that much tbh...
peter-leonov | 18 hours ago
Via Skype?