Hacker News Reader

Being a Microsoft product is such a heavy baggage. Last time I checked the official debugger was still not open sourced and that alone was enough to make many people think twice. The fact that MSFT chose golang instead of C# for Typescript compiler, the state of Windows native GUI app dev... all erode C#'s reputation.

It's a good language though. The latest trend of hating OOP is unjustified/overreaction. I do write Rust too and I am not really convinced that traits are better than shallow inheritance + interface-oriented classes.

    > Being a Microsoft product is such a heavy baggage

Which I always found ironic because TypeScript (from the same guy that created C# even!), VS Code are both Microsoft. Microsoft also makes big contributions and investments in Postgres and Python as well.

TypeScript has fewer competitors for the frontend than C# does for the backend

https://gist.github.com/matthiasak/c3c9c40d0f98ca91def1

JavaScript is one of the most common compile targets. "Who's the better JavaScript" was the most contested field a decade ago. These are not just toy languages - Facebook has Flow and Google has Dart. Both companies are far more web-adjacent than Microsoft. Yet Typescript won. It won so hard that we feel it has no competitors today.

Did anyone ever explain why C# was not considered in the first place ?

Yes, it's because the structure of the existing codebase for the typescript compiler matched go better. (There's a blogpost about it somewhere)

edit: I think it was considered, but go was a better fit

What does "structure" even mean ? How or why are models so much easier in Go compared to other languages ?

https://github.com/microsoft/typescript-go/discussions/411

It is weird now that you mention it. I worked in C# and .NET for a long time. In theory for 20 years. In practice I wasn't writing much C# after 2019 even though the team I led still used it.

I guess I... just got bored of it, and fed up of Microsoft. I came to hate Windows and having to work on Windows so much that it sort of tainted C# for me. I'm not saying I'd never use it again but, whilst it will run cross-platform nowadays, so will loads of other languages and frameworks, so it's never at the top of the list when it comes to choosing something for a new project.

As for TypeScript? Absolutely loathe it. I'll use it professionally when I have to, but I'd never use it for one of my own projects. It's just so ugly I don't even like looking at it. I get why people like it but, for me, it's not enough. If I'm staring at something all day then, I'm sorry, it can't be ugly.

But, strangely, I still use and enjoy VS Code from Microsoft, and have no plans to switch to anything else.

