Appreciation for TUIs and Enhanced Debugging Experiences
Many commenters expressed a general appreciation for Text-based User Interfaces (TUIs) and a desire for better debugging tools. The original post sparked interest due to its focus on features that enhance the debugging experience, particularly asynchronous operations and progress bars. dec0dedab0de says: "I don't work with anything that would need this, but I love TUIs so I checked it out and saw this bit...I wish this were more common, especially the progress bars thing."
Conscat supports the need for process bars saying at their "previous job, the product I worked on would open something like 200 DLL plugins on start-up. This would basically hang GDB while it's indexing the DWARF symbols, but LLDB gives you a very nice asynchronous progress indicator for that."
Nostalgia for Past Debugging Tools
Some users reminisced about older debugging tools, particularly CodeView, and found the new tool reminiscent of those older, simpler interfaces, while expressing dissatisfaction with more complex alternatives. As trollbridge puts it: "Awesome work. Reminds me of CodeView back in the day, which I've been wishing I could have back since, and no, a gigantic pile of Emacs or vim plugins is not the equivalent."
Specific Use Cases and Feature Requests
Several commenters mentioned specific use cases they had in mind for the debugger, particularly for remote debugging and Python. These users also specified features, especially regarding configurability and terminal resizing, that are important to them. jebarker states: "This is nice. I want something like this for python that I can use on remote servers and compute nodes of clusters. I've tried pudb but I find it doesn't behave well with terminal resizing and I wish the interface was a little more configurable." jebarker also says, "I should force myself to live with it for a week and see if I get more comfortable. One face of it it certainly does everything I currently rely on vscode remote for"
Binary Size and Debug Information
The discussion touched upon the large size of the ClickHouse binary, which was used as an example in the debugger's README. Commenters explained potential causes for the large size, including the use of C++ templates, generated code, and extensive debug information. PhilipRoman jokingly says: "#include <iostream>" mmoskal claims: "Very typical for anything with CUDA (they tend to compile everything for 10 different architectures times hundreds of template kernel parameters).
Not sure about ClickHouse though." mrazomor agrees that "Heavy use of C++ templates can significantly increase the binary size. Same for the heavy use of generated code (e.g. protocol buffers etc.)." zX41ZdbW then provides a link to an embedded binary viewer showing that "only about 500 MB of machine code, and the rest of the gigabytes are debug info."
Debugging Development Experience
One commenter highlighted the need for improvement in the debugging development experience and expressed hope that tools like this debugger can help bridge the gap. dvektor says, "Very cool! I have been using LLDB quite a bit lately so I am eager to try this out. The state of debuggers dev experience really hasn't caught up to what things like Cargo have done for build systems, so I am glad to see people working on things like this."
Resources for Writing Debuggers
Several commenters provided resources for those interested in learning how to write debuggers, including tutorials and books. hippospark lists several good resources saying: "For those interested in writing a debugger...There are a series of tutorials on how to write a debugger from scratch for Windows x86-64 using Rust [1]. Additionally, there is a book titled 'Building a Debugger - Write a Native x64 Debugger From Scratch' by Sy Brand [2]."
Installation and Package Management
Some users raised concerns about the lack of package manager support and the use of curl | bash for installation, citing security reasons.
colesantiago asks: "How does one install this? I don't want to go through the curl | bash either for security reasons. It would be nice to have some package manager support, but it looks cool."
laserbeam responded to Colesantiago by saying: "There’s only 1 artifact. A static executable. No “need” for a package manager. If someone builds a package manager they would just need to compile the src and ship the executable. All you need to do otherwise is add it in PATH."
Alternatives and Existing Tools
Some commenters mentioned existing debugging tools, such as GDB and cgdb, and compared them to the new tool. philsnow makes the point that "GDB already has a TUI.. it's pretty "vintage" though. I looked at the screenshot at the top of the repo README and it looks like it has a lot more creature comforts (read: any at all compared to GDB)." mbeavitt gives an alternative saying to "check out cgdb - ncurses based gdb tui, with vim bindings. It's no longer actively worked on, but is decently maintained with bugfixes etc AFAIK."