Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

    > At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby.

.NET actually looking like it has decent support for any teams that are interested[0] (side note: sad that .NET and C# are not considered "major"...). There is an open source C library that they've published that seems rather far along[1]

Support for Windows, Linux[2], and Mac[3] (the latter two with some caveats).

Overall, I think for most dev teams that are not building networking focused products/platforms, HTTP/3 is probably way down the stack of optimizations and things that they want to think about, especially if the libraries available have edge cases and are too early for production. Who wants to debug issues with low-level protocol implementations when there are features to ship, releases to stabilize, and defects to fix?

[0] https://learn.microsoft.com/en-us/dotnet/fundamentals/networ...

[1] https://github.com/microsoft/msquic

[2] https://learn.microsoft.com/en-us/dotnet/fundamentals/networ...

[3] https://learn.microsoft.com/en-us/dotnet/fundamentals/networ...

View on HN

> 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.

I would say that .NET is the best example that Microsoft has not changed: https://isdotnetopen.com/

These are handful of handpicked twitter posts that are almost 3 years old, including the page itself.

https://github.com/ghuntley/isdotnetopen

The website doesn't even explain what they mean by open.

Nor they explain why they think .NET is not open source.

Isn't `vsdbg` still distributed with an incredibly restrictive license? Doesn't sound all too open to me.

Further, the twitter posts themselves are still relevant I believe. If someone took over my repo, I'd remember it 3 years later.

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?

They are criticising Microsoft closing access to .NET debugging tools: https://www.theverge.com/2021/10/22/22740701/microsoft-dotne...

This link again?

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.

First time I've seen that link. What's bad faith about it? Don't know why you're bringing Rust into this.

Parent comment was edited, it no longer seems to include "Rust", difficult to follow. :P

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.

.NET after .NET Framework is just terrible branding by Microsoft.

Call it TypeScript++ or just `dot`; rebrand it Microsoft! Look at this thread full of misunderstandings and confusion around modern .NET!

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!

It's not windows only but it's windows first. A lot of things are missing on other OSs and not nearly all of it is open source.

Fanboys are a bit in denial about this.

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.

    > multiple OSS alternatives out there

What does this mean?

The ironic thing? GitHub, VS Code, and TypeScript are all Microsoft products.

You mean that Microsoft BOUGHT GitHub , like they did with Skype and many other things.

Skype that they ran into the ground despite it being their best messaging product, and are shutting it down in May.

The exceptions prove the rule.

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)

GitHub was purchased, which is a bit different.

TypeScript though I had no idea about! Good for them!

    > GitHub was purchased, which is a bit different.

Why is that different? The purchase was 7 years ago (?) at this point.

Do we make an exemption for SharePoint because it, too, is an extension of FrontPage acquired via Vermeer?[0]

At what point does it lose its exemption from "Hate All Things Microsoft"? 10 years? 20 years?

[0] https://en.wikipedia.org/wiki/Microsoft_FrontPage

The difference here is that we didn't select to use a Microsoft product, a produce we used became Microsoft.

It only matters in the context of it being "ironic" that it is used and favored in the coding community.

OK, then thoughts on VS Code and TypeScript?

Microsoft contributions to Python?

Do they all trigger some weird instant irrational reaction?

Depends. Is everything open source (TypeScript)? Or does it give me basically everything for free when building open source (Github)?

Github looks and works mostly indistinguishable from how it was 7 years ago.

So you are of the belief that Microsoft has not had any effect on GitHub over the last 7 years? Interesting.

Uh? That's not the case at all. It even has popup ads for copilot now.

Why is that ironic? Only one of those are Free Software

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.

> 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.

Yikes. I had no idea the situation was so bleak for those still stuck on TFSV.

Only Typescript is in-house. Others are acquisitions. Do you remember Embrace, extend, and extinguish times?

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

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.

Eh, these days there's a lot of investment in the VSCode extension ecosystem.

They acquired Electron alongside with Atom with GitHub. It is hard not to make parallels between Atom and VS Code

They own Electron now...

From whom was VSCode acquired?

Does the distinction matter?

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.

https://en.wikipedia.org/wiki/CodePlex

I've left later on, when they started to impose 2FA and decided to scan all my code to train their AI.

They may be much less Linux-hostile today, but are still plenty user-hostile. Not to mention their lackadaisical security record.

Can you please highlight some examples of .NET’s lackadaisical security record? I’m curious for my own awareness.

