HACKER Q&A
📣 manux81

DDD was a great debugger – what would a modern equivalent look like?


I’ve always thought that DDD was a surprisingly good debugger for its time.

It made program execution feel visible: stacks, data, and control flow were all there at once. You could really “see” what the program was doing.

At the same time, it’s clearly a product of a different era:

– single-process

– mostly synchronous code

– no real notion of concurrency or async

– dated UI and interaction model

Today we debug very different systems: multithreaded code, async runtimes, long-running services, distributed components.

Yet most debuggers still feel conceptually close to GDB + stepping, just wrapped in a nicer UI.

I’m curious how others think about this:

– what ideas from DDD (or similar old tools) are still valuable?

– what would a “modern DDD” need to handle today’s software?

– do you think interactive debugging is still the right abstraction at all?

I’m asking mostly from a design perspective — I’ve been experimenting with some debugger ideas myself, but I’m much more interested in hearing how experienced engineers see this problem today.

  👤 buster Accepted Answer ✓
Domain driven design?
👤 martijnvds
printf("Got here, x=%u"\n", x);
👤 chrsw
Something like this maybe:

https://whitebox.systems/

Doesn't seem to meet all your desired features though.

👤 TheRoque
Maybe you can have a look at RadDbg [0], as I understand the project has been bought by Epic Games recently. The goal is to make a performant debugger, from what I understand its target audience is mostly game developers, but you can use it for other programs obviously. You can see a talk of the core developer and his vision here: https://www.youtube.com/watch?v=_9_bK_WjuYY

Sadly it's windows only yet, but they have plans to port it to other platforms.

- [0]: https://github.com/EpicGamesExt/raddebugger

👤 apaprocki
Check out Binary Ninja if you haven’t. Especially if you have large binaries!
👤 galkk
I haven’t touched in a while, but Visual Studio’s (standalone, not code) debugger was very cool.

Also rr is impressive in theory, although it never worked on codebases that I worked on.

👤 superdisk
This is a legitimate question but this was clearly generated using an LLM.

To add something constructive, this demo represents an amazing ideal of what debugging could be: https://www.youtube.com/watch?v=72y2EC5fkcE

👤 DeathArrow
I am pretty happy with the debugger from Visual Studio.
👤 markhahn
Linaro (need Allinea) DDT?
👤 w4rh4wk5
May I recommend this episode of The Stand Up podcast with Ryan Fleury as guest, who is the driving force behind the rad debugger.

https://www.youtube.com/watch?v=O-3gEsfEm0g

Casey also makes a good point here on why printf-debugging is still extremely popular.

👤 Agingcoder
Pernosco

Blows everything else out of the water.

https://pernos.co/ ( I’m not affiliated to them in any way, just a happy customer)

👤 uyar
My background is in teaching C programming at the university level and DDD was very helpful there, although not very comfortable to use. For years, I've looked for a replacement and finally found Seer and was very happy with it.

https://github.com/epasveer/seer

Interactive debugging is definitely useful when teaching but obviously teaching is a different context. But Seer is not an educational tool and I believe it will hold up in other cases as well.

👤 anthk
Radare and friends maybe. For sure it has some graph-like options as DDD had where you could graphically see everything.

Most RE tools today will integrate a debugger (or talk to gdb).

👤 michalsustr
What are you using as a Rust debugger?
👤 MichaelRo
Modern equivalent, working on Linux with remote connection from Visual Studio Code is LLDB.

Takes some effort to configure it but beats "printf" (i.e. logging) in the end.

👤 delaminator
Plan 9's acid.
👤 flohofwoe
I always point to the Metal-API debugger in Xcode for what I'd want a CPU debugger to look like, visualizing dependencies and dataflows with an actual graphical UI, letting me view data as something else than just hex dumps (e.g. as image or 3D mesh), etc... etc...

Of course the CPU side usually lacks semantics to automatically create data visualizations (while modern 3D APIs have enough context to figure out data dependencies and data formats), and that would be the "interesting" part to solve - e.g. how to tunnel richer debug information from the programming language to the debugger.

Also there's a middle ground of directly adding a realtime runtime debugging UI to applications via something like Dear Imgui (https://github.com/ocornut/imgui/) which is at least extremely popular in game development - and in this case it's trivial to provide the additional context since you basically develop the debugging UI alongside the application.

👤 BoredomIsFun
I think for Unix-likes, a good old TUI based like Turbo Debugger would be very useful.
👤 Lwerewolf
FoundationDB's approach - look up their testing framework.

I've worked in a company that, for all intents and purposes, had the same thing - single thread & multi process everything (i.e. process per core), asserts in prod (like why tf would you not), absurdly detailed in-memory ring buffer binary logs & good tooling to access them plus normal logs (journalctl), telemetry, graphing, etc.

So basically - it's about making your software debuggable and resilient in the first place. These two kind of go hand-in-hand, and absolutely don't have to cost you performance. They might even add performance, actually :P