Speeding up the Rust edit-build-run cycle

Re:Speeding up the Rust edit-build-run cycle by jesse__ on Thursday November 14, 2024 @04:55PM (#42141634)

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.

[ Parent | on HN ]

Re:Speeding up the Rust edit-build-run cycle by bippihippi1 on Thursday November 14, 2024 @04:57PM (#42141655)

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

[ Parent | on HN ]

Re:Speeding up the Rust edit-build-run cycle by flohofwoe on Friday November 15, 2024 @03:41AM (#42144996)

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

[ Parent | on HN ]

Re:Speeding up the Rust edit-build-run cycle by bippihippi1 on Monday November 18, 2024 @12:26PM (#42174649)

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

[ Parent | on HN ]

Re:Speeding up the Rust edit-build-run cycle by flohofwoe on Friday November 15, 2024 @03:40AM (#42144989)

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

[ Parent | on HN ]

Re:Speeding up the Rust edit-build-run cycle by eddd-ddde on Friday November 15, 2024 @12:40PM (#42149070)

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

[ Parent | on HN ]