Speeding up the Rust edit-build-run cycle

It's a lot faster to add a log point in a debugger than to add a print statement and recompile. Especially with cargo check, I really don't see the point of non-debuggable builds (outside of embedded, but the size of debuginfo already makes that a non-starter).

RichardLake• 2 years ago

Doesn't rust have overflow checks in debug and skips them in release?

0x4574• 2 years ago

Rust has compiled time overflow checks enabled by default in any profile. Runtime overflow checks are disabled by default in release profile.

vbezhenar2• 2 years ago

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.

vlovich1232• 2 years ago

because debugger breaks hardware

What? Seems like you’re talking about embedded but I’ve done a lot of embedded projects in my time and I’ve never had a debugger that breaks the HW.

ryangs• 2 years ago

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 enormously more powerful tool than println debugging. My tests are essentially the println, and if they fail for any interesting reason I'll want the debugger.

Aurornis2• 2 years ago

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.

0x4574• 2 years ago

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.

stouset2• 2 years ago

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.

robdar• 2 years ago

printed/println debugging works if you wrote the code or have a good idea of where to go.

I frequently find myself debugging large unfamiliar code bases, and typically it’s much easier to stick a breakpoint in and start following where it goes rather than blindly start instrumenting with print statements and hoping that you picked the right code path.

bluGill5• 2 years ago

Depends on the developer. in the Practice of Programming https://en.m.wikipedia.org/wiki/The_Practice_of_Programming by Brian W. Kernighan and Rob Pike they say they use debuggers only to get a stack trace from a core dump and use printf for everything else. You can disagree but those are known very good programmers.

dgfitz5• 2 years ago

What if the program doesn’t crash? It just black-boxes the data incorrectly? I can find that error infinitely faster with a debugger.

canucker2016• 2 years ago

But what source code debuggers did they have available?

Other than gdb, I can't name any Unix C source code debuggers. I believe they were working on Unix before GDB was created (wikipedia says gdb was created in 1986 - https://en.wikipedia.org/wiki/Gdb).

Plan 9 has acid, but from the man page and english manual, the debugger is closer to cli/tui than gui.

see https://9fans.github.io/plan9port/man/man1/acid.html and https://plan9.io/sys/doc/acid.html

fiedzia• 2 years ago

Debugging in Rust is substantially less common for me (and probably not only for me) because it is less often needed and more difficult - many things that are accessible in interpreted world don't exist in native binary.

I do care about usable tracebacks in error reports though.

nicce3• 2 years ago

Main challenge with debuggers in Rust is to map the data correctly into the complex type system. For this reason I rarely use debuggers, becase dbg! is superior in that sense.

Animats2• 2 years ago

The only time I use a debugger with Rust is when unsafe code in some library crate messes up. My own code has no "unsafe". I have debug symbols on and a panic catcher that displays a backtrace in a popup window. That covers most cases.

Rust development is mostly fixing compile errors, anyway. Once it compiles, it often works the first time. What matters is compile time for error compiles, which is pretty good.

Incremental compile time for my metaverse client is 1 minute 8 seconds in release mode. That's OK. Takes longer to test a new version.

flohofwoe12• 2 years ago

Debuggers are not only useful for actual debugging as in 'finding and fixing bugs', they are basically interactive program state explorers. Also "once it compiles, it works" is true for every programming language unless you're a complete newbie. The interesting bugs usually only manifest after your code is hammered by actual users and/or realworld data.

toast0• 2 years ago

I trained in the cout school of debugging. I can use a debugger, and sometimes do, but it's really hard to use a debugger effectively when you're also dealing with concurrency and network clients. Maybe one day, I'll learn how to use one of the time traveling debuggers and then I can record the problem and then step through it to debug it.

dgunay• 2 years ago

I use the debugger fairly regularly, though for me I'm on a stack where friction is minimal. In Go w/ VS Code, you can just write a test, set your breakpoints, hit "debug test", and you're in there in probably less than 20 seconds.

I am like you though, I don't typically resort to it immediately if I think I can figure out the problem with a quick log. And the times where I've not had access to a debugger with good UX, this tipping point can get pushed quite far out.

jesse__• 2 years ago

I came here to write exactly this .. if I was drinking something I would have spit it everywhere laughing when I read it.

I guess 'many developers' here probably refers to web developers who don't use the debugger, cause it's mostly useless/perpetually broken in JS land ..? I rely heavily on the debugger; can't imagine how people work without one.

bippihippi14• 2 years ago

when you write async JS code the debugger essentially adds no value over printing

flohofwoe12• 2 years ago

The debuggers integrated into web browsers are actually really good, about the same level as most IDE-integrated debuggers.

