To be fair, .NET only recently got AOT compilation and single binary (or self-contained) deployments as officially supported features.

If you target the classic .NET Framework on Windows, you could just ship a single folder for a long time The .NET Framework is shipped with Windows (though not necessarily at the latest version), and the deployment strategy for your average desktop/console app is just "copy the entire bin folder".

That's true. Single file deployments were also supported in .NET Framework, only a bit obscure by registering a callback for the assembly loader and explicitly bundling every dependency as a resource in the build process.

C# doesn’t really have an equivalent for Go’s channels syntax though.

Also, Go doesn’t have inheritance, but does have interface forwarding and structural (as opposed to nominative) type-system - those both very significant factors that influence final program design.

.NET has channels as part of the standard library.

In C# you must write explicit async/await keywords whereas in Go it is implicit, but the code reads almost the same.

I would argue against using implementation inheritance generally and interfaces sparingly in C# anyways.

Being not super familiar with Go, I think C#'s async/await is similar, isn't it? If you want more complex operations, you might want to look into System.IO.Pipelines.

Nah, totally different than channels. And Goroutines are proper managed threads with their own stacks.

As an aside pipelines are terriblely unergonomic. The public APIs are not fully developed and something simple, like IDK creating an actual processing pipeline, is funky as all hell. Creating a pipe wrapper feels dirty.

The buffer management is cool though and sequence seems like it should have just been made a first class slice type..

.NET’s Pipeline type is not intended for processing-pipelines (surely that would be Windows Workflow Foundation and SSIS?) - it’s meant to be an alternative (and performance-optimised) API for reading and writing to IO streams without faffing around with the differences between MemoryStream, FileStream, and NetworkStream - like if you’re implementing your own network protocol server and client.

See https://learn.microsoft.com/en-us/dotnet/standard/io/pipelin...

The main problem it seems to solve is processing a text or byte range from a stream (be it an endless SSE/WebSocket stream of messages, or just from a huge (multigigabyte+) file on disk - in a non-blocking/async manner.

C# has channels as a library and not a language construct, it lives in System.Threading.Channels namespace.

They do have channels but they don't supply a select equivalent.

Go literally has a Channel class with the same functionality. The major difference is async/await syntax vs goroutine syntax, no?

MSBuild is actually really nice, haha. I wish Gradle was that simple.

How so? Linux is a first class citizen in .NET these days.

A first class citzen would have support for MAUI, and something better than VSCode like macOS gets VS4Mac.

JetBrains Rider is available for Windows, Linux, and macOS, and it's much better than VS, VS for Mac, and VSCode.

It's not free, but VS isn't either for any serious commercial usage, and Rider is certainly worth the money.

What does the company that owns Java offer? Their Java IDE is https://en.wikipedia.org/wiki/JDeveloper and nobody uses that. The latest release came out in 2019. Everyone is using IntelliJ IDEA or perhaps Eclipse.

What does the Python core community offer? IDLE is ugly, is barely an IDE, and didn’t have line numbers until a few years ago. Everyone is using PyCharm or VSCode.

IBM also makes Java, it offers Eclipse.

Sun made Java, it offered Netbeans.

As for the Python community, no one expects great tooling from FOSS languages, as you mention everyone is using tooling from two big corporations.

NetBeans is also still going, although I don't think it has many users.

Does Java even have a MAUI equivalent? There are other open source frameworks for GUI apps. This feels like goal post shifting.

The point is cross-platformness and windows does have MAUI, so not having it on linux means it is not a first-class target.

MAUI is just another workload of the dotnet ecosystem. There is no technical reason for it not to work on Linux outside of someone actually doing so. This has nothing to do with C# at all.

You don’t become a first class citizen overnight. Also, last time I checked .NET lacks something as trivial as an open-source debugger.

It's been many moons, also there is an OSS debugger produced by Samsung.

Except for all ui-only windows-only stuff.

Not really true.

...but the .NET runtime has a higher memory floor. It's a lot easier to write very small apps in Go. New versions are working on stripping in AOT builds but it's still very much a work in progress