Microsoft's. Consult your favorite search engine.

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.

https://octoverse.github.com/2020/

Microsoft's security record. Not one package manager.

https://arstechnica.com/security/2024/01/microsoft-network-b...

More than just that it came from MS.

For a long time, .NET was completely proprietary, and only ran on Windows.

Now it is open source and cross platform, but it is still fighting the momentum of being seen as Windows-only.

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, but okay, does any of the other UIs work fully properly on for example linux?

> 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.

Avalonia: https://avaloniaui.net/, https://docs.avaloniaui.net/docs/overview/supported-platform...

Uno: https://platform.uno/, https://platform.uno/platforms/

what ui library are most .net applications created in the business world today using? what is microsoft telling people to use?

There's no such thing; it depends on the app that people are building, their use cases, and platforms.

Case in point: both Teams and VS Code: both web view wrappers.

Some trading shops are still using WPF and some are even using Windows Forms apps still.

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.

JS is the only true cross-platform UI; sadly.

You spelled qt wrong

More accurately, HTML (+CSS)(+JS).

HTML is all you need for a cross platform UI.

HTML is all you need for a very slow cross platform UI.

FTFY

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.

Until I can do apt-install, it's got a problem with availability.

I'm pretty it's just:

    sudo apt-get install dotnet-sdk-9.0

No?

That comes after adding an untrusted 3rd party repository no? Why are you omitting that part?

Which means that nothing written in .net will enter the real repository until that changes.

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.

Rust is in debian. Why do you do FUD?

My comment says

> making it needlessly complex for everyone (including Rust)

have I missed something?

Rust isn't a person, just FYI. If you had a point, please make it.

> Why are you omitting that part?

Because I didn't have to do that. Have you considered your distro might be special for reasons that have nothing to do with .NET?

Can you name some examples of popular .Net applications on GNU/Linux or *BSD operating systems?

I can't even name any on Windows.

But that's not really what's being discussed in the context of this thread: application servers handling HTTP/3.

On Windows, a lot of desktop software is .NET these days. It can be pretty hard to say when the apps use native (or XAML) UI, though.

To give one example with a particularly large user base, NVidia control center was a WinForms app for a very long time.

Sonarr/Lidarr and Jellyfin as a start, Ryujinx was one too in game emulation space until Nintentdo DMCA'd everything into oblivion.

These are user-facing applications anyway, not back-end ones which is the more common use-case of .NET (where Linux is the most popular OS).

I have not heard of these apps, but - I'll go look them up (well, the first two), and learn something. Thanks.

About back-end - I would repeat my question but I don't want to derail the conversation too far away from the original subject.

osu is a fairly popular rhythm game that is written in .net

https://github.com/ppy/osu

They also severely underrate it's actual usage. For a non "major" language, there sure are a lot of jobs out there.

.NET ain't hip.

.NET ain’t hip because many of the shops that use it are dinosaurs in processes and culture.

And many are not. How many Python shops are living in the past? It’s the same problem everywhere.

I'd like this to be a lie but it's true, different languages have different cultures associated to them.

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.

Have you given C# a new try with Cursor and newer models?

There's a huge difference from Copilot in 2023, if that was your example.

Also, interesting you feel more productive on a language you don't even like than your "main" one.

Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux

Yes, it can.

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?

I have a bit more info here: https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...

Are you sure? https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

"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.

(this comment is correct: https://news.ycombinator.com/item?id=43388962 ; runtime-dependent and self-contained are fine)

    > Native AOT does not support cross-OS compilation

    > ...runtime-dependent and self-contained are fine

This certainly reads like you moved the goal posts and recognized it.

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.

I don't know why we're trying anymore.

You're not going to convince someone who is looking for a way to make something not work however minor it is and not the other way around.

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.

How do you cross compile from linux to macos?

  dotnet publish -r osx-x64 --self-contained

https://learn.microsoft.com/en-us/dotnet/core/deploying/#pub...

Just like for windows or Linux, in other words. The dotnet tooling is amazingly friction and ceremony free these days.

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.

If you’re calling against shared libraries using cgo then things are a little more tricky, but still doable.

But if it’s native Go code, then cross platform compiling is just an a few environmental variables

  GOOS=darwin 
  GOARCH=arm64

Mono's been on Linux for like 20 years, maybe longer... C# is like Java, can run basically anywhere.

I think being on linux and being decent on linux are not the same, and there's .net problem.

Can you link to anything recent which could support your argument?

https://learn.microsoft.com/en-us/dotnet/api/system.diagnost...

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 :)

