Hacker News Reader

Comment by tester756 | Hacker News Reader

.NET was the most sane programming ecosystem that I worked in.

Great CLI, great package manager, very good stdlib, strong IDEs/Debuggers, etc.

but sadly interesting jobs like OSes, databases and compilers are way less common than in C++ world :(

I agree. The stability comes from its ecosystem though. Enterprise Software. Where things like meticulous use of Omit and Task are common place and really REALLY bad things happen if you fuck up.

But besides that, there’s a healthy gamedev community that embraced C# early and have been using it ever since. There’s C++ MFC guys that got duped into WPF and have been supporting it ever since. Winforms devs that are still trying to make a dark mode. I’ve even seen community grass roots “I need this in Silverlight” projects take hold and become one of the largest SDKs in the world. It’s cool. It’s fun. And with AOT, it’s everywhere. C# is like that cool uncle of your Father (Java) that likes to party all night but still holds a job. Maybe someday TS.Net will exist and we’ll all be singing “Back in my day”

I very much doubt about TS.Net, given the rewrite in Go decision.

.NET nowadays has a serious adoption problem, and they should spend more time talking with their own colleagues at Azure, about their use of Java, Go, Rust.

> .NET nowadays has a serious adoption problem

It's seriously going to make people question the future of the platform. Look at Microsoft's actions, not their words.

TS Compiler: Go New TUI Editor: Rust Winget: C++ (this would have been a great candidate for .NET)

At least PowerToys is C#.

.NET is great, but why isn't it good enough for Microsoft? The company that historically has had such a strong culture of dogfooding.

The issue was in the beginning they didn’t think interop with C/C++ was value add. People complained and they added “Managed C++” which unfortunately influenced C++03’s design a lot. It wasn’t until C++11 that Microsoft gave up. You couldn’t effectively interop with C++ without writing a managed C++ wrapper, which only worked on windows. They added support for P/Invoke to aid in Win32 calls (shell.dll, user32.dll) as a simple fix and we went nuts for it. Wrote wrappers using P/Invoke and a config map nightmare of which dll’s, or dylib’s, or so’s, you needed to get the form to show.

Fast forward to today… Rust can interop with C natively. Go can as well, though you’re bringing your luggage with you with CGO. .Net hasn’t ever really had that kind of focus. For one, IL, two, Microsoft saw the platform as a cash cow, three, ecosystem lock in allowed a thriving “MVP” contractor community.

You're clobbering together a bunch of different stuff and not making a ton of sense. C and C++ are very different languages, and that's especially true when doing interop with them from other languages.

For C-based libraries, P/invoking is trivial in C# and has been around forever. And it's cross-platform, working identically on Linux and macOS. I have no idea how you can say ".Net hasn’t ever really had that kind of focus" when it's been a core part of .NET from the start, and .NET relies on P/Invoke to do everything. Go look at all the DllImport() statements in the .NET reference source. Rust FFI is nearly identical in implementation to C#. Go has a slightly different implementation with the CGO module, but whatever, it's close enough. Just step back and remember that, in general, calling into C code is trivial in every language, since it has to be: all these languages will eventually have to hit libc / user32.dll / whatever.

C++ is a totally different story. You can't work with C++ libraries with P/Invoke, that's true... But you also can't work with C++ libraries using Rust or Go, either. Nor Python, Java, Javascript, or really any other popular cross-platform language.

C++ dynamic libraries are really challenging to call into for a variety of reasons. Virtual functions, multiple inheritance, RTTI, name-mangling, struct/class layout, vtable placement, ABI differences, runtimes, etc all make calling into precompiled C++ libraries a nightmare.

In fact, the only way I know of working with pre-compiled C++ libraries is with languages that target specific operating system / compiler collections. E.g., Objective-C++/Swift from Apple, and C++/CLI from Microsoft. These are obviously not cross-platform solutions, since they depend on knowing the exact compiler configuration used to build those libraries in the first place.

For every other language, you either need to manually build C shim libs that you can call into using the C-based approach above, or if you have access to the C++ source code, creating wrappers around it and building it into a module (for example, using pybind11 in Python).

The only reason is name mangling. You can disable this or export declspec it and keep the C-like signature. Painstakingly recreate the API in C#, using P/Invoke, and hope for the best. It wasn’t until late 2015 that we got codegen to “automate” this, or roll your own.

My perspective is from a first adopter, not an insider, 24 years ago, so I can’t speak to motive but as a customer, it felt exactly as I described. The documentation around P/Invoke was lax, you were shoved “Managed C++” down your throat by your rep, and any dream of going cross platform died in that meeting room until Miguel De Icaza did something about it.

It certainly is not, it is quite common to use templates directly or indirectly via the C++ standard library, and P/Invoke cannot handle those.

Also during .NET 1.0 days, Microsoft had a Website where you could paste any well known Win32 API or related SDK, and it would spit the annotations.

What was never as good in .NET as it was in VB 6 and still is in Delphi and C++ Builder to this day, was creating and consuming COM, which is kind of annonying given how much Windows team loves it.

At least it isn't as bad as the multiple reboots in C++, which I will keep asserting that from all of those, MFC still has the best tooling to handle COM.

You are jumping over a few facts there.

P/Invoke was born as J/Direct on J++, it became P/Invoke after the lawsuit, and Cool project turned into C#.

Managed C++ Extensions in .NET 1.0 got replaced by C++/CLI on .NET 2.0, it was a .NET Core 3.1 milestone to support it, and has recently been updated up to C++20, minus modules.

Still heavily used among .NET community on Windows.

Meanwhile the native C++/CX and C++/WinRT, both failed their adoption efforts.

I only wish if C++/CLI worked on other platforms...

Same here, for those of us comfortable on C++ land, it is much easier way to do integration with native libraries, than getting P/Invoke right.

My memory is fragmented in my older age.

Interestingly, the Rust windows crate is generated from an MSIL assembly. And same metadata might be used to generate C# bindings thanks to cswin32 [1] project. The meta-assembly generation (Win32 metadata project) is based on clangsharp and it's fairly straightforward to generate interop code for native Windows libraries. Some time ago I described this process on my blog for the detours library [2]

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

[2] https://lowleveldesign.org/2023/11/23/generating-c-bindings-...

The point is why is another language generating anything for C#?

Yes, and this approach is an extension of the one taken with WinRT metadata which is also ".NET assembly" based.

Windows and Office never adopted .NET for client code in the first place except for the Longhorn period in the mid-00s, which burned them and put them off it. If that didn't stop .NET in the two decades between then and now, I'm not sure why it would today. Actually, Windows is just now starting to adopt C# now that AOT is supported (I think the new native Copilot app is C#).

Many Windows Server admin tools (such as Server Manager or Virtual Machine Connection) and MMC snap-ins (e.g. Event Viewer, Hyper-V Manager) are written in .NET Framework 4. PowerShell is .NET Framework 4. Everyone’s favorite bloated IDE (Visual Studio) is .NET Framework 4 as well.

In the Office land, Excel’s Power Query is .NET Framework 4.

Adopting the modern .NET is probably harder due to its lifecycle.

Calculator is C# as well (though apparently that's somewhat recent: https://github.com/microsoft/calculator/pull/1598).

Porting to C# was a community effort after it went open source, it was originally C++/CX.

Powershell is .NET Core since version 6, the .NET Framework one is Powershell 5.1.

Yeah, Microsoft themselves have issue moving away from .NET Framework.

You can add SQL Server CLR, Dynamics, Sharepoint on prem, to the list.

OMG could you imagine writing MMC snap-ins using some sort of plugin declspec import bs in C++? .Net and reflection with Assembly.Load saves so much time and effort to build modular “ship it now, deliver features later, extend it if we fall behind” apps. Not that those are good things, it just means you can defer until your MS PM gets the budget to fill those backfill positions that have been open for 12 months because the hiring bar is astrophysics

I can, because due to Windows team love for COM and C++, many extension points require doing exactly that.

Want to extend the context menu actions, or add new thumbnail capabilities for a recent file format?

It is exactly that.

Even with WinRT Runtime Components, they were doing in a way that some APIs were only surfaced when using the components from C++.

Quite a different approach from OS / language teams at Apple and Google, where productivity with better languages has a priority no matter what.

Anders Hejlsberg, a main architect on C# & TS, stated somewhere that they re-wrote the TS Compiler in Go because the syntax was the closest to how it was originally written and allowed re-writing to be easiest. He has a great write up of it somewhere on GitHub.

Microsoft is an insanely huge company. There teams seem to be able to use whatever works best for the project/team.

The old XKCD comic of org charts in big tech shows Microsoft as a bunch of people aiming guns at each other for a reason. They'll have 5 teams making 5 competing products sometimes. That's the culture I'm aware of. I'm not aware of the dogfooding culture you are suggesting.

Yeah, and then at BUILD 2025 session, he ended up explaining how they had to rewrite all the data structures, due to the less capable type system from Go versus Typescript.

So the gain isn't as much as what is being sold.

Meanwhile Azure has no issues using AI based translation to port C++ projects into Rust, which they could have done in a similar way to port into C#.

Also, Go has a less capable tooling as C# for WebAssembly, due to Blazor efforts, the team has invested quite a lot into it.

It remains questionable what will they do for the in browser playgrounds and editors use cases.

Exactly. They chose Golang because they wanted to, not because of any technical limitation. Could have been C#, or Rust…

They used Go because it was the best fit for the task. Anders explained the reasons very well.

Not sure I agree on the adoption problem. A few medium sized client projects are nothing compared to the massive internal .NET codebases Microsoft has that run some of their largest services.

.NET team members have acknowledged this on podcast interviews, .NET Rocks, Nick Chapsas, The Unhadled Exception, among possibly others.

I would not touch C# unless you are already using it. Microsoft proves over and over it cannot be trusted in what they say. Watch what they do:

- basically dont use ant UI framework they say is the future and they are not using themselves - be vary of the future of some of it stuff like C#

C# has been around a long enough time and Microsoft's teams over that time have done a pretty good job making upgrading each version easy.

As long as the current leadership in the C# & .NET teams remain, it's a very safe language and framework to use. They also deserve huge kudos to API & performance improvements the past decade since moving on from .NET Framework 4.x, which still runs fine.

They also have a lot of internal & external users using it.

Oh I learned this the hard way. Managed DirectX, XNA, Creators Club, Windows Store, shared profit motive, fair business practices, Project Natal/Kinect, Azure, and finally… .Net. Yup, Microsoft loves developers… loves their subscriptions.

I know, so sad, could have been a great opportunity.

Just like every CNCF project that Azure contributes to, written in Go or Rust, which could have been great carrots to further .NET's adoption.

I blame historic microsoft for their anti-oss stance. It kneecapped the .net ecosystem for over a decade and created an attitude of "if it isn't in .NET, I won't use it".

That has certainly played a role, however that is common to Windows development culture in general.

The 3x "Developers !" meme isn't for nothing, Microsoft just like Apple (and NeXT), always a full stack development experience story.

Everything that one needs is there on the full Visual Studio Professional, and then there was the ecosystem of small indie developers and MS Partners building on top of that.

That is quite different from UNIX FOSS culture, and has also been a friction point to those that went Apple without understanding that also have that on their DNA, regardless of OS X foundations.

I agree as well. The hostile attitude towards OSS under Ballmer led to this. Nadella had the correct approach and a year later, started repairing those bridges, joining the Linux Foundation.

Many things under Satya also feel like good old Microsoft, like lack of GUI frameworks for GNU/Linux, killing VS4Mac after the rewrite, dotnet watch drama, profiling tools being VS only,...

MAUI not supporting Linux feels like such a huge whiff. It is clearly possible to get at least decent cross platform support that includes linux in .net considering Avalonia exists.

MAUI is supposed to use native ui components, AvaloniaUI just uses Skia. I think going with a non-native approach would kinda make Linux a clear second class platform, especially with all the native features that need to be rebuilt?

Is there any multiplatform ui framework that's actually "native" for all the different linux ui toolkits?

VS4Mac deserved to die, that was Mono Code aka Xamarin and it was terrible. No offense to Miguel, mono is amazing, but the IDE they made was horrid.

Microsoft was asleep at the wheel the last decade of Ballmer, leaning too heavily on their Xbox Studios and Enterprise Cloud to care about desktops. They gladly let Mac take office share as “no enterprise software developer would ever choose a Mac”. Those famous Mac vs PC ads.

The GUI development story has plagued us for a long time. No one wants to take on the challenge of a unified user interface spec. Why? Because it will always be wrong - ever changing - and a giant suck of corporate resources.

It’s better to let each team think of their own way of doing things. Then, they can choose the best of them and release them as frameworks (WPF) only to be abandoned by the next regime change.

MAUI, UWA, Metro, WPF, all an attempt to save what effort they have made. Ultimately, everyone loves their Electron apps, so HTML has become to new UI paradigm. They move too slowly. Convinced “they know better than you” and will spend the next 5 years hyping up the next XML abomination.

No it wasn't any longer, that is why the rewrite took place.

I rather use XAML, if given the choice.

What's Omit refer to in this context?

The 14,000~ instances of T? or _

Since you mention great CLI - is there a CLI tool that is free/cross platform that works like prettier ? I found https://csharpier.com/ but have never heard of anyone using it.

Also not sure how it works with linters like roslynator or stylecop ?

This is something I miss very much when coming back from TS, other languages also have better formatters. C# is very tied to editors/IDEs which is a nightmare in teams where some people use vs/vs code/rider

Csharpier is the best option available. I've been using it for 3-4 years now and had success getting it adopted at my last two companies on greenfield projects. It's not exactly an unknown tool - nearly 2k stars on Github. But a lot old school .Net companies just don't seem to have much interest in auto formatters because they've been working without them for a long time.

If you're using csharpier you don't need to use Roslynator formatters. No issue with the analyzers package. The csharpier docs have info on what StyleCop rules need to be adjusted so they can work together. Personally I don't use StyleCop anymore as it seems to be fairly dead, and I don't really feel the need for things like enforcing file layout or naming.

Edit: Also I will add that unless the landscape has changed recently, I believe csharpier is the only C# tool that has deterministic formatting good enough to enforce code formatting checks in CI.

dotnet format [0] exists and is maintained by the .NET team. It is different from Prettier in that it is much more configurable, but it gets the job done for us. It does integrate language services and can automatically apply code fixes for custom analyzers. I have not explicitly tried roslynator or stylecop, but I suspect this would work as expected.

[0] https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-f...

The problem is that dotnet format is horribly slow. So much so that it's only useful as a precommit hook

> It is different from Prettier in that it is much more configurable

I only tried it briefly but found it was waaay to lenient with the amount of variance in style it left unchanged (eg line breaks for function parameters) - can it get configured to produce consistent formatting like prettier ?

I think there are also a lot of default rules which aren't enforced until they're bumped up in severity in the .editorconfig.

Also it can hook into roslyn analyzers, so if you want a more opinionated analyzer then stylecop analyzers ( https://github.com/DotNetAnalyzers/StyleCopAnalyzers) would be an option, although I haven't used it myself for a long time.

It can be configured to be much more aggressive with formatting, but I'm not certain if you can force it to produce the exact same output for any possible whitespace in the input.

I was not able to use (recent) dotnet-format as standalone .exe tool, also it only worked if inside an actual project with .sln/.slnx file and all that. I could not instruct it to work on single file.

Hi! I use csharpier, it does the job - I included it as a preliminary check in our CI pipeline for a step of merge requests quality assessment. It is the closest tool I found, that ressembles prettier. You should definitely give it a try.

I’ve been using csharpier for almost a year now and it’s amazing. Because it’s opinionated, you don’t have the space to overthink it, you just use it.

Besides, I really like its formatting style.

csharpier is great. It is what "dotnet format" should be.

On my little enterprise bubble, the only place remaining for C and C++ is writing native libraries to be consumed by managed languages, or bindings.

The last time I wrote pure C++ applications at work, was in 2005.

Libraries still regularly.

Sometimes I feel like there ought to be a Hacker News like forum for us dinosaurs stuck in the Enterprise tarpit. Instead of talking about Elixir and AWS startup credits, we’d complain about the weather and legacy CORBA components.

Indeed, it could be interesting.

What do you mean by CORBA, isn't that the cool new shiny WebAssembly components? :)

For the last few years, I’ve been developing CAM/CAE software on my job, sometimes embedded Linux.

Same experience: last time I developed software written entirely in C++ was in 2008. Nowadays, only using C++ for DLLs consumed by C#, for 2 reasons: manually vectorized SIMD for CPU bound numerical stuff, and consuming C or C++ libraries like GPU APIs, MS Media Foundation, or Eigen.

I've been using it since 2002 so you can imagine my opinion when jumping to other languages. They've been very good to steal all of the things that worked from other languages and constantly iterate on their core infrastructure and language.

I liked .NET but the performance was really bad for anything that had even reasonably latency requirements. But this was 15 years ago, so maybe it has improved. I don't remember exactly what I wanted to do but it was something like pumping some event every few milliseconds and it was basically impossible. The jitter was already larger than the interval.

Dotnet's GC has a real latency problem. Miguel de Icaza gave a nice talk on why noticeable pauses are inevitable in a stop-the-world tracing GC, proposing Swift's reference-counting GC as the viable alternative [1]. Still, there are recent developments (Satori GC) with the promise to make the worst case far more palatable (e.g. 250ms -> 5ms) [2].

[1] https://www.youtube.com/watch?v=tzt36EGKEZo

[2] https://github.com/dotnet/runtime/discussions/115627#discuss...

https://medium.com/@ocoanet/improving-net-disruptor-performa...

Do you know about any sizeable open source projects written in C#, other than what Microsoft has produced? I rarely come across anything written in it.

It's a curious thing, the .NET ecosystem. The overwhelming majority of it's ecosystem seems to be dominated by Microsoft first-party libraries and frameworks. 3rd party libraries and frameworks seem to either get swallowed up by Microsoft, killed, or never reach critical-mass.

Often in the .NET ecosystem, it seems there is exactly one library or framework for thing $X or $Y. Whereas in the JVM ecosystem, you have 30+ logging libraries, 87 different MVC frameworks, etc. (yes, I'm being a bit facetious, but you get the point).

I imagine .NET developers often think this is a good thing, in regard to their ecosystem. No guessing what to use, just go with the "blessed" path and don't think about it. And, to that end, there is some obvious merit to this.

However, I feel the .NET ecosystem loses out on cross-pollination of ideas. There's zero possibility Microsoft's employees just happen to make the best frameworks and libraries... there should be many web frameworks - each competing for mindshare and trying to out-innovate each other, each with their own pro's and con's, etc.

So, while .NET might be technically open source, it still feels rather like a closed source ecosystem, controlled by a single corporate entity.

That because that's the environment MS nurtured for over a decade. They were openly hostile to things like nuget up until like 2016 or so.

They purposefully made it painful to venture out of the MS ecosystem.

>I imagine .NET developers often think this is a good thing, in regard to their ecosystem. No guessing what to use, just go with the "blessed" path and don't think about it. And, to that end, there is some obvious merit to this.

Supply chain security is important thing, especially after last years

You go with Microsoft's libraries and you don't have to care that much about some random developer receiving 50k USD for their GH account

There are several logging libraries for .net as well, microsoft even lists them: https://learn.microsoft.com/en-us/dotnet/core/extensions/log...

Libraries getting swallowed up is not so bad as it sounds. For instance for web frameworks there was a phase of experimentation with projects like Nancy that inspired changes for asp.net core. There is still alternatives like fast endpoints.

Also you have things happening like integrated system.text.json replacing newtonsoft.json that over time took on some cruft.

Why would anyone make a .NET open source library when Microsoft is quick to squash anything that is actually useful with their own open source implementation?

Microsoft still has some lessons to learn about fostering an active open source ecosystem -- of course, unless they are intentionally suppressing it in .NET.

It's weird you using logging as there used to be 3/4 different libraries people used (nlog, log4net, elmah, another one I forget?).

Then serilog came out and pretty much everyone switched to that in a very short period.

https://github.com/MonoGame/MonoGame (runs even on consoles, which is rare for open source game frameworks and engines)

https://github.com/SubtitleEdit/subtitleedit

https://github.com/jellyfin/jellyfin

https://github.com/AvaloniaUI/Avalonia

https://github.com/bitwarden/server

https://github.com/unoplatform/uno

https://github.com/files-community/Files

https://github.com/NickeManarin/ScreenToGif

https://github.com/DevToys-app/DevToys

https://github.com/d2phap/ImageGlass

https://github.com/ShareX/ShareX

https://github.com/duplicati/duplicati

https://github.com/OpenRA/OpenRA

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

https://sourceforge.net/projects/keepass/

https://github.com/orchardcms

https://github.com/piranhacms/piranha.core

https://github.com/umbraco/Umbraco-CMS

https://github.com/quozd/awesome-dotnet

The FFXIV extension/mod tool is a fun example.

https://github.com/goatcorp/Dalamud

https://github.com/SM64-TAS-ABC/STROOP

Can't speak for FLOSS, but I've worked on massive projects in various Banking, Govt and eLearning spaces. I've never really hurt for library support via NuGet either. It's honestly not always my first choice, but pays the bills.

I mostly just dislike a lot of the excessive use of "Enterprise Patterns" for projects that don't come close to actually needing them.

Jellyfin / Emby

A lot of the *arr tools like Sonarr

Bitwarden and Keepass

Kavita (self hosting for books/comics)

Ryujinx, a state-of-the-art Switch 1 emulator, was open source and written in C#

Not sure what your definition of sizable is. But if it’s just physical size of repo then my language-ext project [1] is about half a million lines of code, ~7,000 stars, and ~25 million downloads.

We are out there :)

[1] https://github.com/louthy/language-ext

Akka.NET and AvaloniaUI are two big ones.

I'll add Orchard CMS to this list. Also a lot of the seven seas software.

It is a self-fullfilling prophecy: No big open source without motivated contributors, no contributors because of bad rap because of no big open source projects.

It is not technology what holds .NET back. It is also not politics (nearly all languages have evil overlords). It is people who hold up to statements like: "I will not touch .NET with a 10-stick-pole"

https://github.com/paintdotnet was the first one that came to mind.

Bitwarden

Unity?

Is Unity open source?

I despise working with Nuget. Whether it's a restore, managing your csproj, or publishing packages, compared to NPM it's an absolute mess.

It is the first time I see anyone praising npm.

> .NET was the most sane programming ecosystem that I worked in.

Having written libraries in .Net I fully disagree with that notion.

First insanity is figuring out what in the fuck you need to support. .Net framework or .Net standard or .Net Core or Mono (or .Net Duplo or .Net dot nes :P).

Second is the Source generators. I swear using t4 templates is the saner option. I've had cached artifacts appearing out of the fucking nowhere like unkillable zombies despite closing the Rider, clearing its cache, and killing build server.

Third is the availability of packages. In Rust and Java there are like several libs for anything (even if C bindings).

> First insanity is figuring out what in the fuck you need to support.

Since I no longer support .NET Framework, it's just .NET now.

.NET was two platforms for a while and they did a lot of weird stuff to make that work (.NET standard) but it's been one platform for many versions now so that specific difficulty can mostly be ignored.

Easy to say, but it poiets to ecosystem fracture. But I've been getting requests to support really weird and outlandish versions. Stuff like Mono and .Net 4.56

Microsoft managed a smoother transition than Python 2.x to 3.x. This kind of thing is very difficult. I don't see any reason to support Mono or .NET 4.56 anymore.

Most C# libraries I use are outdated, crappy and do just a little less than what I need. Also, most Rust libraries I try to use are outdated, crappy and do just a little less than what I need. Maybe what I need is niche but my experience is pretty similar in that regard.

Reply on news.ycombinator.com