4 ms·

> the language emphasizes the reduction of memory bugs That's not really true: Rust's borrowing and ownership apply to most kinds of in-program resource owners

by creata 6y ago

> the language emphasizes the reduction of memory bugs That's not really true: Rust's borrowing and ownership apply to most kinds of in-program resource ownership and aliasing, not just memory. > The resulting code then creates an increased cognitive load which can make other bugs more likely. I'm not saying you're wrong, but I'd like to see any evidence for this. Personally, I'd expect the opposite to be true: knowing whether any given object is non-exclusively borrowed, exclusively borrowed, or owned at any point in the program sounds like very useful documentation for people reading the code.

jstimpfle 6y ago
From skimming some Rust code now and then, it seems to me that Rust programs look completely different at least. While C programs focus on creating simple data structures and getting the task done with as few memory operations as possible, in Rust I've dominantly seen use of types, memory/resource safety patterns and external libraries. My theory is that this removes direct understanding what happens and instead shifts the focus on how to get the task done while not violating the type system rules. In both cases, what the programmer minimizes in the first place might be the lines of code or maybe "code complexity". (Assuming programmers tend to do what most directly leads to completion of the programming task). I'm not in a position to claim that this theory is actually true, and I won't take a stance which is "better", but personally the former is much more appealing to me, for purely aesthetic reasons.
- cryptoquick 6y ago
  Rust provides a good balance between performance, correctness, and ergonomics. It's called the "Goldilocks language", because it's not too slow, it's not too unsafe, and it's not too difficult. Also, much of the tooling I used to add to projects in other languages is either built-in and commonly used (test, fmt), or easily added to cargo (edit, bench, web, mobile).
  - deleted 6y ago
    [deleted]
- viraptor 6y ago
  I find this description unsatisfying. The "use of types" makes applications easier to understand and cleaner for example. Just a generous use of enums helps with some kinds of logic errors as well and ensures more expressive code. (==1 vs ==Match::Domain)
  - jstimpfle 6y ago
    I use enums in C, too. And the problems with C enums that people complain about don't apply for me. That's not what I mean by "use of types". What I mean by it is significant "programming in type language" as opposed to "in code language". Programming in type language I find unappealing because it is very indirect, implicit, and typically achieves very little per line of code.
    - deleted 6y ago
      [deleted]
    - viraptor 6y ago
      > I use enums in C, too Enums in C are just ints with names. They're error prone and not type checked. You can always use 0 instead of a name and it will work. You can use TLSv2 instead of ExterminateHumans and it will also work. > What I mean by it is significant "programming in type language" as opposed to "in code language". I honestly don't understand what you mean by this.
      - jstimpfle 6y ago
        > Enums in C are just ints with names. Yes, they are integers. You can do arithmetic with them, you can use them as bitmasks, or use sentinels instead, like -1. I like that.
        oblio 6y ago
        Keep in mind that just because you like something, doesn't make it good, and that's starting to get more and more important in these days where software is used for everything, including things really depend on.
- alpaca128 6y ago
  > My theory is that this removes direct understanding what happens and instead shifts the focus on how to get the task done while not violating the type system rules In my experience it is in fact still a requirement to understand what's happening in order to write clean and fast Rust code. It is possible to satisfy the compiler using a lot of clone() calls and similar shortcuts, but once you understand what data structure is allocated when and where and how the whole ownership principle works in practice you can suddenly avoid a ton of unnecessary heap allocations and other pitfalls. I'd say my experience with Rust improved a lot once I started grasping what's happening in memory and why certain syntax elements exist, as this makes fixing compiler errors more intuitive and less a blind trial and error session with the borrow checker. Some of Rust's syntax can look weirdly unfamiliar at the beginning, but everything is there for a good reason. Nothing is done implicitly, and much of the pattern matching and Option/Result related stuff is Rust's way of replacing the concept of `null` with thoroughly type-checked expressions.

by creata 6y ago

jstimpfle 6y ago

From skimming some Rust code now and then, it seems to me that Rust programs look completely different at least. While C programs focus on creating simple data structures and getting the task done with as few memory operations as possible, in Rust I've dominantly seen use of types, memory/resource safety patterns and external libraries. My theory is that this removes direct understanding what happens and instead shifts the focus on how to get the task done while not violating the type system rules. In both cases, what the programmer minimizes in the first place might be the lines of code or maybe "code complexity". (Assuming programmers tend to do what most directly leads to completion of the programming task). I'm not in a position to claim that this theory is actually true, and I won't take a stance which is "better", but personally the former is much more appealing to me, for purely aesthetic reasons.

cryptoquick 6y ago
Rust provides a good balance between performance, correctness, and ergonomics. It's called the "Goldilocks language", because it's not too slow, it's not too unsafe, and it's not too difficult. Also, much of the tooling I used to add to projects in other languages is either built-in and commonly used (test, fmt), or easily added to cargo (edit, bench, web, mobile).
- deleted 6y ago
  [deleted]
viraptor 6y ago
I find this description unsatisfying. The "use of types" makes applications easier to understand and cleaner for example. Just a generous use of enums helps with some kinds of logic errors as well and ensures more expressive code. (==1 vs ==Match::Domain)
- jstimpfle 6y ago
  I use enums in C, too. And the problems with C enums that people complain about don't apply for me. That's not what I mean by "use of types". What I mean by it is significant "programming in type language" as opposed to "in code language". Programming in type language I find unappealing because it is very indirect, implicit, and typically achieves very little per line of code.
  - deleted 6y ago
    [deleted]
  - viraptor 6y ago
    > I use enums in C, too Enums in C are just ints with names. They're error prone and not type checked. You can always use 0 instead of a name and it will work. You can use TLSv2 instead of ExterminateHumans and it will also work. > What I mean by it is significant "programming in type language" as opposed to "in code language". I honestly don't understand what you mean by this.
    - jstimpfle 6y ago
      > Enums in C are just ints with names. Yes, they are integers. You can do arithmetic with them, you can use them as bitmasks, or use sentinels instead, like -1. I like that.
      - oblio 6y ago
        Keep in mind that just because you like something, doesn't make it good, and that's starting to get more and more important in these days where software is used for everything, including things really depend on.
alpaca128 6y ago
> My theory is that this removes direct understanding what happens and instead shifts the focus on how to get the task done while not violating the type system rules In my experience it is in fact still a requirement to understand what's happening in order to write clean and fast Rust code. It is possible to satisfy the compiler using a lot of clone() calls and similar shortcuts, but once you understand what data structure is allocated when and where and how the whole ownership principle works in practice you can suddenly avoid a ton of unnecessary heap allocations and other pitfalls. I'd say my experience with Rust improved a lot once I started grasping what's happening in memory and why certain syntax elements exist, as this makes fixing compiler errors more intuitive and less a blind trial and error session with the borrow checker. Some of Rust's syntax can look weirdly unfamiliar at the beginning, but everything is there for a good reason. Nothing is done implicitly, and much of the pattern matching and Option/Result related stuff is Rust's way of replacing the concept of `null` with thoroughly type-checked expressions.