Hacker News Reader

Comment by creata | Hacker News Reader

> 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.

View on HN

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.

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).

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)

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.

> 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.

> 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.

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.

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.

Yup, plus the other uses have their own implementation. If you're doing arithmetics, in rust you probably want a constant. If you want a bitmask, there's bitfield crate (or a struct/enum with bitwise ops implemented).

> 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.

Reply on news.ycombinator.com