I’m currently developing on Windows mainly, but due to the end of life of Windows 10, I might switch my primary OS to Linux instead. However, despite Linux being called “developer friendly” I always preferred the tools available under Windows save for the command line shell of Linux.

My main gripes with Linux development is with the debuggers. On Windows, I have RemedyBG, a pretty good debugger with an easy to use GUI. On Linux, all I have is either GDB or LLDB, and a command line so far.

I looked into some of the “more mainstream” GUI options for Linux, all of them were just a separate tab for the same command line debugger in a text editor.

Please note that I’m the sole developer of my projects on the side of a full time job, so I don’t have 1 month to spare to learn the in and outs of GDB, which in the days of useless AI slop articles littering the internet, might be even 1.5-2 months. I have a modern PC, any performance gains from not having a well-optimized GUI is negligible. No, I don’t care about scripts. And no, unless I’m actually writing the code, the mouse is faster, not slower.

  • @[email protected]
    14•7 hours ago

    As I assume you’re not looking for FOSS-only solutions, you probably want to go with Jetbrains IDEs (IntelliJ). They are arguably the best IDEs around and have native Linux versions.

    I assume you are mostly working with C/C++. I don’t have first experience with CLion but haven’t heard anything negative about it.

  • @[email protected]English
    3•6 hours ago

    I use gdb myself.

    I don’t know exactly what you’re after. From the above, I see:

    “easy to use”

    " the mouse is faster, not slower"

    You don’t specify a language, so I’m assuming you’re looking for something low-level.

    You don’t specify an editor, so I’m assuming that you want something stand-alone, not integrated with an editor.

    There are a number of packages that use gdb internally, but put some kind of visualization on it. I’ve used emacs’s before, though I’m not particularly married to it — mainly found it interesting as a way to rapidly move up and down frames in a stack — but I’m assuming that if you want something quick to learn, you’re not looking for emacs either.

    Maybe seer? That’d be a stand-alone frontend on gdb with a GUI. Haven’t used it myself.

    EDIT: WRT gdb, the major alternative that I can think of to gdb is dbx, and that’s also a CLI tool and looks dead these days. gdb is pretty dominant, so if you want something mouse-oriented, you’re probably going to have some form of frontend on gdb.

    There are other important debugging tools out there, stuff like valgrind, but in terms of a tool to halt and step through a program, view variables, etc, you’re most-likely looking at gdb, one way or another, unless you’re working in some sort of high-level language that has its own debugger. If you want a GUI interface, it’s probably going to be some sort of frontend to gdb.

    EDIT2: Huh. Apparently llvm has its own debugger, lldb. Haven’t used it, and it’s probably not what you want anyway, since it’s also a CLI-based debugger. I am also sure that it has far fewer users than gdb. But just for completeness…guess you already looked at that, mentioned it in your comment.

  • secretspecterEnglish
    1•5 hours ago

    Emacs is a crazy good GUI debugger I’ve heard but I’ve been invested in Neovim for years

  • @[email protected]
    1•6 hours ago

    It’s fine to want a gui debugger and I want to clarify that I’m not actually trying to persuade you to use gdb! My actual advice would be vscode (or other ide) with it’s gdb/lldb integration which allows you to debug from your ide in a gui-oriented way.

    I do however think that you’re wrong about how hard it is to learn gdb. I learned to use it not that long ago and it doesn’t take “1 month”. Using gdb on a basic level is actually not particularly hard, and I can recommend this talk for anyone actually curious about learning gdb. It’s just 15 minutes, but the same speaker has done a couple of other talks on the same theme that are longer if you want to learn even more, you can probably find them in the recommended videos sidebar.

    What I actually think is the case is that learning gdb takes a bit more mental effort because it’s a different paradigm than normal gui editors, and a lot of things aren’t intuitive. If you’re prepared to be a bit uncomfortable and lost for an afternoon, and maybe even flip through the official document for a bit you can be “good enough” at gdb in less than a day.

    Gdb is also more powerful than most gui-only editors, because you can do scripting in gdb. For example you can execute an arbitrary series of gdb commands when you hit a certain breakpoint which can be really useful in some circumstances. My preferred way of debugging in linux is actually to both have a gdb window that I can enter commands in so I can do more scripting stuff if I want to, and also some extra bells and whistles for viewing source code and setting breakpoints etc. I edit in vim so I use the termdebug plugin that comes bundled with vim, but use whatever exists for your editor if you don’t use vim yourself.