←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.021s | 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[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[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[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[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 #
ummonk ◴[27 Jun 25 14:44 UTC] No.44397190[source]▶
No, I don't agree. A compiler bug is something that gets fixed in a patch release after it's reported, or perhaps some platform-specific regression that gets fixed in the next release after it's reported. What we're discussing by contrast is a soundness hole in the language itself - one which will most likely require breaking changes to the language to close (i.e. some older programs that were perfectly safe will fail to compile as a side effect of tightening up the Rust language to prevent this soundness hole).

As to the Ferrocene specification, it explicitly states "Any difference between the FLS and the behavior of the Rust compiler is considered an error on our part and the FLS will be updated accordingly."

Proposals to fix the soundness hole in Rust either change the variance rules themselves, or require where clauses in certain places. Either of these changes would require corresponding changes to chapter 4 of the Ferrocene specification.

replies(2): >>44397265 #>>44397693 #
Ar-Curunir ◴[27 Jun 25 14:57 UTC] No.44397265[source]▶
And Rust has and will make those breaking changes, while Zig will likely not. In fact there are documented and blessed ways to break memory safety in Zig, and no one is calling them soundness bugs!

I really don’t see how you can claim with a straight face that the two approaches are the same.

replies(1): >>44398614 #
1. ummonk ◴[27 Jun 25 17:26 UTC] No.44398614[source]▶
"In fact there are documented and blessed ways to break memory safety in Zig" - just as there are in Rust... even the Rust standard library makes liberal use of them (thereby making any program which invokes those parts of the standard library transitively unsafe by definition).

Look, I'm not saying the Zig and Rust approaches are the same. I explicitly stated that Rust is more memory safe than Zig (which is in turn more memory safe than C/C++).

This is because Rust has clearly delineated a "safe" subset of Rust which you have to explicitly opt out of that is mostly sound (and has a goal of eventually being entirely sound), has a culture of encouraging the use of the safe subset, and has taken a good approach to the interfacing of safe and unsafe code (i.e. if unsafe code is properly written and satisfies the exposed contract - despite the compiler being unable to verify this - then safe code can safely be linked with it).

All of this results in extremely low risk of memory corruption for Rust programs in practice (far lower than any other commonly used non-GC language with the sole exception of SPARK).

What you can't do though is reject the notion of memory safety being a sliding scale and draw a binary distinction between languages that are 100% perfectly memory safe and languages that are memory unsafe. Well you can, but Rust will fall on the side of memory unsafe for many years to come. Java (ignoring vendor-specific extensions) falls on the safe side though - the language semantics as specified are sound and it doesn't even have an unsafe subset.

replies(1): >>44408374 #
2. vlovich123 ◴[28 Jun 25 21:37 UTC] No.44408374[source]▶
On this sliding scale you insist on, I think most would agree with if we’re insisting on being pedantic which isn’t a great place to have informal discussion. Regardless, correct me if I’m wrong - on the sliding scale Zig isn’t actually that far away from C/C++ whereas Rust is more like C#/JS/Java etc. it also broadens the definition of memory safety to include race conditions whereas Zig is still like C/C++ there (and indeed I can’t think of another language that provides the safety against races that Rust does). Moreover it does this without sacrificing any performance.

Look, Zig has neat ideas. No disputing that. But on the sliding scale there’s a threshold where people are comfortable classifying something as being memory safe to avoid perfect being the enemy of good. And by that classification criteria, Zig falls well below the bar and Rust clears it easily.