3 ms·

Just because something is worth the hazzle doesn't mean people do it. Of course, some people are willing to study and learn, but I think you also need to cater

by madez 10y ago

Just because something is worth the hazzle doesn't mean people do it. Of course, some people are willing to study and learn, but I think you also need to cater to those who are not if you want widespread adoption.

AnimalMuppet 10y ago
If I understand correctly, the borrow checker is part of how Rust prevents dangerous code. Rust is not in the business of catering to those who want to write dangerous code, even if that means Rust will not achieve widespread adoption. There are already languages is wide use that allow writing dangerous code; for Rust to become another such language would not be a step forward.
- steveklabnik 10y ago
  Rust does let you write dangerous code; it just makes you explicitly annotate it. As a systems language, Rust _must_ give you total control when you need it. It's just not the default.
ansible 10y ago
As I understand it, the issues that people have with the borrow checker in Rust are the same ones they'd have in another language like C++. Only there, the language doesn't help you become aware of issues, like memory leaks or other use-after-free type bugs. If you really don't want a hassle, then maybe you want to program in a garbage-collected language instead. But then you're potentially giving up some performance and/or memory usage savings.
- steveklabnik 10y ago
  To be clear, while this is true in the general case, there are specific moments where it does break down, due to the conservative nature of static analysis. This thread has some good examples, but in the interest of transparency, I'll provide another: struct Foo { s1: String, // some sort of String data s2: &str, // a slice of said String } What Rust doesn't understand here is that the String's data is on the heap, and therefore, its address is stable. So if you try to construct this, Rust won't let you, because it thinks that the borrow of s1 by s2 would be invalidated by the move. This is fixed by https://crates.io/crates/owning-ref https://crates.io/crates/owning-ref, but it'd be nice if it understood it by default. In general, these cases are small, but they can be annoying when you run into them. As I said downthread, I very rarely run into them personally, but some others seem to constantly. YMMV.
  - rrobukef 10y ago
    Is this actually safe? What happens if you have ownership, then you can mutate the struct Foo like this: foo.s1 = "World" Which destroys the original heap data. Then s2 is a dangling reference. Since references cannot implement a drop method, you need a wrapping datastructure WITH reference counting, like you said.
    - steveklabnik 10y ago
      > then you can mutate the struct Foo like this: You couldn't because it'd be immutably borrowed.

by madez 10y ago

AnimalMuppet 10y ago

If I understand correctly, the borrow checker is part of how Rust prevents dangerous code. Rust is not in the business of catering to those who want to write dangerous code, even if that means Rust will not achieve widespread adoption. There are already languages is wide use that allow writing dangerous code; for Rust to become another such language would not be a step forward.

steveklabnik 10y ago
Rust does let you write dangerous code; it just makes you explicitly annotate it. As a systems language, Rust _must_ give you total control when you need it. It's just not the default.

ansible 10y ago

As I understand it, the issues that people have with the borrow checker in Rust are the same ones they'd have in another language like C++. Only there, the language doesn't help you become aware of issues, like memory leaks or other use-after-free type bugs. If you really don't want a hassle, then maybe you want to program in a garbage-collected language instead. But then you're potentially giving up some performance and/or memory usage savings.

steveklabnik 10y ago
To be clear, while this is true in the general case, there are specific moments where it does break down, due to the conservative nature of static analysis. This thread has some good examples, but in the interest of transparency, I'll provide another: struct Foo { s1: String, // some sort of String data s2: &str, // a slice of said String } What Rust doesn't understand here is that the String's data is on the heap, and therefore, its address is stable. So if you try to construct this, Rust won't let you, because it thinks that the borrow of s1 by s2 would be invalidated by the move. This is fixed by https://crates.io/crates/owning-ref https://crates.io/crates/owning-ref, but it'd be nice if it understood it by default. In general, these cases are small, but they can be annoying when you run into them. As I said downthread, I very rarely run into them personally, but some others seem to constantly. YMMV.
- rrobukef 10y ago
  Is this actually safe? What happens if you have ownership, then you can mutate the struct Foo like this: foo.s1 = "World" Which destroys the original heap data. Then s2 is a dangling reference. Since references cannot implement a drop method, you need a wrapping datastructure WITH reference counting, like you said.
  - steveklabnik 10y ago
    > then you can mutate the struct Foo like this: You couldn't because it'd be immutably borrowed.