> Took you long enough.

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.

All these words and you lost the original part where the APIs are windows oriented?

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 is also in arch. If it is not in debian and ubuntu, that is their fault.

Of course. Microsoft is a tiny poor company. It couldn't possibly afford to hire a consultant to do this kind of job.

> But then again, if you think package management is a serious topic and then dismiss .net for the python mess, come on.

What mess? apt solves the mess, there's no mess if you stay away from pypi (which I advice you do).

> I think nobody in MS believes in Windows as a platform really, it is a sinking ship.

I'm rather sure governments will still use it in 20 or 30 years.

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.

Definitely not Windows-first.

Last startup we built our entire backend in .NET and C#. Every dev ended up using MacBooks. We shipped to AWS t4g Arm64 Linux targets.

This mis-perception is so irrational and not based on any facts.

Just because .NET is what you know best, doesn't necessarily mean it's the best in all use cases.

You're seeming like the node developers trying to push js everywhere because it's all they know. It's not a very rational approach I think.

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.

[0] https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...

[1] https://github.com/CharlieDigital/coderev

node is the wrong tool for any job.

Why would I use C# over any other language though?

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.

It's very productive and kinda nice.

Especially for big backend APIs: https://typescript-is-like-csharp.chrlschn.dev/

LINQ alone is unmatched.

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.

[0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

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.

"All other languages" is a stretch IMO. Any language that has proper macros (e.g. Rust, Clojure) can do something LINQ-like as well as C#.

Can you post some examples?

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

An example on TS with Prisma:

    const loadedAda2 = await tx.runner.findFirst({
      where: { email: 'ada@example.org' },
      include: {
        races: {
          where: {
            AND: [
              { position: { lte: 10 } },
              { time: { lte: 120 } },
              {
                race: {
                  name: { contains: 'New' }
                }
              }
            ]
          }
        }
      }
    })

(Other query tools like Kysely end up using strings (though with the support of TypeScript at dev time))

And the same in C# with EF and LINQ:

    var loadedAda = await db.Runners
      .Include(r => r.RaceResults.Where(
        finish => finish.Position <= 10
          && finish.Time <= TimeSpan.FromHours(2)
          && finish.Race.Name.Contains("New")
        )
      )
      .FirstAsync(r => r.Email == "ada@example.org");

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.

TS does not have macro facilities.

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).

    > TS does not have macro facilities

That I'm aware; I'm curious how this works on Go or Rust.

For details, take a look at the examples here: https://doc.rust-lang.org/book/ch20-06-macros.html

For procedural macros, what you get is not even the syntax tree but rather the token tree: https://doc.rust-lang.org/proc_macro/struct.TokenStream.html. You can then use stdlib to parse that into a Rust syntax tree (which is roughly the equivalent of Expression): https://docs.rs/syn/latest/syn/enum.Expr.html

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.

It wasn't good enough for the typescript rewrite...

Mostly because they didnt consider the AOT compilation mature enough.

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).

Got it; thanks for the tip!

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.

Indeed. And I would think you can use Microsoft's free reverse proxy, YARP, in front of an app (on any platform) that doesn't natively support HTTP/3?

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s...

> At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby.

.NET omission notwithstanding, one of the languages in the list is not like the others: Rust has a deliberately minimal standard library and doesn't include HTTP at all. I don't follow Rust HTTP/3 efforts closely, but there are at least two actively developed libraries: quiche and quinn.

The official Python stance on using the standard library HTTP client is also "are you sure?" and their stance on using the standard library HTTP server is "don't".

https://docs.python.org/3/library/http.client.html#module-ht...

https://docs.python.org/3/library/http.server.html#module-ht...

    > sad that .NET and C# are not considered "major"...

No need to be sad about that list. Java is also missing. There must be millions of enterprise programmers in the world using Java.

I just checked the Java class HttpClient (a common JDK11+ HTTP client). It currently does not support HTTP/3, so add one more to the list!

Ref: https://docs.oracle.com/en/java/javase/24/docs/api/java.net....

Also, most of the very best network clients are now built on top of NettyIO. I can see an "incubator codec" here: https://github.com/netty/netty-incubator-codec-http3

Holy hell, this code is ridiculously complex: https://github.com/netty/netty-incubator-codec-http3/tree/ma...

