Top
Best
New

Posted by ravenical 1/1/2026

Rust--: Rust without the borrow checker(github.com)
139 points | 260 commentspage 3
p0w3n3d 1/1/2026||
There are easier ways of making segfault than writing a custom compiler.
hacker_homie 1/1/2026||
I wish I could make the borrow checker give warnings not errors. It would make exploration so much easier, so I don’t have to fight the borrow checker until I know how to build what I want.
hoppp 1/1/2026|
Then you have code full of warnings and undefined behavior?

I think fighting the borrow checker is more like a rite of passage. Rust is not my favorite language but the borrow checker is great.

leoh 1/1/2026||
This is not a hacker’s take
hoppp 1/1/2026||
I'm lazy. If you turn off the borrow checker the code will need a rewrite later, since it's there for a very good reason.
throwawayffffas 1/1/2026||
It would be great if it only allowed multiple mutable borrows. That's the only one that always bugs me, for mostly innocuous stuff.
threethirtytwo 1/1/2026|
This isn’t actually unsafe unless shared across threads right? Maybe the borrow checker needs to be more nuanced to differentiate this rather then outright banning it all together. It would increase the logic of the borrow checker by a lot though.
aw1621107 1/1/2026||
> This isn’t actually unsafe unless shared across threads right?

Multiple mutable borrows do not need multiple threads to cause UB. Consider the following:

    fn main() {
        let mut v = vec![0, 1, 2];
        let e = &mut v[0];
        v.push(3);
        *e = 4;
    }
rustc refuses to compile this code due to multiple mutable borrows of `v` [0]:

    error[E0499]: cannot borrow `v` as mutable more than once at a time
     --> <source>:4:5
      |
    3 |     let e = &mut v[0];
      |                  - first mutable borrow occurs here
    4 |     v.push(3);
      |     ^ second mutable borrow occurs here
    5 |     *e = 4;
      |     ------ first borrow later used here
If rustc allowed multiple mutable borrows here, `v.push(3)` would cause the underlying vec to reallocate, which invalidates `e`, and so `*e = 4` would cause UB.

[0]: https://rust.godbolt.org/z/bsxKTWG3K

bhaney 1/1/2026||
Are the compile times noticeably faster?
worldsavior 1/1/2026|
Probably not, because it seems like it still checks for errors but just suppresses them.
misnome 1/1/2026||
Even so, the borrow checker repeatedly profiles as an insignificant part of compile times, so wouldn’t make a difference.
shmerl 1/1/2026||
Isn't unsafe just for that? Why does it need a separate compiler?
andrewaylett 1/1/2026||
Unsafe isn't so unsafe that it disables the borrow checker!

The two main things the compiler allows in an unsafe block but not elsewhere are calling other code marked "unsafe" and dereferencing raw pointers. The net result is that safe code running in a system that's not exhibiting undefined behaviour is defined to continue to not exhibit undefined behaviour, but the compiler is unable in general to prove that an unsafe block won't trigger undefined behaviour.

You can side-step the borrow checker by using pointers instead of references, but using that power to construct an invalid reference is undefined behaviour.

idontsee 1/1/2026||
The borrow checker still applies in unsafe { } blocks. What it means (iirc) is that you can do pointer/memory stuff that would otherwise not be allowed. But you still fully adhere to Rust semantics
JoelJacobson 1/1/2026||
Rust without async maybe?
juped 1/1/2026|
This would actually be good though!
nineteen999 1/1/2026||
Love the "Note for LLMs" and the NSFW license.
reverseblade2 1/1/2026||
Should be named in rust we don't trust
ismailmaj 1/1/2026|
undefined behavior on steroids be like:
More comments...