6 ms·

> There's too much "unsafe" code in libraries. Which libraries? I see very few that do this, and all of them are safe abstractions containing some unsafe code

> There's too much "unsafe" code in libraries. Which libraries? I see very few that do this, and all of them are safe abstractions containing some unsafe code. You keep repeating this claim but I haven't seen any evidence to back it up. > If Rust let you access a slice of bytes as an slice of ints, alignment and length permitting, the code above could be much more straightforward. That's what I mean about expressive power. The hack to do that used here: The byteorder crate lets you do this. Of course, it uses unsafe code, but that's safely encapsulated away (and easy to verify). This crate doesn't use it, but it could. Not every operation needs to be baked into the language semantics.

yazaddaruvala 10y ago
While I mostly agree with you, I'd like to play devil's advocate: The Rust core team is relatively relaxed about the community's usage of `unsafe`. I say this because they do not seem to be interested in actively discouraging it's usage. i.e. `unsafe` is discouraged in documentation, not via tools. "Hey please don't use `unsafe` unless you know what you're doing". Is like writing a comment in Javascript, `function(x /* int */) {`. Ideally, the usage of `unsafe` should be discouraged by the compiler via friction. The compiler should, at the least, spit out some metrics after a compile cycle about the percentage of `unsafe` lines/instructions. Even more ideal, when the compiler detects an `unsafe` it would pause and ask, "Is Crate Z trusted [y/N]?". Cargo can then make this easy in Cargo.toml. All of a sudden Crate writers need to think twice about their usage of `unsafe`, will users be willing to trust my code? is using `unsafe` here really worth the risk of adopting fewer users? is there already a library that solves this which is generally trusted?
- Manishearth 10y ago
  Nobody is putting effort into propaganda about unsafe because the community is already very strongly averse to this, and is careful about writing unsafe code. It's not a problem. If it becomes a problem (I doubt it) we can put effort into it. People learn about the language through discussion or documentation, and both of these venues actively discourage unsafe. The one resource out there that teaches unsafe code in depth (the Rustonomicon) is very heavy on warning the reader about unsafe code pitfalls and in general discouraging the reader from writing unsafe code. A tool for tracking unsafe dependencies has been talked about before, though. Sounds like a good idea to me. Like I said I don't think there's a particular need for it, but it would be nice to have.
  - duaneb 10y ago
    Have you ever been bitten by unsafe code? IMHO any metrics would be gamed and prioritized above actually quality. As actual quality isn't suffering, why add the unsafe metric in at all? Seems like paranoia not born out of experience.
    - Manishearth 10y ago
      > Have you ever been bitten by unsafe code? Yeah. Most often in FFI code (when the invariants are much harder to uphold). Rarely when writing unsafe abstractions. The few times I remember this happening with abstractions is due to really old code that broke in a compiler upgrade (pre-1.0). > IMHO any metrics would be gamed and prioritized above actually quality. Yeah, there have been discussions in the past about a "safe code" badge for crates and stuff like this, and the conclusion is that it might discourage people from using unsafe code where they actually should be.
    - yazaddaruvala 10y ago
      I have been bitten by the lack of a type checker. I have been bitten by inexplicit casts. I have been bitten by segfaults. I have been bitten by poor/no tests. I have been bitten by mutable containers. In every case, more constraints and more explicitness have liberated portions of my cognitive load. I've ended up with fewer bugs, more flexibility to play, reduced ramp-up time for new devs, increased speed of iteration. Why would this trend, to add constraints and explicitness, not continue to be beneficial? P.S. You haven't been bitten by unsafe code, yet, because the people that write Rust, are still builders of the language. It is still in the early adopter stage. Think about Java, which is now predominantly written by users of the language, imagine that for Rust. The teams currently working with Rust, chose to do so as an experiment. They don't have to get a feature out tomorrow, but that will come. Similarly, there isn't "legacy Rust", yet (except in the compiler - which is fine because it is literally maintained by the experts). Is it really worth waiting for crappy code to get written, then re-written, then forgotten and finally broken, and to relive our mistakes, before we fix a predictable problem?
- Animats 10y ago
  Tooling could encourage this by requiring that if a module or crate contains unsafe code, its name has to contain "unsafe".
  - marvy 10y ago
    That sounds horrifying (to me). I'm not a Rust user. I've never written a line of Rust code in my life. So my opinion is not worth much. And I'm exaggerating a bit. But still. I don't think I can explain my real reason for objecting to such a thing; it's more emotional than rational, but at least let me give one rational-sounding example of where I think even you would agree such a policy would backfire. Some library comes out, becomes fairly popular. Eventually a version 2 is released, but the new version has a few lines of unsafe code, whereas the old one did not. Maybe it's to enable a new feature, or maybe it's for performance. Maybe the author was properly paranoid and did a full-fledged correctness proof that his code had no bugs compared to the documentation, and then verified the proof with several different interactive proof assistants. (This is getting a bit unrealistic, but bear with me for a few more sentences.) But he now has to rename his crate, instantly making the upgrade process for existing users way more annoying. And to add insult to injury, the new name is wrong! There's nothing unsafe about his code, as far as users are concerned. The only trouble is that the Rust compiler could not prove it safe. As you pointed out yourself, this is not surprising: it can't even cope with a linked list! Sophomores in college implement these things, but the borrow checker can't cope with them. So of course unsafe is needed. And if version 3 finds a workaround, so that unsafe is no longer needed, do you rename it yet again? People think Java's checked exceptions are annoying, but surely this is far worse?
