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 >.
Turning off Rust's borrow checker completely (2022)
21–30 of 63 posts
Re: Turning off Rust's borrow checker completely (2022)
#22I 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 >.
... What are you doing ? It's definitively unusual.
Re: Turning off Rust's borrow checker completely (2022)
#23I 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.
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)
#24Earlier 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…
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)
#25Earlier 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…
Re: Turning off Rust's borrow checker completely (2022)
#26Earlier 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…
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)
#27Earlier 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…
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)
#28Earlier 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.
Re: Turning off Rust's borrow checker completely (2022)
#29Earlier 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…
Re: Turning off Rust's borrow checker completely (2022)
#30I 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 >.
However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies.