3 ms·

I think the main problem with rust, is that the things they decided to settle on early on (aka the borrow checker) are the ones at the root of all the difficult

by bsaul 4y ago

I think the main problem with rust, is that the things they decided to settle on early on (aka the borrow checker) are the ones at the root of all the difficulties. They then tried to tame those issues little by little by improving the language ergonomics. This is pretty different from swift for example. Which had a sane basis very early on, but decided to expand the language by adding features over features, moving the language to a lot of different directions, turning it into an ugly beast ( i still like it though, but i’m not sure for how long).

mdavidn 4y ago
Learning to work with Rust's borrow checker leaves one with the sinking realization that every C program also has a borrow checker: The very fallible programmer.
- microtonal 4y ago
  Not just C, any language with mutable aliases references/pointers, which is pretty much every modern language. https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-000-aliasing-bugs.html https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-00...
  - eru 4y ago
    Well, Haskell has mutable aliases, references and pointers. But you seldom use them.
    - pdimitar 4y ago
      At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. It's the strategy of the C devs whose memory safety bugs and buffer overflow mistakes we still find to this day, in a number of popular and very widely used programs. ...Nah. We shouldn't go back (and I am not saying you claim so, I am kind of just developing the thought here). Let's have memory safety and algebraic data types and maybe pluggable GC runtimes (if lifetime management proves too difficult which it has at times; not every task is perfectly suited for Rust's borrow checker) and async, and any other goodies that help us solve real problems, and let's not dream of a simpler life. That "simpler life" has failed. We should acknowledge that and move on and work with the reality in front of us. Rust's lifetime management and async runtime(s) can be maddeningly difficult but after being on all parts of the spectrum -- from bash scripts and JS Wild West projects to Rust -- I confidently claim that the more strictness the better. ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it.
      - eru 4y ago
        I mostly agree with you. > At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. However in the case of Haskell, manually mucking around with mutable aliases, references and pointers is culturally similar to using unsafe in Rust. By default in Haskell you are using immutable variables. And if you have multiple threads and want to share mutable state, you typically use software transactional memory. > ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it. Well, Golang has quick compile times, partially because it makes the human do half of the compiler's job. OCaml is indeed something that's more worth aspiring, too. As a compromise, I found that `cargo check` is much quicker than a build and does most of what I need when developing: most of the time, I don't actually care about the resulting binary, I just want the compiler to tell me quickly whether I introduced any errors it can detect.
  - throwaway894345 4y ago
    While there are other benefits to the borrow checker, the main one is safe memory management and GC languages get you that much while allowing for faster development.
    - pdimitar 4y ago
      Can't disagree with you at all, even though I want to. I love Rust and I hate having to emulate enums in Golang but the speed of development becomes more and more a deal-breaker the more time I spend with Rust. I might just settle at OCaml, if at all possible. Or, since this is the real life and there are no simple final solutions, I'll likely just become a master of all three. But really, as much as I appreciate Rust for being super strict, I also don't think strict lifetime management is as important for many tasks (though it's a life-saver for some).
      - throwaway894345 4y ago
        Yeah, I 100% agree with hating emulating enums in Go (particularly because there is no safe way to emulate exhaustiveness checks). Personally I haven’t found Ocaml to be any more productive (inadequate libraries, poor tooling, constant futzing with multiple std libraries), but maybe I didn’t commit to it for long enough? That said, I’m starting to do a bit more systems development so I’m excited to dabble a bit more in Rust.
    - bsaul 4y ago
      gc is about memory disposal. IMHO the main purpose of the borrow checker is to ensure proper concurrent memory access, while the memory is still in use. Which gc don't help at all..
      - throwaway894345 4y ago
        I don’t think the main purpose is concurrent memory access considering the enormous share of memory managed by the borrow checker which is never accessed in a concurrent context. Whichever purpose is the “main” purpose hardly matters anyway—the fact of the matter is that Rust makes memory management quite burdensome even though it makes it easier to ensure certain correctness properties.
viraptor 4y ago
Unfortunately you can't start simple and add lifetimes-as-types into your language, because that's at the very core of it. You'd kill all backwards compatibility with it. There's likely no gradual path to Rust from non-Rust.
- eatonphil 4y ago
  I don't follow.that logic: If you can mark sections of Rust unsafe why could language X not allow marking sections of X as "safe"? Then over time you can use only 3rd party packages that are fully safe (same as has happened naturally with rust but just "not unsafe").
  - viraptor 4y ago
    https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html > It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. Going from the other side would be really hard to design for. The whole standard library in rust is relying on the lifetimes being there. If you started without them you'd end up with things which can't be implemented safely anymore. Even with the lifetimes available, some traits took ages to stabilise and ensure no edge cases. You'd have two standard libraries and the compiler would have to know how to make them interact. Or maybe they couldn't interact and you'd have to remember some hashes have get/set you started with and others need `.entry(...).and_modify(...)`. That sounds terrible for usability.
