RemedyBG: Replacing the Visual Studio Debugger | Hacker News Reader

RemedyBG: Replacing the Visual Studio Debugger

remedybg.handmade.network

55 pointsnoch35 comments

It would be nice to make it talk the VS debug adapter protocol. Then you could ironically use it in VS and VS Code, and non-ironically, in any editor that chooses to support that. Given how quickly LSP took off, I would expect there to be a few eventually.

https://microsoft.github.io/debug-adapter-protocol/

GDB can be driven remotely since a long time.

Emacs and Eclipse both integrate GDB via the MI interface. LLDB supports it as well. https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI...

What is the advantage of the debug adapter protocol against the existing debugger--editor integration protocols?

Mainly that DAP was designed as such from the get go, with multiple implementations for many very different languages being one of the driving assumptions behind its design.

MI, on the other hand, was originally just an API to use gdb programmatically, and was later repurposed by others simply because it was already implemented by other tooling, dealing with its gdb-specific idiosyncrasies being the path of least resistance.

https://kichwacoders.com/2017/08/02/gdbs-mi-is-not-a-debug-p...

As a consequence, DAP is much easier to work with from the IDE side, and it's easier to implement an adapter, as well. Looking at this table - even ignoring all the Microsoft-made ones - how many of the languages listed have a MI debugger implementation?

https://microsoft.github.io/debug-adapter-protocol/implement...

On the tooling side, Emacs and Eclipse are both covered:

https://microsoft.github.io/debug-adapter-protocol/implement...

Still, for native debugging specifically, it's a good point that on the IDE side, MI is currently better supported. So implementing that first would make more sense in terms of lighting up more IDEs, at the price of a somewhat more complex implementation. DAP can be implemented on top of MI - this is exactly what the VSCode C++ debug adapter does.

Why would you want to avoid the Visual Studio debugger? Can anyone enlighten me? I personally haven't encountered a better debugger yet, so I'm puzzled.

I guess that the author started it to avoid relying on the IDE to be able to debug anything. He says that Visual Studio gets to use about 80% of the debug info available in the debugging files, I am curious to see what that 20% extra is about.

That’s not quite what they wrote.

I, for one, fully support the handmade philosophy: RemedyBG doesn't use any third-party libraries (x). This includes Window's own Debug Help Library (DbgHelp), Debugger Engine (DbgEng), or even a library for reading symbol files (PDBs). I played around with these libraries to judge their effectiveness. Yes, using them can get you 80% of the functionality you need very quickly but after that you are forever 20% away from sweetness. And besides, Visual Studio is using these libraries and the whole point was to get away from this beast!

Then later:

There are a lot of interesting features coming down the pipe after realizing the wealth of information that compiler emits (and that Visual Studio hides from us).

Visual Studio's base installation is quite large for one. The complexity of locating the visual studio installation path is also extra work compared to scripts which only need to call a single executable which you can put anywhere you want.

EDIT: Not sure why I got down-voted for this. It's straight from some of the folks I know who started using it. You may not like their reasoning but you can reply instead of bury.

That’s not a compelling reason at all.

Try using Windows with a 64 gig ssd. You run out of room really fast.

I have VS installed on 64 gig SSD. But if you're a developer, hardly you can't afford better.

You mean developer in a developed country.

I was a student part time dev in Russia 12 years ago, and I could easily afford the necessary storage and RAM.

RAM and SSD is currently suffering through supply chain issues across the board and companies keeping the price artifically inflated. it is super expensive to upgrade to the point where the ddr5 spec includes some ideas to mitigate cost issues

https://pcpartpicker.com/trends/internal-hard-drive/

My take is that the author doesn't have anything against the debugger per se, but rather it seems he prefers vim as a code editor. I've never used vim for C# but I've used it for other projects, and you do get spoiled by its responsiveness once you get it down.

So if you're in that workflow, it's a shame that for debugging you have to open up the beast, wait for it to load, wait while it figures out what .csproj files have changed, wait while it uses all your system RAM, wait while it notifies you about all the Azure plugin updates, wait while it thinks a little more about who knows what, just to start a debugging session. That's where having one tool that does one job great comes in handy.

Not to mention, it does seem like a great deep-dive project to learn about things. In my experience it's projects like these that really increase your dev skills. High-level tech like writing todo apps in a million different web frameworks doesn't.

If you are on Windows and are using VS for debugging, you should really rethink your workflow and consider using all of it and most importantly, launching it once and keep working in it. Launching it seperately for each new debugging session seems really foolish. Even just having it reload csproj files is faster than completely restarting it.

If the debugger is written just for the heck of it, I can totally get behind this reason. No amount of reading can replace practical experience.

That's the problem, ms is creating these amazing open source solutions and hitching the rotting carcass of visual studio to all of them.Even visual studio code is such a joy to use in comparison to even visual studio 2019.however you can't for some reason run solution based projects in code.i'm currently making xamarin apps and boy is it a fucking chore to do in visual studio to the point where the whole program crashes routinely in a normal workday(switching to flutter for this reason).