- steveklabnik 10y ago
  > Ideally, the usage of `unsafe` should be discouraged by the compiler via friction. This is enforced via tools: you have to say 'unsafe' to use something unsafe. That's the speed bump. In addition, there's a lint that you can on to fail the build if you use `unsafe`. This won't apply to your dependencies, but you can make it apply to your code.
  - yazaddaruvala 10y ago
    Explain to me why, ticki, who is a relatively experienced Rust dev choose to retype `unsafe` over re-using a crate (byteorder) which is supposedly equivalent? 1. Crate discoverability could be improved. 2. He wanted full control of the abstraction. 3. This particular library is just an experiment. 4. ... Regardless of the reason, the reality is the same, `unsafe` could have been ignored but wasn't. Instead, the path of least resistance was to re-write `unsafe` blocks. IMO, it is not truly "friction"/discouraged if it is also the path of least resistance.
    - steveklabnik 10y ago
      I can't read ticki's mind, so I can't really say why they made this decision. But I don't think you're right to suggest that this is inherently about using the path of least resistance; #2 on your list is not about that, for example.
      - yazaddaruvala 10y ago
        Disagree. Unless improving the flexibility of the existing abstraction has been explored and deemed infeasible, re-building an abstraction instead of working with the existing abstraction's owner, to improve its flexibility, is taking the path of least resistance.
    - Manishearth 10y ago
      > is a relatively experienced Rust dev choose to retype Probably because they were an experienced dev and are experienced enough with unsafe code to write good unsafe code without worrying about it. It was a minor unsafe operation of which the validity is easily proven. Doesn't really prove that there isn't an aversion to unsafe code in the community. I would generally put the folks who work on Redox in the bucket of "experienced people who know how to write unsafe code" and am pretty sure that they're more comfortable with writing unsafe code than most. Byteorder is a crate that handles this neatly and well (including endianness and stuff), but for ticki's purposes, really, a simple type pun on integers is not that bad. It's like the left-pad of unsafe code.
jononor 10y ago
How does one verify unsafe blocks in a library? Wondering what are the best practices.

yazaddaruvala 10y ago

While I mostly agree with you, I'd like to play devil's advocate: The Rust core team is relatively relaxed about the community's usage of `unsafe`. I say this because they do not seem to be interested in actively discouraging it's usage. i.e. `unsafe` is discouraged in documentation, not via tools. "Hey please don't use `unsafe` unless you know what you're doing". Is like writing a comment in Javascript, `function(x /* int */) {`. Ideally, the usage of `unsafe` should be discouraged by the compiler via friction. The compiler should, at the least, spit out some metrics after a compile cycle about the percentage of `unsafe` lines/instructions. Even more ideal, when the compiler detects an `unsafe` it would pause and ask, "Is Crate Z trusted [y/N]?". Cargo can then make this easy in Cargo.toml. All of a sudden Crate writers need to think twice about their usage of `unsafe`, will users be willing to trust my code? is using `unsafe` here really worth the risk of adopting fewer users? is there already a library that solves this which is generally trusted?

