91–100 of 125 posts
Earlier quoted context omitted.
I mean, even then c/CPP will optimize out stuff and you won't get as nice one-to-one mapping as you do with eg. Java.
That's why the debug build config one uses during development only does little to no optimizations.
Earlier quoted context omitted.
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.
E.g. I keep wondering whether the split between people who can't live without debuggers vs people who rarely use debuggers is actually people who use IDEs versus people who don't.
Earlier quoted context omitted.
That's why the debug build config one uses during development only does little to no optimizations.
My point is that even that little can sometimes lead to less pleasant experiences, like stepping half a function's body ahead.
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?
> ~/.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 pu…
>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…
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).
Earlier quoted context omitted.
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. Increm…
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.
> ~/.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 pu…
If you have to blame the developer, blame the OS. Shit drops down from above. Maybe it's just old and crappy.
Earlier quoted context omitted.
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.
You're obviously not a Rust programmer.
Earlier quoted context omitted.
They use printf. Which they claim is faster.
Faster than pressing F9 (to set a breakpoint on the current line) and then F5 (to start into the debugger)? Printf-debugging has its uses, but they are very niche (for instance when you don't have access to a properly integrated debugger). Logging on the other hand is useful, but logs are only one small piece of the puzzle in the overall debugging workflow - usually only for debugging problems that slipped into produ…
If, however, it’s something where I need to examine state at multiple times in the execution, I lose track in my mind of the state I’ve seen before. This is where print debugging shines: I can see how state evolved over time and spot trends.