Show HN: Uscope, a new Linux debugger written from scratch

Original Article ↗ Hacker News Discussion ↗

Overall reaction

  • Many are excited to see a new native Linux debugger, especially one not based on gdb, and are curious about its Zig implementation and progress.
  • Others are skeptical, seeing the project as very ambitious given how hard debuggers are, and question whether it can realistically surpass gdb/lldb.

Why a new debugger?

  • Supporters argue gdb and lldb are powerful but painful: crashes, slow startup on large C++ binaries, poor data browsing, awkward UIs/APIs, and long‑standing unfixed bugs.
  • Some respond that “building it for fun” is reason enough and fits the HN spirit, and that fresh attempts can surface new ideas even if they don’t fully succeed.

Debate over GDB/LLDB quality

  • One camp calls gdb “great” but quirky, emphasizing its power, Python extensibility, and improved multi-process support; they suggest filing bugs instead of just declaring it bad.
  • Another camp describes gdb as buggy, slow, with poor code quality and a terrible machine interface (MI), causing frontends to “suck” too; some report frequent segfaults and years-old bugs they must patch themselves.
  • LLDB is seen as somewhat better in places but also buggy (e.g., SIGINT handling quirks) and slow on large projects.

Linux debugging infrastructure

  • Several note Linux itself is a big part of the problem: ptrace is called a “horribly stupid” API that composes badly with perf, eBPF, etc., and multithreaded support is painful.
  • Comparisons are made to other OSes (e.g., Fuchsia) that have cleaner, handle-based process control; Linux is criticized as an accretion of features with poor composability.

Design choices: Zig, library, hackability

  • The Zig choice interests people, but a side thread debates Zig vs Rust for kernels; consensus there is that Rust’s stronger static guarantees make it a better fit for kernel code, Zig for user space.
  • Many like the goal of building the debugger as a reusable library, contrasting it with gdb’s difficulty as an embeddable component.
  • “Hackability” is praised: small, composable, scriptable components are seen as crucial for long-term maintainability and ecosystem growth.

Desired features and missing pieces

  • Better UI/UX:
    • GUI or rich TUI that doesn’t get “smashed” by program output.
    • Good visualization of large collections (arrays, text, tables) with scrolling and filtering, something users miss from older tools.
    • Easy skipping of library/boilerplate frames (e.g., stdlib, #[derive(Debug)]), and better control over what to step into.
  • Advanced breakpoint behavior: time-based breakpoints (e.g., “only break after N seconds”), robust conditional breakpoints, and reliable tab-completion without lockups.
  • Mixed-language debugging: some argue that ruling out non-native languages is short-sighted; they really want first-class Python + C/C++ debugging in the same process and unified call stacks.
  • Remote / programmable control: people ask for socket-based or protocol-based control (similar to gdb’s remote protocol or DAP), and even suggest reusing browser devtools protocols.

Comparisons to other tools

  • Other debuggers mentioned:
    • raddebugger/raddbg (Windows-only but planning Linux), TotalView, Linaro DDT (proprietary), WinDbg/Visual Studio (often cited as much better UX than gdb).
    • rr and Undo for time-travel debugging; discussion covers their single-core execution model, “chaos mode” / thread fuzzing, and limitations for extremely timing-sensitive races.
  • Some argue time spent criticizing gdb/lldb would be better invested in building an obviously better alternative; others insist clear, concrete criticism is important if you publicly claim existing tools “suck.”