

Linux kernel Rust is special because of using the kernel’s memory model instead if Rust’s, not because they don’t use external crates (they actually do vendor a few).
no_std or no external crates doesn’t alone qualify as special.
Previous Account: @badmin@lemm.ee
Alternative Account: @badmin@reddthat.com


Linux kernel Rust is special because of using the kernel’s memory model instead if Rust’s, not because they don’t use external crates (they actually do vendor a few).
no_std or no external crates doesn’t alone qualify as special.


And compiling foss rust projects regularly gets my computer to freeze up.
Provide one example.


If it’s similar to the kernel policy, they can incorporate desirable crates in-tree if needed. A crate is just a modular unit after all. And what’s more relevant here is std/no-std dependency assumptions.
References about external crates usually mean avoiding “crates.io” in the build process, not avoiding crates themselves as modular units.
And even if a crate is not fully incorporated, modules from it can be copied (and possibly modified) still, as people in the real world tend to not re-implement stuff from first principles 😉


Assuming you’re not being clownish on purpose, maybe you should actually try the language one day, or just building some project with the compiler, instead of regurgitating memes you heard from others.


rustix supports no_std. spin too. And there are others. Those are the good low-level crates. A hard dependency on std is itself an indication that a crate is not really low-level.
The announcement doesn’t say core only btw. alloc is there too which is very relevant. So this doesn’t filter out anything from the no_std world.
But this is all about ecosystem choice subtleties, not some change in how the language itself is used, which is why I found your comment amusing.


as a Rust dev, it also sounds like I would struggle…
It’s literally Rust. If you actually knew rust, why would you struggle?


You’re using the syntax and presumably compiler (rustc)
but almost nothing else from Rust
waat 😲


That’s python’s problem. You have no idea how much of a life improvement simply using uv + an older python version (uv natively supports this) is.


All major distributions ship their own compiled rustc/cargo packages already, and they’ve done so for years.
And putting rust projects using nightly features aside*, stable rust version updates are much less disruptive than major GCC or clang updates. Breakages are rare, known in advance, and communicated to upstreams before hand (look up “crater” if you want to learn more).
* Not sure if distros package, or need to package any such packages, but I didn’t do any surveys on the subject.


To not depend on LLVM, you only need a non-LLVM code generator (i.e. replacing the LLVM IR generation step with another representation). A full fledged implementation in GCC is not strictly necessary. The “presumably complex” Rust implementation is actually modular like that. Multiple code generators already exist.
rustc_codegen_gcc is progressing nicely. Priority is given to targets with no LLVM support whatsoever (architectures you probably never heard of) and x86_64. Using the latter as a target could become fully usable within months (90%+ of the work is already done).
Another code generator that exists and is even more well supported is cranelift, but that strictly targets fast compilation (at the expense of slower binaries), so it’s mostly useful for faster development workflows.
There are even code generators that generate C code, which manage to turn the full reference rust compiler itself to C 😉
The implement-Rust-in-GCC project is called gccrs, but that’s years away from reaching a fully usable state.


Dare I ask, what ssh thing?
Side Note: It was already believed that SSH encryption was broken by state actors since the first NSA leaks. So, people should at least always use it over another encrypted channel anyway.
Good list, since the three projects use public runners people can check.
They must be cheating building from scratch (including fetching dependencies from crates.io) in github actions in <2 minutes and never freezing, despite those runners gaining a bad reputation lately.
The github runners building it in 4 minutes without freezing must be fake. Or maybe you were building SpiderMonkey from source, and that part was the problem 🙂
If you mean the Zed fork, they must be cheating building from scratch (including fetching dependencies from multiple locations and repos) in <18 minutes (the total run includes running tests) in resource-limited codeberg runners, and never freezing.
I also built this locally, and despite this being a wild project, and resource limiting the build on a workstation with a ~10 year old CPU, it finished in <24 minutes, and the target dir size (the build dir for those not familiar) is a WOPPING 3GiB (the executable alone is ~220MiB, ~168MiB if you strip it).