3 ms·

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 tru

by 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.

by eloff 5y ago

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.