[jfkebwjsbx]

The downside is that it is a very common marketing trick. Promise something so that customers feel good about it.

I know the Rust contributors are doing their best, and that this blog post is not writing a marketing ploy, but in the end, the result is what matters.

My take on this is that I am fine with compile times as long as some effort is being done to keep it near optimal.

But I really do not want the Rust team to feel pressure to improve the compile times so much that they will end up killing other features or designing the language differently just for that (like Go, for instance). Or even making the compiler so complex that adding new features is harder for them.

I really like Rust as a language that is more complex to write and to compile but in return gives you robustness and performance. Compilation times be damned. I am not writing Rust to compile fast!

[bluGill]

I want two different languages. I want one that compiles fast so I can run my unit tests fast. I want one that takes however long needed to get the fastest binary. These need not share the same compiler so long as both compile the same source to the same result.

[noch]

> I want one that takes however long needed to get the fastest binary.

Year after year, people keep saying this or things like it. But it's worth remembering that it is not the compiler that makes your code fast, but how you structure your data transformations that makes code fast. In 2014, Mike Acton taught us that the best compiler optimisations can only account for 1-10% of the performance optimisation problem space. "The vast majority of [performance] problems, are problems the compiler cannot reason about." https://youtu.be/rX0ItVEVjHc?t=2097

[unrealhoang]

Hopefully we can use cranelift as backend soon. That will be the first milestone for fast compile - not as fast result.

[whatshisface]

>The downside is that it is a very common marketing trick.

"The less you intend to do about something, the more you have to talk about it." However this maxim is not applicable here because compile times actually have been improving.

[erik_seaberg]

This. Don't ever dumb down a language just to make tools faster. Anything the tools don't help with, I have to do with my brain, which is made of meat and runs at 0.0000001 GHz.

[nnethercote]

Hi, I'm the author of the blog post.

There is definitely a marketing angle to these posts. Rust has a reputation for slow compilation, and one of my goals is to show that (a) people working on Rust care about compile times, and (b) improvements are being made.

I'll let you judge whether the marketing is backed by actual substance. It's a long-running blog post series, here are links to all the posts.

* https://blog.mozilla.org/nnethercote/2016/10/14/how-to-speed...

* https://blog.mozilla.org/nnethercote/2016/11/23/how-to-speed...

* https://blog.mozilla.org/nnethercote/2018/04/30/how-to-speed...

* https://blog.mozilla.org/nnethercote/2018/06/05/how-to-speed...

* https://blog.mozilla.org/nnethercote/2018/11/06/how-to-speed...

* https://blog.mozilla.org/nnethercote/2019/07/17/how-to-speed...

* https://blog.mozilla.org/nnethercote/2019/07/25/the-rust-com...

* https://blog.mozilla.org/nnethercote/2019/10/11/how-to-speed...

* https://blog.mozilla.org/nnethercote/2019/12/11/how-to-speed...

* https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed...

* https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed...

EDIT: I just saw that alilleybrinker already linked to all these and more below: https://news.ycombinator.com/item?id=24061346