Live data from Hacker News

Speeding up the Rust edit-build-run cycle

davidlattimore.github.io

121–125 of 125 posts

Re: Speeding up the Rust edit-build-run cycle

#121

Earlier quoted context omitted.

Rust only protects from a very small subset of bugs (memory corruption issues and data races) but not from logic bugs which are far more common.

Rust protects against undefined behavior. This is enough that programs either panic in a well-defined way, or continue to run well enough that logging works.

Not having UB isn't exactly unique to Rust though (Rust does have some UB btw it's just not as easy to encounter as in C or C++).

Re: Speeding up the Rust edit-build-run cycle

#122
post #98

Earlier quoted context omitted.

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

There is a standard which you should follow. Here you go https://specifications.freedesktop.org/basedir-spec/latest/

Yep, likely an example of downstream problems that should not exist.

Re: Speeding up the Rust edit-build-run cycle

#123
post #5

>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 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.

Re: Speeding up the Rust edit-build-run cycle

#124

Earlier quoted context omitted.

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

Not in my experience, async JS/TS code is perfectly fine debuggable (at least with setting a breakpoint here and there).

the callstacks are hard to read and watching variables across context boundaries is difficult. yea you can pause the program with the debugger, but doing so doesn't give much of a picture of how the program is functioning. I've found seeing the prints from all the 'threads' gives a better sense of what's happening

Re: Speeding up the Rust edit-build-run cycle

#125
post #50

Earlier quoted context omitted.

are there debugging tools specifically for situations like that? do you just write code to test manually? How do you ensure dev builds don't break stuff like that even without considering debugging?

The most useful tool is a full tracing system (basically a stream of run instructions you can use to trace the execution of the code without interrupting it), but unfortunately they're quite expensive and proprietery, and require extra connections to the systems that do support them, so they're not particularly commonly used. Most people just use some kind of home-grown logging/tracing system that tracks the particul…

like a perf trace?
Post reply on HN