5 ms·

Sigh. This again. The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the languag

Sigh. This again. The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier. For example: `Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important features in Rust, besides memory safety. To easily consume an `Enum`, you have to use `match`, which forces you to handle all members of the enum. In C/C++ it's easy to build a switch for an enum, and then later when a new member is added to the enum and you forget to update all your switches. Support for multiple return values (through tuples) means being able to avoid the nightmare of output pointer arguments to functions. No NULL pointers. Unit testing built into the canonical tooling. Documentation testing built into the canonical tooling. The `Option` type, which lets you return "nothing". In C/C++ you'd have to return a bool, and again use a nightmarish output pointer argument. `OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C). No undefined behavior. The list goes on. The flavor of it, is that Rust makes it easier to write defensive code. Defensive code is code that is hard to use wrong. For example, for a backup solution I built using Rust, I made all the cryptographic types their own unique, opaque types. EncryptionKey, HmacKey, Salt, etc. For someone new to the codebase, these types make it obvious what each function is asking for, and make it really difficult to use the functions or the types the wrong way. And they are super easy to build and use in Rust, see my code: https://github.com/fpgaminer/preserve/blob/master/src/keystore.rs#L20 https://github.com/fpgaminer/preserve/blob/master/src/keysto... C++ would require a whole set of classes, and require instantiating a new class every time I want to add a new cryptographic type. Rust only requires 3 lines per type. TL;DR: The real magic is that it's easier to do the right thing in Rust.

cesarb 9y ago
> `OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C). Nowadays, you should just call getentropy (http://man7.org/linux/man-pages/man3/getentropy.3.html http://man7.org/linux/man-pages/man3/getentropy.3.html) instead of trying to read from /dev/urandom, unless you have special requirements.
- dbaupp 9y ago
  Great example! OsRng will use that system call, if it is available.
bandook_raja 9y ago
> It's all too easy to throw away error codes in C/C++. Warning is produced by nearly every good compiler. They aren't forced because sometimes I don't really want to check for return values. > In C/C++ it's easy to build a switch for an enum, and then later when a new member is added to the enum and you forget to update all your switches. why would you update all other enum values in accordance to addition to a new one? I understand you could possibly be skipping one switch case because you just added it in enum definition but didn't update switch case, but why would you update rest? Is this a forced requirement in Rust? This is bad if it is. > Support for multiple return values (through tuples) means being able to avoid the nightmare of output pointer arguments to functions. std::tuple? > No NULL pointers. but what if you need them? Lets say a type safe, non-zero nullptr? I understand some people want to bring up whole NULL is bad mistake argument but remember some of us work with maintaining large code where such changes are non-trivial. > Unit testing built into the canonical tooling. Documentation testing built into the canonical tooling. This is good argument :) > The `Option` type, which lets you return "nothing". In C/C++ you'd have to return a bool, and again use a nightmarish output pointer argument. std::optional? Or many other implementations of optional type? I've been using them since ages(before rust was even born) and writing them is no NP problem. Don't credit rust as if it brought the `Option` type. > `OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C). Is this intended to be sarcasm? try <random> header and see if it fulfills your requirement, otherwise there are tons of libraries. But wait, what? This is another already solved problem unless I'm missing something. > No undefined behavior. Lol do you even unsafe bro? > C++ would require a whole set of classes, and require instantiating a new class every time I want to add a new cryptographic type. Rust only requires 3 lines per type. Depends on your cpp skills and judging by this post, they're certainly less than expected from a beginner. I hope you learn about certain languages (even the ones you are defending) before writing things on internet, since 90% of what you wrote won't even come near acceptable so I suggest doing your research properly.
- fuwafuwa 9y ago
  Your comment indicates that you don't really understand the value of ADTs as the switch, option type and NULL pointer comments overlap: in your new code(and it would be be new code since it's rewritten in Rust) you define it to have Some(pointer) or None. Then to access the value you have to switch on and evaluate the None case at any dereference site. NULL cannot happen but you can still pass around a None type. Regarding safely reading urandom, you don't seem to be aware that concurrency issues occur when accessing it from multiple processes. This is something that the borrow system can aid with by formalizing access to a resource like urandom and not allowing contention for it to occur at runtime. Also, nobody appreciates aggro kid language.
