Live data from Hacker News

Rust--: Rust without the borrow checker

github.com

141–150 of 269 posts

Re: Rust--: Rust without the borrow checker

#141
post #132

Isn't unsafe just for that? Why does it need a separate compiler?

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.

Re: Rust--: Rust without the borrow checker

#142

This 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?

Correct, I was reading a very interesting blog post [1] on how the rust compiler will change the LLVM annotaions like sending noalias for mutable pointer. This changes a lot the generated machine code. Disabling the borrow checker won't enable those LLVM flags.

[1] https://lukefleed.xyz/posts/who-owns-the-memory-pt1/

Re: Rust--: Rust without the borrow checker

#143

My controversial opinion: If Rust were to "borrow" something from the C/C++ spirit, then disabling the borrow checker should be available as a compiler option. As in, you're an adult: if you want it, you can have it, instead of "we know better".

If you could disable the borrow checker globally, projects would do it, and it would become impossible to compile anything with it enabled. You can already disable it locally: the unsafe keyword is for that.

The unsafe keyword doesn't disable the borrow checker... it lets you interact with different pointer types that aren't borrow checked, but if you're using the normal reference types in rust the same guardrails are still in place.

Re: Rust--: Rust without the borrow checker

#144

This 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?

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…

For all its faults, and it has many (though Rust shares most of them), few programming languages have yielded more value than C++. Maybe only C and Java. Calling C++ software "garbage" is a bonkers exaggeration and a wildly distorted view of the state of software.

Re: Rust--: Rust without the borrow checker

#145

Earlier quoted context omitted.

herb sutter and the c++ community as a whole have put a lot of energy into improving the language and reducing UB; this has been a primary focus of C++26. they are not encouraging people to “churn out more broken garbage”, they are encouraging people to write better code in the language they have spent years developing libraries and expertise in.

And for which there's often no serious alternative to in many domains anyway.

Yes, many or even most domains where C++ sees a large market share are domains with no other serious alternative. But this is an indictment of C++ and not praise. What it tells us is that when there are other viable options, C++ is rarely chosen.

The number of such domains has gone down over time, and will probably continue to do so.

Re: Rust--: Rust without the borrow checker

#146
post #125

Earlier quoted context omitted.

I have been using kde for years now without a single problem. Calling cpp garbage sounds wrong.

People who can't do something, sometimes assume nobody else possibly could.

I’m sure some people could tiptoe through minefields daily for years, until they fail. Nobody is perfect at real or metaphorical minefields, and hubris is probably the only reason to scoff at people suggesting alternatives.

Re: Rust--: Rust without the borrow checker

#147
I've been thinking of writing a language with Rust's ergonomics but less of the memory safety stuff. I prefer using no dynamic allocations, in which case the only memory safety feature I need is leaking references to locals into outer scopes. As for the thread safety stuff, most of my stuff is single-threaded.

Re: Rust--: Rust without the borrow checker

#148

This 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?

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…

How are we still having the same trade off discussion being argued so black and white when reality has shown that both options are preferred by different groups.

Rust says that all incorrect programs (in terms of memory safety) are invalid but the trade is that some correct programs will also be marked as invalid because the compiler can't prove them correct.

C++ says that all correct programs are valid but the trade is that some incorrect programs are also valid.

You see the same trade being made with various type systems and people still debate about it but ultimately accept that they're both valid and not garbage.

Re: Rust--: Rust without the borrow checker

#149
post #59

Earlier quoted context omitted.

The borrow checker doesn't decide when things are dropped. It only checks reference uses and doesn't generate any code. This will work exactly the same as long as your program doesn't violate any borrowing rules.

No, I get that from an architectural perspective they are separate processes. The point is, unlike in other languages, the compiler is developed assuming the input has been borrow checked, right? So it is surprising to me that it doesn’t blow up somewhere when that invariant doesn’t hold.

In a correct program, the borrow checker has no effect.

Languages like C compile code with the understanding that if the compiler can't prove the code is incorrect, it'll assume it's correct. Rust compiles with the expectation that unless the compiler can prove the code correct (according to the language rules), it won't compile it. In C, all programs that only perform defined behaviour are valid, but many programs which exhibit undefined behaviour are also valid. In safe Rust, all programs which exhibit undefined behaviour are invalid. But as a trade-off, many programs which would actually execute perfectly well are also considered invalid.

In both cases, once you get past the layers that check stuff, you may normally assume that whatever you have has already been shown to be OK and you probably don't have enough information to re-check while compiling. It might blow up at runtime, it might not.

Re: Rust--: Rust without the borrow checker

#150

It would be great if it only allowed multiple mutable borrows. That's the only one that always bugs me, for mostly innocuous stuff.

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.
Post reply on HN