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.
>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.
> 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.
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.
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.
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)
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?
Speeding up the Rust edit-build-run cycle
(davidlattimore.github.io)113 points by tempaccount420 14 November 2024 | 122 comments
Comments
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!
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.
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.