eddd-ddde• 2 years ago

Ironically the JS debugger is the only one I ever use because it's the only one that "just works".

eminence32• 2 years ago

In my experience Java debuggers are exceptionally powerful, much more so than what I've seen from C/C++/Rust debuggers.

If I'm debugging some complicated TomEE application that might take 2 minutes to start up, then I'm absolutely reaching to an IntelliJ debugger as one of my first tools.

If I'm debugging some small command line application in Rust that will take 100ms to exhibit the failure mode, there's a very good chance that adding a println debug statement is what I'll try first

freeone30003• 2 years ago

CLion adds the power of IntelliJ debuggers to Rust. It works exceptionally well.

flohofwoe12• 2 years ago

much more so than what I've seen from C/C++/Rust debuggers.

...have you ever used the Visual Studio integrated debugger for C/C++ instead of 'raw' gdb/lldb without a UI frontend?

flohofwoe12• 2 years ago

I also don't get it, debuggers as integral part of the programming workflow are a productivity multiplier. It does seem to be a fairly popular opinion in some programmer circles that step-debugging is useless, but I guess they never really used a properly integrated debugger to begin with (not a surprise tbh if all they know is gdb in the terminal).

pjmlp3• 2 years ago

That is why I found so great that Carmack's opinion on debuggers is similar to ours, at least there is some hope to educate the crowds that worship Carmack's achievements.

jcelerier• 2 years ago

In c++ for debugging a mid-sized app, gdb will sometime take up to 5 min to start (assuming no remote symbol cache used). On fairly powerful hardware - i7 13000-something, 64g of RAM. I have the time to do 15 compile-edit-run cycles adding prints in that time span before I have even reached main() in it. (And I really tried every optimisation, gdb-index, caches, split DWARF etc. It jus is absolutely mind bogglingly slow and sometimes will even just crash when reaching a breakpoint. Same for lldb. Those are just not reliable tools. And I'm not even talking of the MSVS debugger which I once timed to take 18 minutes from "start debugging" to actually showing a window with all the symbol server stuff.

SleepyMyroslav• 2 years ago

Vs story does not match my experience for AAA game projects. First vs always had start debugging without loading any symbols at all. 2nd one can load each one module on demand. 3rd local file cache for symbol servers can be very much warm (ie have most of needed symbols in RAM). 4th if your project is stuck on old Vs version you can still debug with latest version of debugger in many cases. Ie for us there are no limits of how many versions of vs dev has on their pc. It might be only available if org has volume deals with Ms though.

Downloading symbols for first time from network symbol server is long but its not part of debugging cycle, at least after 1st run.

agent281• 2 years ago

I work in data engineering. I tend to do println debugging because the production data sets are not available from my machine. I tend to prefer REPL or notebook driven development from a computer that is connected to the production environment.

Aurornis2• 2 years ago

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 8 seconds spent compiling isn’t an issue.

Ar-Curunir• 2 years ago

Just ignore that part then? You don't have to stop reading the rest of the (very good) article lol.

sunshowers• 2 years ago

Step through debuggers and tracers are two different dimensions of debugging, and not directly comparable.

fmbb• 2 years ago

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.

forrestthewoods• 2 years ago

Stepping through code and adding breakpoints is a spectacular way to figure out where to put log statements. Modern code is so abstract that it’s nigh impossible to figure out what the fuck function even gets called just from looking at code.

saurik• 2 years ago

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.

ffsm8• 2 years ago

Your serious code isn't performance sensitive if it's a distributed monolith like you're describing.

It's just another wannabe big scale dumbsterfire some big brain architect thought up, thinking he's implementing a platform that's actively being used by millions of users simultaneously, aka Google's or a few social media sites.

flohofwoe12• 2 years ago

I wouldn't even start a new project before figuring out a proper debugging strategy for it. This also includes not using languages or language features that are not debuggable (stepping from one compiled language into another usually isn't a problem btw, debug information formats like DWARF or PDB are language-agnostic).

bluGill5• 2 years ago

Is it really saving time or are you not thinking enough about what is wrong until you stumble on an answer? I can't answer for you but I find that the forced wait for build also forces me to think and so I find the problem faster. It feels slower though but the clock is the real measure.

unclad5968• 2 years ago

It's one click to set the breakpoint in the ide or one line if you're using gdb from the command line. I'm not sure how printf debugging could be quicker even if you didn't have to rebuild. Having done both, I'd take the debugger any day.

ehaliewicz22• 2 years ago

Sometimes "just thinking harder" works, but often not. A debugger helps you understand what your code is actually doing, while your brain is flawed and makes flawed assumptions. Regardless of who you are, it's unlikely you will be manually evaluating code in your head as accurately as gdb (or whatever debugger you use).

