Hacker News Reader

Comment by nercury | Hacker News Reader

For anyone unfamiliar how rust helps, the idea is this: first, you can identify common usage patterns and build safe wrappers around raw system operations.

The wrappers have no additional cost when compiled: A nested structure of Wrapper<OtherWrapper<OverSomePointer>> has a size of the flattened contained data, all the type info will be stripped away.

This part is the hardest, but the reward is that you can then use these wrappers without thinking about lower-level details. Of course, it is possible to do that in other languages, but rust type system can encode more information in types. That means more checks at compile time and less cautionary instructions are needed in the code comments.

I always hear arguments that "Rust still does not prevent X!". That's not the point. Rust type system simply can prevent more if used as intended.

View on HN

Indeed. What I hate about C is a function that returns an integer, and go figure out the docs about what the value of this integer means. In Rust, an enum with "RequestSuccessul" usually means just that: a successful request. That means I have much less uncertainty about things and spend less time going through docs.

C has enums, too, you know. What do Rust enums do that C enums don't?

> What do Rust enums do that C enums don't?

In Rust, an enum can also carry data along with the tag, and the type of the data can be different for each value of the tag. A Rust enum is more like a "tagged union" (a struct containing both an enum as the tag and a union for the extra data) in C.

Rust's enums are "sum types" or "tagged unions".

Perhaps the most practical example of this is the Option type, where you can say an Optional value is either `Some(value)` or `Nothing`.

With this, you don't have do deal with null pointers; a `null` pointer would instead be `Nothing`, and a non-null value would be `Some(value)`, and the compiler can enforce you're sticking to this.

I wish "enums" would stay relatively simple numbers or something and "sum types" would remain full sum types, but, here we are. Now whenever I see someone asking for "enums" I have to ask them what they're actually saying, because the majority of the time they mean sum types, but only the majority. It is not even close to always. Sometimes people want more fully featured enumerations, too, e.g., better automatic stringification of a variety of types.

exhaustiveness checking

It's a reasonable question. Aside from the nice data encapsulation of enums (which make them more like unions), the answer is basically "they're enforced".

Most C libraries and system calls return integers not enums. Often the meaning of those integers is hard coded in a header somewhere. There's no guarantee that the number returned will be one of the values in the header.

When a library does return enums, there's no guarantee the value returned is actually in the enum. It could be anything.

When you pattern match an enum in C, you have no checks to make sure you catch all the cases, or don't drop a break;.

All of the above means that in C, you're relying on the programmer to cross check they haven't made a mistake. Rust does it all for you - if you match against an enum type, you have to handle all the cases. You can't return anything other than the type you said you would. It basically does all the work that the programmer has to do in C. And most importantly, it does it every time you recompile. Even if the first person to call a function in C is meticulous, the members in the enum might change later.

You could have similar warning in C compilers: https://godbolt.org/z/aj6TWsxK3

I agree that Rust has more comprehensive guard railes, but except for pointer ownership and sharing where C is missing tools (although model checking tools can achieve this too), I think you could basically have everything else in C as well by building similar abstractions building on existing compiler warnings and maybe adding a couple of new ones.

So while I like some ideas of Rust, I think in the discussions proponents often compare it to a worst-case C without old programming style and no static analysis applied and comparing to an ideal Rust with no use of unsafe (and also this binder rewrite uses unsafe).

But C does not have algebraic enums. Try doing JSON in C and see how that goes. Every function now returns an int and a void*; go ahead and make sure they are always paired together.

> I always hear arguments that "Rust still does not prevent X!". That's not the point. Rust type system simply can prevent more if used as intended.

That's just the Nirvana fallacy. Just because it's not perfect shouldn't prevent you from improving stasus quo.

Absurd example: "Seatbelts don't prevent impalements or drowning in car, ergo they are useless.

the seatbelt example isn't a 100% fit as seatbelt-opposers argued that seatbelts actually increase the risk of drowning, so they're not a security improvement but a trade-off. of course, cases of drowning in an automobile where the passengers would have survived without a seatbelt are incredibly rare, while all other accidents where seatbelts help are comparably common.

I have doubts that would even be true. I'll gladly take a struggle to remove the seatbelt over receiving a head trauma immediately prior needing to escape the car and swim to safety.

First, the biggest problem for drowning in a car isn't seatbelts but windows. People will remember to unhook the seatbelts, and by that time it will be too late to open windows. In essence, you're arguing for the removal of windows, not seatbelts.

Second, the nirvana fallacy is comparing actual things to unrealistic, idealized alternatives. You're comparing actual (seat belts) to an idealized alterative (something that prevents all car crashes, no matter the cause).

Third, it's a less generalized example. Stuff seatbelts don't protect and might even lessen chances of survival - rockets, gunfire, rhinoceros, trains, meteors, nuclear blasts, black holes, multiversal collapse.

the argument that seatbelts cause drowning wasn't mine personally but one an original advocate against seatbelts brought. shortly after the guy died in a car accident. i don't even back out of the garage without my seatbelt on.

could have been this one: https://www.snopes.com/fact-check/seat-belt-advocate-killed/

The book unsafe at any speed, is a good background on the resistance regarding security improvements in the car industry.

Something can be more then useless yet still be less than worth it. Not saying rust isn't worth it in this case, just that the extremes are not the only two conditions.

Sure, a Nirvana fallacy depends on the alternative being some idealized, unreachable state. In the Rust case, the alterative is - write better code (or everyone will use static code checkers)!

Reply on news.ycombinator.com