blub 9y ago
Some corrections: * option and result are also available in C++, the former is even standardised. * random numbers support is quite good. * C++ compilers will warn if not all members of an enum have been handled in a switch. It's also easy to assert/throw in the default case as a safety measure. * tuples are likewise supported * I believe something like your opaque types could be done with templates and tag classes in a similar amount of LOC. But yes, in Rust it's generally easier to do the right thing. This is the big benefit of learning from others' mistakes and not having to maintain backwards compatibility with ancient decisions.
- Manishearth 9y ago
  std::optional don't enforce exhaustiveness; you can get away with accidentally unwrapping it. In Rust this requires an explicit check or explicit call to unwrap()/expect(). To me, this is super important. But yeah, it's still a good thing to have! IIRC there are TMP-implemented versions of this that are safer (though a bit ugly to use) though.
sidlls 9y ago
I mainly agree that Rust is more than about safety. I just wish these other features had a tenth of the vocal support as Safety. It's even worse here on HN, where the a certain group seem to thrive on blasting not-Rust, especially if that not-Rust is C or C++. I've seen comments to the effect that anyone writing in C or C++ today is literally acting with reckless indifference to life and safety. It's terrible.
- jacquesm 9y ago
  It's actually harming Rust. And not just a little bit.
  - sidlls 9y ago
    The official Rust community isn't helping itself, either, here. If they were even a little bit as eager to step on lazy "C is bad" comments as to point out how safe Rust is it might help. Lazy reasoning about competitor languages isn't helpful because it inhibits the ability to effectively tout Rust's benefits. But I've basically stopped commenting in Rust threads. There's too much "not even wrong" as regards C and C++ to be bothered with.
- fpgaminer 9y ago
  Criticism is just so much easier than constructive arguments. That's why it's rampant in communities, even HN. And controversial subjects (Bitcoin, health, food, Javascript) will magnify the problem. It's easy to find fault in C/C++. It's easy to parrot the Rust marketing. It's not so easy to actually have spent the time to learn and use Rust, let alone articulate the subtle ways that its design, taken as a whole, is better than alternatives. Building those constructive arguments is _hard_. I remember reading an article about error handling. It had to have been at least 10 pages worth of content, covering the history of error handling throughout all the old and modern languages, and using examples for where each fails or succeeds. It culminates, more or less, in explaining exactly why the error handling of languages like Rust outperforms in the field of systems programming. (NOTE: The author of that article was actually arguing for the error system used in the language they developed for their OS, IIRC. But Rust was pretty darn close to the ideal the author was going for, and they pointed out as much.) My point is that it took 10+ pages to make a solid argument for _just_ error handling. Not many people have the experience, wisdom, time, and willingness to write even a fraction of such insightful content in a comment on HN. That said, well written, balanced comments still generally float to the top in even controversial HN threads. EDIT: I would also like to point out something specifically in response to "I've seen comments to the effect that anyone writing in C or C++ today is literally acting with reckless indifference to life and safety." There is a tremendous amount of pent up anger in the programming community against C/C++. The language should have been put our to pasture a _long_ time ago. Rust is the first language which has a real chance to displace it. So it's no wonder that a lot of us are willing to just burn C/C++ to the ground and jump ship. Not to mention that as programmers we may be quickly approaching a time when security bugs become a governmental issue, and the _last_ thing we want is the government mandating how we write code. So it is in everyone's interest if we self regulate. Again, that would explain why everyone is kinda jumpy about C and security bugs.

cesarb 9y ago

> `OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C). Nowadays, you should just call getentropy (http://man7.org/linux/man-pages/man3/getentropy.3.html http://man7.org/linux/man-pages/man3/getentropy.3.html) instead of trying to read from /dev/urandom, unless you have special requirements.

dbaupp 9y ago
Great example! OsRng will use that system call, if it is available.

bandook_raja 9y ago

> It's all too easy to throw away error codes in C/C++. Warning is produced by nearly every good compiler. They aren't forced because sometimes I don't really want to check for return values. > In C/C++ it's easy to build a switch for an enum, and then later when a new member is added to the enum and you forget to update all your switches. why would you update all other enum values in accordance to addition to a new one? I understand you could possibly be skipping one switch case because you just added it in enum definition but didn't update switch case, but why would you update rest? Is this a forced requirement in Rust? This is bad if it is. > Support for multiple return values (through tuples) means being able to avoid the nightmare of output pointer arguments to functions. std::tuple? > No NULL pointers. but what if you need them? Lets say a type safe, non-zero nullptr? I understand some people want to bring up whole NULL is bad mistake argument but remember some of us work with maintaining large code where such changes are non-trivial. > Unit testing built into the canonical tooling. Documentation testing built into the canonical tooling. This is good argument :) > The `Option` type, which lets you return "nothing". In C/C++ you'd have to return a bool, and again use a nightmarish output pointer argument. std::optional? Or many other implementations of optional type? I've been using them since ages(before rust was even born) and writing them is no NP problem. Don't credit rust as if it brought the `Option` type. > `OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C). Is this intended to be sarcasm? try <random> header and see if it fulfills your requirement, otherwise there are tons of libraries. But wait, what? This is another already solved problem unless I'm missing something. > No undefined behavior. Lol do you even unsafe bro? > C++ would require a whole set of classes, and require instantiating a new class every time I want to add a new cryptographic type. Rust only requires 3 lines per type. Depends on your cpp skills and judging by this post, they're certainly less than expected from a beginner. I hope you learn about certain languages (even the ones you are defending) before writing things on internet, since 90% of what you wrote won't even come near acceptable so I suggest doing your research properly.

