
RemedyBG: Replacing the Visual Studio Debugger - noch
https://remedybg.handmade.network
======
int_19h
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/](https://microsoft.github.io/debug-adapter-protocol/)

~~~
jpfr
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...](https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html)

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

~~~
int_19h
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...](https://kichwacoders.com/2017/08/02/gdbs-mi-is-not-a-debug-
protocol/)

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...](https://microsoft.github.io/debug-adapter-
protocol/implementors/adapters/)

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

[https://microsoft.github.io/debug-adapter-
protocol/implement...](https://microsoft.github.io/debug-adapter-
protocol/implementors/tools/)

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.

------
gmueckl
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.

~~~
joeld42
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.

~~~
WalterGR
_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.

~~~
mattnewport
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.

~~~
gmueckl
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)

~~~
mattnewport
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.

------
strmpnk
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.

------
malkia
Seems like it's using Dear IMGUI

~~~
taspeotis
This is confirmed by the author:

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