- bsaul 4y ago
  My guess is this is what swift has planned. They’ve been slowly adding hidden features inside the compiler to detect more and more problematic memory sharing patterns. My hunch is that the two language will eventually converge. Rust slowly improving the ergonomics, and swift slowly adding more safety.

by bsaul 4y ago

mdavidn 4y ago

Learning to work with Rust's borrow checker leaves one with the sinking realization that every C program also has a borrow checker: The very fallible programmer.

microtonal 4y ago
Not just C, any language with mutable aliases references/pointers, which is pretty much every modern language. https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-000-aliasing-bugs.html https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-00...
- eru 4y ago
  Well, Haskell has mutable aliases, references and pointers. But you seldom use them.
  - pdimitar 4y ago
    At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. It's the strategy of the C devs whose memory safety bugs and buffer overflow mistakes we still find to this day, in a number of popular and very widely used programs. ...Nah. We shouldn't go back (and I am not saying you claim so, I am kind of just developing the thought here). Let's have memory safety and algebraic data types and maybe pluggable GC runtimes (if lifetime management proves too difficult which it has at times; not every task is perfectly suited for Rust's borrow checker) and async, and any other goodies that help us solve real problems, and let's not dream of a simpler life. That "simpler life" has failed. We should acknowledge that and move on and work with the reality in front of us. Rust's lifetime management and async runtime(s) can be maddeningly difficult but after being on all parts of the spectrum -- from bash scripts and JS Wild West projects to Rust -- I confidently claim that the more strictness the better. ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it.
    - eru 4y ago
      I mostly agree with you. > At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. However in the case of Haskell, manually mucking around with mutable aliases, references and pointers is culturally similar to using unsafe in Rust. By default in Haskell you are using immutable variables. And if you have multiple threads and want to share mutable state, you typically use software transactional memory. > ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it. Well, Golang has quick compile times, partially because it makes the human do half of the compiler's job. OCaml is indeed something that's more worth aspiring, too. As a compromise, I found that `cargo check` is much quicker than a build and does most of what I need when developing: most of the time, I don't actually care about the resulting binary, I just want the compiler to tell me quickly whether I introduced any errors it can detect.
- throwaway894345 4y ago
  While there are other benefits to the borrow checker, the main one is safe memory management and GC languages get you that much while allowing for faster development.
  - pdimitar 4y ago
    Can't disagree with you at all, even though I want to. I love Rust and I hate having to emulate enums in Golang but the speed of development becomes more and more a deal-breaker the more time I spend with Rust. I might just settle at OCaml, if at all possible. Or, since this is the real life and there are no simple final solutions, I'll likely just become a master of all three. But really, as much as I appreciate Rust for being super strict, I also don't think strict lifetime management is as important for many tasks (though it's a life-saver for some).
    - throwaway894345 4y ago
      Yeah, I 100% agree with hating emulating enums in Go (particularly because there is no safe way to emulate exhaustiveness checks). Personally I haven’t found Ocaml to be any more productive (inadequate libraries, poor tooling, constant futzing with multiple std libraries), but maybe I didn’t commit to it for long enough? That said, I’m starting to do a bit more systems development so I’m excited to dabble a bit more in Rust.
  - bsaul 4y ago
    gc is about memory disposal. IMHO the main purpose of the borrow checker is to ensure proper concurrent memory access, while the memory is still in use. Which gc don't help at all..
    - throwaway894345 4y ago
      I don’t think the main purpose is concurrent memory access considering the enormous share of memory managed by the borrow checker which is never accessed in a concurrent context. Whichever purpose is the “main” purpose hardly matters anyway—the fact of the matter is that Rust makes memory management quite burdensome even though it makes it easier to ensure certain correctness properties.

viraptor 4y ago

Unfortunately you can't start simple and add lifetimes-as-types into your language, because that's at the very core of it. You'd kill all backwards compatibility with it. There's likely no gradual path to Rust from non-Rust.

eatonphil 4y ago
I don't follow.that logic: If you can mark sections of Rust unsafe why could language X not allow marking sections of X as "safe"? Then over time you can use only 3rd party packages that are fully safe (same as has happened naturally with rust but just "not unsafe").
- viraptor 4y ago
  https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html > It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. Going from the other side would be really hard to design for. The whole standard library in rust is relying on the lifetimes being there. If you started without them you'd end up with things which can't be implemented safely anymore. Even with the lifetimes available, some traits took ages to stabilise and ensure no edge cases. You'd have two standard libraries and the compiler would have to know how to make them interact. Or maybe they couldn't interact and you'd have to remember some hashes have get/set you started with and others need `.entry(...).and_modify(...)`. That sounds terrible for usability.
bsaul 4y ago
My guess is this is what swift has planned. They’ve been slowly adding hidden features inside the compiler to detect more and more problematic memory sharing patterns. My hunch is that the two language will eventually converge. Rust slowly improving the ergonomics, and swift slowly adding more safety.