9 ms·

One of the things with Rust is that while the compiler could be considered slow, once your Rust code compiles, if you stay away from `unsafe` code and `unwrap()

One of the things with Rust is that while the compiler could be considered slow, once your Rust code compiles, if you stay away from `unsafe` code and `unwrap()`, the code is usually bug free (apart from logic bugs that no compiler could catch). At least that's been my experience with Rust.

abjKT26nO8 7y ago
Although Rust's type system does catch a lot, I wouldn't say it's that effective. I, for one, will usually make an off-by-one error or forget that I left a stub somewhere and didn't come back to write a proper implementation. But it's easily caught by the most rudimentary tests; so you don't have to bother yourself with writing them as elaborate as people usually do with e.g. Python.
- frenchman99 7y ago
  An off-by-one error is a logic error.
  - laumars 7y ago
    That doesn't mean it isn't _also_ a software bug given that the result is still unintended / unexpected.
- bluejekyll 7y ago
  A lot of those basic issues, clippy often catches. One thing I enabled recently to make sure it’s caught before release, is checking for spurious uses of dbg! and unimplememted!, as well as println! in production code. For off by 1 errors, in Rust it’s often better to turn to iterators where appropriate than to say using indexes (it’s also more efficient in most cases). Clippy can also catch those issues.
  - abjKT26nO8 7y ago
    In my experience, all Clippy does is find style issues. Perhaps it's more effective in other projects, but in the code I wrote all by myself it didn't find a single error (as in bug). That's not to say Clippy isn't useful. I value style consistency (in this case consistency among the general pool of all Rust programmers and not inside a single project). Of course, YMMV. > For off by 1 errors, in Rust it’s often better to turn to iterators where appropriate than to say using indexes (it’s also more efficient in most cases). The off-by-one errors I made weren't related to indexing collections. I don't remember anymore what it was exactly, it got caught by the very first tests I wrote before even trying to use anything. I do use iterators whenever they make sense and I write new iterators whenever it makes sense. Still, good note from you.
    - bluejekyll 7y ago
      Some of those style things are better style specifically because they help avoid common bugs. I’ve found that it is helpful in avoiding those and additional directing you to more performant choices. YMMV.
DarthGhandi 7y ago
Huh? How exactly do you stay away from error handling? Even the most basic code on Earth has unwrap or expect in it. Show me one single library that doesn't unwrap somewhere along the line.
- abjKT26nO8 7y ago
  Unwrapping results with pattern matching in "match" or "if let" lets you handle error conditions safely.
- tov_objorkin 7y ago
  unwrap() or expect() unconditionally smash program execution in case of error. Properly written program should handle such errors or use unwrap_or_* as fallback. The point is that unwrap/unsafe is breaking safety rules, user writing one know what hes doing or just don't bothering.
  - jashmatthews 7y ago
    Unwrap and expect don’t violate any safety rules! If they did you’d need to wrap it in an unsafe block. https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html
    - tov_objorkin 7y ago
      You're technically right, i mean if user aim for durable code then using unwrap is not desired behavior most of the time. For example pointer deference in C is implicit operation. In Rust user must choose explicitly how to handle Option/Result. Even if using unwrap not so harmful as using unsafe and didn't violate rules this is our deliberate choose to break "end-user safety".
- crematoria 7y ago
  You have it wrong. Only the most basic code on Earth has unwrap in it. Real-world code will either actually handle the error with `match`, forward it with `?`, or unwrap it with `except` iff it's sure that an error will not occur.
AnIdiotOnTheNet 7y ago
> the code is usually bug free (apart from logic bugs that no compiler could catch) So basically your code is not even a little bug-free, it just probably doesn't have a certain small class of bug in it.
- nullc 7y ago
  Worse, it probably calls libraries written by rust users who drank that compiles=bug-free koolaid... It won't likely crash, beyond that: all bets are off. I've now encountered several pieces of rust software that have no error / exceptional case handling and just panic at things like unexpected command-line arguments.
  - gameswithgo 7y ago
    panic at unexpected input is not ideal, but when you encounter bad software from a C/C++ programmer that bad input could be an ACE instead.
    - nullc 7y ago
      With false claims like the ancestor here being commonly made it becomes plausible that software written in rust could be faulty at a higher rate than in less safe languages, specifically because of the lack of care and dismissal of risks (plus ecosystem considerations). I wouldn't go so far as to argue that it is at this point. But I think rust advocates probably ought to stop arguing as though it's axiomatically true. Maybe Mozilla could be talked into funding an academic study comparing defect rates in rust vs other languages used for systems programming. Beyond substantiating the rust-improves-reliability trope, it could also identify areas for improvement where it doesn't.
gameswithgo 7y ago
The statement "if it compiles it works" is a feeling you get from small programs in very safe languages, but we all know it isn't true, and saying stuff like that immediately causes experienced programmers to think you are naive. It isn't good language PR to say it or anything like it.
- Tainnor 7y ago
  In my experience, though, the statement is largely true for refactorings. Even in a language like Java that doesn't have a very expressive type system, if I need to change the structure of my classes, rename some stuff, etc., just knowing that it compiles tells you that you probably didn't break anything. Of course, once you add / change logic, I agree with your assessment that the statement is hopelessly naïve in most practical use cases.
- wizzwizz4 7y ago
  "If it compiles, and the tests pass, it works" is more accurate; if your tests are pretty thorough, it's very unlikely that you've got any major logical errors, and Rust rules out a massive class of lifetime, double-use, mutability etc. errors just by being Rust. I've translated pure-logic business code (with fairly thorough, albeit static, tests that all passed) from Python to Rust, and the compiler's complained about subtle errors that would have taken down a business using the code in days had they been put into production. Turns out there was a flaw in the spec. Leveraging Rust's type system to logically separate the meanings of different integers, and only permitting arithmetic operations where meaningful (e.g. no distance+time, distance/time=speed), also uncovered a couple of even more subtle bugs – though luckily assertions would've caught these in the event of them actually making it through to production. If it compiles, it probably works. But, more importantly, Rust forces you to write code that works in the first place. You have to think through the ramifications of what you're doing, sometimes to hold the entire function in your head at once, and that means you have to understand what you're doing. If you don't, it complains, and the chances are you won't be able to get it to compile until you do understand it. And if it does compile when it's wrong, it's obviously wrong and your tests will fail. Most of the time. Isn't programming fun?
- frenchman99 7y ago

abjKT26nO8 7y ago

Although Rust's type system does catch a lot, I wouldn't say it's that effective. I, for one, will usually make an off-by-one error or forget that I left a stub somewhere and didn't come back to write a proper implementation. But it's easily caught by the most rudimentary tests; so you don't have to bother yourself with writing them as elaborate as people usually do with e.g. Python.

frenchman99 7y ago
An off-by-one error is a logic error.
- laumars 7y ago
  That doesn't mean it isn't _also_ a software bug given that the result is still unintended / unexpected.
bluejekyll 7y ago
A lot of those basic issues, clippy often catches. One thing I enabled recently to make sure it’s caught before release, is checking for spurious uses of dbg! and unimplememted!, as well as println! in production code. For off by 1 errors, in Rust it’s often better to turn to iterators where appropriate than to say using indexes (it’s also more efficient in most cases). Clippy can also catch those issues.
- abjKT26nO8 7y ago
  In my experience, all Clippy does is find style issues. Perhaps it's more effective in other projects, but in the code I wrote all by myself it didn't find a single error (as in bug). That's not to say Clippy isn't useful. I value style consistency (in this case consistency among the general pool of all Rust programmers and not inside a single project). Of course, YMMV. > For off by 1 errors, in Rust it’s often better to turn to iterators where appropriate than to say using indexes (it’s also more efficient in most cases). The off-by-one errors I made weren't related to indexing collections. I don't remember anymore what it was exactly, it got caught by the very first tests I wrote before even trying to use anything. I do use iterators whenever they make sense and I write new iterators whenever it makes sense. Still, good note from you.
  - bluejekyll 7y ago
    Some of those style things are better style specifically because they help avoid common bugs. I’ve found that it is helpful in avoiding those and additional directing you to more performant choices. YMMV.

DarthGhandi 7y ago

Huh? How exactly do you stay away from error handling? Even the most basic code on Earth has unwrap or expect in it. Show me one single library that doesn't unwrap somewhere along the line.

abjKT26nO8 7y ago
Unwrapping results with pattern matching in "match" or "if let" lets you handle error conditions safely.
tov_objorkin 7y ago
unwrap() or expect() unconditionally smash program execution in case of error. Properly written program should handle such errors or use unwrap_or_* as fallback. The point is that unwrap/unsafe is breaking safety rules, user writing one know what hes doing or just don't bothering.
- jashmatthews 7y ago
  Unwrap and expect don’t violate any safety rules! If they did you’d need to wrap it in an unsafe block. https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html
  - tov_objorkin 7y ago
    You're technically right, i mean if user aim for durable code then using unwrap is not desired behavior most of the time. For example pointer deference in C is implicit operation. In Rust user must choose explicitly how to handle Option/Result. Even if using unwrap not so harmful as using unsafe and didn't violate rules this is our deliberate choose to break "end-user safety".
crematoria 7y ago
You have it wrong. Only the most basic code on Earth has unwrap in it. Real-world code will either actually handle the error with `match`, forward it with `?`, or unwrap it with `except` iff it's sure that an error will not occur.

AnIdiotOnTheNet 7y ago

> the code is usually bug free (apart from logic bugs that no compiler could catch) So basically your code is not even a little bug-free, it just probably doesn't have a certain small class of bug in it.

nullc 7y ago
Worse, it probably calls libraries written by rust users who drank that compiles=bug-free koolaid... It won't likely crash, beyond that: all bets are off. I've now encountered several pieces of rust software that have no error / exceptional case handling and just panic at things like unexpected command-line arguments.
- gameswithgo 7y ago
  panic at unexpected input is not ideal, but when you encounter bad software from a C/C++ programmer that bad input could be an ACE instead.
  - nullc 7y ago
    With false claims like the ancestor here being commonly made it becomes plausible that software written in rust could be faulty at a higher rate than in less safe languages, specifically because of the lack of care and dismissal of risks (plus ecosystem considerations). I wouldn't go so far as to argue that it is at this point. But I think rust advocates probably ought to stop arguing as though it's axiomatically true. Maybe Mozilla could be talked into funding an academic study comparing defect rates in rust vs other languages used for systems programming. Beyond substantiating the rust-improves-reliability trope, it could also identify areas for improvement where it doesn't.

gameswithgo 7y ago

The statement "if it compiles it works" is a feeling you get from small programs in very safe languages, but we all know it isn't true, and saying stuff like that immediately causes experienced programmers to think you are naive. It isn't good language PR to say it or anything like it.

Tainnor 7y ago
In my experience, though, the statement is largely true for refactorings. Even in a language like Java that doesn't have a very expressive type system, if I need to change the structure of my classes, rename some stuff, etc., just knowing that it compiles tells you that you probably didn't break anything. Of course, once you add / change logic, I agree with your assessment that the statement is hopelessly naïve in most practical use cases.
wizzwizz4 7y ago
"If it compiles, and the tests pass, it works" is more accurate; if your tests are pretty thorough, it's very unlikely that you've got any major logical errors, and Rust rules out a massive class of lifetime, double-use, mutability etc. errors just by being Rust. I've translated pure-logic business code (with fairly thorough, albeit static, tests that all passed) from Python to Rust, and the compiler's complained about subtle errors that would have taken down a business using the code in days had they been put into production. Turns out there was a flaw in the spec. Leveraging Rust's type system to logically separate the meanings of different integers, and only permitting arithmetic operations where meaningful (e.g. no distance+time, distance/time=speed), also uncovered a couple of even more subtle bugs – though luckily assertions would've caught these in the event of them actually making it through to production. If it compiles, it probably works. But, more importantly, Rust forces you to write code that works in the first place. You have to think through the ramifications of what you're doing, sometimes to hold the entire function in your head at once, and that means you have to understand what you're doing. If you don't, it complains, and the chances are you won't be able to get it to compile until you do understand it. And if it does compile when it's wrong, it's obviously wrong and your tests will fail. Most of the time. Isn't programming fun?
frenchman99 7y ago