Hacker News Reader

Comment by oxff | Hacker News Reader

It is a very cool abstraction that makes lots of things possible, which are (to my understanding) impossible to do in other languages without the explicit safety contract.

Like this: https://www.infoq.com/news/2021/11/rudra-rust-safety/, and I quote: "In C/C++, getting a confirmation from the maintainers whether certain behavior is a bug or an intended behavior is necessary in bug reporting, because there are no clear distinctions between an API misuse and a bug in the API itself. In contrast, Rust's safety rule provides an objective standard to determine whose fault a bug is."

People bring up `unsafe` Rust as an argument against the language, but to me it appears to be an argument `for` it.

View on HN

> People bring up `unsafe` Rust as an argument against the language

Those people usually don't understand what `unsafe` is.

I especially like the following quote in that context:

> The biggest failure in Rust‘s communication strategy has been the inability to explain to non-experts that unsafe abstractions are the point, not a sign of failure.

Appeared on TWiR: https://this-week-in-rust.org/blog/2021/10/20/this-week-in-r....

My only complaint is I wish they didn't name it `unsafe` and instead named it something like `compiler_unverifiable` so that people could more properly understand that we can make safe abstractions around what the compiler can't verify.

I like the word `unsafe`. It's a nice red flag to newbies that "you almost certainly shouldn't use this" and once you have enough experience to use `unsafe` well you'll know its subtleties well enough.

I don't think newbies using it would be a problem. There is an issue with people/companies evaluating Rust and stopping when they see `unsafe` without looking much further into it.

I just saw a tweet from Esteban Küber[0] the other day that made me rethink a silly thing I did:

"I started learning Rust in 2015. I've been using it since 2016. I've been a compiler team member since 2017. I've been paid to write Rust code since 2018. I have needed to use `unsafe` <5 times. That's what why Rust's safety guarantees matter despite the existence of `unsafe`."

For me, I was being a bit lazy with loading some config on program startup that would never change, so I used a `static mut` which requires `unsafe` to access. Turns out I was able to figure out a way to pass my data around with an `Arc<T>`. I think either way would have worked, but I figured I should avoid the unsafe approach anyway.

[0] https://twitter.com/ekuber/status/1511762429226590215

Yeah if you don't need mutation after initialization is done, Arc<T> is a good option for sharing. Lazy<T> (https://docs.rs/once_cell/latest/once_cell/sync/struct.Lazy....) is also nice, especially if you want to keep treating it like a global. I believe something like Lazy<T> is eventually going to be included in the standard library.

It's already on nightly: https://doc.rust-lang.org/std/lazy/struct.Lazy.html

I’ll be even lazier (heh) and just straight up leak memory for true once-set read-only config values.

https://github.com/shepmaster/stack-overflow-relay/blob/273a...

Don't ever use `static mut`. It's dangerous[1]. In nightly you now have `SyncUnsafeCell`[2] to avoid it.

[1] https://github.com/rust-lang/rust/issues/53639

[2] https://github.com/rust-lang/rust/pull/95438

If I were to go back and do it again I'd propose to rename unsafe blocks to something like `promise`, to indicate that the programmer is promising to uphold some invariants (the keyword on function declarations would still be `unsafe`). (Of course the idea of a "promise" means something different in JavaScript land, but I'm not worried about confusion there.)

While we're at it, I also would have preferred `&uniq` over `&mut`.

And from the great Steve Klabnik himself: StrBuf instead of „String“

I still like `trust_me`, maybe a bit unprofessional in some contexts though.

Or just `unchecked`. It is similarly short but holds a similar meaning. Of course `unchecked_by_the_compiler` would be more accurate.

That's inaccurate, because Rust still performs all the usual checks inside of unsafe blocks. The idea that unsafe blocks are "turning off" some aspect of the language is a persistent misconception, so it's best to pick a keyword that doesn't reinforce that.

Shrug. I really don't think unchecked is "wrong" in spirit, since adding an unsafe block makes it trivial to write code which ignores the usual boundary and pointer lifetime checks, which is not very different in practice from turning off checks. Also unsafe code is usually wrong, and deeply difficult to write correctly, much more so than C.

Also, I dislike the word "unsafe" since "unsafe code" is easily (mis)interpreted to mean "invalid/UB code", but "invalid/UB code" is officially called "unsound" rather than "unsafe". Unsafe blocks are used to call unsafe functions etc. (they pass information into unchecked operations via arguments), and unsafe trait impls are used by generic/etc. unsafe code like threading primitives (unsafe trait impls pass information into unchecked operations via return values or side effects).

unchecked would make a good keyword name for blocks calling unchecked operations, but I'm not so sure about using it for functions or traits.

Technically, code that contains UB is just UB, and unsound code is code that allows you to trigger UB using safe code only.

For example, this is UB:

  unsafe { std::hint::unreachable_unchecked() };

And this is an unsound code, that may not contain any UB if I call `unsound()` with `false`:

  fn unsound(trigger: bool) {
      if trigger { unsafe { std::hint::unreachable_unchecked() }; }
  }

That’s right, the keyword enables additional operations, namely those that can’t be checked — which one might even call “unchecked operations” to justify the keyword.

My problem with the word “unsafe” is that many people seem to think unsafe code blocks necessarily have security issues. Hence the bullying of library authors even in cases where the authors did their homework.

Anything about the mechanics of the implementation is a second-order detail compared to that, as far as I’m concerned.

Jon Goodwin's Cone [0] language had a nice idea of calling it "trust", as in, "Compiler, trust me, I know what I'm doing"

[0] https://cone.jondgoodwin.com/coneref/reftrust.html

I like the sound of “trusted”.

I think the benefit of the name "unsafe" is that it immediately tells newer users that the code inside has deeper magic than they may be comfortable using. Where "trusted" is what the writer attests to the compiler, "unsafe" is what writer warnings to a future reader.

I believe the term "unsafe" in this sense predates Rust. Haskell's GHC has unsafePerformIO [1], which is very similar conceptually. Generally used to implement an algorithm in a way where it can be pure/safe in practice, but where this cannot be proved by the type system.

[1] https://stackoverflow.com/questions/10529284/is-there-ever-a...

The unsafe concept exists since early 60's in systems programming languages.

The real issue here is Rust fans trying to make Rust into a type dependent language while abusing unsafe's original purpose.

    hold_my_beer {
    }

yeet {

}

Reply on news.ycombinator.com