(I also still have an Office subscription - or whatever it is Microsoft are calling that suite nowadays, I don't care - because I still use both Excel and Word fairly frequently. I could probably get by without, but I actually quite like Office - even on the Mac.)

Ironic that you quit using it because of Windows right around the time you no longer needed to be on Windows to use it.

The decision to use Go for TS7 compiler is even more baffling considering Go's low level memory management functionalities is nowhere near the level of C#'s Span<T> etc, especially since TS and C# are invented by the same person.

I got so worked up by it I built my own TyepScript compiler with my clankers in C# to prove that it can be done, my revival of the Common Language Runtime concept, project Copeland:

https://github.com/yuechen-li-dev/copeland

Currently, Copeland compiles a dialect of TypeScript to JavaScript, C#, WASM via Blazor WebAssembly, and NativeAOT, runs in csproj, and uses xUnit.NET for testing framework.

(The other reason is that Microsoft still refuses to do the obvious thing in .NET 11 and take the best part of Rust and let enums be `match`ed, despite the fact that both TypeScript and C# have weak enums historically, so I added payload enums to my TypeScript dialect because Microsoft won't.)

There's an open-source debugger by Samsung, compatible with GDB/MI and the DAP protocols: https://github.com/Samsung/netcoredbg

Well, there's a lot of sides of it.

On the historical (And semi-current-ish) downside we had/have;

- lots of 'flash in the pan' stuff between 2008-2012ish (Silverlight comes to mind here)

- Anemic Entity Framework in pre-core, and the weird stuff EF Core had going on early in it's life.

- That constant worry as to whether you need to add .ConfigureAwait(false) to every async call in a library you want to open source.

- The thing where trying to do 'traits' in NetCore (Now that you can mostly mimic the behavior) has had some side-effects on performance, mostly resolved but still something you have to consider as far as impact. (To be clear tho, thank god, needed that...)

- WTF was that UWP workflow?

- Why can't we get a proper designer? I don't think it would be that hard especially given I can do nice things around workflow designers today. Speaking of workflows...

- The complete (what I probably guess was MS groups eating their own tail) thing where Workflow Foundation was almost truly productive, SSMS had a thing based on it that was surprisingly productive, and it has been murdered instead of getting the TLC it needed to really disrupt. This one is extra loud because it is so similar to the 'low code' platforms so many orgs have sank money into.

- Less impactful as far as people eating the lunch microsoft left on the table, but WCF.

The upshot is;

- If you're willing to do some looking there are great options out there. lazy example, linq2db is basically a DSL that is close enough to EFCore as far as 'how you compose' that you can teach it to a group of WITCH devs in 30 minutes or less.

- It really is easy to do all sorts of stuff. It's just productive.

I love C# and F#, but every .NET shop I worked for was full of MS cool aid drinkers and enterprisey nonsense. I don’t miss the culture at all. The languages are excellent, though.

Exactly this. The workaround is to explicitly hire developers from other languages whose idiomatic use matches your style.

This. It's so nice to work on C# stuff on your own without any of that baggage.

I've been writing C# for literally 25 years.

I still choose .NET as the go-to whenever I can. On Windows or Linux.

I think the baggage view was valid for a while - but now we have a new generation of developers who only know about .Net Core and may not associate the Framework years in quite the same way.

I've been writing .NET code for 25 years too. I've tried a lot of other languages and platforms. Every time I've come back to .NET. All my web apps run on bare metal Kestrel under Linux which has come such a long way. I write all my Windows desktop apps in .NET too. Very clean code, easy to read, easy to write.

the APIs/primitives are so good too

I pretty much exclusively use .NET with AI for backend stuff and run it all in linux containers. It's really good. I generally try to stick to stock standard .NET with only a few popular packages where it makes sense. You don't actually need too many extra things as there's quite a lot built in. Even for CLI its ok, though it won't be the smallest binary.

I recently started a new project on .NET, mainly for its batteries included approach, seemingly a bit more serious ecosystem and the tooling AI agents can leverage during development and ops. Really happy so far, but too early and too small to have meaningful conclusions yet.

I'm especially interested in exploring F# as a concise, non ambiguous way to communicate definitions between humans and agents, somewhere between writing code like the olden days of yesteryear and describing things in English prose.

If you're going heavy into AI coding with C# (like approaching 100% AI code), give my 5 part writeup a read. Battle tested configuration with a fast moving team that was pretty much 100% AI code with good code quality. The configuration for `csharprepl` in particular is a special kind of unlock; having the agent be able to reach into the running DI container, wrap/replace functions while app is running just unlocks a lot of capabilities for the agent. It's the difference between an ultrasound and reaching in and manipulating the organ.

Oh, thank you, this looks really helpful at this stage!

Yes, the plan is essentially 100% AI code with a small team of programmers and domain experts from other technical backgrounds. But still depends on a few things on the business end before I can really kick it off. More of an exploration until then.

I'm just starting to get a handle on how to use agents, can you give a short description of how you get your agents to use csharprepl

I have more detail written up here: https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...

But the gist of it is that I wire it up through Aspire (don't need to, but makes it nice) to set the environment variable on my main app host. Then the agent can run `csharprepl` commands directly via CLI and read/mutate the running application state directly via the service provider (DI container)

I have a small set of utility functions to access the DI container with common patterns like creating a scope for scoped services: https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze... (optional, but useful)

And a skill: https://github.com/zeeq-ai/zeeq-app/blob/main/.agents/skills... (also optional, but cuts down on agents relearning the #wrap and #replace behavior)

I recommend you "train" the skill like I do in my the blog post. Basically ask the agent to get an instance of an object from DI like a repository class or your DbContext and have it perform some operations. Have it wrap a function and add logging. Have it replace a function. Then once it learns how to do this, have it write the skill bespoke to your project.

I strongly recommend that you try it "by hand" one time via blog of CSharpRepl author: https://fuqua.io/blog/2026/06/injecting-a-csharp-repl-into-a... If you try it manually one time, it clicks what the agent is doing and why it is so powerful (because the agent accesses and modifies the running application state without a compile).

It's certainly not a big topic of discussion online but it's powered all of the healthcare infra my career has been around. There's a lot of "dark matter" code written in C#.

The fact that when most devs look at C#, they can only see the silhouette of Microsoft is kind of making me mad sometimes, but I think it is understandable.

The corporate history of C# is undeniably strong, and even till this day in modern C#, they still have a lot of legacy components in it, like AppDomain, APM and MarshalByRefObject.

It is also unfortunately that C# has largely lost in the AI race, that it failed to gain tractions from AI developers despite heavy investments from Microsoft. Early AI stuff like Semantic Kernel actually included C# as its primary languages besides from Python. Nowadays it is not mentioned so much and the default is just Python but perhaps it really isn't a fair comparison due to the gravity of Python in AI as a whole.

Yet for another fact that even within Microsoft, Rust wins over C# for agentic development, is a clear indication that C# has lost a meaningful place in software development as its former parent started to berate it as well. TypeScript is rewritten in Go rather than C#, and consider the fact that Anders Hejlsberg made both C# and TypeScript...

Sure, maybe Bing and a large part of Azure and Xbox services still have heavily relying on it, probably because of ASP.NET Core and Orleans, but outside of the two Microsoft greenhouses, it is a free for all battle royale where C# don't even have a chance of being picked at due to being too weak.

I even tried to contribute a C# SDK to the Restate project, but the maintainers actively rejected it due to them not being familiar and refused the handover. They said they will consider if there are commercial fundings backing it, then they would starting to consider (that's even with money attached they would still think about it). This also shows how unpopular C#/dotnet is among open source development and failed to build hype. The same Restate project even have a Java SDK for it, so it is not like they can't handle C#, they just didn't like to.

The last few thing C# is good at is just Unity I'm afraid, and that is also dying too as Unity is also not doing so well lately.

Rust and C# serve different purposes. For things like CLI tooling and the Copilot SDK (supports Go, Python, JS/TS, Java, .NET), Rust makes total sense.

For web API backends and MCP servers, I firmly believe C# is the better choice.

For AI use cases (as in make calls to LLMs), there's not much difference, IMO from Python and C# and TypeScript. At the end of the day, those are all just REST API calls and SDKs are mostly wrappers around it.

For LoB apps where the AI/LLM is just one small leg of the actual flow, C# is still a winner, IMO, because of how good the overall stack is (e.g. EF Core). Orleans (actor model framework) is also super interesting and I'm exploring some memory/communication system based around it.

Semantic Kernel isn't getting updates because they've replaced it with Agent Framework.

It’s also awesome for SREs / SysOps / Whatever We Call Ourselves Today:

Opinionated in a good way, which means almost all C# apps have the same parameterisation with environment variables, command line, and config files. It’s all very systematic, consistent, but flexible and pluggable.

“Node has that too!” you’re about to say. Lol, no. It has bits and pieces the devs have to wire themselves, which means a fleet of vaguely related apps made by independent teams will have wildly different config styles. Good luck consistently making all of them pull API client certs from KMS or Key Vault, or whatever!

OpenTelemetry is now baked in to the core components and rapidly spreading through other libraries.

Excellent “pervasive” system APIs for spans, traces, metrics, and logs means that the sources are omnipresent and very rich, going back decades. Even very old third party libraries are often a breeze to instrument.

Debug snapshots from production crashes on App Service feels like cheating.

Built in container build outputs with no extra tooling.

Sane defaults for its package manager means far fewer nasty security surprises.

Far more first-party “coverage” of essential capabilities in the optional Microsoft packages so you don’t have to resort to NPM where your security-critical code is written by Sergei and support is “LOL Wut!?”

A GC that automatically responds to container limits instead of the host limits.

It uses thread pools for async tasks in most configurations so whole categories of production-time issues that occur with single threaded runtimes just doesn’t happen.

Etc, etc…

I think C# would be a great choice for both CLI apps and server less functions.

Other than that I totally agree with everything you said.

    > I think C# would be a great choice for both CLI apps and server less functions.

Really? I feel those are the two areas where it falls short. CLI apps and serverless both value cold starts and C# is not great at it because of the JIT overhead. The immaturity of NativeAOT ecosystem on C# was cited by Anders as one of the reasons the TS team chose to rewrite in Go.

I think by CLI apps they mean something more like Claude Code than ripgrep.

I write all my CLI apps in C#, but I hear you on the startup time. I guess it depends what you are working on whether that little hiccup is a problem. I've never once noticed it with anything I've written.

I’d be curious whether a CLI app written in C# would compare to one in Python for startup time. Python isn’t exactly a speed demon, but I use it constantly.

I may have to play with F# for that.

How does AI do with F#?

Motion shifted to C# around August of last year. Part of the reason, I suspect, is that the CTO (Hi Chander!) is an OCAML fanboy and F# was the most practical platform alternative.

We shifted all new product backend build to C# (because at this time last year, we were still "AI assisted" and deemed F# too foreign for most devs to read well), but all internal tooling was built on F#.

By maybe May of this year? We had multiple F# backend codebases, fully AI generated. Only one person on the entire team had worked with F# by hand. Several things work in F#'s favor even though it has a lot less representation in training: 1) the people that write F# really love F# so the code out in the wild is going to be better quality (hunch), 2) F# is a bit more terse/dense than C# and less noise in context, 3) F# benefits from the same tooling stack, 4) F# type system is still a bit more expressive than C#.

I know C# deeply so I know what good looks like and I know how to get agents to write good C#. F# I'm less familiar with, but we had great success with it.

AIs write pretty good F#, but there simply isn't very much of a reason to use F# over C# since Microsoft basically uses F# as an experimental test bed to test .NET features before bringing them into C#. Plus, annoyingly, F# doesn't interop well with existing C# projects which there is even less of a reason for existing .NET shops to adopt F#.

I also agree with this. When we were internally finalizing on C#/F#, I showed the CTO that most of what he liked about F# was already possible in C# (though requiring third party libs like OneOf or Dunet) with the benefit that C# syntax is more familiar for most folks. With 15, I think they are even closer now.

One of my favorite things about F# is what some would consider a deficiency: that within a project, files must be ordered and you may only refer to a symbol defined earlier, with the sole exception of types which are explicitly declared together in a single statement (`type X = ... and Y = ...`).

This in contrast to C# where, within one .csproj, there is no "order" and all classes and methods are able to mutually reference one another.

The F# way creates an annoying housekeeping step of maintaining file order, and would be a nightmare to do with manually edited .fsproj files (I have only ever written F# with an IDE), but IMO, it is worth it. On the reading side, it makes it easier to understand how a project you've never read before is structured, since you know the order of the F# source files also must be the bottom-to-top layering of the code. On the writing side, it sometimes causes one to rethink the architecture and simplify it to minimize the number of mutual declarations.

Built the massive enterprise backend of a super app fully in F#. From my experience, AI was able to write idiomatic F# code since Opus 4.8 (all models started doing very decent things around that period).

> Some folks out there still think .NET is Windows only.

Wait until you meet devs who don’t understand that other OS are a thing!

some folks here sound a little desperate