Should be named in rust we don't trust
Rust--: Rust without the borrow checker
81–90 of 269 posts
Re: Rust--: Rust without the borrow checker
#82Earlier quoted context omitted.
Straightjackets can be very useful. Haskell (and OCaml etc) give you both straightjackets and a garbage collector. Straightjackets and GC are very compatible. Compared to C, which has neither straightjackets nor a GC (at least not by default).
>Straitjackets can be very useful. Only if you’re insane.
Damn! This is the funniest HN comment that I have ever come across...
Re: Rust--: Rust without the borrow checker
#83Earlier quoted context omitted.
Straightjackets can be very useful. Haskell (and OCaml etc) give you both straightjackets and a garbage collector. Straightjackets and GC are very compatible. Compared to C, which has neither straightjackets nor a GC (at least not by default).
>Straitjackets can be very useful. Only if you’re insane.
How dare you. C is a fine language.
Just don't accidentally step on any of these landmines and we'll all get along great.
Re: Rust--: Rust without the borrow checker
#84Earlier quoted context omitted.
If you write correct Rust code it'll work, the borrowck is just that, a check, if the teacher doesn't check your homework where you wrote that 10 + 5 = 15 it's still correct. If you write incorrect code where you break Rust's borrowing rules it'll have unbounded Undefined Behaviour, unlike the actual Rust where that'd be an error this thing will just give you broken garbage, exactly like a C++ compiler. Evidently mil…
People don't want garbage. But in any case, they don't want straightjackets like the borrow checker. Hence, they use GC'd languages like Go whenever they can.
[deleted]
Re: Rust--: Rust without the borrow checker
#85Earlier quoted context omitted.
Straightjackets can be very useful. Haskell (and OCaml etc) give you both straightjackets and a garbage collector. Straightjackets and GC are very compatible. Compared to C, which has neither straightjackets nor a GC (at least not by default).
>Straitjackets can be very useful. Only if you’re insane.
The meaning of straightjacket here is inherently subjective and not to be meant literally.
Re: Rust--: Rust without the borrow checker
#86What are protental issues with compiler, by just disabling borrow checker? If I recall correctly some compiler optimisations for rust can not be done in C/C++ because of restrictions implied by borrow checker.
Without the borrow checker, how should memory be managed? Just never deallocate?
It would be the same as in any language with manual memory management, you'd simply get a dangling pointer access. The 'move-by-default' semantics of Rust just makes this a lot trickier than in a 'copy-by-default' language though.
It's actually interesting to me that the Rust borrow checker can 'simply' be disabled (e.g. no language- or stdlib-features really depending on the borrow checker pass) - not that it's very useful in practice though.
Re: Rust--: Rust without the borrow checker
#87Earlier quoted context omitted.
Certain people feel very emotional about the compilers and interpreters they use You couldn't pay me to work with them
Don't worry, they probably wouldn't want to work with you either. Some programmers think and care a lot about software correctness in a kind of mathematical way. Others just want to ship features and enjoy their lives. Both approaches are fine. They just don't necessarily mix super well. Some people like to tell you that diverse teams work better. Years ago I worked with someone who had a PhD in psychometrics. She sa…
There is a third kind. Those who want to have a lot of fun by using their imagination to come up with interesting ways build something, but in rust, the borrow checker often won't have any of it.
In rust you have to learn and internalize lot of the non-intutive borrow checker reasoning to remain sane. If you remember to spend a fraction of that effort to remember the "unsafe" things you could end up doing in C, then I think most people would be fine.
But rust enforces it, which is good for a small fraction of all software that is being written. But "Rust for everything!?"..Give me a fucking break!
Re: Rust--: Rust without the borrow checker
#88What are protental issues with compiler, by just disabling borrow checker? If I recall correctly some compiler optimisations for rust can not be done in C/C++ because of restrictions implied by borrow checker.
Without the borrow checker, how should memory be managed? Just never deallocate?
The borrow checker does not deal with ownership, which is what rust’s memory management leverages. The borrow checker validates that borrows (references) are valid aka that they don’t outlive their sources and that exclusive borrows don’t overlap.
The borrow checker does not influence codegen at all.
Re: Rust--: Rust without the borrow checker
#89What are protental issues with compiler, by just disabling borrow checker? If I recall correctly some compiler optimisations for rust can not be done in C/C++ because of restrictions implied by borrow checker.
Rust can set restricts to all pointers, because 1 mut xor many shared refs rule. Borrow checker empowers this. https://en.wikipedia.org/wiki/Restrict
The crazy part about this is that (auto) vectorization in Rust looks something like this: iter.chunks(32).map(vectorized)
Where the vectorized function checks if the chunk has length 32, if yes run the algorithm, else run the algorithm.
The compiler knows that the chunk has a fixed size at compile time in the first block, which means it can now attempt to vectorize the algorithm with a SIMD size of 32. The else block handles the scalar case, where the chunk is smaller than 32.
Re: Rust--: Rust without the borrow checker
#90This can't possibly be guaranteed to work just by disabling the checker, can it? If Rust optimizes based on borrow-checker assumptions (which I understand it can and does) then wouldn't violating them be UB, unless you also mess with the compiler to disable those optimizations?
Yes. An analog would be uninitialized memory. The compiler is free to make optimizations that assume that uninitialized memory holds every value and no value simultaneously (because it is undefined behavior to ever read it).
In the following example, z is dereferenced one time and assigned to both x and y, but if z and x are aliased, then this is an invalid optimization.
fn increment_by(x: &mut i32, y: &mut i32, z: &i32) {
*x = *z;
*y = *z;
}