News for hackers. Stuff that matters.

A comment on Comparing Pythagorean triples in C++, D, and Rust. Parent comment

Re:Comparing Pythagorean triples in C++, D, and Rust by kibwen on Monday December 31, 2018 @12:27PM (#18795630)
This is going to sound unbelievable, but I don't really ever do runtime debugging of my Rust code. Nearly all my debugging happens at compile-time (which is faster to iterate with thanks to cargo-check skipping codegen and linking). That said, I do know some people with large Rust codebases who do value the ability to run debug builds, and the slowness of -O0 binaries is a sore spot for them. As with C, you can try -O1 for a compromise between runtime and compiletime.
[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by WalterBright on Monday December 31, 2018 @01:14PM (#18795971)
As my decades of programming experience accumulate, the source of most of my programming bugs shifted. Earlier it was dumb mistakes, memory management errors, seg faults, etc. Now it's logic errors due to design mistakes and failing to understand properly what needed to be done.

A fair bit of the D programming language design is there to head off the detail mistakes people make. A more subtle thing in the language design is to make the designs less prone to error.

[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by jordigh on Monday December 31, 2018 @12:31PM (#18795655)
The issue is that the optimised code is not the same as the unoptimised code, and debugging optimised code sucks. It appears to the debugger that your execution is jumping around erratically and often variables don't exist because the optimiser decided that they didn't need a reason to exist.

It's a problem with any kind of compiled language that runs through an optimiser, whether C, C++, Rust, or D. Maybe that's why so many people just don't use debuggers, although my philosophy is that everyone should use a debugger, but maybe they just haven't found the right one yet.

[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by loeg on Monday December 31, 2018 @07:53PM (#18798187)
It doesn't have to suck nearly as badly as it does today with LLVM-based toolchains, including Rust's. With C and C++, GCC does a much better job of maintaining accurate DWARF information with performance at least as good as Clang. (And optimized code certainly shouldn't be "jumping around erratically," simply because that results in poor performance on modern CPUs with multi-cycle instruction pipelines and imperfect branch predictors.)

A variable doesn't have to be in a single register throughout an entire function, or even present in registers / memory at all! DWARF is capable of representing storage locations that change over the course of a subroutine, as well as synthesizing values from other registers/memory, simple operations, and constants. Compilers can do a lot better (although certainly not 100%) than they do today without sacrificing any of the optimizations they make, and especially Clang/LLVM have a lot of room for improvement.

I highly recommend this blog post on the subject: https://backtrace.io/blog/engineering/compile-once-debug-twi...

[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by marksomnian on Monday December 31, 2018 @12:58PM (#18795855)
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.
[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by staticassertion on Monday December 31, 2018 @01:13PM (#18795956)
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.
[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by marksomnian on Monday December 31, 2018 @01:16PM (#18795992)
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.
[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by staticassertion on Monday December 31, 2018 @01:31PM (#18796072)
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-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.

[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by steveklabnik on Monday December 31, 2018 @01:09PM (#18795936)
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.

[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by pjmlp on Tuesday January 01, 2019 @05:54AM (#18799713)
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.

[ Parent | on HN ]
Re:Comparing Pythagorean triples in C++, D, and Rust by steveklabnik on Tuesday January 01, 2019 @01:55PM (#18801609)
Fun fact: I loved coding in HyperCard as a kid.
[ Parent | on HN ]