3 ms·

I think it's a common misconception that ownership is there to make you suffer compiler shenanigans. When in my experience it changes the way you model programs

I think it's a common misconception that ownership is there to make you suffer compiler shenanigans. When in my experience it changes the way you model programs. Turns out, that structuring your program in a way were it's clear who owns what makes for easier to understand and debug programs. It's a bit analogous to static typing, saying I'll use a language like Python without type hints, because its gonna make me avoid compiler errors, is a bit short sighted when I plan on developing the piece of code for a longer time. Here is a blog post that explains this in more detail https://without.boats/blog/notes-on-a-smaller-rust/ https://without.boats/blog/notes-on-a-smaller-rust/.

hgs3 3y ago
> I think it's a common misconception that ownership is there to make you suffer compiler shenanigans. I don't think it's a misconception. When I tried Rust I tried to implement a cyclic data structure but couldn't because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integer handles. So, instead of juggling pointers I was juggling integers which made the code harder to debug and find logic errors. At least when I was troubleshooting C I could rely on the debugger to break on a bad pointer, but finding where an integer became "bad" was more time consuming. > When in my experience it changes the way you model programs. Having to rearchitect my code to please the borrow checker gave me flashbacks to Java where I'd be forced to architect my code as a hierarchy of objects. In both languages you need design patterns and other work-arounds since both force a specific model onto your code whether it makes sense or not.
- Voultapher 3y ago
  You seem to have a preset opinion, and I'm not sure you are interested in re-evaluating it. So this is not written to change your mind. I've developed production code in C, C++, Rust, and several other languages. And while like pretty much everything, there are situations where it's not a good fit, I find that the solutions tend to be the most robust and require the least post release debugging in Rust. That's my personal experience. It's not hard data. And yes occasionally it's annoying to please the compiler, and if there were no trait constraints or borrow rules, those instances would be easier. But way more often in my experience the compiler complained because my initial solution had problems I didn't realize before. So for me, these situations have been about going from building it the way I wanted to -> compiler tells me I didn't consider an edge case -> changing the implementation and or design to account for that edge case. Also using one example, where Rust is notoriously hard and or un-ergonomic to use, and dismissing the entire language seems premature to me. For those that insist on learning Rust by implementing a linked list there is https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/.
  - hitekker 3y ago
    The GP commented once, politely disagreeing and describing their own experience. Looking over their past comments, I also don't see hostility to the ideals of memory safety or using Rust. Seems like you made a passive-aggressive presumption.
pizlonator 3y ago
Having to change how you write your program is the worst case of suffering compiler shenanigans that I can think of.
- Voultapher 3y ago
  If you want to keep doing programming in a way you are already familiar with, and are not willing to change your way of thinking about programs, yes then it's a bad fit. If you want to write reliable programs, there is evidence that changing the way we think about and express programming problems, can have substantial effects on reliability.
  - hgs3 3y ago
    You don't need a borrow checker to write reliable programs. If anything the Rust obsession with memory safety has been harmful since it detracts from general safety. But don't take my word for it, maybe consider what the co-author of The Rust Programming Language, 2nd edition has to say [1]. If you really care about writing robust programs then focus on improving your testing methodology rather than fixating on the programming language. [1] https://steveklabnik.com/writing/memory-safety-is-a-red-herring https://steveklabnik.com/writing/memory-safety-is-a-red-herr...
    - steveklabnik 3y ago
      I said that it is necessary, but not sufficient. That does not mean it's a distraction: that means it is foundational.
    - pizlonator 3y ago
      Memory safety is a good thing to obsess over. It's just that we don't need ownership and borrow checking to get there.
  - pizlonator 3y ago
    You're assuming too much. Not saying we shouldn't change anything. I am saying that adding ownership is't the change that's needed, since you won't be able to convert most C code to that regime.

hgs3 3y ago

> I think it's a common misconception that ownership is there to make you suffer compiler shenanigans. I don't think it's a misconception. When I tried Rust I tried to implement a cyclic data structure but couldn't because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integer handles. So, instead of juggling pointers I was juggling integers which made the code harder to debug and find logic errors. At least when I was troubleshooting C I could rely on the debugger to break on a bad pointer, but finding where an integer became "bad" was more time consuming. > When in my experience it changes the way you model programs. Having to rearchitect my code to please the borrow checker gave me flashbacks to Java where I'd be forced to architect my code as a hierarchy of objects. In both languages you need design patterns and other work-arounds since both force a specific model onto your code whether it makes sense or not.

Voultapher 3y ago
You seem to have a preset opinion, and I'm not sure you are interested in re-evaluating it. So this is not written to change your mind. I've developed production code in C, C++, Rust, and several other languages. And while like pretty much everything, there are situations where it's not a good fit, I find that the solutions tend to be the most robust and require the least post release debugging in Rust. That's my personal experience. It's not hard data. And yes occasionally it's annoying to please the compiler, and if there were no trait constraints or borrow rules, those instances would be easier. But way more often in my experience the compiler complained because my initial solution had problems I didn't realize before. So for me, these situations have been about going from building it the way I wanted to -> compiler tells me I didn't consider an edge case -> changing the implementation and or design to account for that edge case. Also using one example, where Rust is notoriously hard and or un-ergonomic to use, and dismissing the entire language seems premature to me. For those that insist on learning Rust by implementing a linked list there is https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/.
- hitekker 3y ago
  The GP commented once, politely disagreeing and describing their own experience. Looking over their past comments, I also don't see hostility to the ideals of memory safety or using Rust. Seems like you made a passive-aggressive presumption.

pizlonator 3y ago

Having to change how you write your program is the worst case of suffering compiler shenanigans that I can think of.

Voultapher 3y ago
If you want to keep doing programming in a way you are already familiar with, and are not willing to change your way of thinking about programs, yes then it's a bad fit. If you want to write reliable programs, there is evidence that changing the way we think about and express programming problems, can have substantial effects on reliability.
- hgs3 3y ago
  You don't need a borrow checker to write reliable programs. If anything the Rust obsession with memory safety has been harmful since it detracts from general safety. But don't take my word for it, maybe consider what the co-author of The Rust Programming Language, 2nd edition has to say [1]. If you really care about writing robust programs then focus on improving your testing methodology rather than fixating on the programming language. [1] https://steveklabnik.com/writing/memory-safety-is-a-red-herring https://steveklabnik.com/writing/memory-safety-is-a-red-herr...
  - steveklabnik 3y ago
    I said that it is necessary, but not sufficient. That does not mean it's a distraction: that means it is foundational.
  - pizlonator 3y ago
    Memory safety is a good thing to obsess over. It's just that we don't need ownership and borrow checking to get there.
- pizlonator 3y ago
  You're assuming too much. Not saying we shouldn't change anything. I am saying that adding ownership is't the change that's needed, since you won't be able to convert most C code to that regime.