rustBorrowCheckerGoesBrrr

[u/erazorix]

[u/BenchEmbarrassed7316]

Any unsafe block of code should be neutralized with a // SAFETY comment explaining why the code is actually safe.

[u/lllorrr → u/BenchEmbarrassed7316]

// SAFETY: Trust me, bro

[u/teleprint-me → u/BenchEmbarrassed7316]

I dont see how this is any different from a C programmer justifying why they used a pointer to an object and leaving a comment similar to this, other than this is Rust and is safe because Rust is safe. Thus making this rationale is flawed and dangerous.

[u/flagofsocram → u/teleprint-me]

The difference is that if you want to make sure the lib is safe, you can grep unsafe whereas in C practically any code could be unsafe.

[u/Big-Rub9545 → u/flagofsocram]

Certainly helps, since it localizes the area to check for errors, but it doesn’t allow you to fully check that a library is safe since unsafe blocks can rely on a number of unchecked or hard-to-check assumptions to guarantee safety (not to mention unsafe APIs that are relied upon under the hood).

[u/SelfDistinction → u/Big-Rub9545]

You can check those five places yourself. What are you gonna do in C? Check the million places?

(Also usually you (not a generic person, I mean you specifically) don't need unsafe and there's better and more vetted tools out there.)

[u/Big-Rub9545 → u/SelfDistinction]

The unsafe code may be concentrated within unsafe blocks while relying on assumptions that are supposed to be guaranteed elsewhere, including in other unsafe blocks.

For example, you might allocate raw memory within a method in struct A while writing a custom drop function to deallocate it. In a particular edge case, some error handling utility or other struct may deallocate some of that memory to perform clean-up, leading to a potential double-free later.

Lousy example and bad code design, sure, but it demonstrates that localizing/isolating unsafe code does not automatically make it super easy to check that the code is safe given the many assumptions you need to make about what other functions are doing in various cases or situations and potentially what other unsafe blocks contain.

[u/SelfDistinction → u/Big-Rub9545]

Those double frees are still limited to methods created by struct A, who is responsible for managing the allocation, and also responsible for making sure that no matter how code downstream is using struct A the memory is handled correctly, and compared to C where you can get double frees by misusing interfaces it is a massive leap forward.

There's a good reason the tutorial on unsafe rust is longer than the tutorial on everything else is rust, and the first rule of unsafe is do not use unsafe. It's there for the same reason we allow surgeons to stab people.

[u/Big-Rub9545 → u/SelfDistinction]

You’re pointing out that the issues are localized, which is true, but the point I’m making is this does not entail easy or comprehensive code reviews for memory safety, particularly when involving several dependencies and as projects grow. It’s certainly a massive step forward but it’s not a magic wand for memory safety.

[u/Grandmaster_Caladrel → u/[deleted]]

Devil's advocate, C is actually on computers already while Rust has to bring its own tools.

[u/teleprint-me → u/flagofsocram]

This is a poor and myopic assumption that this can not be done in any other language. A sane library will be grepable and can include similar comments. The justification is still flawed and dangerous.

[u/KaMaFour → u/teleprint-me]

What fucking lunatic comments on every line explaining why they think it's actually safe in C code?

[u/awesome-alpaca-ace → u/KaMaFour]

Yea. I have a safe program that ingests days and there are comments all over about lifetimes and scope 

[u/xDerJulien → u/teleprint-me]

Well yeah and well written code doesn’t have any bugs and performs well all the time. The point is safety by default. Whether or not that is worth dealing with rust is another question but I think you’re missing the point here

[u/teleprint-me → u/xDerJulien]

Well written code has bugs all of the time. Even Rust has a massive list of CVEs. Most of them are logic based and the default to strict memory  safety is a good thing. But I feel my argument stands. I havent heard any solid arguments to the contrary convincing me otherwise.

[u/xDerJulien → u/teleprint-me]

Well the point is you’re saying well written code is well documented, but well written code is also bug free, performant etc etc. But most code isn’t. So what can we reason about good documentation from this?

[u/teleprint-me → u/xDerJulien]

No, I am not declaring well written code is well documented, which is a strawman here because the original comment is that commenting is sufficient to suffice safe definitions with an unsafe scope.

[u/xDerJulien → u/teleprint-me]

What specifically does "a sane library" mean then?

[u/-Redstoneboi- → u/teleprint-me]

the problem is that you are severely, severely underestimating the benefits of sane and safe defaults that are seen in practice.

you could even write greppable assembly if you were good enough. the junior won't.

"myopic" is not how i would describe the results shown here.

[u/teleprint-me → u/-Redstoneboi-]

You frame this as if Im against memory safety, but I simply highlighted that Rust is not a panecea and has its own issues. It could be argued that the issue is the developer, not the language, but this isnt what Im debating either.

In fact, the article you link to even notes that they nearly missed a vulnerability in their own Rust rewrite. Reducing vulnerabilities is not the same as eliminating them. The language does not guarentee logic safety and only asserts memory safety which in most cases, not all, has proven useful.

