Legacy

how dare you 😧

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.

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.

what is cgexec 🤔

such as Firefox

You can use the cliget extension which generates full CLI commands for major CLI tools. Such tools have many options (e.g. curl’s --rate-limit).

There is an ancient fully user-space simple tool called netbrake that works by LD_PRELOADING a library that overrides some functions like recv/sendto (similar to eatmydata’s approach*). It may just work if you don’t have special requirements. If you’re curious, you can see the full list of overridden symbols with:

readelf -s /path/to/libnetbrake.so | grep -v UND

If you want a possibly fail-safe (kernel level) solution, you may find with a web search a helpful approach combining tc with cgroups.

Neither solutions need systemd.

* The realization that people growing up with SSD’s probably never heard of eatmydata just sunk in.

This has been happening forever. This old post always pops up in my mind for some reason as a historic example from an earlier linux boom.

Unfortunately, people have been pushed to not call out such things, because it’s “not nice”, when as the blog above shows, not calling it out is what’s not nice, and potentially dangerous.

More obvious, but systemd has a lot of features that a simple cron doesn’t.

Which cron?

Oh wait. Why did I assume OP would know there are multiple implementations? 😄

muh io bound

🤣

If the DB is IO-bound, and “slow languages” don’t matter because “IO bound”, then show me the DB you’re using implemented in a slow language.

It’s hilarious how op is being this stupidly unaware, even within his stupid false argument which is provided as a supposed given.

How are people seriously engaging with this blog fart full of false premises and contradictions?

You seem to be confused about what Signal protects against, or claims to protect against.

None of the items from your list apply. Maybe you’re confusing it with another distributed solution with peers connected through anonymous transport.