←back to thread

Why is the Rust compiler so slow?

(sharnoff.io)
302 points Bogdanp | 1 comments | 26 Jun 25 19:29 UTC | HN request time: 0s | 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 #
ummonk ◴[26 Jun 25 21:18 UTC] No.44391516[source]▶
Zig is less memory safe than Rust, but more than C/C++. Neither Zig nor Rust is fundamentally memory safe.
replies(1): >>44391829 #
Ar-Curunir ◴[26 Jun 25 21:48 UTC] No.44391829[source]▶
What? Zig is definitively not memory-safe, while safe Rust, is, by definition, memory-safe. Unsafe rust is not memory-safe, but you generally don't need to have a lot of it around.
replies(3): >>44392198 #>>44392909 #>>44395714 #
ummonk ◴[26 Jun 25 22:44 UTC] No.44392198[source]▶
Safe Rust is demonstrably not memory-safe: https://github.com/Speykious/cve-rs/tree/main
replies(1): >>44392674 #
steveklabnik ◴[27 Jun 25 00:07 UTC] No.44392674[source]▶
This is a compiler bug. This has no bearing on the language itself. Bugs happen, and they will be fixed, even this one.
replies(1): >>44393188 #
ummonk ◴[27 Jun 25 02:13 UTC] No.44393188{3}[source]▶
It's a 10 year old bug which will eventually be fixed but may require changes to how Rust handles type variance.

Until you guys write an actual formal specification, the compiler is the language.

replies(2): >>44393258 #>>44395048 #
steveklabnik ◴[27 Jun 25 02:32 UTC] No.44393258{4}[source]▶
It’s a ten year old bug because it has never been found in the wild, ever, in those ten years. Low impact, high implementation effort bugs take less priority than bugs that affect real users.

The project is adopting Ferrocene for the spec.

replies(1): >>44393323 #
ummonk ◴[27 Jun 25 02:48 UTC] No.44393323{5}[source]▶
Ferrocene is intended to document the behavior of the current version of the rustc compiler, so it's just an effort to formalize "the compiler is the language".

Yes, the soundness hole itself is low impact and doesn't need to be prioritized but it undermines the binary "Zig is definitively not memory-safe, while safe Rust, is, by definition, memory-safe" argument that was made in response to me. Now you're dealing with qualitative / quantitative questions of practical impact, in which my original statement holds: "Zig is less memory safe than Rust, but more than C/C++. Neither Zig nor Rust is fundamentally memory safe."

You can of course declare that Safe Rust is by definition memory safe, but that doesn't make it any more true than declaring that Rust solves the halting problem or that it proves P=NP. RustBelt is proven sound. Rust by contrast, as being documented by Ferrocene, is currently fundamentally unsound (though you won't hit the soundness issues in practice).

replies(1): >>44396286 #
_flux ◴[27 Jun 25 12:30 UTC] No.44396286{6}[source]▶
I believe these two statements should show the fundamental difference:

- If a safe Rust program exhibits a memory safety problem, it is a bug in the Rust compiler that is to be fixed - If a Zig program exhibits a memory safety problem, it is a bug in the Zig program that needs to be fixed, not in the compiler

Wouldn't you agree?

> Ferrocene is intended to document the behavior of the current version of the rustc compiler, so it's just an effort to formalize "the compiler is the language".

I must admit I haven't read the specification, but I doubt they attempt to be "bug for bug" compatible in the sense that the spec enumerates memory safety bugs present in the Rust compiler. But am I then mistaken?

replies(2): >>44397190 #>>44397280 #
1. vlovich123 ◴[27 Jun 25 14:58 UTC] No.44397280{7}[source]▶
> If a safe Rust program exhibits a memory safety problem, it is a bug in the Rust compiler that is to be fixed - If a Zig program exhibits a memory safety problem, it is a bug in the Zig program that needs to be fixed, not in the compiler

That is the absolute best description of memory safety I’ve heard expressed.