Speeding up the Rust edit-build-run cycle

(davidlattimore.github.io)

Comments

Arch-TK 15 November 2024
> ~/.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!

ryangs 14 November 2024
>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.

Aurornis 14 November 2024
> 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.

sendomatic 14 November 2024
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.
nuudlman 14 November 2024
Not linking debug info must be some kind of sick joke. What is the point of a debug build without symbols?
khuey 14 November 2024
split-debuginfo = "unpacked" (-gsplit-dwarf for C/C++) is the way. Your tools (debuggers, profilers, etc) probably support it by now.
James_K 14 November 2024
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.
mdaniel 15 November 2024
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)
tel 14 November 2024
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?
zerd 14 November 2024
This post is from February, any interesting changes/improvements since then? Progress on “wild”?
renewiltord 14 November 2024
Good set of tips. Thank you.
omani 14 November 2024
thanks