free-vscode-csharp VS clojure

The debugger is proprietary but still works cross-platform. I don't know how Jetbrains does C# debugging in Rider exactly, but that shows that you don't have to use VS (Code) to do C# development if you don't want to.

Thanks to Samsung of all companies, there's an open source C# debugger on GitHub (https://github.com/Samsung/netcoredbg). That seems to be the basis of the open source C# extension's debugging capabilities: https://open-vsx.org/extension/muhammad-sammy/csharp

The VSCodium C# community wants Microsoft to open source their debugger instead of having to maintain an open source version themselves, but that doesn't mean you need to use Microsoft's open source version. If anything, this forceful separation makes it so that there never will be only one implementation (like there is for languages like Rust which have always been open and therefore only have one way of doing things).

If you don't like XAML, you can use https://github.com/AvaloniaUI/Avalonia.Markup.Declarative to write declarative SwiftUI-like code. You can also use F# if that's your cup of tea: https://github.com/fsprojects/Avalonia.FuncUI.

If you prefer GTK, there are rich GObject bindings that are a successor to GTK#: https://gircore.github.io/

Here are samples that demonstrate basic GTK4 usage scenarios: https://github.com/gircore/gir.core/tree/main/src/Samples/Gt...

All this should require less than 10 minutes including setup and such.

Lastly, I want to make a disclaimer that you do not need C# Dev Kit extension for VS Code, only the base C# one, which is what gives you language server, debugger, etc. If you are using VSCodium which cannot use closed-source vsdbg component that the base extension uses, you can replace it with https://github.com/muhammadsammy/free-vscode-csharp which uses open-source debugger from Samsung instead. It can be rough around the edges but works well enough in standard scenarios. Just don't use Debugger.WriteLine over Console. :D

C# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) - this is what the base C# extension[1] uses. Both of these are licensed under MIT.

The only closed-source component is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].

[0]: https://github.com/dotnet/roslyn/tree/main/src/LanguageServe...

[1]: https://github.com/dotnet/vscode-csharp

[2]: https://github.com/muhammadsammy/free-vscode-csharp

> 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 only tried F# for few days, but it was a pleasant experience on both macos and linux.

dotnet CLI should take care of build process, it can even generate self-sufficient executable (that bundle parts of .NET in them). The infamous required XML boilerplate has also been cut down to near-zero.

My biggest gripe is that Microsoft's debugger is closed-source and proprietary (though free for users of official VSCode builds). There is open-source netcoredbg by Samsung, so you can use VSCod[e,ium] with https://open-vsx.org/extension/muhammad-sammy/csharp , but YMMV.

When looking into C# tools though, my understanding is that the main debugging tool is under a proprietary MS license, although maybe I'm misunderstanding that. My question is, is there a FOSS debugger or tool kit for C# development? I did find this on the marketplace but am not sure if this is what I'm looking for. I know this is a bit of a niche case but was hoping to clarify. I'm not committed to VSCodium and am open to other text editors/IDEs, although would prefer to stick with it if possible.

My understanding is that I can install VSCodium and that they have many of the most popular extensions available. They even seem to have an alternative for the C# debugger. I could also use VSCodium and manually install the Microsoft extensions from the distributed VSX files.

and there is a VSCode extension that uses this instead of the MS debugger

https://open-vsx.org/extension/muhammad-sammy/csharp

Oversimplifying, there are three big variants: Common Lisp, Scheme, Clojure. Each of them has a lot of somewhat similar implementations:

* Clojure: A lot of support for immutable data. It runs in the JVM so you will have a lot of the libraries you are use to. Probably the best option for you. https://clojure.org/

* Scheme, in particular Racket: Mostly functional, and in particular Racket has a lot of support to make your own variant. This is the option I prefer but I have to disclaim it's a biased recommendation. https://racket-lang.org/

* Common Lisp: I heard a lot of good things about SBCL, in particular to add anotations to make the code faster https://www.sbcl.org/

> why this language is so special

Macros, everyone use macros, too many at the beginning, but a few where they are really necessary later.

  #lang racket

Another project of mine Bob can be seen as an example of spec-first design. All its tooling follow that idea and its CLI inspired Climate. A lot of Bob uses Clojure a language that I cherish and who's ideas make me think better in every other place too.

Glojure author here! Your analysis is spot-on :). I'll definitely take a look at clojure.core-test. As components mature, I focus on improving compatibility by porting tests from Clojure [0], but they often require modifications to accommodate differences in the host language. As you noted, there are still several fundamental features missing — most notably some core data structures. That said, the implementation is robust enough to support another non-trivial hobby project [1].

A bit more detail on some of your observations:

> No JIT or AOT compilation (right now).

I do plan to implement AOT compilation eventually. JIT, however, is more complex. Go's "plugin" standard library [2] could serve as a mechanism, but its support is limited and not without issues [3].

> it looks like the analysis could be largely a port of tools.analyzer

Exactly! Another key implementation strategy has been the handling of clojure.core. Instead of reimplementing everything from scratch, the Clojure 1.11 core libraries are programmatically transformed to work with Go [4]. However, this approach has its downsides — many functions appear to be available but are non-functional because parts of their implementation haven't yet been adapted.

And by the way, impressive progress on Jank! I've been following it closely and really admire the work you're doing.

[0] https://github.com/clojure/clojure/tree/master/test/clojure/...

Clojure is a LISP for the Java Virtual Machine (JVM). As a schemer, I wondered if I should give Clojure a go professionally. After all, I enjoy Rich Hickey's talks and even Uncle Bob is a Clojure fan. So I considered strength and weaknesses from my point of view:

Clojure

Here's what I mean by Malli's inability to check macros.

https://github.com/clojure/clojure/blob/ad54fec/src/jvm/cloj...

clojure.spec has a privileged spot in the compiler so that it can validate the data in macros. No other library can do this, because the Clojure compiler directly calls into clojure.spec and does not expose any sort of hook for validating macros.