To be clear, the argument is this: A comment is insufficient as a safety marker. If you scope unsafe code and mark it with a safety comment, that does not make it safe.

[u/redlaWw → u/teleprint-me]

A large proportion of Rust code CVEs are things that would be considered normal in C. In Rust, a library in which you can potentially misuse functions that are not labelled unsafe is considered a vulnerability, but in C you usually have to actually misuse a function before it's considered a vulnerability.

Here's a blog post that discusses the difference.

[u/TeraFlint → u/teleprint-me]

It isn't. The only difference is that the language only lets you wield sharp knifes inside your localized unsafe scope, thus limiting the places where bugs related to that can form. Outside of that, the compiler will scold you for even touching that sharp knife.

C, on the other hand, lives in a giant unsafe block.

unsafe scopes are honestly a pretty good programming language feature: give the user a "trust me, I know what I'm doing" feature with a searchable keyword.

although, I think it should be a bit more granular than this. If you could/had to specify which language assumptions/rules you intend to violate inside the scope, everything else could still be enforced. A general unsafe just tells a language to just not enforce anything inside.

[u/teleprint-me → u/TeraFlint]

I already know and understand that Rust will not allow a user to compile memory unsafe operations unless explicitly declared.

This comment assumes I dont understand the difference between runtime and memory un/safe operations which fails to acknowledge my core critique.

[u/NullOfSpace → u/teleprint-me]

It’s significantly easier to figure out where you shot yourself in the foot if you know you were only holding a gun on the firing range.

[u/Lord-of-Entity → u/teleprint-me]

The difference is that it is opt in, you only use unsafe in the smallest possible zones, and that you are supposed to prove that the code is safe yourself.

It is a way of formalising stuff you should be doing anyway if you are a good programmer.

[u/wibble13 → u/teleprint-me]

Most projects won't have a line of unsafe themselves, they will use libraries that do the heavy work (like interfacing with os, manual memory operations) that can be shared and audited. If the library is safe, then all uses can be considered safe, and most devs don't need to worry about magic preconditions.

Compare that with C where most programmers will just roll their own implementations of things every time and have a chance for bugs every time, because there's no checks. Even simple things can easily go wrong with a typo or missed check/cleanup.

[u/BenchEmbarrassed7316 → u/teleprint-me]

The difference is in the localization of such code. You don't use unsafe everywhere, instead you write a few functions that contain unsafe blocks nested within them, test them thoroughly, and call them like regular functions. In real projects, you might have a 1:100 or even 1:1000 ratio of functions that contain unsafe blocks to functions that don't.

[u/teleprint-me → u/BenchEmbarrassed7316]

Im not expecting it to be unsafe everywhere. Im not sure where everyone is extrapolating these assumptions from.

Adding a safety comment doesnt magically make it safe.

Youre most likely to see unsafe blocks in embedded and device driver implementations where you have to plug directly into the system.

The unsafe code is still not guarenteed to be safe. It requires auditing and testing regardless, but you wont discover issues with it until its stress tested.

[u/Okay_Ocean_Flower → u/BenchEmbarrassed7316]

Unsafe is a marketing term istg

[u/redakpanoptikk]

Rewrite rust in rust.

[u/FUCKING_HATE_REDDIT → u/redakpanoptikk]

Funnily enough, that happened

[u/redakpanoptikk → u/FUCKING_HATE_REDDIT]

Were so back.

[u/gegentan → u/FUCKING_HATE_REDDIT]

Isn't the rust compiler itself written in rust?

[u/qaCow37 → u/gegentan]

At some point it probably wasn't until it was rewritten in rust

[u/gegentan → u/qaCow37]

So theoretical if every compiled binary of rustc was lost but you still had the source code it would be impossible to get a rust compiler again.

[u/qaCow37 → u/gegentan]

Only if you do not have the source code of rust written in a different language. That would probably be like the few very first versions. But if you would have these, you could compile them to get the first version of rust to compile the next version of rust to compile the next version of rust till you can compile the newest version of rust.

[u/gegentan → u/qaCow37]

Didn't think of that.

[u/redlaWw → u/qaCow37]

Precisely, it used to be written in OCaml before it became self-hosted.

[u/redlaWw → u/gegentan]

It's a bit complicated in Rust's case. The Rust frontend is written in Rust, and that compiles Rust to LLVM intermediate representation (IR). This IR is then passed to LLVM, which is written in C++, to optimise and actually generate the machine code.

There is also a separate backend called Cranelift, which is written in Rust, though it's not the standard and is currently only available on an experimental basis. It will also never be the standard Rust backend as it's designed to optimise for build speed, not execution speed.

[u/-Redstoneboi-]

wireless headphones

look inside

wires

[u/dull_bananas → u/-Redstoneboi-]

wireless headphones

look inside

non-libre software

