Good set of tips. Thank you.
It was my pleasure.
Speeding up the Rust edit-build-run cycle
11–20 of 125 posts
Re: Speeding up the Rust edit-build-run cycle
#12Not linking debug info must be some kind of sick joke. What is the point of a debug build without symbols?
Doesn't rust have overflow checks in debug and skips them in release?
Rust has compiled time overflow checks enabled by default in any profile.
Runtime overflow checks are disabled by default in release profile.
Re: Speeding up the Rust edit-build-run cycle
#13> If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger You lost me here. Using a debugger to step through the code is a huge timesaver. Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient. If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the…
Just ignore that part then? You don't have to stop reading the rest of the (very good) article lol.
Re: Speeding up the Rust edit-build-run cycle
#14> If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger You lost me here. Using a debugger to step through the code is a huge timesaver. Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient. If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the…
Step through debuggers and tracers are two different dimensions of debugging, and not directly comparable.
Re: Speeding up the Rust edit-build-run cycle
#15[flagged]
Re: Speeding up the Rust edit-build-run cycle
#16>Debug information tends to be large and linking it slows down linking quite considerably. If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger, then this is wasted time. Interesting. Is this true? In my work (java/kotlin, primarily in app code on a server, occasional postgres or frontend js/react stuff), I'm almost always reaching for a debugger as an…
println debugging is where everyone starts. Some people never graduate to knowing how to use a debugger. Debugging through log data still has a place, of course. However, trying to do all of your debugging through println is so much harder, even though it feels easier than learning to use a debugger.
To be fair, if your code is multithreaded and sensitive to pauses, it becomes harder to debug with a debugger.
Ultimately, if you have a good logging setup and kinda know where the issue is a quick log message could be faster than debugging if all you want to do is look a variable value.
Re: Speeding up the Rust edit-build-run cycle
#17>Debug information tends to be large and linking it slows down linking quite considerably. If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger, then this is wasted time. Interesting. Is this true? In my work (java/kotlin, primarily in app code on a server, occasional postgres or frontend js/react stuff), I'm almost always reaching for a debugger as an…
println debugging is where everyone starts. Some people never graduate to knowing how to use a debugger. Debugging through log data still has a place, of course. However, trying to do all of your debugging through println is so much harder, even though it feels easier than learning to use a debugger.
I am comfortable using a debugger, but println debugging is easy, fast, and disproportionately effective for most of my debugging in practice.
I reach for a “real” debugger when necessary, but that’s less than 5% of the time.
Re: Speeding up the Rust edit-build-run cycle
#18Not linking debug info must be some kind of sick joke. What is the point of a debug build without symbols?
1. Skipping some optimizations to build faster.
2. Conditionally compiling some code like logging (not sure if matters for typical Rust projects, but for embedded C projects it's typical).
3. Conditionally compiling assertions to catch more bugs.
I'm using logs, because debugger breaks hardware. Very rarely do I need to reach debugger. Even when hard exception occurs, usually enough info is logged to find out the root cause of the bug.
Re: Speeding up the Rust edit-build-run cycle
#19> If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger You lost me here. Using a debugger to step through the code is a huge timesaver. Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient. If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the…
> Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient.
That all depends on how long it takes to compile and run.
> If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the 8 seconds spent compiling isn’t an issue.
Meh, it's fine.
You still have to set new ones and re-run your code to trigger the reproduction iteratively if you don't know where anything is wrong.
Clicking "add logging break point here" and adding a print statement is really not very different. In my experience the hard part is know where you want to look. Stepping through all your code line by line and looking at all values every step is not a quick way to do anything. You have to divide and conquer your debugging smartly, like a binary search all over your call sites in the huge tree-walk that is your program.
Re: Speeding up the Rust edit-build-run cycle
#20> If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger You lost me here. Using a debugger to step through the code is a huge timesaver. Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient. If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the…
Engh... I used to rely on a debugger a lot 25 years ago when I was learning to program, and was extremely good at making it work and using its quirks; but, I was building overly-simplistic software, and it feels so rare of a thing to be useful anymore. The serious code I now find myself actually ever needing to debug, with multiple threads written in multiple languages all linked together--code which is often performance sensitive and even often involves networked services / inter-process communication--just isn't compatible with interactive debugging.
So like, sure: if I have some trivial one-off analysis tool I am building for which I am running into some issue I could figure out how to debug it, but even then I am going to have to figure out yet another debugging environment for yet another language, and also of course surmount the hassle of a ton of ensuring that sufficient debugging information is available and I'm running a build that is somehow not optimized enough for debugging and yet also not so slow that I'm gouging my eyes out, I could use a debugger, but I'd rather sit and stare at the code longer than start arguing with a debugger.