←back to thread

302 points Bogdanp | 3 comments | | HN request time: 0.432s | source
Show context
AndyKelley ◴[] 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 #
taylorallred ◴[] No.44390942[source]
@AndyKelley I'm super curious what you think the main factors are that make languages like Zig super fast at compiling where languages like Rust and Swift are quite slow. What's the key difference?
replies(4): >>44390972 #>>44391002 #>>44391022 #>>44396531 #
steveklabnik ◴[] No.44391022[source]
I'm not Andrew, but Rust has made several language design decisions that make compiler performance difficult. Some aspects of compiler speed come down to that.

One major difference is the way each project considers compiler performance:

The Rust team has always cared to some degree about this. But, from my recollection of many RFCs, "how does this impact compiler performance" wasn't a first-class concern. And that also doesn't really speak to a lot of the features that were basically implemented before the RFC system existed. So while it's important, it's secondary to other things. And so while a bunch of hard-working people have put in a ton of work to improve performance, they also run up against these more fundamental limitations at the limit.

Andrew has pretty clearly made compiler performance a first-class concern, and that's affected language design decisions. Naturally this leads to a very performant compiler.

replies(1): >>44393713 #
rtpg ◴[] No.44393713[source]
> Rust has made several language design decisions that make compiler performance difficult

Do you have a list off the top of your head/do you know of a decent list? I've now read many "compiler slow" thoughtpieces by many people and I have yet to see someone point at a specific feature and say "this is just intrinsically harder".

I believe that it likely exists, but would be good to know what feature to get mad at! Half joking of course

replies(3): >>44394404 #>>44394813 #>>44397854 #
1. Mawr ◴[] No.44394404[source]
You can have your house built fast, cheap, or well. Pick two; or a bit of all three that adds up to the same effort required. You can't have all three.

You can't have a language with 100% of the possible runtime perf, 100% of the possible compile speed and 100% of the possible programmer ease-of-use.

At best you can abuse the law of diminishing returns aka the 80-20 rule, but that's not easy to balance and you run the risk of creating a language that's okay at everything, but without any strong selling points, like the stellar runtime performance Rust is known for.

So a better way to think about it is: Given Rust's numerous benefits, is having subpar compilation time really that big of a deal?

replies(2): >>44398097 #>>44401930 #
2. rtfeldman ◴[] No.44398097[source]
> Given Rust's numerous benefits, is having subpar compilation time really that big of a deal?

As someone who uses Rust as a daily driver at work at zed.dev (about 600K LoC of Rust), and Zig outside of work on roc-lang.org (which was about 300K LoC of Rust before we decided to rewrite it in Zig, in significant part because of Rust's compilation speed), yes - it is an absolutely huge deal.

I like a lot of things about Rust, but its build times are my biggest pain point.

3. rtpg ◴[] No.44401930[source]
I think this qualitative argument is made but is very unsatisfying for something as quantitative as compilation or runtime speeds.

It leads to blithe things about how there's no such things as zero-cost abstractions. But at one point the cost is so low and amortized that you're looking at something that's basically free.

What is the compilation cost of the `?` syntax shorthand? Probably quite low!

What about the compilation cost of underscores in number literals? Again, quite low?

To this point a bit, I think a lot of people talk about the borrow checker, but my understanding is it's fairly low cost, and I don't worry about it.

Monomorphisation costs though? That feels like something that could generate a lot of work.