4 ms·

> First, the expressiveness is all there. You just need to explicitly say you are responsible by using unsafe blocks. So risky pointer and allocation logic beco

> First, the expressiveness is all there. You just need to explicitly say you are responsible by using unsafe blocks. So risky pointer and allocation logic becomes the programmer's job, not the borrow checker. No, unsafe would be overkill and if you needed unsafe, it would put Rust at a massive disadvantage vis-à-vis garbage-collected languages. Simply put, Rust doesn't handle multiple ownership well. It results in syntactic bloat and/or runtime overhead. But multiple ownership occurs naturally in a number of real-world programs. > Second, this article only considers the costs of a stricter borrow checker, not the benefits. This is why I very specifically mentioned that it's a tradeoff.

bluejekyll 10y ago
I think you're implication here is that other languages do handle multiple ownership well. What I think you find in Rust, is that the guarantees you need to make when using unsafe in these limited situations, are the exact same guarantees you need to make in a language like C or C++. Destroying a circular list takes some thought to make sure you don't double free, same as Rust. Rust just makes those sections of code very explicit and calls your attention to it, while in C you may end up with a segfault, or worse a program that only shows odd bugs during runtime. At least Rust is telling you that you need to put some extra thought in this section.
- rbehrends 10y ago
  Your assumption seems to be that I'm talking about languages with manual memory management. I'm not; I'm talking about garbage-collected languages, where you get memory safety automatically, regardless of ownership rules. In fact, C++ has some of the same problems that Rust has when it comes to multiple ownership.
  - kaoD 10y ago
    Then use https://github.com/Manishearth/rust-gc https://github.com/Manishearth/rust-gc if you're willing to pay the price of a GC (still experimental). Or better, stick to a GC'ed language. If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in. Use the right tool for the job.
    - rbehrends 10y ago
      > If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in. That's exactly the point that I made in my original comment?
      - kaoD 10y ago
        Sorry, HN isn't great at keeping track who's who on a comment tree.
    - Manishearth 10y ago
      (Please don't use rust-gc, it's more of a proof of concept. I mean, it works, and some folks do use it, but Rc + Weak are probably better options)
  - galangalalgol 10y ago
    Does GC imply memory safety? Use after free and dangling references probably can't happen, but I have never heard of a GC supplying cross thread memory safety. The borrow checker does.
    - rbehrends 10y ago
      Memory safety in multi-threaded programs is not a hard problem once you have GC. Eiffel solved it decades ago. The JVM also has a weak form of memory safety; it does not preclude data races, but the VM cannot crash as the result of a data race.
humanrebar 10y ago
> No, unsafe would be overkill I don't see an issue with 'unsafe' if it's an implementation detail and well-tested. Obviously it would be better to avoid it if possible. 'unsafe' is overkill sometimes and worth it other times.
- bluejekyll 10y ago
  Instead of unsafe, as much as possible should be looking at interior mutability, Cell and RefCell allow for this, with no unsafe, and they guarantee for you at runtime that what you believe is accurate. unsafe should be IMO, reserved for only those cases where strictly needed, e.g. FFI is the clearest example.
- braveo 10y ago
  > if it's an implementation detail and well-tested The same can be said of C and C++, at which point, why does it matter if you use Rust?
  - humanrebar 10y ago
    Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.
    - AstralStorm 10y ago
      You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11. The only thing you cannot exactly prevent is "cast_dammit_cast".
      - dbaupp 10y ago
        Could you be specific about how the type system and polymorphic memory allocators defend against things like dangling references, iterator invalidation and use-after-free/move? I can't imagine an allocator affecting these unless it's one that just has a no-op free (which only use-after-free, anyway), nor is the type system strong enough by itself.

bluejekyll 10y ago

I think you're implication here is that other languages do handle multiple ownership well. What I think you find in Rust, is that the guarantees you need to make when using unsafe in these limited situations, are the exact same guarantees you need to make in a language like C or C++. Destroying a circular list takes some thought to make sure you don't double free, same as Rust. Rust just makes those sections of code very explicit and calls your attention to it, while in C you may end up with a segfault, or worse a program that only shows odd bugs during runtime. At least Rust is telling you that you need to put some extra thought in this section.

rbehrends 10y ago
Your assumption seems to be that I'm talking about languages with manual memory management. I'm not; I'm talking about garbage-collected languages, where you get memory safety automatically, regardless of ownership rules. In fact, C++ has some of the same problems that Rust has when it comes to multiple ownership.
- kaoD 10y ago
  Then use https://github.com/Manishearth/rust-gc https://github.com/Manishearth/rust-gc if you're willing to pay the price of a GC (still experimental). Or better, stick to a GC'ed language. If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in. Use the right tool for the job.
  - rbehrends 10y ago
    > If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in. That's exactly the point that I made in my original comment?
    - kaoD 10y ago
      Sorry, HN isn't great at keeping track who's who on a comment tree.
  - Manishearth 10y ago
    (Please don't use rust-gc, it's more of a proof of concept. I mean, it works, and some folks do use it, but Rc + Weak are probably better options)
- galangalalgol 10y ago
  Does GC imply memory safety? Use after free and dangling references probably can't happen, but I have never heard of a GC supplying cross thread memory safety. The borrow checker does.
  - rbehrends 10y ago
    Memory safety in multi-threaded programs is not a hard problem once you have GC. Eiffel solved it decades ago. The JVM also has a weak form of memory safety; it does not preclude data races, but the VM cannot crash as the result of a data race.

humanrebar 10y ago

> No, unsafe would be overkill I don't see an issue with 'unsafe' if it's an implementation detail and well-tested. Obviously it would be better to avoid it if possible. 'unsafe' is overkill sometimes and worth it other times.

bluejekyll 10y ago
Instead of unsafe, as much as possible should be looking at interior mutability, Cell and RefCell allow for this, with no unsafe, and they guarantee for you at runtime that what you believe is accurate. unsafe should be IMO, reserved for only those cases where strictly needed, e.g. FFI is the clearest example.
braveo 10y ago
> if it's an implementation detail and well-tested The same can be said of C and C++, at which point, why does it matter if you use Rust?
- humanrebar 10y ago
  Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.
  - AstralStorm 10y ago
    You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11. The only thing you cannot exactly prevent is "cast_dammit_cast".
    - dbaupp 10y ago
      Could you be specific about how the type system and polymorphic memory allocators defend against things like dangling references, iterator invalidation and use-after-free/move? I can't imagine an allocator affecting these unless it's one that just has a no-op free (which only use-after-free, anyway), nor is the type system strong enough by itself.