3 ms·

It is an honest definition of memory safety. The fact that you can not write a non trivial Rust program without unsafe dependencies is not an argument against t

It is an honest definition of memory safety. The fact that you can not write a non trivial Rust program without unsafe dependencies is not an argument against that definition. Most languages considered memory safe have some sort virtual machine model where non trivial programs can be written without any use of unsafe. The virtual machine implementation itself may be unsafe of course, but that is a pretty solid boundary. In Rust, that boundary is easily crossed by anyone, for any reason, to the point where it sips into 50% of dependencies, as this paper shows. I am not saying that C# evades this issue in principle, obviously it has the same functionality, it is just not used as liberally. Concurrency is orthogonal.

woodruffw 5y ago
> Most languages considered memory safe have some sort virtual machine model where non trivial programs can be written without any use of unsafe. With the obvious exception of JS in the browser, I don’t believe this is true: Python, Ruby, Java, C# all have widely used unsafe native escape hatches that are regularly found in dependency trees. All you have to do is misuse these interfaces, which is significantly easier than in Rust.
- incrudible 5y ago
  Read carefully: The premise is that you can't write a non-trivial program in Rust without using unsafe. It's true that most language implementations have an escape hatch in the form of a foreign function interface and/or they have native extension modules, nevertheless non-trivial programs can be written without using them. Conversely, using such facilities is often a reason why a program may not be portable between multiple language implementations.
  - eloff 5y ago
    No, that's not my premise. You can't write a non trivial rust program that doesn't use unsafe in it's dependencies, often the standard library. But this is true of every other programming language I'm aware of. So if you want to define memory safety to be something never achieved in practice, fine, but that's not a useful definition in my books.
    - incrudible 5y ago
      > No, that's not my premise. You can't write a non trivial rust program that doesn't use unsafe in it's dependencies, often the standard library. Same difference, because the use of unsafe is transitive. There is no distinction between "unsafe-but-part-of-the-standard-library" and "unsafe". > But this is true of every other programming language I'm aware of. So if you want to define memory safety to be something never achieved in practice, fine, but that's not a useful definition in my books. I don't. I already made that distinction further up in the thread, you can read that and reply there if you have any objections.
      - eloff 5y ago
        So nothing is memory safe by your definition then. Languages like C# are more memory safe than Rust because the uses of unsafe code are fewer and more concentrated in the runtime where bugs are more easily caught. I think that's a fair comparison.
        incrudible 5y ago
        > So nothing is memory safe by your definition then. No. I will now apply maximum charity and explain the distinction once again: Let's take Java. It runs on a VM. The VM has a memory model. There is no way to write memory-unsafe code while staying within that model. Not only can you write non-trivial programs against that model, the vast majority of Java code is written against it and is thus memory safe. That's a fair definition of memory safety. Of course, in practice, you will likely use an implementation of that language that uses unsafe memory access. You will likely use an implementation that has escape hatches to call into native code - unsafely. That's a reasonable boundary to have while still calling the language memory-safe. Unsafe in C# was a late addition that can usually be disabled without much peril.

woodruffw 5y ago

> Most languages considered memory safe have some sort virtual machine model where non trivial programs can be written without any use of unsafe. With the obvious exception of JS in the browser, I don’t believe this is true: Python, Ruby, Java, C# all have widely used unsafe native escape hatches that are regularly found in dependency trees. All you have to do is misuse these interfaces, which is significantly easier than in Rust.

incrudible 5y ago
Read carefully: The premise is that you can't write a non-trivial program in Rust without using unsafe. It's true that most language implementations have an escape hatch in the form of a foreign function interface and/or they have native extension modules, nevertheless non-trivial programs can be written without using them. Conversely, using such facilities is often a reason why a program may not be portable between multiple language implementations.
- eloff 5y ago
  No, that's not my premise. You can't write a non trivial rust program that doesn't use unsafe in it's dependencies, often the standard library. But this is true of every other programming language I'm aware of. So if you want to define memory safety to be something never achieved in practice, fine, but that's not a useful definition in my books.
  - incrudible 5y ago
    > No, that's not my premise. You can't write a non trivial rust program that doesn't use unsafe in it's dependencies, often the standard library. Same difference, because the use of unsafe is transitive. There is no distinction between "unsafe-but-part-of-the-standard-library" and "unsafe". > But this is true of every other programming language I'm aware of. So if you want to define memory safety to be something never achieved in practice, fine, but that's not a useful definition in my books. I don't. I already made that distinction further up in the thread, you can read that and reply there if you have any objections.
    - eloff 5y ago
      So nothing is memory safe by your definition then. Languages like C# are more memory safe than Rust because the uses of unsafe code are fewer and more concentrated in the runtime where bugs are more easily caught. I think that's a fair comparison.
      - incrudible 5y ago
        > So nothing is memory safe by your definition then. No. I will now apply maximum charity and explain the distinction once again: Let's take Java. It runs on a VM. The VM has a memory model. There is no way to write memory-unsafe code while staying within that model. Not only can you write non-trivial programs against that model, the vast majority of Java code is written against it and is thus memory safe. That's a fair definition of memory safety. Of course, in practice, you will likely use an implementation of that language that uses unsafe memory access. You will likely use an implementation that has escape hatches to call into native code - unsafely. That's a reasonable boundary to have while still calling the language memory-safe. Unsafe in C# was a late addition that can usually be disabled without much peril.