Live data from Hacker News

Turning off Rust's borrow checker completely (2022)

iter.ca

21–30 of 63 posts

Re: Turning off Rust's borrow checker completely (2022)

#21

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and it takes like 10-20 seconds to compile. Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc >.

Compiling clippy certainty doesn’t take that long and it’s a substantially larger project. What you describe is pretty weird to be honest.

Re: Turning off Rust's borrow checker completely (2022)

#22

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and it takes like 10-20 seconds to compile. Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc >.

> after the number of times I resorted to things like Arc>.

... What are you doing ? It's definitively unusual.

Re: Turning off Rust's borrow checker completely (2022)

#23
post #22

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and it takes like 10-20 seconds to compile. Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc >.

> after the number of times I resorted to things like Arc >. ... What are you doing ? It's definitively unusual.

> ... What are you doing ? It's definitively unusual.

No it's not, it's extremely common. `Arc>` or `Arc>>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely clear, knowing exactly what parts of every struct is shareable (Arc) & mutable (Mutex).

[1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

Re: Turning off Rust's borrow checker completely (2022)

#24
post #23
post #22

Earlier quoted context omitted.

> after the number of times I resorted to things like Arc >. ... What are you doing ? It's definitively unusual.

> ... What are you doing ? It's definitively unusual. No it's not, it's extremely common. `Arc >` or `Arc >>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely…

> No it's not, it's extremely common.

Arc-Mutex yes, Arc-Box no.

It's like "I want a shared, immutable reference to something recursive, or unsized". The heap part makes no sense because it's already allocated there if you use an Arc : https://doc.rust-lang.org/std/sync/struct.Arc.html

> The type Arc provides shared ownership of a value of type T, allocated in the heap.

Moreover, you don't even need the box for a dyn : https://gist.github.com/rust-play/f19567f8ad4cc00e3ef17ae6b3...

Re: Turning off Rust's borrow checker completely (2022)

#25

Earlier quoted context omitted.

It is a matter of being polite when it comes to semantics. Weird is English written in obtuse grammar, but it is still legible. Undefined behavior still compiles into _something_, and if it’s after the code I care about observing, it doesn’t matter. The very first C++ templates compilation was observed through undefined behavior and errors. If you don’t have some way to “escape” from proper semantics, just to experim…

> and if it’s after the code I care about observing, it doesn’t matter That's not how undefined behavior works, though. Undefined behavior doesn't have an "after." By definition it leaves your entire program in an undefined state, which means its behavior cannot be reasoned about temporally or spatially in this way. Sure, in a simple or trivial case you might "get lucky", but merely by introducing undefined behavior…

I feel like people like OP, who don't understand UB and its consequences, would benefit the most from the strict compiler, but can be bothered the least to learn what it's saying.

Re: Turning off Rust's borrow checker completely (2022)

#26
post #24
post #23

Earlier quoted context omitted.

> ... What are you doing ? It's definitively unusual. No it's not, it's extremely common. `Arc >` or `Arc >>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely…

> No it's not, it's extremely common. Arc-Mutex yes, Arc-Box no. It's like "I want a shared, immutable reference to something recursive, or unsized". The heap part makes no sense because it's already allocated there if you use an Arc : https://doc.rust-lang.org/std/sync/struct.Arc.html > The type Arc provides shared ownership of a value of type T, allocated in the heap. Moreover, you don't even need the box for a dyn…

> Arc-Mutex yes, Arc-Box no.

Yeah, looks like Arc-Box is kind of pointless, but isn't there some thread locality reason why people wrap `Box` in `Arc`? I remember reading something about it a while ago but maybe I'm misremembering.

Re: Turning off Rust's borrow checker completely (2022)

#27

Earlier quoted context omitted.

It is a matter of being polite when it comes to semantics. Weird is English written in obtuse grammar, but it is still legible. Undefined behavior still compiles into _something_, and if it’s after the code I care about observing, it doesn’t matter. The very first C++ templates compilation was observed through undefined behavior and errors. If you don’t have some way to “escape” from proper semantics, just to experim…

> and if it’s after the code I care about observing, it doesn’t matter That's not how undefined behavior works, though. Undefined behavior doesn't have an "after." By definition it leaves your entire program in an undefined state, which means its behavior cannot be reasoned about temporally or spatially in this way. Sure, in a simple or trivial case you might "get lucky", but merely by introducing undefined behavior…

It isn’t about the “after” it’s about the “before”. For example, if I insert some code that divides by zero “later” but causes some new behavior I’m interested in, that’s what I’m interested in. The divide by zero is annoying, but can be addressed later.

If the compiler forced me to check ever integer division wasn’t a divide by zero, that would be annoying in this case. The borrow checker is like this. It forces you to rewrite entire application code just to see if some new behavior fixes a bug, in the name of safety, without realizing that “for just this execution, I don’t care about safety.”

Re: Turning off Rust's borrow checker completely (2022)

#28
post #25

Earlier quoted context omitted.

> and if it’s after the code I care about observing, it doesn’t matter That's not how undefined behavior works, though. Undefined behavior doesn't have an "after." By definition it leaves your entire program in an undefined state, which means its behavior cannot be reasoned about temporally or spatially in this way. Sure, in a simple or trivial case you might "get lucky", but merely by introducing undefined behavior…

I feel like people like OP, who don't understand UB and its consequences, would benefit the most from the strict compiler, but can be bothered the least to learn what it's saying.

I understand what it’s saying. I just disagree that it has to be done for every compilation. Often, as a human, I can reason that it is safe (or reasonably safe for what bug I am attempting to fix). I’m not talking about released software, I’m talking about software I am developing in the moment that I am developing it.

Re: Turning off Rust's borrow checker completely (2022)

#29
post #23
post #22

Earlier quoted context omitted.

> after the number of times I resorted to things like Arc >. ... What are you doing ? It's definitively unusual.

> ... What are you doing ? It's definitively unusual. No it's not, it's extremely common. `Arc >` or `Arc >>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely…

At that point a regular GC is probably faster (at least from my experience of doing memory management in C++ with ref-counted smart pointers, which has a 'death-by-a-thousand-cuts' performance profile, e.g. the refcounting overhead is smeared over the whole code base and doesn't show up as obvious hotspots in the profiler).

Re: Turning off Rust's borrow checker completely (2022)

#30

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and it takes like 10-20 seconds to compile. Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc >.

I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware.

However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies.

[1] https://github.com/makepad/makepad/

Post reply on HN