It was a release build just to be clear. Debug builds twice as fast (they have a custom profile with opt-level = 1) and indeed uses a lot more disk space.

ram

I just did a release build with --jobs=1, while measuring total RES memory of the cargo process tree. Number of pids ranged from 1 (just cargo, obviously) to 8, and max RES memory was ~3471MiB (~512MiB median, <2GiB @ 95% percentile). So not too lightweight, but not buck breaking either (a system with 2GiB RAM free + zram shouldn’t even swap).

People just have unrealistic expectations. Developers could optimize the compiler for memory usage, but that would make the compiler actually slower. And who would be the target audience of such optimizations? People who want to build big Rust projects on Raspberry Pi Zero?

Good list, since the three projects use public runners people can check.

Tauri

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.

Servo

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 🙂

Gram

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

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.

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.