←back to thread

Why is the Rust compiler so slow?

(sharnoff.io)
302 points Bogdanp | 2 comments | 26 Jun 25 19:29 UTC | HN request time: 0.409s | source
Show context
AndyKelley ◴[26 Jun 25 20:16 UTC] No.44390865[source]▶
My homepage takes 73ms to rebuild: 17ms to recompile the static site generator, then 56ms to run it.

    andy@bark ~/d/andrewkelley.me (master)> zig build --watch -fincremental
    Build Summary: 3/3 steps succeeded
    install success
    └─ run exe compile success 57ms MaxRSS:3M
       └─ compile exe compile Debug native success 331ms
    Build Summary: 3/3 steps succeeded
    install success
    └─ run exe compile success 56ms MaxRSS:3M
       └─ compile exe compile Debug native success 17ms
    watching 75 directories, 1 processes
replies(8): >>44390894 #>>44390942 #>>44390948 #>>44391020 #>>44391060 #>>44391265 #>>44391881 #>>44393741 #
vlovich123 ◴[26 Jun 25 20:25 UTC] No.44390948[source]▶
Zig isn’t memory safe though right?
replies(3): >>44391142 #>>44391516 #>>44391617 #
pixelpoet ◴[26 Jun 25 20:43 UTC] No.44391142[source]▶
It isn't a lot of things, but I would argue that its exceptionally (heh) good exception handling model / philosophy (making it good, required, and performant) is more important than memory safety, especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge

What I'm more interested to know is what the runtime performance tradeoff is like now; one really has to assume that it's slower than LLVM-generated code, otherwise that monumental achievement seems to have somehow been eclipsed in very short time, with much shorter compile times to boot.

replies(2): >>44391457 #>>44393291 #
1. jorvi ◴[27 Jun 25 02:41 UTC] No.44393291[source]▶
> especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf.

Your first claim is unverifiable and the second one is just so, so wrong. Even big projects with very talented, well-paid C or C++ devs eventually end up with CVEs, ~80% of them memory-related. Humans are just not capable of 0% error rate in their code.

If Zig somehow got more popular than C/C++, we would still be stuck in the same CVE bog because of memory unsafety. No thank you.

replies(1): >>44396112 #
2. dgb23 ◴[27 Jun 25 12:04 UTC] No.44396112[source]▶
> If Zig somehow got more popular than C/C++, we would still be stuck in the same CVE bog because of memory unsafety. No thank you.

Zig does a lot of things to prevent or detect memory safety related bugs. I personally haven't encountered a single one so far, while learning the language.

> ~80% of them memory-related.

I assume you're referencing the 70% that MS has published? I think they categorized null pointer exceptions as memory safety bugs as well among other things. Zig is strict about those, has error unions, and is strict and explicit around casting. It can also detect memory leaks and use after free among other things. It's a language that's very explicit about a lot of things, such as control flow, allocation strategies etc. And there's comptime, which is a very potent tool to guarantee all sorts of things that go well beyond memory safety.

I almost want to say that your comment presents a false dichotomy in terms of the safety concern, but I'm not an expert in either Rust or Zig. I think however it's a bit broad and unfair.