I'm not hating on NettyIO here, but the protocol looks complex. Yet another reason why it is so slow to be deployed to more application frameworks.

I don't think many people use the builtin HttpClient these days. Apache httpclient would be the conservative standard, apparentyl it has some support for 2 but not 3: https://hc.apache.org/httpcomponents-client-5.4.x/index.html .

There is a very simple reason for not being on the list: It support HTTP/3 and the purpose of the post was to show the lack of support in common languages. .NET does not fit that list well.

And it is obviously only popular in the dark matter of Enterprise Software Development.

C# is much closer in popularity to TypeScript/Python (the number 1s) than it is to Rust.

In usage yes, in analysis yes but not in general popularity.

And to Rust ... definitely. Rust is a niche product for system development. A very good one. A very popular one. But nothing you need for your day to day microservice.

    > And it is obviously only popular in the dark matter of Enterprise Software Development.

Well, and apparently for game development given both Godot and Unity use C# and various builds of .NET

Kind of misleading - Rust stdlib doesn't include HTTP 1 or 2 either

Until the dotnet packages are shipped in every major Linux distro's default repositories (it's okay if it's a 5-year-old version), we can't call C# a major language.

But apparently there aren't enough people willing to actually do the work.

> side note: sad that .NET and C# are not considered "major"...

Even Microsoft does not use C# for their new projects. See the new TypeScript compiler that is being rewritten in Go. So I think it is safe to say C# is indeed a minor language.

    > So I think it is safe to say C# is indeed a minor language

That's not really the case; StackOverflow survey[0] shows C# (27.1%) right behind Java (30.3%) and well ahead of Go (13.5%), Rust (12.6%), Kotlin (9.4%), Ruby (5.2%), and Scala (2.6%). If we exclude HTML/CSS, Bash/Shell, and SQL, C# would be #5 in actual languages used over the past year by devs in this survey.

You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

    1. JS/TS (note these two are collapsed)
    2. Python
    3. Java
    4. C#

Two completely separate sources with the same output...

    > See the new TypeScript compiler that is being rewritten in Go