having an answer that would let me escape from the arcanities of visual studio in a corporate environment would be a joy

While I do use VS Code, I have not gotten it to a point where it is that much more than yet another text editor to me. I do a lot of work in C++ and C# and there VS proper is miles ahead in terms of coding and debugging support. Admittedly, this is partly also because of Resharper. But I do want all the annotations and refactorings and stuff offered by these tools because they speed my work up by a huge amount. I wish that I had access to the same kind of tooling on Linux. Eclipse has fallen behind somewhat. And I don't know any other IDE that comes as close.

Just because everything else is worse, doesn't mean visual studio couldn't be better.

I've been watching the development of this, here's their main points:

It's slow. Stepping through code and updating watches can take a few seconds. Which really does slow you down when you're doing a lot of work with it. It's ginormous, you shouldn't need a huge program with tons of dependencies to debug things. And finally, it's primitive. It usually works for what it does but it would be nice for a debugger to be more flexible and allow things like: Displaying blocks of memory as images, allowing custom display visualization, and navigation of your own data structures, or charting how a value changes over time. Debugger functionality has been pretty stagnant for at least a decade. Also plugging in project specific debugging tools like serialization and custom tools would be neat.

For slowness when single-stepping, turning off Intellitrace (if not required) and playing with the function/expression evaluation and symbol loading settings in Tools->Options can help with that, if you haven’t already.

It’s slow.

Do you use ReSharper?

It’s been a while since I used either ReSharper or Visual Studio, but I remember ReSharper being like lashing a half-ton Snap On tool chest to your car.

Yeah, I had to turn ReSharper off despite liking some of its features as it brings my monster development PC to its knees and is basically unusable due to its abysmal performance. It makes vanilla Visual Studio seem svelte and responsive by comparison.

How big is the project you are working on? Resharper qas a net productivity gain for me on moderately complex projects (the lag was more than compensated by the speed gained from the mode powerful editing and refactoring, let alone the lower barrier to start otherwise tedious refactoring jobs)

It's not huge. It's a Unity project and it's a couple of years of development with a team that has grown from just me to 4 programmers in that time so it's a decent size but there are much bigger Unity projects out there I'm sure.

Uhm... I get why you would want stuff like data visualizations on your debugger (I missed that enough times already), but which debugger has all of these features out of the box?

Also, VS is much more extensible than people tend to give it credit for. So even if the advanced debugging features are not avaiable out of the box, you can add them.

I am not a VS fan boy, but compared to the competition, there are some things where it is absolutely worth its money (in other cases, it isn't).

VS debugger supports custom display visualization already: https://docs.microsoft.com/en-us/visualstudio/debugger/creat...

If you think the watch is slow it's probably because one of the expressions you are trying to evaluate is slow (eg getters doing more computation behind the scenes than you think). If you just watch plain data it's blazing fast.

I personally like windbg more on windows. It's a light standalone tool not tied to a behemoth editor and build system. It's more command line oriented. Remote support is a bit more flexible. It's better at debugging without symbols too.

Some (all?) of windbg’s functionality is available within the VS debugger.

I don’t have VS handy right now; maybe someone else can weigh in...

Edit: On first glance, this looks informative: https://stackoverflow.com/questions/3438489/using-windbg-fro... . Be sure to read all the answers.

Analyzing kernel crash dumps comes tro my mind as a feature that seems windbg only.

vs debugger and windbg shares the same debugging engine but are geared towards different scenarios.

VS Only: rich extensions for languages. GUI debugging(wpf visualization etc.)

Windbg: kernel debugging (drivers etc). Scripting. Better command line interface. Fully expose sos. Dump corrupted heap objects. Better support for C++

The kernel debugger, ntsd and windbg share a debugging engine, and visual studio is a different one.

At higher levels, VS is a much nicer experience. If you ever need to get down to lower levels, especially windows libraries and services, the power of the ntsd/windbg engine and its extensions make it much more useful. Knowing it also helps when you eventually need to use KD.

Visual Studio is the best debugger right now, but it is also incredibly simple and primitive. In 2019 we should be able to program/scripts our debuggers in a million way. Dealing with large data sets in visual studio is still a pain. I want watches that can run queries to search for data, and reformat their display. I want to associate watches to functions or point in time etc.

The sky is the limit and I am sure someone could sit down and reinvent debuggers which basically haven't been evolving for decades.

Even though RemedyBG is in infancy and there's plenty of work ahead, it has the ability to surprise us tomorrow with features that haven't been in any other debuggers.

Also check out http://www.radgametools.com/debug.htm

RemedyBG is still very young but I'm impressed by the consistent progress. I don't think it will be replacing other debuggers for my needs quite yet but I'm happy to sponsor work like this. If you're on windows and work with native executables, consider giving it a shot.

Seems like it's using Dear IMGUI

This is confirmed by the author:

> Also, for the user interface, I am using Dear ImGui which has been a joy to use.

Reply on news.ycombinator.com