Manishearth 10y ago
Nobody is putting effort into propaganda about unsafe because the community is already very strongly averse to this, and is careful about writing unsafe code. It's not a problem. If it becomes a problem (I doubt it) we can put effort into it. People learn about the language through discussion or documentation, and both of these venues actively discourage unsafe. The one resource out there that teaches unsafe code in depth (the Rustonomicon) is very heavy on warning the reader about unsafe code pitfalls and in general discouraging the reader from writing unsafe code. A tool for tracking unsafe dependencies has been talked about before, though. Sounds like a good idea to me. Like I said I don't think there's a particular need for it, but it would be nice to have.
- duaneb 10y ago
  Have you ever been bitten by unsafe code? IMHO any metrics would be gamed and prioritized above actually quality. As actual quality isn't suffering, why add the unsafe metric in at all? Seems like paranoia not born out of experience.
  - Manishearth 10y ago
    > Have you ever been bitten by unsafe code? Yeah. Most often in FFI code (when the invariants are much harder to uphold). Rarely when writing unsafe abstractions. The few times I remember this happening with abstractions is due to really old code that broke in a compiler upgrade (pre-1.0). > IMHO any metrics would be gamed and prioritized above actually quality. Yeah, there have been discussions in the past about a "safe code" badge for crates and stuff like this, and the conclusion is that it might discourage people from using unsafe code where they actually should be.
  - yazaddaruvala 10y ago
    I have been bitten by the lack of a type checker. I have been bitten by inexplicit casts. I have been bitten by segfaults. I have been bitten by poor/no tests. I have been bitten by mutable containers. In every case, more constraints and more explicitness have liberated portions of my cognitive load. I've ended up with fewer bugs, more flexibility to play, reduced ramp-up time for new devs, increased speed of iteration. Why would this trend, to add constraints and explicitness, not continue to be beneficial? P.S. You haven't been bitten by unsafe code, yet, because the people that write Rust, are still builders of the language. It is still in the early adopter stage. Think about Java, which is now predominantly written by users of the language, imagine that for Rust. The teams currently working with Rust, chose to do so as an experiment. They don't have to get a feature out tomorrow, but that will come. Similarly, there isn't "legacy Rust", yet (except in the compiler - which is fine because it is literally maintained by the experts). Is it really worth waiting for crappy code to get written, then re-written, then forgotten and finally broken, and to relive our mistakes, before we fix a predictable problem?
Animats 10y ago
Tooling could encourage this by requiring that if a module or crate contains unsafe code, its name has to contain "unsafe".
- marvy 10y ago
  That sounds horrifying (to me). I'm not a Rust user. I've never written a line of Rust code in my life. So my opinion is not worth much. And I'm exaggerating a bit. But still. I don't think I can explain my real reason for objecting to such a thing; it's more emotional than rational, but at least let me give one rational-sounding example of where I think even you would agree such a policy would backfire. Some library comes out, becomes fairly popular. Eventually a version 2 is released, but the new version has a few lines of unsafe code, whereas the old one did not. Maybe it's to enable a new feature, or maybe it's for performance. Maybe the author was properly paranoid and did a full-fledged correctness proof that his code had no bugs compared to the documentation, and then verified the proof with several different interactive proof assistants. (This is getting a bit unrealistic, but bear with me for a few more sentences.) But he now has to rename his crate, instantly making the upgrade process for existing users way more annoying. And to add insult to injury, the new name is wrong! There's nothing unsafe about his code, as far as users are concerned. The only trouble is that the Rust compiler could not prove it safe. As you pointed out yourself, this is not surprising: it can't even cope with a linked list! Sophomores in college implement these things, but the borrow checker can't cope with them. So of course unsafe is needed. And if version 3 finds a workaround, so that unsafe is no longer needed, do you rename it yet again? People think Java's checked exceptions are annoying, but surely this is far worse?
steveklabnik 10y ago
> Ideally, the usage of `unsafe` should be discouraged by the compiler via friction. This is enforced via tools: you have to say 'unsafe' to use something unsafe. That's the speed bump. In addition, there's a lint that you can on to fail the build if you use `unsafe`. This won't apply to your dependencies, but you can make it apply to your code.
- yazaddaruvala 10y ago
  Explain to me why, ticki, who is a relatively experienced Rust dev choose to retype `unsafe` over re-using a crate (byteorder) which is supposedly equivalent? 1. Crate discoverability could be improved. 2. He wanted full control of the abstraction. 3. This particular library is just an experiment. 4. ... Regardless of the reason, the reality is the same, `unsafe` could have been ignored but wasn't. Instead, the path of least resistance was to re-write `unsafe` blocks. IMO, it is not truly "friction"/discouraged if it is also the path of least resistance.
  - steveklabnik 10y ago
    I can't read ticki's mind, so I can't really say why they made this decision. But I don't think you're right to suggest that this is inherently about using the path of least resistance; #2 on your list is not about that, for example.
    - yazaddaruvala 10y ago
      Disagree. Unless improving the flexibility of the existing abstraction has been explored and deemed infeasible, re-building an abstraction instead of working with the existing abstraction's owner, to improve its flexibility, is taking the path of least resistance.
  - Manishearth 10y ago
    > is a relatively experienced Rust dev choose to retype Probably because they were an experienced dev and are experienced enough with unsafe code to write good unsafe code without worrying about it. It was a minor unsafe operation of which the validity is easily proven. Doesn't really prove that there isn't an aversion to unsafe code in the community. I would generally put the folks who work on Redox in the bucket of "experienced people who know how to write unsafe code" and am pretty sure that they're more comfortable with writing unsafe code than most. Byteorder is a crate that handles this neatly and well (including endianness and stuff), but for ticki's purposes, really, a simple type pun on integers is not that bad. It's like the left-pad of unsafe code.

jononor 10y ago

How does one verify unsafe blocks in a library? Wondering what are the best practices.