6 ms·

The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of

The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another approach toward decreasing unsafetyness by providing fewer and easier to understand primitives so that the programming logic is harder to write wrong. It might come at a moderate cost for some applications.

zzzcpan 10y ago
True, they messed up in their PR a bit with bold claims about safety. It definitely would be better to be careful with the words they use. Like this "safe concurrency" claim sounds really fearless to me, even though I know they mean some guarantees towards thread safety and all that, not actual safe concurrency.
- bassislife 10y ago
  Yes, for instance, it's easy to create concurrent programs that are semantically wrong (in other words inadequate for use) albeit correct in terms of "types" because the coder made an erroneous assumption about determinism somewhere. The type systems that we see nowadays do not help with that.
- oconnor663 10y ago
  The docs are very clear about what safety means, but agreed that the subtleties can get lost in advertising. https://doc.rust-lang.org/book/unsafe.html#what-does-safe-mean https://doc.rust-lang.org/book/unsafe.html#what-does-safe-me...
stevedonovan 10y ago
Exactly. There is always the danger of self-hypnosis, by repeating 'memory safety means safety, full stop' too often.
rkrzr 10y ago
> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language). But I think that is beside the point here. This is about eliminating whole classes of errors. A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. A good memory model can eliminate all unsafe memory problems. There are also languages that can eliminate all data races from your programs. All these advances in PL theory make it easier and safer to deal with hard problems like concurrency, memory management etc. and thus allow us to focus on what our programs can actually do.
- bassislife 10y ago
  > A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Especially since the systems we use are often dynamic with changing requirements.
  - rkrzr 10y ago
    > It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. Like I said: It will eliminate a specific class of errors, namely all type errors. Your program will literally not compile if there are any type errors. > The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Sure, I don't disagree with that statement. But it's important to recognize that eliminating whole classes of errors is extremely valuable and allows us to focus on the important things.
    - ytugiuyghvk 10y ago
      Every type system eliminates all its own type errors by definition. Even the trivial system with one type eliminates all its own type errors (vacuously, since there are zero of them). There is no universal set of errors called type errors. What are type errors depend on your type system. A good type system allows more errors to be encoded as type errors so you can catch them at compile time, but it doesn't mean anything to say that a language like Rust or Haskell eliminates all type errors. There are certainly type systems which could catch more errors.
kaoD 10y ago
> Rust is about decreasing unsafetyness or whatever the correct word for that is. I think the word you're looking for is "safety". Safety is inherently relative and mostly about risk management. There's no such thing as 100% safe by definition.
- bassislife 10y ago
  "unsafety" rather ? ;) decreasing non-safety is not the same as increasing safety. One starts with the assumption that things are safe. The other does not.
kzrdude 10y ago
Yes! Rust adds a way to manage it, in a two-tier system. There is `unsafe` marked code blocks and code without. The trusted code base has to be in the part marked `unsafe`. It's simple (only the two tiers), but it is another tool for abstraction and managing complexity.
Manishearth 10y ago
In the context of Rust, "safety" usually means "memory and data-race safety".
duneroadrunner 10y ago
Yeah, I'm a bit worried that Rust is raising the floor, but maybe lowering/hardening the ceiling when it comes to code safety. I mean, if you consider static (compile-time) versus dynamic (run-time) safety, Rust leans heavily toward the former, and presumably gains a performance benefit because of it. But Rust acknowledges that it is not practical to achieve memory safety completely statically and so provides dynamically checked data types as well (vectors, RefCell, etc.). As you consider higher (application) level notions of safety, it generally becomes less practical to achieve that safety statically (at compile-time), so you'd want your language or your framework or whatever to facilitate the implementation and performance optimization of dynamic (run-time) safety. At the moment I'm thinking about automatic injection of run-time asserts (of application level invariants) at appropriate places in the code. (At the start and maybe at the end of public member functions for example.) If you subscribe to this idea, then it sort of follows that Rust's borrow checker may be "in the wrong place". That is, rather than forcing you to write code that is memory safe in a particular statically verifiable way, Rust could have instead enforced memory safety by injecting run-time checks into the code and optimizing them out when it recognizes code that appeases the borrow checker. (Of course the optimizer could report what run-time checks it was not able to optimize out, if you wanted to self-impose static verification.) (Statically optimized) dynamic safety is more scalable than statically verified safety. As a "systems language", Rust may be less concerned with higher/application level safety. But I think this might be a little short-sighted. The definition of "system" is expanding, and the proportion of "higher level" safety concerns along with it.
- msbarnett 10y ago
  > If you subscribe to this idea, then it sort of follows that Rust's borrow checker may be "in the wrong place". That is, rather than forcing you to write code that is memory safe in a particular statically verifiable way, Rust could have instead enforced memory safety by injecting run-time checks into the code and optimizing them out when it recognizes code that appeases the borrow checker. That kind of lack of transparency about what in the hell your code is doing at runtime is really inappropriate in a system's language. It's an interesting idea, and it would be neat to play with in a language that wanted to restrict itself to more business-logic level safety concerns, but it would absolutely come at the cost of not being appropriate for systems-level tasks.
