3 ms·

> All the major scripting languages are memory-safe. Newer hard-compiled languages such as D and Go are memory-safe, although they have to use GC to do it. A wh

by dbaupp 12y ago

> All the major scripting languages are memory-safe. Newer hard-compiled languages such as D and Go are memory-safe, although they have to use GC to do it. A whole generation of programmers have never had to look for a buffer overflow or a dangling pointer. They all have the ability to write unsafe code in the same manner as Rust; but only Rust has it really built-in to the language so the compiler can reason about it. E.g. - http://golang.org/pkg/unsafe/ http://golang.org/pkg/unsafe/ - https://docs.python.org/3.4/library/ctypes.html https://docs.python.org/3.4/library/ctypes.html It just doesn't make sense to presuppose that it is any worse in Rust. In fact, quite the opposite, the type system is designed for ensuring memory safety without a GC, and in multithreaded environments. I believe this is not true for Go (it is vulnerable to data races, and requires a runtime tool to detect some subset of the ones can occur in any given program), but I don't know about D. Rust cannot remove `unsafe` without being useless for its target, and useless as a language (it wouldn't even have FFI).

Dewie 12y ago
> Rust cannot remove `unsafe` without being useless for its target, and useless as a language (it wouldn't even have FFI). I like to think of Haskell as a parallel: It guarantees side effect-free code. But you still need an escape hatch in the form of unsafePerformIO in order to use the FFI. The language's semantics can easily be broken with that functionality, but it seems to be a necessary price to pay if you want to have any kind of FFI. (<- Well, I guess something like Proof Carrying Code could be an alternative..)
Animats 12y ago
Calling external code is a separate issue. This is about unsafe code within the language.
- dbaupp 12y ago
  I thought it was about buffer overflows and security vulnerabilities within Rust programs? i.e. not just the parts written directly in Rust. Looking at anything else seems a bit silly, since the thing that runs in the real world is the whole program. The low-level code has to exist somewhere, vectors need to be allocated, strings need to be printed, and people will want the performance. This code is either going to be in external libs called via FFI, as raw codegen in the compiler or in Rust. The last sounds like the one that is safest since the FFI code would have to be written in one of the unsafe systems languages, while writing in Rust gives all the type system advantages and high-level features (references, pattern matching), not to mention avoiding the (mental) overhead of correctly interacting between languages. It seems to me that taking away the low-level power of opt-in `unsafe` is just myopically punting the problem along, rather than seeing it as giving Rust the ability to avoid having to write really unsafe C plugins (like Python etc.).
- kibwen 12y ago
  But they aren't separate issues. If you couldn't do these things in Rust, people would just drop into C to do them. Given that that would introduce much more unsafety into Rust programs, Rust does the right thing by reifying unsafe memory operations and sequestering them away.

by dbaupp 12y ago

Dewie 12y ago

> Rust cannot remove `unsafe` without being useless for its target, and useless as a language (it wouldn't even have FFI). I like to think of Haskell as a parallel: It guarantees side effect-free code. But you still need an escape hatch in the form of unsafePerformIO in order to use the FFI. The language's semantics can easily be broken with that functionality, but it seems to be a necessary price to pay if you want to have any kind of FFI. (<- Well, I guess something like Proof Carrying Code could be an alternative..)

Animats 12y ago

Calling external code is a separate issue. This is about unsafe code within the language.

dbaupp 12y ago
I thought it was about buffer overflows and security vulnerabilities within Rust programs? i.e. not just the parts written directly in Rust. Looking at anything else seems a bit silly, since the thing that runs in the real world is the whole program. The low-level code has to exist somewhere, vectors need to be allocated, strings need to be printed, and people will want the performance. This code is either going to be in external libs called via FFI, as raw codegen in the compiler or in Rust. The last sounds like the one that is safest since the FFI code would have to be written in one of the unsafe systems languages, while writing in Rust gives all the type system advantages and high-level features (references, pattern matching), not to mention avoiding the (mental) overhead of correctly interacting between languages. It seems to me that taking away the low-level power of opt-in `unsafe` is just myopically punting the problem along, rather than seeing it as giving Rust the ability to avoid having to write really unsafe C plugins (like Python etc.).
kibwen 12y ago
But they aren't separate issues. If you couldn't do these things in Rust, people would just drop into C to do them. Given that that would introduce much more unsafety into Rust programs, Rust does the right thing by reifying unsafe memory operations and sequestering them away.