3 ms·

Can you share any compiler benchmarks showing Rust compiles slower than C++? I can see something totally opposite in my projects - particularly recompiling aft

Can you share any compiler benchmarks showing Rust compiles slower than C++? I can see something totally opposite in my projects - particularly recompiling after a change is very quick. And cargo check often runs in less than 1s. I never got such quick incremental recompile times in any of my earlier C++ projects, particularly when using templated or header heavy libraries like STL ;) As for the borrow checker thing, it is not broken but it's simply a limitation. In a strictly statically checked it is usually possible to run into a situation of a valid program that gets rejected by the compiler. Here this limitation comes from the compiler following a pretty simple rule - only one reference is allowed if it is mutable. This simple rule is what makes many of Rust safety guarantees possible, and I guess relaxing it conditionally might be very tricky. NLLs have already made it a bit nicer recently, do maybe it is possible to improve it further.

masklinn 4y ago
> As for the borrow checker thing, it is not broken but it's simply a limitation. Limitations are when the borrow checker is not smart enough to understand things like sub-scope borrows (fixed by NLL) or the interaction of mutable borrows and loops (which hopefully will eventually be fixed by Polonius aka NLLv2). But here they want to acquire a shared reference to an object with an outstanding unique reference. That is quite literally the first of only two rules references have: 1. At any given time you can have either a single unique reference or multiple shared references. 2. References must be valid.
- pkolaczk 4y ago
  In the given example they are not using the shared reference at all during the whole lifetime of the immutable reference and the operation on the immutable one does not change the object at all, so it would be actually safe. This is the situation where those two rules are a bit too strict and reject a valid program.
  - masklinn 4y ago
    > In the given example they are not using the shared reference at all during the whole lifetime of the immutable reference and the operation on the immutable one does not change the object at all, so it would be actually safe. The compiler does not work at that level of resolution. It’s unclear that it should, even for a point query: there is no telling how much a weirdo ISA would bungle that if the two accesses came from different threads, for instance. > This is the situation where those two rules are a bit too strict and reject a valid program. Compilers will always, necessarily, reject valid programs. The alternative is to allow invalid programs.
    - ArrayBoundCheck 4y ago
      > The compiler does not work at that level of resolution. It’s unclear that it should The correct solution is to never ever use rust. It's a failed experiment that noone noticed failed
ArrayBoundCheck 4y ago
> Can you share any compiler benchmarks showing Rust compiles slower than C++? You got to do this yourself because YMMV My projects don't use many includes and little templates. So C++ is more than 4x faster. I think in one case it was 10x faster but other people might claim I'm cheating because most people don't write code that way. If you often write template heavy code or need to include many large headers you'll get different results

masklinn 4y ago

> As for the borrow checker thing, it is not broken but it's simply a limitation. Limitations are when the borrow checker is not smart enough to understand things like sub-scope borrows (fixed by NLL) or the interaction of mutable borrows and loops (which hopefully will eventually be fixed by Polonius aka NLLv2). But here they want to acquire a shared reference to an object with an outstanding unique reference. That is quite literally the first of only two rules references have: 1. At any given time you can have either a single unique reference or multiple shared references. 2. References must be valid.

pkolaczk 4y ago
In the given example they are not using the shared reference at all during the whole lifetime of the immutable reference and the operation on the immutable one does not change the object at all, so it would be actually safe. This is the situation where those two rules are a bit too strict and reject a valid program.
- masklinn 4y ago
  > In the given example they are not using the shared reference at all during the whole lifetime of the immutable reference and the operation on the immutable one does not change the object at all, so it would be actually safe. The compiler does not work at that level of resolution. It’s unclear that it should, even for a point query: there is no telling how much a weirdo ISA would bungle that if the two accesses came from different threads, for instance. > This is the situation where those two rules are a bit too strict and reject a valid program. Compilers will always, necessarily, reject valid programs. The alternative is to allow invalid programs.
  - ArrayBoundCheck 4y ago
    > The compiler does not work at that level of resolution. It’s unclear that it should The correct solution is to never ever use rust. It's a failed experiment that noone noticed failed

ArrayBoundCheck 4y ago

> Can you share any compiler benchmarks showing Rust compiles slower than C++? You got to do this yourself because YMMV My projects don't use many includes and little templates. So C++ is more than 4x faster. I think in one case it was 10x faster but other people might claim I'm cheating because most people don't write code that way. If you often write template heavy code or need to include many large headers you'll get different results