EugeneOZ 10y ago
when compiler doesn't let you write race conditions or unintended variable mutation - it's a huge thing, not just "decreasing unsafetyness". Although I hope Rust will also get rid of arrays bounds errors.

zzzcpan 10y ago

True, they messed up in their PR a bit with bold claims about safety. It definitely would be better to be careful with the words they use. Like this "safe concurrency" claim sounds really fearless to me, even though I know they mean some guarantees towards thread safety and all that, not actual safe concurrency.

bassislife 10y ago
Yes, for instance, it's easy to create concurrent programs that are semantically wrong (in other words inadequate for use) albeit correct in terms of "types" because the coder made an erroneous assumption about determinism somewhere. The type systems that we see nowadays do not help with that.
oconnor663 10y ago
The docs are very clear about what safety means, but agreed that the subtleties can get lost in advertising. https://doc.rust-lang.org/book/unsafe.html#what-does-safe-mean https://doc.rust-lang.org/book/unsafe.html#what-does-safe-me...

stevedonovan 10y ago

Exactly. There is always the danger of self-hypnosis, by repeating 'memory safety means safety, full stop' too often.

rkrzr 10y ago

> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language). But I think that is beside the point here. This is about eliminating whole classes of errors. A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. A good memory model can eliminate all unsafe memory problems. There are also languages that can eliminate all data races from your programs. All these advances in PL theory make it easier and safer to deal with hard problems like concurrency, memory management etc. and thus allow us to focus on what our programs can actually do.

bassislife 10y ago
> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Especially since the systems we use are often dynamic with changing requirements.
- rkrzr 10y ago
  > It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. Like I said: It will eliminate a specific class of errors, namely all type errors. Your program will literally not compile if there are any type errors. > The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Sure, I don't disagree with that statement. But it's important to recognize that eliminating whole classes of errors is extremely valuable and allows us to focus on the important things.
  - ytugiuyghvk 10y ago
    Every type system eliminates all its own type errors by definition. Even the trivial system with one type eliminates all its own type errors (vacuously, since there are zero of them). There is no universal set of errors called type errors. What are type errors depend on your type system. A good type system allows more errors to be encoded as type errors so you can catch them at compile time, but it doesn't mean anything to say that a language like Rust or Haskell eliminates all type errors. There are certainly type systems which could catch more errors.

kaoD 10y ago

> Rust is about decreasing unsafetyness or whatever the correct word for that is. I think the word you're looking for is "safety". Safety is inherently relative and mostly about risk management. There's no such thing as 100% safe by definition.

bassislife 10y ago
"unsafety" rather ? ;) decreasing non-safety is not the same as increasing safety. One starts with the assumption that things are safe. The other does not.

kzrdude 10y ago

Yes! Rust adds a way to manage it, in a two-tier system. There is `unsafe` marked code blocks and code without. The trusted code base has to be in the part marked `unsafe`. It's simple (only the two tiers), but it is another tool for abstraction and managing complexity.

Manishearth 10y ago

In the context of Rust, "safety" usually means "memory and data-race safety".

duneroadrunner 10y ago

Yeah, I'm a bit worried that Rust is raising the floor, but maybe lowering/hardening the ceiling when it comes to code safety. I mean, if you consider static (compile-time) versus dynamic (run-time) safety, Rust leans heavily toward the former, and presumably gains a performance benefit because of it. But Rust acknowledges that it is not practical to achieve memory safety completely statically and so provides dynamically checked data types as well (vectors, RefCell, etc.). As you consider higher (application) level notions of safety, it generally becomes less practical to achieve that safety statically (at compile-time), so you'd want your language or your framework or whatever to facilitate the implementation and performance optimization of dynamic (run-time) safety. At the moment I'm thinking about automatic injection of run-time asserts (of application level invariants) at appropriate places in the code. (At the start and maybe at the end of public member functions for example.) If you subscribe to this idea, then it sort of follows that Rust's borrow checker may be "in the wrong place". That is, rather than forcing you to write code that is memory safe in a particular statically verifiable way, Rust could have instead enforced memory safety by injecting run-time checks into the code and optimizing them out when it recognizes code that appeases the borrow checker. (Of course the optimizer could report what run-time checks it was not able to optimize out, if you wanted to self-impose static verification.) (Statically optimized) dynamic safety is more scalable than statically verified safety. As a "systems language", Rust may be less concerned with higher/application level safety. But I think this might be a little short-sighted. The definition of "system" is expanding, and the proportion of "higher level" safety concerns along with it.

msbarnett 10y ago
> If you subscribe to this idea, then it sort of follows that Rust's borrow checker may be "in the wrong place". That is, rather than forcing you to write code that is memory safe in a particular statically verifiable way, Rust could have instead enforced memory safety by injecting run-time checks into the code and optimizing them out when it recognizes code that appeases the borrow checker. That kind of lack of transparency about what in the hell your code is doing at runtime is really inappropriate in a system's language. It's an interesting idea, and it would be neat to play with in a language that wanted to restrict itself to more business-logic level safety concerns, but it would absolutely come at the cost of not being appropriate for systems-level tasks.

EugeneOZ 10y ago

when compiler doesn't let you write race conditions or unintended variable mutation - it's a huge thing, not just "decreasing unsafetyness". Although I hope Rust will also get rid of arrays bounds errors.