[epage]

> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed !

I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"?

From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency graphs? Do they have large individual crates? And so on.

[sanxiyn]

While I think n>1000 data points on Rust learning curve is informative, I think build time complaint is less so.

This being Google, it probably means something like "this C++ build takes 24 hours locally, but thanks to magical distributed build infrastructure it completes in 10 minutes, whereas Rust build takes 18 hours locally but even with magic does not complete in under 30 minutes, which is too long". That is important to Google, but it is almost completely irrelevant to anyone outside Google.

It is unclear to me whether improving rustc performance is the right solution to Google's problem. It is probable working on Rust integration to Google's build infrastructure is higher ROI than working on rustc.

[norir]

> Or is it "any waiting is bad"?

Yes, this is the problem. Waiting is always bad for productivity. Even a second is long enough to lose a bit of focus. When that stretches out to 10 seconds, it starts getting tempting to, say, check Hacker News and lose your train of thought. I believe that most of the programs that I might be tempted to write in rust could be written in an alternate language with a compiler that is up to 100x faster. Of course this hypothetical language would have to be simpler than rust and would lack many of its features. As it currently stands though, I believe that it will be impossible to make the rust compiler 10x faster, let alone 100x faster so it would be nice if there was more effort to design alternative languages that build on what we've learned from rust to make something better.

[gaganyaan]

I don't really wait for the compiler much. One initial wait for a clean compile, sure. But after that, LSP mode means immediate feedback in my editor before I could even switch to my terminal

[jsgf]

In my experience from a Googlish environment (tho mostly focusing on backend service development): 1. people don't know about check builds and have a much nicer iteration experience once they learn about it, 2: rust-analyzer red wiggles also help, and 3. a lot of the actual build time is from build/link of C++ dependencies from the rest of the codebase.

[internetting3]

Hey jsgf! Your posts have caught my eye. We're planning on joining the YC Winter 2024 batch with a B2B infra project. Reach out to me at [e-mail] if you are interested.

[wredue]

Rust is basically entirely code gen. It’s no surprise that compiling is slow and speeding up compiling is a troublesome endeavour.

Rust itself might as well be considered a highly constrained macro language at this point.

[IshKebab]

Yeah most of these results are meaningless without comparison to other languages. Same with the "how quick is it to learn?" what are the equivalent numbers of Go?

Based on my experience they're overselling how easy it is to learn and underselling the compiler speed.

Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds.

But on the other hand most people could probably learn all of Go in the time it takes to begin to understand the borrow checker.

[nicoburns]

> Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds.

Faster than C++ is of course very faint praise. C++ is also very slow!

[pjmlp]

Only when considering clean builds as building the whole world from scratch.

Which we seldom due on most C++ projects, we rather rely on binary libraries and build only our own code.

Also when comparing with Delphi, Ada, D, or even Haskell or OCaml, it isn't that great.

You might feel like pointing out that Haskell or OCaml can be even slower, which is true, however they package multiple toolchains and a REPL, and as of today Rust still isn't as flexible in having multiple toolchains for different purposes.

[IshKebab]

> Which we seldom due on most C++ projects, we rather rely on binary libraries and build only our own code.

Depends on the project. Many commercial projects do vendor dependencies and build them too, because you can't rely on the OS version. Especially on Windows or with more niche dependencies.

Just compiling Boost takes 15 minutes - more than any Rust project I've ever compiled.

Not sure what you mean about multiple toolchains.

[pjmlp]

On Windows even more so, as most folks do heavy use of DLLs and COM.

And yes exporting C++ from DLLs is compiler specific, which doesn't matter, as there is only one specific compiler version that is usually validated for the whole project delivery pipeline.

Plus we can edit and continue on C++ Builder and Visual C++, with incremental compiler and incremental linker.

There is a reason why so many companies forbid Boost.

Regarding toolchains, JIT, AOT, bytecode interpreter, REPL. Here, 4 variants to compile and execute code, depending on release requirements and developer workflow loop, each with its own sets of plus and minus. It is great when there is a choice.

[tracker1]

Hard for me to directly compare, but Rust builds that I have experienced have been comparable to large Node/npm projects built with webpack (JS tooling). Totally different space and output, but comparible.

The long dependency trees are part of it, but usually not too bad and only really bad the first time, since you don't have to rebuild every crate every time (I could be wrong, but it seems that way). I haven't been using it day in, day out though. I've installed a few apps via cargo, and have done some experiments for service applications, and Tauri as well.

As for the day to day use and how painful it is... I haven't had enough exposure to really comment on... it seems "fast enough" but I'm not running compiles often enough, simply because my knowledge and experience aren't really great in Rust. I've looked at it and played with it a few times, then I set it aside for months at a time and every time it's like I'm starting over.

Where I'm working now, there are some serious issues that may result in areas needing better start time on services, so that may be an opportunity to advocate for Rust. I've never really loved C or C++, so I'm less inclined to want to use them.