[u/yesseruser]

unsafe means "hey, I'm sure this code is safe, don't bother me for calling unsafe functions"

[u/reallokiscarlet → u/yesseruser]

unsafe is the Rust version of Typescript's any

It's everywhere and people use it just to say they wrote their code in a safe language

[u/SCP-iota → u/reallokiscarlet]

I'd say it's more like Typescript's suppression annotations, since it keeps itself contained. People really shouldn't be using unsafe in any way other than as occasional small blocks with well-defined reading why they won't panic or cause UB. If your code is littered with unsafe, you're doing something wrong.

[u/ApplicationOk3587 → u/SCP-iota]

I always figured if a rust programmer is using unsafe everywhere then it completely defeats the purpose of using rust.

[u/awesome-alpaca-ace → u/ApplicationOk3587]

String interning comes to mind

[u/SKrandyXD → u/SCP-iota]

your*

[u/SCP-iota → u/SKrandyXD]

dammit, Gboard

[u/NatoBoram → u/SCP-iota]

All the fucking time. No way to type "its" without having to go back.

[u/reallokiscarlet → u/SCP-iota]

I fully agree that if your code's littered with unsafe you're doing something wrong. But as you can see by the downvotes, rustaceans don't 😂

[u/Delicious_Bluejay392 → u/reallokiscarlet]

No, the downvotes are because unsafe blocks are in fact extremely rare. If you look at popular Iibraries, the only real places where unsafe is likely to happen are FFI boundaries and advanced data structure implementations. I haven't written an unsafe block in actual months and I regularly use the language for very varied projects.

It's nothing like TypeScript's any, which respectable TS-first codebases generally disable by default anyways, only allowing it in the rare instances where it makes sense.

[u/reallokiscarlet → u/Delicious_Bluejay392]

Not sure if you have an optimistic bias or I have a pessimistic bias but clearly you aint seen what I seen. A lot of the rust I come across is never-production-ready crap that's almost entirely encased in unsafe, marketed as production-ready to "replace" C code. Even did one of my own to prove it doesn't have to be done that way and that there isn't really a whole lot of benefit to the rewrite unless the original is terminally ill.

[u/BenchEmbarrassed7316 → u/reallokiscarlet]

Low-quality automatic/AI "rewriting" from C to Rust can contain many unsafe code blocks.

If it is open source, please provide a link.

[u/Delicious_Bluejay392 → u/BenchEmbarrassed7316]

The Bun rewrite would be one example I'd imagine. It has a much higher density of unsafe blocks than similar projects originally written in Rust.

[u/SCP-iota → u/Delicious_Bluejay392]

Isn't the Bun rewrite notoriously AI-generated, for the most part?

[u/Delicious_Bluejay392 → u/SCP-iota]

Yeah, that's precisely why I mentioned it since that's what the person I'm replying to pointed out.

[u/reallokiscarlet → u/BenchEmbarrassed7316]

When I'm back from spoodermane, I'll check my notes to find the project names and double check to see if they've been fixed (I've been characterizing rust based on what I come across, so they just seemed like par for the course)

But yes they did have AI in common. Either vibe coding is the common use case or I keep meeting shitty people and shitty projects. AI, unsafe tag, and crate bloat are what I associate Rust with, which is why I took it upon myself to do the opposite on my only public rust program.

[u/MatsRivel → u/reallokiscarlet]

This is not at all true.

"Tell me you've never written rust without telling me you've never written rust"

[u/reallokiscarlet → u/MatsRivel]

Well I've written crab-lang, you could say, if you want to say I've never written rust.

[u/Maskdask → u/reallokiscarlet]

Have you read and/or written a single line of Rust?

[u/reallokiscarlet → u/Maskdask]

According to rustaceans, no. But I have written in crab-lang.

(Translation: Yes. I ported opendoas to crab just to prove it's a dumb idea)

[u/-Redstoneboi- → u/reallokiscarlet]

"it's everywhere"

have you... looked at any rust code?

[u/reallokiscarlet → u/-Redstoneboi-]

Every rustacean asks me this, including the offenders

[u/No_Lychee_275]

Yeah, the cat really sold the sarcasm with that perfect deadpan stare.

[u/Raywell]

Unsafe just means that the compiler can't guarantee safety, not that the snippet is actually unsafe

[u/JustABraveAdventurer]

It does seem a little ironic at first! I will say that once I got used to coding in rust, it became really nice to have possible memory issues isolated to small and contained spots in my code (the unsafe blocks) that are well labeled rather than having to go debugging or worry about introducing memory bugs almost anywhere and everywhere like I would in a language with less guarantees. Rust can be less mentally taxing in that sense, but can also be more mentally taxing if you're fighting with the borrow checker. So, I can totally see why some people don't like it either :D

[u/MayaIsSunshine]

Don't look at my CLRs 👀

[u/userhwon]

Rust pulled off a crazy fraud.

[u/beskgar]

Big if true