If they had started from scratch, Anders mentioned the considerations would be different. But because they had an existing body of code that was not class based, it would be more of a re-write (C#) versus a refactor (Go). A lot of folks read the headline without actually reading Anders' comments and reasoning.

C# is good for many things -- in particular application backends, game engines (both Godot and Unity) -- and not optimal for other things -- like serverless functions. Each language has a place and Go and Python are certainly better for CLI tools, for example.

[0] https://survey.stackoverflow.co/2024/technology

> StackOverflow survey[0] shows C# (27.1%) right behind Java (30.3%)

Can we rule out sample bias here? After all, Jon Skeet [0] is an important part of the Stack Overflow's C# community.

It might just be the case that C# and Java developers use Stack Overflow more than users of other languages.

[0] https://toggl.com/blog/save-princess-8-programming-languages

You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

    1. JS/TS (note these two are collapsed)
    2. Python
    3. Java
    4. C#

So now you have two data points that align and are completely independent measuring two different things (one self reported, one based on employer job postings).

I'd say it's consistent and reliable?

It's not like people use StackOverflow because it's written in C#; people use StackOverflow because Google points us there.

But because they had an existing body of code that was not class based, it would be more of a re-write (C#) versus a refactor (Go).

I don't understand this reasoning at all, and I'm hoping you can shed some light on it.

As far as I know, C# supports static methods. Thus, using OO in C# would not have been required, would it?

I feel like I'm missing something here.

C# supports top-level functions as well, that's not the issue. But, just to give a simple example, in TS you can do things like:

   var foo: { bar: { baz: string } }

which have no equivalent in C#, because it doesn't have anonymous struct types, and its typing system is almost entirely nominal. Go, on the other hand, can translate this directly pretty much mechanically:

   var foo struct { bar struct { baz string } }

And keep in mind that they aren't completely ditching the existing implementation, either, so for a while they're going to have to e.g. fix bugs in both side by side. It helps when the code can also be mapped almost 1:1.

The interesting thing is that you can do this in C# with tuples because tuples can nest tuples.

    type Platform = "Mastodon" | "Bluesky" | "Threads";

    type Profile = {
      name: string,
      socials: {
        handle: string,
        platform: Platform
      }[]
    }

    function getProfiles() : Profile[] {
      return [{
        name: "Charles",
        socials: [
          { handle: "@chrlschn", platform: "Mastodon" },
          { handle: "@chrlschn", platform: "Bluesky" }
        ]
      },
      {
        name: "Sandra",
        socials: [
          { handle: "@sndrchn", platform: "Threads" }
        ]
      }]
    }

Versus:

    using Profile = (
      string Name,
      (
        string Handle,
        Platform Platform
      )[] Socials //  Array of tuples in another tuple
    );

    enum Platform { Mastodon, Bluesky, Threads }

    Profile[] GetProfiles() => new[] {
      ("Charles", new[] {
        ("@chrlschn", Platform.Mastodon),
        ("@chrlschn", Platform.Bluesky),
      }),
      ("Sandra", new[] {
        ("@sndrchn", Platform.Threads)
      }),
    };

With some caveats

I would love if in mapping the typescript types to go they ended up building a "compiler plugin" to enhance go's type system.

TypeGo by Microsoft (TM).

Considering how fast the TypeScript compiler is, the TypeGo -> Go transpilation might as well be similar (up to a constant factor) in speed to Go compilation itself.

I'd give it a try. As a highly enthusiastic Go programmer, a powerful TypeScript-like type system is something I'd welcome in Go with open arms.

That wouldn't feel very idiomatic - you can do it but would feel wrong

I’ve never filled out a stack overflow survey. I wouldn’t say Stack Overflow is statistically representative what’s being used — it’s statistically representative of people that use Stack Overlow. 10 years ago SO was my go-to. Now, I barely notice it — it seems very outdated in many respects.

I never understood SO as a measurement tool for anything, but people that can't read docs.

You have to have some metrics from somewhere to be able to understand which languages are being used.

SO is one data point, but there are certainly others.

GitHub is probably a better source. SO is self selecting for people asking questions about something, not actually using it. A “harder” thing might have more SO questions, so it isn’t representative of actual usage.

I posted above, but you can also see:

You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

    1. JS/TS (note these two are collapsed)
    2. Python
    3. Java
    4. C#

Two datapoints, completely discrete, same result.

It tells me which languages have people asking questions about them. That metric is useful only if it's normalized around how many people are using that language, but we don't have that metric.

The interviews with the Typescript dev doing the rewrite will tell you why. Switching their compiler to Go was a quick transition since Go matched their current JS build. The dev also wanted to use go, and use functional programming. It would have required more work to switch from functional to OOP style that C# has. Dev also didn't want to learn F#. Nothing about C#, just a personal decision with the least amount of work to get to a beta.

FWIW the "functional programming" angle here is misconstrued - C# has better facilities for it than Go.

The thing that they actually wanted is data-centric programming with structural types.

It's pretty true from recent experience. I've recently started rewriting a C# based desktop/window stream tool because of how weak the support is across the board for C#. Microsoft abandoned WinRTC, Sipsorcery is one guy and is missing VP9 HEVC and AV1 support. And for fancier stuff like using computer shaders for color space conversion, SharpDX is constantly referenced by chatgpt and MS docs, yet it's archived and unmaintained as well. I ended up using media streams VideoFrame class but it and two other classes required to interact with it have unpreventable thread and memory leaks built into the WinRT implementations themselves 4+ years ago. Good times.

All of the above was easy to implement in Rust

This is an interesting point I hadn't thought of when I saw the announcement of the new TypeScript compiler. It might be overstating the case to say that C# is indeed a minor language, but it's thought-provoking that it wasn't Microsoft's automatic choice here, the way it is for some all-Microsoft in-house IT shops.

Microsoft themselves ship on a variety of platforms.

It's more about right tool for the right job.

Good example is Azure CLI; it's Python. Microsoft is also a big contributor in the Python scene[0]

I don't think it's surprising at all that they didn't use C# to write a compiler for TS.

They have internal champions for Rust[1]

I'd say Microsoft is possibly one of the most diverse shops when it comes to tech selection.

[0] https://devblogs.microsoft.com/python/supporting-the-python-...

[1] https://www.theregister.com/2022/09/20/rust_microsoft_c/

TypeScript guys have a FAQ and even a video explaining why they chose Go exactly, and why not C# (or Rust, or other things). They had their reasons.

It's not thought-provoking if you care to spend 5 minutes and read/listen to the reasons they provided.

I am not at all surprised to find that there are people in whom it does not provoke thought, but I am mildly amused that one of them would admit to it.

Go folks are going to be holding up this Typescript decision for years, aren't they...

Reply on news.ycombinator.com