5 ms·

The collections criticism is bizarre. How often do you actually have to use "unsafe" in practice? Collections is one example, but it seems to be quite atypical,

by Certhas 11y ago

The collections criticism is bizarre. How often do you actually have to use "unsafe" in practice? Collections is one example, but it seems to be quite atypical, and not something you'd typically implement yourself. The argument has always been that it reduces the amount of code you have to check for safety manually. Most of it will be checked by the compiler. Have you run into the problem that most of your code is unsafe? I've only started dabbling in Rust for some projects, but I've not had to write a single line of unsafe yet, and don't see where that would change.

tomp 11y ago
> The argument has always been that it reduces the amount of code you have to check for safety manually. No, Rust's argument is that it eliminates memory unsafety. It even says so on it's front page: "guaranteed memory safety". Except that it's not guaranteed. It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. I agree that this criticism is mostly a theoretical one; Rust is still a huge improvement (in safety, and probably other areas) over C. But some people (e.g. myself) oppose lies in principle, no matter how well-intentioned they are.
- Manishearth 11y ago
  > It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. This is a vast oversimplification. It relies on you trusting tiny bits of unsafe code which have been carefully reviewed. This is opposed to entire C codebases which need reviewing. It's much, much easier to audit 10 lines of unsafe code than it is to audit an entire application. The vast majority of Rust code is not unsafe.
  - tomp 11y ago
    Exactly. Just as I've written in my post: > Rust is still a huge improvement > Except that it's not guaranteed
    - Manishearth 11y ago
      You will never be able to get both 100% guaranteed memory safety and low level control/performance. Opposing it based on principle means that you'll never move on to anything better because a perfect solution doesn't exist. For what it's worth, you can write quite a lot in 100% safe code, such that you have to trust only the standard library. Which is the case for any programming language. So, the argument on the front page is true. It does guarantee memory safety in safe Rust code, as much as possible. It gives you the tools to extend your abstractions with unsafe Rust code, which you need to supply your own guarantees with.
      - kazagistar 11y ago
        > You will never be able to get both 100% guaranteed memory safety and low level control/performance. Sure you can. You just need a full fledged proof engine instead of "merely" a type system.
        Manishearth 11y ago
        Well, ok. I guess that's too heavyweight, though. However, http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/
        scott_s 11y ago
        Since tomp objects to trusting code, then I agree with Manishearth: if you're never willing to trust code, then you can never have guarantees. Even the proof engine is trusted code.
        tomp 11y ago
        Well, you have to trust something... Silicone manufacturer, CPU designer, the OS, the compiler... But the big difference is, if I can do proofs and the compiler breaks my trust, that's a bug in the compiler. On the orher hand, Rust disallows complex proofs entirely, so I have to use unsafe code and trust random humans!
- Rusky 11y ago
  Even if the language pulled some magic trick where it could verify collection implementations without unsafe, all you'd have done is move the unsafety into the type checker and compiler backend. The only difference is that Rust 1) moved some of that into the stdlib and 2) lets third parties extend it to provide more guarantees. Given this, I think you're drawing a rather arbitrary line- Rust (the compiler + stdlib, optionally + other libraries wrapping unsafe) does guarantee memory safety, full stop. Whether the guarantees are provided by the stdlib or compiler is irrelevant.
  - tomp 11y ago
    It does guarantee memory safety... until you need to write your own collection. Then it explicitly endorses unsafe code (as opposed to offering a more powerful proof engine). I'm find with trusting something (compiler, proof engine, stdlib), but the issue is that safe Rust is barely a complete language!
    - kibwen 11y ago
      This is a strange argument. The `unsafe` keyword only lets you do the following: dereference unsafe pointers, call unsafe functions (which usually either dereference unsafe pointers themselves, or are just wrappers over C functions, which are obviously unprovable), and mutate static data. Saying that safe Rust is "barely complete" is just as good as saying that Python is "barely complete" due to the fact that it doesn't allow you to read arbitrary locations in memory.

by Certhas 11y ago

tomp 11y ago

> The argument has always been that it reduces the amount of code you have to check for safety manually. No, Rust's argument is that it eliminates memory unsafety. It even says so on it's front page: "guaranteed memory safety". Except that it's not guaranteed. It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. I agree that this criticism is mostly a theoretical one; Rust is still a huge improvement (in safety, and probably other areas) over C. But some people (e.g. myself) oppose lies in principle, no matter how well-intentioned they are.

Manishearth 11y ago
> It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. This is a vast oversimplification. It relies on you trusting tiny bits of unsafe code which have been carefully reviewed. This is opposed to entire C codebases which need reviewing. It's much, much easier to audit 10 lines of unsafe code than it is to audit an entire application. The vast majority of Rust code is not unsafe.
- tomp 11y ago
  Exactly. Just as I've written in my post: > Rust is still a huge improvement > Except that it's not guaranteed
  - Manishearth 11y ago
    You will never be able to get both 100% guaranteed memory safety and low level control/performance. Opposing it based on principle means that you'll never move on to anything better because a perfect solution doesn't exist. For what it's worth, you can write quite a lot in 100% safe code, such that you have to trust only the standard library. Which is the case for any programming language. So, the argument on the front page is true. It does guarantee memory safety in safe Rust code, as much as possible. It gives you the tools to extend your abstractions with unsafe Rust code, which you need to supply your own guarantees with.
    - kazagistar 11y ago
      > You will never be able to get both 100% guaranteed memory safety and low level control/performance. Sure you can. You just need a full fledged proof engine instead of "merely" a type system.
      - Manishearth 11y ago
        Well, ok. I guess that's too heavyweight, though. However, http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/
      - scott_s 11y ago
        Since tomp objects to trusting code, then I agree with Manishearth: if you're never willing to trust code, then you can never have guarantees. Even the proof engine is trusted code.
        tomp 11y ago
        Well, you have to trust something... Silicone manufacturer, CPU designer, the OS, the compiler... But the big difference is, if I can do proofs and the compiler breaks my trust, that's a bug in the compiler. On the orher hand, Rust disallows complex proofs entirely, so I have to use unsafe code and trust random humans!
Rusky 11y ago
Even if the language pulled some magic trick where it could verify collection implementations without unsafe, all you'd have done is move the unsafety into the type checker and compiler backend. The only difference is that Rust 1) moved some of that into the stdlib and 2) lets third parties extend it to provide more guarantees. Given this, I think you're drawing a rather arbitrary line- Rust (the compiler + stdlib, optionally + other libraries wrapping unsafe) does guarantee memory safety, full stop. Whether the guarantees are provided by the stdlib or compiler is irrelevant.
- tomp 11y ago
  It does guarantee memory safety... until you need to write your own collection. Then it explicitly endorses unsafe code (as opposed to offering a more powerful proof engine). I'm find with trusting something (compiler, proof engine, stdlib), but the issue is that safe Rust is barely a complete language!
  - kibwen 11y ago
    This is a strange argument. The `unsafe` keyword only lets you do the following: dereference unsafe pointers, call unsafe functions (which usually either dereference unsafe pointers themselves, or are just wrappers over C functions, which are obviously unprovable), and mutate static data. Saying that safe Rust is "barely complete" is just as good as saying that Python is "barely complete" due to the fact that it doesn't allow you to read arbitrary locations in memory.