Comment by neonsunset | Hacker News Reader

Comment by neonsunset | Hacker News Reader

Parent Full thread

These events predate .NET Core 3.1, which what I consider the baseline where "the new" .NET gotten good enough for businesses to migrate to. Before that there was a lot of uncertainty, breaking changes and culture shock, the echo of which is still felt to this day. Nonetheless, this holds little influence on the state of affairs in the last few versions, certainly since .NET 5, which, if I understand your first reply correctly, is the criticism in question.

Would you like to put it against Go for lacking package manager, Java for being stuck on version 8 or Rust for not having stable language server? /s

Or, to phrase it differently, "this is an issue" - "it was an issue in 2018" - "no, you don't get it, it's a valid criticism because nothing can ever be improved". You see how flawed this argument is?

I'm so tired of these low effort replies here that it's just sad, in technical conversations in other contexts I'd equally defend another language when someone blatantly misconstrues the facts. I don't have a horse in this race at this point, it's simply annoying to try to converse productively when the quality of replies is this low. I should probably spend time elsewhere.

The difference is that it's still an issue in 2024.

It's not. Base C# extension for VS Code is free and MIT[0], the closed component, that is a debugger, is free as well. There is an open-source alternative too, and what effectively all debugger implementations do is integrate with debugger API provided by .NET itself, which any new tool can hook into. At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability.

[0]: https://github.com/dotnet/vscode-csharp (this is _not_ DevKit, which is optional, the actual language support like Roslyn language server is part of the base extension, and you really don't need DevKit which has "extra VS-style accommodations" most of which can be done with different extensions, if that's what you want)

> the closed component, that is a debugger, is free as well.

Iff you use Microsoft's builds of VS Code. Just like back in 2018.

> At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability.

So... still useless for the rest of us.

> So... still useless for the rest of us.

Why? How does the situation look in Java?

It also seems you have not read the original reply. So to reiterate, there is https://github.com/Samsung/netcoredbg too.

In any case, I assume none of this has any use to you and the reply is posted simply as bad faith engagement, as it continues to happen whenever a piece of software that uses .NET is mentioned, because usually very few people within community have/take issue with the current (rich) tooling options.

Note how many comments here and in similar submissions completely ignore the topic at hand and instead try to criticize the points that their authors assume are an issue with .NET itself.

> Why? How does the situation look in Java?

jdb is part of OpenJDK, and doesn't try to implement any such restrictions. Neither does gdb, for that matter.

But there is also a cultural difference. .NET libraries (including the standard library) are notoriously poor at implementing useful .ToString() overrides, because it's all designed to assume that you will use a debugger.

For comparison, Scala and Rust have cultures that emphasize printf-friendliness, and I rarely have to reach for a debugger at all. The difference it makes for my sanity is immense (as someone who wasted years on the shitshow that is .NET).

> It also seems you have not read the original reply. So to reiterate, there is https://github.com/Samsung/netcoredbg too.

I spent way too long trying to get netcoredbg to work, and couldn't get it to do much of anything. Maybe it's less of a shitshow now? Given that your original reply wasn't "yeah nobody uses the MS debugger anyway", I somehow doubt it.

> and the reply is posted simply as bad faith engagement

I mostly get annoyed when I see bad faith arguments that old problems are irrelevant because they're old, even if the problem has never actually been addressed.

> I spent way too long trying to get netcoredbg to work, and couldn't get it to do much of anything. Maybe it's less of a shitshow now? Given that your original reply wasn't "yeah nobody uses the MS debugger anyway", I somehow doubt it.

This got me curious. Turns out there exists an actively maintained fork of the official C# extension that comes with NetCoreDbg instead: https://github.com/muhammadsammy/free-vscode-csharp

I was able to successfully debug simple async code with it after installing the vsix, disabling the official one and restarting VS Code without changing any other settings.

So, for the trivial case it works. Submitted issues do indicate further compatibility problems like not supporting "Debug.Write*" methods (just use a logger or Console.Write* I guess?) or instability when bridging this extension to something that isn't VS Code.

Still, someone even managed to get it to work with Cursor: https://github.com/dgokcin/dotnet-cursor-debugging-with-brea...

> For comparison, Scala and Rust have cultures that emphasize printf-friendliness, and I rarely have to reach for a debugger at all. The difference it makes for my sanity is immense (as someone who wasted years on the shitshow that is .NET).

This is the first time I hear someone tout print-based debugging as an advantage. The approach F# takes with printfn "%A" might be more to your taste. Otherwise, DebuggerDisplay and DebuggerTypeProxy are there for a reason, and I don't understand the case for not using a debugger. But if you really want to, there are many ways to make the output pretty. Making a simple '.Print()' extension method that will do indented JsonSerializer.Serialize is already a start. Records also come with default ToString implementation.

A great example of moving the goalpost post-hoc.

Reply on news.ycombinator.com