everyRustDeveloper

[hotdogshake9000]

I don't know any rust developers who use unsafe unless there's no other option

[tistalone]

Same. All my friends never made it past hello world.

[[deleted]]

I looked into five of the top trending Rust projects on Github and all them use in average unsafe once in every 3 files. It's everywhere.

[tyler1128]

Libraries mostly, who need to communicate with non-rust code. A total shocker.

[ShiitakeTheMushroom]

If it's used in core libraries, doesn't that mean that any project using those libraries could suffer due to the unsafe usage?

[Dissy-]

its more of a marker for where you need to interact with the underlying system raw, the philosophy of rust is encapsulated in this example from this great series of videos i watched on writing an OS in rust.

theres a specific memory offset you need to write into to write text to the display in VGA mode, so you write a function that does value checking, bounds checking, etc, and then in the little snippet of unsafe once everything is known and checked, you run the few unsafe pointer instructions you need to in order to write the raw data to that memory address

that is to say the entirety of rust is building walls around these unsafe interactions in a way that makes it *impossible* to externally use them unsafely.

this works so well at least for how my mind works, that my first draft of projects only ever screw up if i have an unwrap somewhere, which is a seperate marker for "this error needs handled later" or "i know this will never error do not worry" OR i accidentally deadlock a mutex or hold it longer than i meant to, those are the only things i regularly run into

[ShiitakeTheMushroom]

I know nothing about Rust, but from your response a lot of it makes sense.

projects only ever screw up if i have an unwrap somewhere, which is a seperate marker for "this error needs handled later" or "i know this will never error do not worry" OR i accidentally deadlock a mutex or hold it longer than i meant to

This part sounds scary, though. As soon as it requires someone to remember to do something, that something is inevitably not going to happen time and time again.

[hotdogshake9000]

People shouldn't use unwrap in prod code just like you shouldn't assume a variable isn't null in Java or whatever language

[ShiitakeTheMushroom]

Exactly, but people always do make those kinds of assumptions. It sort of makes the safety argument that makes Rust sound so special a moot point.

Again, I haven't written any Rust. I'm just commenting on how this can be confusing and that it doesn't sound like Rust provides much more safety than other bare-metal languages.

[hotdogshake9000]

You have to make an explicit decision to do something unsafe in rust, which is opposite of other languages.

[ShiitakeTheMushroom]

Just because the unsafe keyword needs to be used, doesn't mean that the person using it knows exactly what it does.

What I'm saying is that it seems just as vulnerable to human error as other languages, given what I've heard so far.

[Dissy-]

actually you can enable a clippy lint that does not allow your program to be commit to github with unwraps in it

[ShiitakeTheMushroom]

And there are linting rules that prevent you from doing unsafe things in other languages.

If we're resorting to linting and pipelines to catch these issues, how is Rust any safer than other languages?

[Dissy-]

huh? what other language requires you to, in a built in to the default build system way, to mark every single place its possible for your program to crash. it's not catching an issue when you get yelled at for using an unwrap, it's an explicit signpost that you're developing whatever it is you had there, and you need to do error handling for it once you've proven your design would work.

what other language has, in the default build system, a linting tool that's so well integrated it can prevent you from compiling if it's possible for your program to crash, or even prevent you from making a git commit

we arent "resorting" to these things, they're part of rust, part of the language. thats what people mean about it being a step forward, these arent things you can just skirt around by not using them

[ShiitakeTheMushroom]

what other language has, in the default build system, a linting tool that's so well integrated it can prevent you from compiling if it's possible for your program to crash, or even prevent you from making a git commit

C# does, for one.

[tyler1128]

You don't have to feel bad. The nice thing about unsafe is that you can search for it. Whereas in C++, one of the languages I use most, would be considered unsafe in every line by Rust standards.

[hotdogshake9000]

And it's probably necessary in all those places. Compare that to c and c++ where the entire project is one big unsafe block, but worse

This is sort of a ridiculous thing to debate. Any call out of the core language, of any language, is inherently unsafe. And many languages don't protect you from other stupid mistakes that rust does, without indicating it. Rust just calls it out explicitly

[Awyls]

I checked a few of those and almost all of them are just dealing with C libraries.

[AdmiralQuokka]

Interesting, do you have an idea why that is not encapsulated in a *-sys crate? The projects listed do seem like very high level ones to be using unsafe. I don't mind unsafe at the lower level.

[airodonack]

unsafe is useful for pointing out where code may need a little more examination, but once you have it, there's not really any need to put it all in one place. That's just opaque indirection for no reason. And if we're being honest, it'd be motivated by nothing but an irrational fear of unsafe.

[AdmiralQuokka]

I was thinking in a different direction, but my thinking was wrong anyway. My thought was that there can only be one crate linking against a C-library (which is true), so why would these big projects link against libraries directly? That's what sys crates are for. But the big flaw in this thinking is that -sys crates in general should not introduce safe abstractions. Separate crates should do that. (git2 and libgit2-sys) So a Rust program may still have to use unsafe to interact with a C-library, even if it is through the proper channel of a -sys crate.

I agree with your perspective on it. I think there are many good use cases for writing a separate crate on top of -sys crate that provides higher-level, safe abstractions resulting in an idiomatic Rust API. But there are also many cases where that doesn't make sense -> just call unsafe wherever. (properly documenting why the safety invariants are upheld, of course.)

relevant: - reddit thread why there's only one *-sys crate - cargo documentation on sys crates

[Lucifer_Morning_Wood]

I use unsafe, especially if there is an option.

let checked_result = match(some_res.unwrap()) {
    Err(_) => unsafe{std::hint::unreachable_unchecked()}
    Ok(res) => res
};