5 ms·
If you don't really need the borrow checker to compile Rust, can the original Rust compiler have a mode where it doesn't do the borrow checking? That might make
by grok2 9y ago
If you don't really need the borrow checker to compile Rust, can the original Rust compiler have a mode where it doesn't do the borrow checking? That might make it easier to ease into Rust, because right now, "fighting" the borrow-checker is the hardest problem with learning Rust.
- steveklabnik 9y agoThe borrow checker is needed for soundness; this means mrustc will miscompile things. Assuming the input is sound, mrustc will do the right thing. Ignoring the borrow checker will not make things magically work.
- __s 9y agoLearning Rust without borrowck is throwing the baby out with the bath water
- nickrio 9y agoHow about "throwing the baby out but keeps the bath water"? Which is more appropriate for this scene I think. LOL
- keeperofdakeys 9y agoRemoving the borrow checker would allow you to compile broken code (eg. use after free, data races). However given code that compiles on rustc - passes the borrow checker - you don't need to reverify the borrow checking to get correct code from mrustc.
- banachtarski 9y ago(note, not the OP) Yea but by the same token, the borrow checker prevents me from doing perfectly valid logic and is frustrating in its own right.
- angelsl 9y agoThere are probably assumptions/invariants built into how rustc generates LLVM IR that you will have to guarantee are met if borrowck is disabled. Do you really want that?
- moomin 9y agoThat's true of literally all compile time validation.
- weberc2 9y agoBut its more true of some than others.
- banachtarski 9y agoNo I'm not saying I have an issue with compile time validation. Far from it. My point is that the borrow checker is explicitly meant to protect against data races and such. There are situations where I write code I can prove does not violate any hazards but Rust's "validation" is overly-zealous.
- steveklabnik 9y agoWhich ones do you run into most often?
- keeperofdakeys 9y agoYes, some valid code won't pass the borrow checker. But at the same time, far more invalid code doesn't pass it. Personally I see it as a tool to help me reduce possible runtime errors, and instead have them as compile time errors. This does mean that I often need to design my program around it, but that's try of basically every other language. The few times I do have an issue I'm usually writing FFI code to interact with C, and I try to minimise that code as much as possible.
- tmzt 9y agoAnd of course in Rust, if you Try you might get an Ok Result, or you may just return in Err. It's often a good exercise to craft your program to the language you're targetting, to take advantage of it's strengths or embrace it's traditions.
- kibwen 9y agoBe careful not to underestimate the failure mode of trying to compile arbitrary Rust code without the borrow checker. It appears that your goal is to let people "ease into Rust" by trading compilation errors for runtime segfaults, but it's just as likely that un-borrow-checked Rust code could produce malformed LLVM IR that will cause totally unpredictable compile-time failures in LLVM with indecipherably cryptic error messages.
- grok2 9y agoThat really wasn't my intention -- it mostly makes sense to use Rust for the borrow checker. Instead my only intention was that it simplify the process of learning Rust -- using all it's features (except the borrow checker), getting a working program fast and have some easy wins when learning Rust without stumbling constantly over the borrow checker. Maybe production mode could always enable the borrow checker.
- Lorkki 9y agoThe need for the borrow checker is driven by Rust's chosen resource management model. It sounds like what you really want is an optional mode with garbage collection, in which case I recommend you check out F#.
- vog 9y ago... or the "original", OCaml, from which Rust was heavily inspired.
- sitkack 9y agoF# is a superset of OCaml, one can program OCaml in F#, sorta [1][2]. [1] https://stackoverflow.com/questions/4239121/code-compatibility-between-ocaml-and-f https://stackoverflow.com/questions/4239121/code-compatibili... [2] https://stackoverflow.com/questions/179492/f-changes-to-ocaml https://stackoverflow.com/questions/179492/f-changes-to-ocam...
- ptx 9y agoYou still need the borrow checker, and this compiler won't change the kinds of programs you can write. It only works on programs that pass the borrow checker, just like the regular compiler, the difference being that it doesn't check that the program is valid (i.e. passes the checker) but assumes that its validity has already been checked earlier by the regular compiler. If you give an invalid program to the regular compiler it will be rejected, but if you give the same program to this compiler it might produce nonsense. So the developer of a program would feed it to the regular compiler for checking, but others could take the finished release of the program, assume that it's valid and feed it to this compiler instead, as I understand it.
- Sharlin 9y agoOTOH that's already the case with C and C++ where the compiler is allowed to assume undefined behavior cannot happen.
- Ygg2 9y agoSimilarily, I like Haskell, but find it's syntax and the whole function and currying thing confusing. Can't I just write Haskell without HKT, functions and currying? ------------------- Jokes, aside, if you aren't there for Rust borrow-checker, then I wonder, do you really need Rust at all?
- weberc2 9y agoI never understand this. I don't mind the borrow checker, I mind the affine type system. It really bugs me that I can't pass the same String into two functions in series, or why preventing that would be a desirable language property.
- kiriakasis 9y agoIIRC because the first function could deallocate it.
- weberc2 9y agoSeems like explicitly freeing memory should be regarded as unsafe. Unsafe things aside, the compiler should regard it as a copy instead of a move so multiple functions can safely use the resource without having to pass it by reference. If there is a good reason for an affine type system, I suspect it has to do with parallelism and not manual memory management.
- dbaupp 9y agoYour suspicion is wrong. It has benefits for parallelism, but is critical for ensuring safety of the more predictable (vs GC) Rust/C++ style of "manual" memory management. When one doesn't have a pervasive GC to dynamically clean things up, things still need to be freed but have to be freed in static locations (either explicit free calls in C or end of scopes in Rust and C++). Making this safe means defending against pointers becoming dangling which Rust does by restricting mutation. This restriction translates into some things that can't be copied, such as mutable references (that can lead to iterator invalidation and use after free, among every other undefined behaviour). In other words, explicit/scope-based freeing being unsafe means the only way to safely manage memory is a garbage collector (tracing or reference counting), which limits how many programs can be written that are verified-safe by a computer. I believe Ada takes the approach you suggest, but this limits it to be most useful for programs that don't allocate (or only do O(1) allocation during startup). Affineness also allows modeling things like session types better, letting programmers construct their own APIs that defend against mistakes. You could, and people have, argue that some types could be "autoclone", as in, have `clone` calls automatically inserted where necessary, but when it is raised, a lot of people express dislike because they feel it will encourage slow code and mean people aren't guided towards the (usually) better solution of using references.