5 ms·

11 uses of "unsafe". (this is not a critique of this specific library, it's more a look at the rust ecosystem as a whole) i keep looking at Rust, but at the e

11 uses of "unsafe". (this is not a critique of this specific library, it's more a look at the rust ecosystem as a whole) i keep looking at Rust, but at the end it seems it is not a language for me. Rust developers just seem to use more "unsafe" than what i am comfortable with. generally, if there could be a choice between using "unsafe", and taking a 2% performance penalty,i personally would go with the performance-penalty. of course, i can understand others have different priorities. the question is, what are the priorities of the rust ecosystem? i mean, can i find libraries that go with as-safe-as-possible or are most libraries as-fast-as-possible? also, the claim that the rust language is fast and safe becomes harder to accept when the fast libraries use unsafe :) (i do understand code using "unsafe" can be safe if the developer does not make mistakes. the problem is, developers do make mistakes.)

unlinked_dll 7y ago
I'll critique the language. Unsafe is a bad name. It doesn't mean "not safe" it means "cannot be verified by the compiler to be memory safe." Some things are inherently unsafe by that definition, including things necessary for software development. It may be better than other names, but frankly - it's too scary. In particular, the implementation of data structures. Raw memory allocation, usage of pointers, low level concurrency primitives - none of that can be done without the programmer manually enforcing invariants. But unsafe isn't wanton abandon. You still have to obey the type system and ownership rules. As for the goal, it depends on the author. Some prioritize one over the other. In general the Rust community these days tries to optimize the balance of safety and speed with as few compromises as possible - which is fundamentally why the language exists.
- rat9988 7y ago
  unsafe doesn't mean dangerous or hazardous. If we cannot verify safety then it's unsafe. The word's choice seems correct to me. I agree with the rest of your comment though.
  - atoav 7y ago
    Another name that came to my mind was trustme as you as the programmer have to uphold certain garantuees that outside an unsafe block the compiler would enforce.
    - steveklabnik 7y ago
      I tried: https://github.com/rust-lang/rfcs/pull/117 https://github.com/rust-lang/rfcs/pull/117
- asdf-asdf-asdf 7y ago
  sorry, what does "to optimize the balance of safety and speed with as few compromises as possible" mean? it's possible to cover many-many situations with that description.
platinumrad 7y ago
If you're looking for concurrent code that doesn't use `unsafe` you won't find any. To start, implementing `Send` and `Sync` are both unsafe.
- onei 7y ago
  Is that by design, necessity or compiler/language deficiencies? I'm curious if this is something the language hopes to improve on over time in the name of fearless concurrency or it's simply not possible.
  - platinumrad 7y ago
    Stepping back from concurrency for a second, you can't even implement `RefCell<T>` without `unsafe`. Any method that takes `&self` and performs "interior mutation" is unsafe to implement. Not sure whether you would consider that to be by "design", "necesity", or a "compiler/language deficiency".
  - Avi-D-coder 7y ago
    Unless you require your programs to be formally verified or use dependent linear types, the best you can do is an effect system, STM and GC. There is no panacea.
  - dodobirdlord 7y ago
    In principle it could perhaps be enforced by the compiler, but it would be very difficult. Whether something is memory-safe to Sync or Send across threads can depend on things like platform-specific atomic operations, thread-local storage, how panics and stack unwinds proceed, etc. Sounds like a nightmare for the compiler to make guarantees about. Maybe when compiling for a specific version of a specific OS, but to do it at the language level would be an incredible feat, and might make the language unusably complex.
  - cakoose 7y ago
    I think this statement from the grandparent post might have been misleading: > If you're looking for concurrent code that doesn't use `unsafe` you won't find any. The Rust standard library provides a bunch of concurrency primitives. You can write 100% safe Rust code use these primitives to do things concurrently, and Rust guarantees that your resulting program is free of a specific category of bugs: memory errors, data races, etc. No other mainstream language gives you this combination of concurrency safety and efficiency. The implementation of the concurrency primitives, however, often includes assembly, or C, or unsafe Rust code, which the Rust compiler can't provide guarantees for. We have to rely on humans for that. This is the norm for almost all programming languages. Ideally, yes, it would be nice if the safe subset of Rust were powerful enough to implement efficient concurrency primitives, but that would add a TON of complexity to the type system. People are generally ok with the Rust standard library using assembly, C, or unsafe Rust, because even though it can be tricky to write this kind of code correctly, the standard library is maintained by Rust experts who take every change seriously. People tend to worry more about third party libraries because, on average, the authors are not Rust language experts and may not understand the subtleties.
Klonoar 7y ago
I think... you miss the point. Usage of unsafe is effectively flagging areas for peer review. You can't build everything in safe Rust - certain things _require_ the use of unsafe. Having it gated, reviewed, and so on is effectively a check on a class of bugs that can be hard to pin down. IMHO, the community cares way, way too much about the mere sight of an unsafe in a codebase - it borders on religious zealotry. It's just a tool like anything else in the (wonderful) language.
- asdf-asdf-asdf 7y ago
  i don't think i missed the point here. i wrote: "i do understand code using "unsafe" can be safe if the developer does not make mistakes. the problem is, developers do make mistakes." you wrote: "Usage of unsafe is effectively flagging areas for peer review. You can't build everything in safe Rust - certain things _require_ the use of unsafe. Having it gated, reviewed, and so on is effectively a check on a class of bugs that can be hard to pin down." it's the same thing. the difference is that you look at it from the glass-half-full point of view (it's good that must-be-verified-by-a-person blocks are limited here), and i do from the other end (it's bad that these blocks are necessary).
  - nickez 7y ago
    I think you missed parent's point. There are constructs that the current compiler can't prove is correct and to write such code you need unsafe. It is often not about a trade-off between speed/safety.
    - Jonhoo 7y ago
      I actually gave a talk about exactly this a few weeks back that may be relevant: https://youtube.com/watch?v=QAz-maaH0KM https://youtube.com/watch?v=QAz-maaH0KM
    - asdf-asdf-asdf 7y ago
      oh, i see what you mean. yes, i did somehow miss the "You can't build everything in safe Rust - certain things _require_ the use of unsafe." part of the argument. i did talk about it in my other comment here: https://news.ycombinator.com/item?id=22701550 https://news.ycombinator.com/item?id=22701550
cesarb 7y ago
> Rust developers just seem to use more "unsafe" than what i am comfortable with. And that's a good thing! In most other languages, what would require an "unsafe" in Rust can be done without any visible marker. The Rust language shines a spotlight in these places, which allowed you to notice them. > the question is, what are the priorities of the rust ecosystem? i mean, can i find libraries that go with as-safe-as-possible or are most libraries as-fast-as-possible? From what I've seen, the priorities of the Rust ecosystem tends to be "as-fast-as-possible wrapped into an as-safe-as-possible abstraction". That is, presenting a safe interface around a fast core, which can be audited separately; users of the safe interface do not have to worry about unsafety in the implementation.
burntsushi 7y ago
If you don't mind the performance penalty, then just use Mutex<HashMap>. You don't have to use this. Rust isn't about completely eliminating all unsafe code. It never has been. It has always been about building safe abstractions with auditable unsafe internal parts.
Ar-Curunir 7y ago
What's your point of comparison? C and C++ are all entirely unsafe. At least with Rust you can pinpoint the parts that need scrutiny.

unlinked_dll 7y ago

I'll critique the language. Unsafe is a bad name. It doesn't mean "not safe" it means "cannot be verified by the compiler to be memory safe." Some things are inherently unsafe by that definition, including things necessary for software development. It may be better than other names, but frankly - it's too scary. In particular, the implementation of data structures. Raw memory allocation, usage of pointers, low level concurrency primitives - none of that can be done without the programmer manually enforcing invariants. But unsafe isn't wanton abandon. You still have to obey the type system and ownership rules. As for the goal, it depends on the author. Some prioritize one over the other. In general the Rust community these days tries to optimize the balance of safety and speed with as few compromises as possible - which is fundamentally why the language exists.

rat9988 7y ago
unsafe doesn't mean dangerous or hazardous. If we cannot verify safety then it's unsafe. The word's choice seems correct to me. I agree with the rest of your comment though.
- atoav 7y ago
  Another name that came to my mind was trustme as you as the programmer have to uphold certain garantuees that outside an unsafe block the compiler would enforce.
  - steveklabnik 7y ago
    I tried: https://github.com/rust-lang/rfcs/pull/117 https://github.com/rust-lang/rfcs/pull/117
asdf-asdf-asdf 7y ago
sorry, what does "to optimize the balance of safety and speed with as few compromises as possible" mean? it's possible to cover many-many situations with that description.

platinumrad 7y ago

If you're looking for concurrent code that doesn't use `unsafe` you won't find any. To start, implementing `Send` and `Sync` are both unsafe.

onei 7y ago
Is that by design, necessity or compiler/language deficiencies? I'm curious if this is something the language hopes to improve on over time in the name of fearless concurrency or it's simply not possible.
- platinumrad 7y ago
  Stepping back from concurrency for a second, you can't even implement `RefCell<T>` without `unsafe`. Any method that takes `&self` and performs "interior mutation" is unsafe to implement. Not sure whether you would consider that to be by "design", "necesity", or a "compiler/language deficiency".
- Avi-D-coder 7y ago
  Unless you require your programs to be formally verified or use dependent linear types, the best you can do is an effect system, STM and GC. There is no panacea.
- dodobirdlord 7y ago
  In principle it could perhaps be enforced by the compiler, but it would be very difficult. Whether something is memory-safe to Sync or Send across threads can depend on things like platform-specific atomic operations, thread-local storage, how panics and stack unwinds proceed, etc. Sounds like a nightmare for the compiler to make guarantees about. Maybe when compiling for a specific version of a specific OS, but to do it at the language level would be an incredible feat, and might make the language unusably complex.
- cakoose 7y ago
  I think this statement from the grandparent post might have been misleading: > If you're looking for concurrent code that doesn't use `unsafe` you won't find any. The Rust standard library provides a bunch of concurrency primitives. You can write 100% safe Rust code use these primitives to do things concurrently, and Rust guarantees that your resulting program is free of a specific category of bugs: memory errors, data races, etc. No other mainstream language gives you this combination of concurrency safety and efficiency. The implementation of the concurrency primitives, however, often includes assembly, or C, or unsafe Rust code, which the Rust compiler can't provide guarantees for. We have to rely on humans for that. This is the norm for almost all programming languages. Ideally, yes, it would be nice if the safe subset of Rust were powerful enough to implement efficient concurrency primitives, but that would add a TON of complexity to the type system. People are generally ok with the Rust standard library using assembly, C, or unsafe Rust, because even though it can be tricky to write this kind of code correctly, the standard library is maintained by Rust experts who take every change seriously. People tend to worry more about third party libraries because, on average, the authors are not Rust language experts and may not understand the subtleties.

Klonoar 7y ago

I think... you miss the point. Usage of unsafe is effectively flagging areas for peer review. You can't build everything in safe Rust - certain things _require_ the use of unsafe. Having it gated, reviewed, and so on is effectively a check on a class of bugs that can be hard to pin down. IMHO, the community cares way, way too much about the mere sight of an unsafe in a codebase - it borders on religious zealotry. It's just a tool like anything else in the (wonderful) language.

asdf-asdf-asdf 7y ago
i don't think i missed the point here. i wrote: "i do understand code using "unsafe" can be safe if the developer does not make mistakes. the problem is, developers do make mistakes." you wrote: "Usage of unsafe is effectively flagging areas for peer review. You can't build everything in safe Rust - certain things _require_ the use of unsafe. Having it gated, reviewed, and so on is effectively a check on a class of bugs that can be hard to pin down." it's the same thing. the difference is that you look at it from the glass-half-full point of view (it's good that must-be-verified-by-a-person blocks are limited here), and i do from the other end (it's bad that these blocks are necessary).
- nickez 7y ago
  I think you missed parent's point. There are constructs that the current compiler can't prove is correct and to write such code you need unsafe. It is often not about a trade-off between speed/safety.
  - Jonhoo 7y ago
    I actually gave a talk about exactly this a few weeks back that may be relevant: https://youtube.com/watch?v=QAz-maaH0KM https://youtube.com/watch?v=QAz-maaH0KM
  - asdf-asdf-asdf 7y ago
    oh, i see what you mean. yes, i did somehow miss the "You can't build everything in safe Rust - certain things _require_ the use of unsafe." part of the argument. i did talk about it in my other comment here: https://news.ycombinator.com/item?id=22701550 https://news.ycombinator.com/item?id=22701550

cesarb 7y ago

> Rust developers just seem to use more "unsafe" than what i am comfortable with. And that's a good thing! In most other languages, what would require an "unsafe" in Rust can be done without any visible marker. The Rust language shines a spotlight in these places, which allowed you to notice them. > the question is, what are the priorities of the rust ecosystem? i mean, can i find libraries that go with as-safe-as-possible or are most libraries as-fast-as-possible? From what I've seen, the priorities of the Rust ecosystem tends to be "as-fast-as-possible wrapped into an as-safe-as-possible abstraction". That is, presenting a safe interface around a fast core, which can be audited separately; users of the safe interface do not have to worry about unsafety in the implementation.

burntsushi 7y ago

If you don't mind the performance penalty, then just use Mutex<HashMap>. You don't have to use this. Rust isn't about completely eliminating all unsafe code. It never has been. It has always been about building safe abstractions with auditable unsafe internal parts.

Ar-Curunir 7y ago

What's your point of comparison? C and C++ are all entirely unsafe. At least with Rust you can pinpoint the parts that need scrutiny.