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.