[byko3y]

>Do not misrepresent them and pretend that the Rust developers are incompetent or malicious.

I'm sorry, but I sensirely think the Rust designer did a sloppy work by reimplementing C++ flaws with a new syntax. The history repeats itself, the same pathological mechanism once driving C++ development now drived Rust — I mean large enterprise wanting to change everything without changing nothing, the new tool that would feel like the old tool. They did not really invent some new model, look at std::shared_ptr, std::mutex, move semantic — it was already in C++ before the prototype of Rust. The "share immutables, lock mutables" model was a holy grail of C++ concurrency caused by the way STL worked — and STL is not nearly the only container library in C++.

Okay, what's your take on why exactly Rust compiles slowly?

[vacuity]

Rust certainly takes after C++, but it's not the same. It's more like C++ if it was made today. For instance, Rust's destructive move semantics are the better default. (However, Rust making everything moveable by default is a bit of a drawback.) I don't understand your point about std::shared_ptr, std::mutex, and the immutability/mutability model. These are not C++ constructs; they are general programming constructs that C++ has an implementation of. Rust does not claim to have some innovative take on reference counting or locking. However, Rust's borrowing is an improvement (by default) on managing shared mutable state. Rust is not Carbon, or whatever new C++ variant is out there; it is a backwards-incompatible language that offers better ways to do many of the things C++ is used for.

> Okay, what's your take on why exactly Rust compiles slowly?

It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this.

[aw1621107]

> It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this.

I think one interesting thing that could be explored more is what aspects of Rust "inherently" result in slow compilation (i.e., if you changed said aspects to improve compilation speeds then you end up with a "different" language, assuming some hand-waviness with respect to equivalence here) and what aspects are practically and/or theoretically improvable.

For example, rustc's reliance on LLVM for optimization is a well-known source of sluggishness, but I wouldn't classify that as "inherent" since Rust could use a different backend that works faster (e.g., Cranelift) and/or be more efficient about the IR it emits. Something like monomorphization, on the other hand, is a more in a grey area since it's (as far as I know) essential for Rust to meet its performance goals, but IIRC it's not out of the question for the compiler to implement generics using a different strategy instead, which might be viable as an opt-in tradeoff.