I think a lot of linux/mac folks tend to printf debug, while windows folks tend to use a debugger, and I suspect it is a culture based choice that is justified post hoc.

However, few things have been better for my code than stepping through anything complex at least once before I move on (I used to almost exclusively use printf debugging).

cmontella• 2 years ago

Trace debugging can be inefficient, but it's also highly effective, portable between all languages, and requires no additional tooling. Hard to beat that combo.

eviks• 2 years ago

Using a debugger to step through the code is a huge timesaver.

This is too slow and manual of a process to be a huge timesaver, you'd need a "time-travel" debugging capability that eliminate these to save time

tel• 2 years ago

Just my lack of experience here, but I'm trying to verify I'm successfully using sold. The mold linker claims it leaves metadata in the .comment section, but on mach-o does that exist? Is there a similar evaluation command using objdump as the mold readelf command?

joshka• 2 years ago

Last time I tested mold/sold on Mac, there was no measurable time difference.

James_K• 2 years ago

Surely it would be better to use a debugger and avoid recompiling your code for the added print statements than to strip out the debug information to decrease build times.

evrimoztamur• 2 years ago

I build wasm as a target and this is sadly not an option, I have to rebuild for each little bit. I will be trying a different linker and see how it goes though!

khuey• 2 years ago

split-debuginfo = "unpacked" (-gsplit-dwarf for C/C++) is the way. Your tools (debuggers, profilers, etc) probably support it by now.

sendomatic• 2 years ago

There are a lot of different t views on debugging with a debugger vs print statements and what works better. This often seems to be based on user preference and familiarity. One thing that I haven’t seen mentioned is for issues with dependencies. Setting up a path dep in rust or fetching the code in whatever language you’re using for your project usually takes more time than simply adding some breakpoints in the library code.

zerd• 2 years ago

This post is from February, any interesting changes/improvements since then? Progress on “wild”?

DylanSp• 2 years ago

Looks like he's been continuing to work on it.

GitHub repo: https://github.com/davidlattimore/wild

List of his blog posts, a couple of which are about wild: https://davidlattimore.github.io/

Arch-TK3• 2 years ago

~/.cargo/

This reminds me...

STOP putting your shitty dot-directories full of a mix of config, cache and data in my god damned home directory.

Concerned that not doing this will break things? Just check if you've dumped your crap in there already and if not then put it in the right places.

Worried about confusing existing users migrating to other machines? Document the change.

Still worried? How about this: I'll put a file called opt-into-xdg-base-directory-specification inside ${XDG_CONFIG_HOME:-$HOME/.config} and if you find that file you can rest assured I won't be confused.

Thanks in advance!

pvinis• 2 years ago

I would upvote at least 10 times if I could.

This!

childintime2• 2 years ago

If you have to blame the developer, blame the OS. Shit drops down from above. Maybe it's just old and crappy.

HdS84• 2 years ago

As a non linux expert I always wonder where to put crap - most places seem not fit for purpose.

johnisgood2• 2 years ago

Blame the OS? Why? And what good would that do? The developers could have used XDG_CONFIG_HOME at the very least.

NautilusWave• 2 years ago

So like ~/.ssh/ is bad? Or does it get grandfathered?

ramon156• 2 years ago

I feel like a healthy mix is fine. Just like I wouldn't want my repo to be 90% cache, having 1-2 folders is fine.

Vilian• 2 years ago

SSH has the argument that they are older than the specification, now cargo, nah, a lot of application that use ssh hardcoded .ssh, cargo don't have that excuse

Arch-TK3• 2 years ago

I thought my comment addresses this specifically.

Yes, it's bad. If you predate the specification then see options 2 (check), 3 (document) or 4 (come up with a new spec for opting in).

rascul2• 2 years ago

Stop giving me a mix of locations that aren't even used correctly and just put the dot file/directory in my home directory.

Thanks in advance.

porridgeraisin• 2 years ago

I hate XDG. I prefer app/kinds-of-data. If home directory clutter is the problem, I would prefer having a ~/crap folder. So it would be ~/crap/.cargo

Arch-TK3• 2 years ago

I am all for a "Please put everything in random sub directories of /" config option for the installer of your linux distribution of choice where / is your home directory, PATH, configuration directory and everything else. But I think you're in the minority.

mdaniel• 2 years ago

It's funny that two different posts today are having the same "tabs vs spaces" about "printf vs debugger" https://news.ycombinator.com/item?id=42146338 (Seer: A GUI front end to GDB for Linux)

Speeding up the Rust edit-build-run cycle

Related Stories