fuwafuwa 9y ago
Your comment indicates that you don't really understand the value of ADTs as the switch, option type and NULL pointer comments overlap: in your new code(and it would be be new code since it's rewritten in Rust) you define it to have Some(pointer) or None. Then to access the value you have to switch on and evaluate the None case at any dereference site. NULL cannot happen but you can still pass around a None type. Regarding safely reading urandom, you don't seem to be aware that concurrency issues occur when accessing it from multiple processes. This is something that the borrow system can aid with by formalizing access to a resource like urandom and not allowing contention for it to occur at runtime. Also, nobody appreciates aggro kid language.

blub 9y ago

Some corrections: * option and result are also available in C++, the former is even standardised. * random numbers support is quite good. * C++ compilers will warn if not all members of an enum have been handled in a switch. It's also easy to assert/throw in the default case as a safety measure. * tuples are likewise supported * I believe something like your opaque types could be done with templates and tag classes in a similar amount of LOC. But yes, in Rust it's generally easier to do the right thing. This is the big benefit of learning from others' mistakes and not having to maintain backwards compatibility with ancient decisions.

Manishearth 9y ago
std::optional don't enforce exhaustiveness; you can get away with accidentally unwrapping it. In Rust this requires an explicit check or explicit call to unwrap()/expect(). To me, this is super important. But yeah, it's still a good thing to have! IIRC there are TMP-implemented versions of this that are safer (though a bit ugly to use) though.

sidlls 9y ago

I mainly agree that Rust is more than about safety. I just wish these other features had a tenth of the vocal support as Safety. It's even worse here on HN, where the a certain group seem to thrive on blasting not-Rust, especially if that not-Rust is C or C++. I've seen comments to the effect that anyone writing in C or C++ today is literally acting with reckless indifference to life and safety. It's terrible.

jacquesm 9y ago
It's actually harming Rust. And not just a little bit.
- sidlls 9y ago
  The official Rust community isn't helping itself, either, here. If they were even a little bit as eager to step on lazy "C is bad" comments as to point out how safe Rust is it might help. Lazy reasoning about competitor languages isn't helpful because it inhibits the ability to effectively tout Rust's benefits. But I've basically stopped commenting in Rust threads. There's too much "not even wrong" as regards C and C++ to be bothered with.
fpgaminer 9y ago
Criticism is just so much easier than constructive arguments. That's why it's rampant in communities, even HN. And controversial subjects (Bitcoin, health, food, Javascript) will magnify the problem. It's easy to find fault in C/C++. It's easy to parrot the Rust marketing. It's not so easy to actually have spent the time to learn and use Rust, let alone articulate the subtle ways that its design, taken as a whole, is better than alternatives. Building those constructive arguments is _hard_. I remember reading an article about error handling. It had to have been at least 10 pages worth of content, covering the history of error handling throughout all the old and modern languages, and using examples for where each fails or succeeds. It culminates, more or less, in explaining exactly why the error handling of languages like Rust outperforms in the field of systems programming. (NOTE: The author of that article was actually arguing for the error system used in the language they developed for their OS, IIRC. But Rust was pretty darn close to the ideal the author was going for, and they pointed out as much.) My point is that it took 10+ pages to make a solid argument for _just_ error handling. Not many people have the experience, wisdom, time, and willingness to write even a fraction of such insightful content in a comment on HN. That said, well written, balanced comments still generally float to the top in even controversial HN threads. EDIT: I would also like to point out something specifically in response to "I've seen comments to the effect that anyone writing in C or C++ today is literally acting with reckless indifference to life and safety." There is a tremendous amount of pent up anger in the programming community against C/C++. The language should have been put our to pasture a _long_ time ago. Rust is the first language which has a real chance to displace it. So it's no wonder that a lot of us are willing to just burn C/C++ to the ground and jump ship. Not to mention that as programmers we may be quickly approaching a time when security bugs become a governmental issue, and the _last_ thing we want is the government mandating how we write code. So it is in everyone's interest if we self regulate. Again, that would explain why everyone is kinda jumpy about C and security bugs.