> side note: sad that .NET and C# are not considered "major
I've said it before on here, but the tech community severely underrates .NET today. It's not Windows only (and hasn't been for ~8 years) plus C# is a very nice language. F# is also an option for people who like functional languages. I'd highly recommend giving it a try if you haven't already.
.NET suffers from the long lasting reputational taint of Microsoft. It was seen as the sworn enemy of open source and Linux, and for good reason.
Today’s MS is not what it was back then. But long memories are not a bad thing, really. If .NET suffers a bit from some unfair perception, perhaps that can remind MS and others what happens when you take an aggressively adversarial approach.
VSCodium uses NetCoreDbg. There are community snippets to make the same work for Cursor, NeoVim, etc.
So far, there was little demand to write another debugger integration (because, really, the debugger core is implemented in the runtime itself - what vsdbg, NetCoreDbg and Rider all primarily do is consume the runtime API).
Yes, it is annoying. You can run VS Code on a PI and have an amazing Rust environment, or Zig, or any language. Except for .Net. Why MS? What is the benefit to your business to make .net suck without your closed sourced bits?
I'm baffled by insistent behavior like this. I think it is just alienating people and even if they move ecosystems, the negative impression will stay.
If you engage in bad faith behavior in a technical discussion, can you be expected to conduct yourself acceptably in a professional setting? Unlikely.
This is a discussion about HTTP/3 support of all things. Why does it happen only when someone leaves a briefly positive note on C#? I don't know any other language (besides PHP, to an extent) that gets the same amount of hate.
I edited it because it's not just my own experience of dealing with this. On twitter, I follow a couple Japanese developers from mainly gamedev scene and even they complain they started hearing more about "but it only works on windows" and "it's not open-source". Don't you find it strange that it should be the other way around the more years pass since .NET went OSS?
The link itself is also quite outdated and mainly consists of posts from Miguel de Icaza who's promoting Swift, arguably less OSS language. Take from that what you will.
You forgot to mention that Miguel de Icaza was probably the single biggest .NET fanboy for literally decades before throwing in the towel. The fact that a person like this ended up being alienated tells volumes.
I should also add that the general public only saw the tip of the iceberg in this entire episode. Miguel spent a lot of time and effort internally trying to right the .NET ship, gradually escalating through management until he finally gave up.
I don’t doubt this but the criticism has to be rooted in facts and the current state of affairs, and you have to consider conflict of interest. It’s not too different to what you can read here. No one ever talks about whether C# offers good cohesive experience when solving a specific task, or what are the pros and cons of its build system, or how a typical .NET team looks like in a particular region. No.
Instead, the complaints you will read here are about what the authors think .NET’s problems are without ever verifying if any of that is true in hopes of making swipes for god knows what reason, because posting something accurate requires knowledge on the subject and the results of a cursory search usually do not support cheap arguments.
(and I see this as an embarrassment because you can learn a lot from doing research instead of repeating the same tired phrases you heard elsewhere)
My point is that there was no "conflict of interest" when it comes to Miguel. If there was one person in the entire F/OSS ecosystem that ever wanted .NET to succeed, it was him. That is also why he spent so much time and effort trying to get Microsoft to not do things that alienate the community and harm .NET uptake.
Speaking for myself, I happen to like .NET from the technical perspective. While both the language and the stdlib have a lot of cruft from days of yore, it can mostly be ignored, and that aside it's a fast runtime with a decently expressive type system giving one considerable flexibility to pick the right tool to model different domains. It also has great tooling around it. But this all is separate from the question of how open .NET really is, and its long-term prospects in that department.
I don't think we can survive another rename haha. It doesn't seem to have helped PHP either. But we could use a newer .NET language with better lambda lowering, dependent types, HM type inference, structs as the default data type, improved lifetime analysis and different tradeoffs w.r.t now that we're going to have zero-cost-ish non-suspending async calls.
I assumed .NET is Windows-only and proprietary, too, but it has to do with me not having done enough research, so if it is not the case anymore, the blame is on me.
Hey, I just want to commend you for amending your perspective (even if a little). There's a lot of intellectual hoop jumping in this thread with respect to Microsoft.
One has to know what they don't know, or at least consider the possibility that they might not know the whole story. I did not know the whole story, but I do now, thanks to earlier comments with regarding to .NET!
Why hasn't Java been tainted the same since Oracle bought Sun and now 100% controls Java's development? I am continuously surprised to see they continue to make major investments in the platform. Project Valhalla was started in 2014 and is still going strong. I keep waiting for Oracle to cancel all major Java improvements, then milk the remaining corpse.
Me too! And yet it keeps going, with a reasonably open process, and multiple OSS alternatives out there. It is possible to run a Java shop with zero Oracle-derived code, which may be why people are ok with actually using the Oracle JDK.
My bet is this is a pitched battle inside Oracle, and the forces that keep it open have been winning...so far.
In my head, when I think Microsoft I think about the stress and anger I feel using Windows, and the OS-level notification I got apropos of nothing a few minutes ago trying to sell me an Xbox Game Pass subscription. The fear of what is going to break in the next forced update. For months now I haven't been able to do a task as simple as take a screenshot on my PC because seemingly the flash effect it plays gets caught in the image and the resulting screenshot has all the colors blown out, so it's mostly white.
So yes, this does color my opinion of how many ecosystems of theirs I want to tie myself too (minimal)
Yet, somehow DevOps and Visual Studio (proper) continue living as near zombies.
I would never have predicted Microsoft would still be developing a (sort of) Github competitor after acquiring Github. Why not plow all of that focus and energy into making Github the best project management system around? Project management in Github is one of the biggest gripes people have - even on Teams and Enterprise.
GitHub is behind ADO in multiple areas. Boards is the one they're furthest from ADO on; leaving that for last is letting them get the others to a state where ADO users can successfully migrate some of their work to GitHub now, even if the boards need to stay in ADO.
That said, Microsoft is never going to be able to completely kill Azure DevOps. If nothing else, they'll have to keep it alive for enterprise customers' TFVC source control history.
Surely there's a migration path to git from TFVC? Many large projects successfully moved from CVS and SVN into git.
I'm just surprised that, after 7 years of owning Github, Microsoft hasn't plowed their resources into Github's Projects. It's literally the number one complaint I see regarding project management inside Github - and would likely be an easy way to scale subscriptions for Teams and Enterprise. Heck, today it's still impossible to generate a Burn Down chart without using 3rd party "Apps" or the API.
The different branching approaches makes migrating history difficult. Microsoft's recommendation is to migrate just the tip, but will allow you to migrate up to 180 days of history for the trunk (no branches).
If you need branch history, or more than 180 days worth of history, the only option is third-party tooling (git-tfs). It seems to work good enough for development purposes (i.e. git blame)... but I'm not sure if it's good enough if we need the history for legal purposes.
VS code is mostly in house too. Sure, they don’t own Electron, but I was at MSFT when project Monaco (which became the basis for VS Code) was started and remember being very impressed by it back then
Text editors and IDEs come and go, there is very little commitment to using one.
If you write a project in C#, you've committed to it and it's ecosystem. Getting out of there when MS makes a choice you don't agree with is going to be near impossible.
In the case of GitHub, yeah. I don’t think a Microsoft source control “social network” would have taken off in the same way GitHub did.
In fact when Microsoft purchased GitHub, quite a few people did leave and close their account. But GitHub already had such a monumental market lead that the departures ended up being a drop in the ocean.
To be honest, I’m still waiting for the moment when Microsoft managed to fuck it all up like they did with Skype.
Don't forget prior to GitHub Microsoft ran the home-grown, TFS-enabled Codeplex. It worked quite well if using Visual Studio but obviously, like Skype, there was no reason to run it when "something better" came along.
You might be interested in GitHub's State of the Octoverse report from 2020 that had a section dedicated to security of popular languages, active open source projects on GH with those languages, and the package managers for those platforms.
except if you want to use for example system.windows.forms, then "oh well different teams maintain that, nobody made it for linux!!!" "the core is open!!!"
they clearly WANT applications written in .net not to be cross platform
It's not about different teams, it's that System.Windows.Forms is exactly what the namespace says. It's Windows Forms. It's a fairly thin wrapper over the Windows API. It's never going to be adapted to be cross-platform and isn't really something they've put any development work into for many years at this point.
If you want a cross platform UI, use WPF with Avalonia. Or if you want something entirely from Microsoft themselves, there's MAUI as an option.
> obviously system.windows.forms could easily be implemented elsewhere
It can, but not easily. As OP has said, it is a wrapper around Win32, and not an opaque one - it literally has stuff like e.g. the Message struct with members like HWnd and LParam.
Mono did try at one point, but they kept hitting edge cases where this kind of stuff would break things. Eventually they gave up and just wrapped Wine. So, yes, if you really really want to run WinForms on Linux, Mono is where it's at. But ... why?
well maybe because there exists countless gui applications that uses it, and furthermore, if you say its crossplatform, you cant say that with a straight face unless you also support gui? fact of the matter is, microsoft was perfectly happy to preach their .net shit as cross platform to try extend into non-windows usage, except for gui stuff, as thats "for windows"
We are talking about WinForms specifically. If you want crossplatform GUI, then don't write it in WinForms - write it in Gtk#, or Avalonia, or Uno, or ...
Note that C++, Rust, Go all don't have any kind of standard GUI support out of the box at all.
I'm amazed people are still using WinForms. When I was going around tables at a job fair in college, 13ish years ago, one of the questions for me from representatives for a large bank was about if I've used WPF. I said I don't use it, and they basically told me I should get with the times.
I haven’t developed with .NET in a dozen years, let alone since it went cross platform, but I at least know it is capable of being cross platform. It amazes me how many developers I speak to that still assume .NET is Windows only.
Because in the relevant distros it is included in the first-party feeds. Only Debian acts like a special snowflake making it needlessly complex for everyone (including Rust). I believe there is an ongoing work to modify .NET's full source build (i.e. https://github.com/dotnet/source-build) to satisfy Debian's admission requirements, but really it's a problem inflicted by Debian on themselves, not the other way around.
I’ve been a .Net developer since it launched, but recently I find myself using it less and less. I’m so much more productive with LLM assistance and they aren’t very good at C#. (Seriously, I thought AI coding was all exaggeration until I switched to Python and realized what the hype was all about, these language models are just so much more optimized for python)
Plus now Microsoft is being a bully when it comes to Cursor and the other VS Code forks, and won’t let the .net extensions work. I jumped through a lot of hoops but they keep finding ways to break it. I don’t want an adversarial relationship with my development stack.
I miss C# and I really don’t like Python as a language, but I don’t see myself doing a lot more C# in the future if these trends continue.
You can use VS Code and cursor at the same time. One to code and the other to compile the code. That's how I build for Android. I generate code in Cursor/Windsurf then I compile and deploy using Android Studio.
I work on .NET and work on Mac (hate the OS, but the hardware and battery life are way better).
Last startup, we shipped AWS t4g Arm64 and GCP x64 Linux containers. A few devs started on Windows (because of their preferred platform), but we all ended up on M1 MacBook Pros using a mix of Rider and VS Code.
Common misconception between old .NET Framework and new .NET # (e.g. .NET 9) (MS terrible naming). C#/.NET has been capable of cross platform binaries for close to a decade?
"Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL."
Now, you don't have to actually use AOT, the other deployment options are actually much easier to cross-build, but true cross build AOT is still not supported.
Native AOT compilation is definitely not the same as self-contained package. With that logic, every Docker container could be considered AOT compiled static executable.
An image or a container could be, yes. It isn't, because Docker stuff is mostly distributed as Dockerfiles and docker-compose files, and those cause your system to download and install stuff, and that part is not like self-contained package.
More that there are at least three different ways to deploy things in dotnet, and only AOT is directly equivalent to Go executables. I like dotnet and use it at work but this is a nuisance limitation for us.
The original question did ask about creating executables like Go, which means a single file you can run as is, so it was fair to mention AOT. For servers etc you usually don't want the AOT version, so then it doesn't matter which platform you develop on, but it's not always just like Go when you want to ship little applications.
The context of the thread is HTTP/3 servers; would it not make sense to take the comment in that context? Original article mentions that browsers (the client side) already supports HTTP/3 with the application server ecosystem being the missing piece.
Hi, I own the Native AOT compiler and self-contained compiler for .NET.
Self-contained will work fine because we precompile the runtime and libraries for all supported platforms.
Native AOT won't, because we rely on the system linker and native libraries. This is the same situation as for C++ and Rust. Unlike Go, which doesn't use anything from the system, we try to support interop with system libraries directly, and in particular rely on the system crypto libraries by default.
Unfortunately, the consequence of relying on system libraries is that you actually have to have a copy of the system libraries to link against them, and a linker that supports that. In practice, clang is actually a fine cross-linker for all these platforms, but acquiring the system libraries is an issue. None of the major OSes provide libraries in a way that would be easy to acquire and deliver to clang, and we don't want to get into the business of building and redistributing the libcs for all platforms (and then be responsible for bugs etc).
Note that if you use cgo and call any C code from Go you will end up in the same situation even for Go -- because then you need a copy of the target system libc and a suitable system linker.
If your code does not rely on native libraries, or you're fine with shipping multiple copies for different operating systems, a single build works everywhere with dotnet installed.
Or you can cross-compile and run without having dotnet on the target system, I do it from Linux to all three platforms all the time, it's pretty seamless. The application can be packaged into a single binary (similar to Go), or as a bunch of files which you can then then package up into a zip file.
JIT deployments do not care where they get built on. AOT deployments do because they use OS-provided linker to produce the final binary, much like C++ and Rust do (unless you use PublishAotCross nuget package which uses Zig toolchain to allow you to build Linux binaries from under Windows, I'm sure if someone's interested it could be extended further)
Also, if you want to have just a single binary, you want to do 'dotnet publish /p:PublishSingleFile=true /p:PublishTrimmed=true' instead. Self-contained build means it just ships everything needed to run in a folder without merging the assembly files or without trimming unreachable code and standard library components.
I'm a dabbler in Go, far from an expert. But I'm not familiar with a capability to use, say, native MacOS platform libraries from a go app that I'm compiling in Windows/Linux without using a VM of some sort to compile it. If that's possible I'd love to learn more.
Look at this garbage API that for no reason whatsoever mirrors winapi on posix for example.
Then after you painfully wrote your linux application despite all of that, you find out that .net is not included by any linux distribution, so have fun distributing your app!
I'm not sure why you are reading the docs sideways but just in case - C# has method overloading. Process API, while dated, simply offers multiple overloads suitable for different scenarios.
Launching a new process can be as easy as `Process.Start(path, args)`.
Although if you are doing this, I can recommend using CliWrap package instead which provides nicer UX. Anything is possible the second you stop looking for a strawman.
> you find out that .net is not included by any linux distribution
Would I? If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
Lastly - no one wants to put up with the maintainers with such attitude and you know well enough that "not included in any linux distribution" is both provably false and a non-factor - in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
Yeah I do have a life. I advice you to get one as well.
> Launching a new process can be as easy as `Process.Start(path, args);`.
-_-' Same exact problem. Letting every single process do their own escaping of the arguments. A proper portable API would have an array of strings for the arguments, to map execve(). That's how on windows every program does its own escaping and there's lots of programs doing it differently than others, but not how it works on posix.
Thanks for confirming you don't even comprehend the issue here. Crying "strawman!" won't help.
> If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
You can't do any GUI in .NET outside of windows and you know it fully well.
The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none. Please go ahead and misunderstand this sentence on purpose like you've been doing so far.
> in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
I guess ubuntu, debian, red hat do not matter? What's left? neonsunsetimaginarylinux?
Look, it is very difficult to hold a conversation with someone who responds with "you're just a fanboy, it's 5!" to "2 + 2 equals 4".
On the off chance you are making an intentionally inflammatory reply - you could also ask normally.
Let me try one last time (and now I vaguely remember having similar conversation here before).
On Ubuntu:
sudo apt install dotnet9
On RHEL (8 or 9):
sudo dnf install dotnet-sdk-9.0
On Alpine:
sudo apk add dotnet9-sdk
Then, you can get a simple cross-platform application template like this:
dotnet new install Avalonia.Templates && \
dotnet new avalonia.app -o AvaloniaExample && \
cd AvaloniaExample && \
dotnet publish -o build -p:PublishAot=true && \
./build/AvaloniaExample
The above can target: Linux, macOS, Windows, WASM and with some caveats Android and iOS (although I would not recommend using Avalonia for mobile devices over e.g. Flutter).
The build folder will contain the native application itself and the Skia dynamically linked dependency alongside it (and possibly some symbols you can delete). This is very similar to the way Qt applications are shipped.
This is just one GUI framework. There are other: Uno Platform, Gir.Core (GTK4 + GObject libraries), SDL2 via Silk.NET, Eto. I'm sure there's more.
What is bewildering is you could argue about "first-class" or "subpar", etc. But "does not work at all" is just ridiculous and indefensible. What kind of thought process leads to this conclusion?
In any case, I doubt you're going to read this since your replies seem to indicate interest in tilting at any windmill with ".NET" label on it instead, but at least my conscience is clear that I tried to explain this to the best of my ability.
Man.. All of these words did proof you were wrong.
> The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none.
This statement is false. It is also in arch. If it is not in debian and ubuntu, that is their fault. (But it would not surprise me, any user will soon run into the fact that even for non-obscure software there are no up-to-date packages in the main repo. The default escape hatch is to add extra repo sources, but my advice is to skip those distro's altogether anyways, unless you have very specific needs.)
But then again, if you think package management is a serious topic and then dismiss .net for the python mess, come on.
> the APIs are windows oriented?
The design of this particular API might be off. I guess this dates from the pivot to cross-platform. Usually, tuning for .net performance is better on Linux. I think nobody in MS believes in Windows as a platform really, it is a sinking ship.
It's not Windows only but it is Windows-first. Every few years I take a look but it still doesn't feel like a serious ecosystem for Linux development (in the same way that e.g. Perl might have a Windows release, but it doesn't feel really first-class). I can't think of a single .NET/C# program that people would typically run on Linux to even have the runtime installed, so no wonder people don't bother investigating the languages.
I don't think I've ever said it was good for all use cases and probably said to the contrary.
I write it very explicitly here[0]:
> Should you use C# for web front-ends?
>
> We're only considering backends here; I do not think that .NET-based front-ends (e.g. Blazor) are competitive in all use cases.
We are in a thread about...backend application servers.
Most of my side projects are TS/JS and run serverless Node.js functions on the BE[1]. I don't choose favorites; I choose the right one for the job.
C# has a strong high level feature set and lower level tools to keep performance up. The language itself is well designed and consistent. Its able to mix functional and OO features without being dogmatic, leading to better dev-x over all.
ASP is actually very good these days and feels cleaner than Spring Boot. There's less choice but the available choices are good. It has arguably the best gRPC implementation. It's just a nice experience over all.
Addendum: having `Expression`[0] type representing the expression tree is a really killer feature.
I've been doing a writeup comparing how ORMs work in TypeScript vs ORMs in .NET and one thing that is magical is that having the `Expression` type enables a much more functional and fluent experience with ORMs.
LINQ in EntityFramework certainly isn't perfect, but frankly it's so far ahead of anything else available in all other languages. It was a brilliant idea to add expressions type into the language AND to create a standard set of interfaces that enable collection interop AND to to then create universal clients for local and remote collections that use all this machinery to deliver first class DX.
Having been working in TS with Prisma for a bit, what stands out is how a Prisma query is effectively trying to express an expression tree in structural form
The difference being that the C# code is actually passing an expression tree and the code itself is not evaluated, allowing C# to read the code and convert it to SQL.
Proper macros operate on AST, which it to say, it is exactly like the Expression stuff in C#, except it can represent the entirety of the language instead of some subset of it (C# doesn't even fully support the entirety of System.Linq.Expressions - e.g. if you want LoopExpression, you have to spell the tree out explicitly itself).
Or you can do your own parsing, meaning that you can handle pretty much any syntax that can be lexed as Rust tokens. Which means that e.g. the C# LINQ syntactic sugar (from ... select ... where etc) can also be implemented as a macro. Or you could handle raw SQL and do typechecking on it.
Actually, the reason why they went with Go rather than C# is because they wanted to port the existing code as much as possible rather than rewriting from scratch. And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically.
> And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically.
Are there examples of this?
I ask because I've been working on a Nest.js backend in TS and it's remarkably similar to C# .NET Web APIs (controllers, classes, DI). Really curious to see the translation from TS to Go.
TSC codebase is quite unlike regular TypeScript code you will see out there. So it is about specific way TSC is written in being the easiest to port to Go rather than the TS language as a whole.
There's a screenshot comparing the two side-by-side, IIRC it was showcased on the video of the talk (if someone has a timestamp - please post).
The TL;DR version is that they don't really use classes and inheritance (which is the part that would be hard to map to Go but easy to map to C#). It's all functions dealing with struct-like objects.
The other part of it is that C# is very firmly in the nominal typing camp, while TS is entirely structurally typed. Go can do both.
I've said it before on here, but the tech community severely underrates .NET today. It's not Windows only (and hasn't been for ~8 years) plus C# is a very nice language. F# is also an option for people who like functional languages. I'd highly recommend giving it a try if you haven't already.