4 ms·

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

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.
      - steveklabnik 6y ago
        Okay so, the issue here is that you two are speaking past each other. Enums in Rust are more than enums are in C. So this conversation is something like: Them: I like sandwiches. You: I get sandwiches from McDonalds, they're great. Them: Yes, but those are burgers. (The implication being that there are also other kinds of sandwiches.) You: Yes, burgers are good. You're not wrong, but you're kind of missing what they're saying. Enums in Rust can be like enums in C, but they can also be tagged unions. Furthermore, Rust won't automatically cast an enum to an int, so it is a bit harder to make mistakes, even if you're using the C-like ones. That's the advantages they're speaking about. Enums are good and useful in C, it's true. That's why Rust added stuff to make them even more useful.
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.

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.
    - steveklabnik 6y ago
      Okay so, the issue here is that you two are speaking past each other. Enums in Rust are more than enums are in C. So this conversation is something like: Them: I like sandwiches. You: I get sandwiches from McDonalds, they're great. Them: Yes, but those are burgers. (The implication being that there are also other kinds of sandwiches.) You: Yes, burgers are good. You're not wrong, but you're kind of missing what they're saying. Enums in Rust can be like enums in C, but they can also be tagged unions. Furthermore, Rust won't automatically cast an enum to an int, so it is a bit harder to make mistakes, even if you're using the C-like ones. That's the advantages they're speaking about. Enums are good and useful in C, it's true. That's why Rust added stuff to make them even more useful.

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.