-
netcoredbg
NetCoreDbg is a managed code debugger with GDB/MI, VSCode DAP and CLI interfaces for CoreCLR.
> 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.
-
Stream
Stream - Scalable APIs for Chat, Feeds, Moderation, & Video. Stream helps developers build engaging apps that scale to millions with performant and flexible Chat, Feeds, Moderation, and Video APIs and SDKs powered by a global edge network and enterprise-grade infrastructure.
-
Correct, granted it's more complicated than "clients". At least Node.js (Neon), Python (PyO3), and Ruby (rb-sys/magnus) have nice supported bridge wrappers. The .NET-to-Rust interfacing in the Temporal .NET SDK required pure C FFI and P/Invoke and being careful about GC and lifetimes during interop. Can see the bridge at https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo....
I can say with regards to panics, .NET is very nice to wrap Rust panics into `SEHException` classes (though of course we strive to be completely panic free).
-
Before Rich made Clojure for the JVM, he wrote dotLisp[1] for the CLR. Not long after Clojure was JVM hosted, it was also CLR hosted[2]. One of my first experiences with ML was F#[3], a ML variant that targets the CLR. These all predate the MIT licensed .net, but prior to that there was mono, which was also MIT licensed.
1: https://dotlisp.sourceforge.net/dotlisp.htm
2: https://github.com/clojure/clojure-clr
3: https://fsharp.org/
-
Before Rich made Clojure for the JVM, he wrote dotLisp[1] for the CLR. Not long after Clojure was JVM hosted, it was also CLR hosted[2]. One of my first experiences with ML was F#[3], a ML variant that targets the CLR. These all predate the MIT licensed .net, but prior to that there was mono, which was also MIT licensed.
1: https://dotlisp.sourceforge.net/dotlisp.htm
2: https://github.com/clojure/clojure-clr
3: https://fsharp.org/
-
-
Give this tool a try: https://github.com/dotnet/ClangSharp?tab=readme-ov-file#gene...
Just specify the headers to generate bindings for, and then use the generated interop code. Not too different from importing header file(s) effectively.
-
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
Unfortunately there is no short answer to this. But the main gist is that improving this to take advantage of all the underlying type system and compiler features would require a new API for LINQ, improvements for generic signature inference in C# (and possibly Rust-like associated types support), and introducing a similar new API to replace regular delegates, used by lambdas, anonymous functions, etc. with "value delegates" dispatched by generic argument to methods accepting them, with possibly a lifetime restriction of 'allows ref struct' which is a new feature that clarifies that a T may be a ref struct and is not allowed to be boxed, as it can contain stack references or references to a scope that would be violated by such operation.
There have been many projects to improve this like https://github.com/dubiousconst282/DistIL and community libraries that reimplement LINQ with structs and full monomorphization, but the nature of most projects written in C# means their developers usually are not interested or do not need the zero-cost-like abstractions, which limits the adoption, and for C# itself it would need to evolve, and willingly accept a complete copy of existing APIs in LINQ with new semantics, which is considered, and I agree, a bad tradeoff where the simpler cases can be eventually handled through compiler improvements, especially now that escape analysis is back on the menu.
Which is why, in order to "properly" provide Rust-like cost model of abstractions as the first-class citizen, only a new language that targets .NET would be able to do so. Alternatively, F# too has more leeway in what it compiles its inferred types to, but its a small team and as a language F# has different priorities as far as I know.
-
> 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, DebuggerView and DebuggerDisplay are there for a reason, and I don't understand the case for not using a debugger. And when you do insert WriteLines, or logger writes, there are many tools to make the output pretty. Making a simple extension method that will do indented JsonSerializer.Serialize is already a start. Records also come with default ToString implementation.
-
> 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, DebuggerView and DebuggerDisplay are there for a reason, and I don't understand the case for not using a debugger. And when you do insert WriteLines, or logger writes, there are many tools to make the output pretty. Making a simple extension method that will do indented JsonSerializer.Serialize is already a start. Records also come with default ToString implementation.
-
dotnet-cursor-debugging-with-brea
Discontinued [GET https://api.github.com/repos/dgokcin/dotnet-cursor-debugging-with-brea: 404 - Not Found // See: https://docs.github.com/rest/repos/repos#get-a-repository]
> 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, DebuggerView and DebuggerDisplay are there for a reason, and I don't understand the case for not using a debugger. And when you do insert WriteLines, or logger writes, there are many tools to make the output pretty. Making a simple extension method that will do indented JsonSerializer.Serialize is already a start. Records also come with default ToString implementation.
Related posts
-
Rust to .NET compiler – Progress update
-
Introducing csharp 10 — top-level namespaces, global imports, lambda improvements, struct records, and more
-
Towards Sub-100ms Latency Stream Processing with an S3-Based Architecture
-
Why Developers Are Switching to Rust: The Rise of Rust Development in 2025
-
Rust Cargo: The Backbone of Rust Development