3 ms·

How do you debug logic errors in that case? I imagine that most logic errors can't be caught by the compiler, although I could be wrong.

steveklabnik 8y ago
I come from Ruby, where debuggers are useful but also not often used. I find that I tend to write more and smaller unit tests than people who reach for debuggers. I debug logic errors by using println or writing more tests. And yes, Rust is still very susceptible to logic errors.
- pjmlp 8y ago
  Developing with powerfull debuggers is an experience that kind of resembles using a REPL, specially with languages that enjoy fast compiles. I advise devs to go through Xerox PARC and ETHZ papers about interactive development, or Apple's Object Pascal/MCL/Dylan/Hypercard, on was the birth of IDEs.
  - steveklabnik 8y ago
    Fun fact: I loved coding in HyperCard as a kid.
staticassertion 8y ago
Most logic errors can definitely be caught by the compiler if you're taking the approach of encoding your logic into your type system. I've done this with real codebases (in Python as well, actually, using Mypy) and it's been very effective.
- marksomnian 8y ago
  Can it catch something like accidentally writing "x == y", when you meant to write "x != y"? I feel like this kind of bug can be insidious enough to waste lots of debugging time, yet difficult to catch until you run the code.
  - staticassertion 8y ago
    Not easily. Rust's type system has limits, and what you're talking about is something you'd probably want dependent types for. But it can catch lots of other logic errors. The approach I have used in both mypy and rust is to encode state transitions into types. It's more elegant in Rust, and safer as well, but even with mypy it means I could be very sure about certain properties of my service (it was a sensitive service and I needed to be reasonably sure it wouldn't end up in an invalid state). https://insanitybit.github.io/2016/05/30/beyond-memory-safety-with-types https://insanitybit.github.io/2016/05/30/beyond-memory-safet... This is an example of the pattern. When you take a "Type driven" approach to your code - stating your constraints upfront, and encoding them into your types - you can push a lot of the debug cycle to your compiler.

steveklabnik 8y ago

I come from Ruby, where debuggers are useful but also not often used. I find that I tend to write more and smaller unit tests than people who reach for debuggers. I debug logic errors by using println or writing more tests. And yes, Rust is still very susceptible to logic errors.

pjmlp 8y ago
Developing with powerfull debuggers is an experience that kind of resembles using a REPL, specially with languages that enjoy fast compiles. I advise devs to go through Xerox PARC and ETHZ papers about interactive development, or Apple's Object Pascal/MCL/Dylan/Hypercard, on was the birth of IDEs.
- steveklabnik 8y ago
  Fun fact: I loved coding in HyperCard as a kid.

staticassertion 8y ago

Most logic errors can definitely be caught by the compiler if you're taking the approach of encoding your logic into your type system. I've done this with real codebases (in Python as well, actually, using Mypy) and it's been very effective.

marksomnian 8y ago
Can it catch something like accidentally writing "x == y", when you meant to write "x != y"? I feel like this kind of bug can be insidious enough to waste lots of debugging time, yet difficult to catch until you run the code.
- staticassertion 8y ago
  Not easily. Rust's type system has limits, and what you're talking about is something you'd probably want dependent types for. But it can catch lots of other logic errors. The approach I have used in both mypy and rust is to encode state transitions into types. It's more elegant in Rust, and safer as well, but even with mypy it means I could be very sure about certain properties of my service (it was a sensitive service and I needed to be reasonably sure it wouldn't end up in an invalid state). https://insanitybit.github.io/2016/05/30/beyond-memory-safety-with-types https://insanitybit.github.io/2016/05/30/beyond-memory-safet... This is an example of the pattern. When you take a "Type driven" approach to your code - stating your constraints upfront, and encoding them into your types - you can push a lot of the debug cycle to your compiler.