YHK - yet another hacker news clone

I have also found c# async to be lighter than go's concurrency story, and dotnet11 is going to make that much more clear.

Now: I write software for fun, not for money.

Also Go is at the stage of C# .NET 2.0, and still plenty of lacking language features.

I really think the creator of C# made a disservice to the .NET community by picking Go for the Typescript rewrite.

Sure, having a runtime is downside but difference in container size for your average CRUD App doesn't really matter. Performance IME is very similar.

Ops type here.

Put things like their remote debugging experiences side-by-side and you will quickly learn why some of us go for the Microsoft tools rather than the others.

My experience with Go is a while back, before it got generics. While I liked the overall idea of a language with little syntax and a focus on simplicity, I didn't really like Go in the end. It was a weird mix of too low-level and high level code. It exposed low level details that I don't need to think about in C#, and it is missing convenient abstractions like LINQ.

Personally, I like async/await in C# more than Go concurrency. I know this is heretical here, but I don't care about function coloring or any of the abstract advantages of other concurrency approaches. Async/Await in C# works for me (in non-legacy code) and is easy to understand.

I'm going to talk about the second part first. .NET is often deployed with a JIT compiler runtime like Java. That means that hello-world scripts use a lot more memory than Go, but that difference becomes a lot smaller on real-world programs and .NET can use less memory than Go depending on what you're doing.

C#'s concurrency can also be more efficient than Go's since it's coroutine based async/await is a lightweight state machine rather than green threads. That's not to say Go is especially heavy or anything, but it is more overhead.

In terms of "efficient in syntax", Go has a lot fewer features. That's one of Go's biggest strengths and weaknesses.

Here's an example. With Go, you just have struct tags: strings of anything that can be attached to a field in a struct. Let's say you have a User struct and you want to make it so the JSON won't have the user's email in it. You do: Email string `json:"-"`. But what if you mess up and write "jsom" or `json:-` without the quotes? It's basically a meaningless string to the compiler. With C#/.NET, you have annotatons/attributes that are a part of the language and checked as types. You'd do: [JsonIgnore] public string Email. JsonIgnore is an attribute class so your IDE can help you.

There's a lot in Go where the answer kinda becomes "f-it, we'll just use strings instead of having something meaningful." Go talks about how important error handling is, but then you get an error from a function and it's basically just a string. If you're doing good error handling, you want to handle different errors differently, but that's not easy in Go. Frankly, it's not easy in most languages, but this is definitely an area where it felt like Go gave up on creating something good in order to get something out the door quickly enough that Google didn't cancel the project. In a language like Zig, errors are enums and you get exhaustiveness checking. With Go, someone could add another error state to something you're using and you'd never know - or they could change the phrasing of an existing error and you'd silently stop matching on it.

Go's lambda syntax is clunky. func(x MyType) string { x.ToString(); } vs (x) => x.ToString()

There's lots of stuff like that. I'm not arguing that Go is bad, but it has a ton less stuff and that's both a blessing and a curse.

Golang is a fantastic delightful language, but it's still missing a lot of stuff that's existed in C# for years.

However, do you *need* all those .net tricks?

Golang is usually enough for a small project you need to build in a weekend. Scaling it to a mono repo with 200 developers might be a bit difficult

Go is for me just a, hmm, concurrency programming language. Its popularity stems just from being pushed by Google, and the cosmetics of using braces. Despite what pundits say, it's completely and utterly not like C.

While C# is a successful and comfortable everything-language. It is blazing fast, has amazing tooling, you can get going to prototyping, then enterprise code, its serverside handling is excellent. It has many low level features and built-in data structures. It's I would say preferable for almost any kind of work except scripting. (I really don't like C# scripting.)

Go's advantage is mostly the fast compile speed, goroutines, profiling, and a very opinionated formatter. Neither has an overwhelming advantage over the other though.

Some example.

Open API document generation using type handlers doing this in go was a pain in .net is comes out of the box.

A lot of people underestimate the power of extension methods.

.nets metadata system is compiled time safe where Go is not and this has burnt me a lot.

I really like go for command line tools Small binary sizes I lovely.

go's standard library is significantly more hackable than .nets there have been a few things where I've ended up using Go because to do it in .net would require me maintaining a fork of the standard library.

Go makes composing data insanely simple. where in .NET you can have an equivalency but it will be done via interfaces.

Go's Dark Type System is both great and really annoying.

C#'s stricter type system when it comes to interfaces can be really handy as that can be used as metadata to change how data is processed and enforce compile time checks.

There have been smaller runtime improvements like this one in recent releases, but this one seems a big one to point to to prove that the runtime is truly growing at a faster and more interesting pace than the old days.

The tooling ecosystem in Python is just so bad that I can barely stomach it after spending the last 20 years in .NET. At times, when supporting analysts at work wanting to write a little glue code, I've found their main complaint about C# is "curly braces" (which seems like a really odd thing to complain about, but ok) and I've found it easier to teach them a little VB than to figure out whatever the hell is going on with dependency and runtime version management in Python.

And then, for the folks who go deep on Python for ML tasks, I've mostly found them caring now about specific libraries than the language itself. I then show them how .NET has equivalent or better libraries available and that a lot of the code-golf stuff they do in Python has a much cleaner version in F#.

Or PowerShell if you want to hash out something really quick.

Once burned, twice shy.

Sinofsky left a lasting damage. The way things go with LLMs, it might be now pure app-specific Rust instead of any common frameworks....

I know this may as well be beseeched of the King of Nod, but if they just made WPF cross platform I'd be delighted beyond words.

https://github.com/iBobX/RapidR

Not compatible, but you can use it in a cross-platform way.

You can start reading through it starting at: https://github.com/dotnet/csharplang/blob/main/proposals/dis...

Definitely want to move to get this in asap :)

https://devblogs.microsoft.com/dotnet/performance-improvemen...

Not really for any groups that commonly use .Net. Even numbers are LTS and odd numbers are not, or at least it's been this way for a while.

>I have clients who refuse to budge from 2.1

Give me their names, sounds like it would be easy to penetrate them again and again and again with AI.

2.3 on .NET Framework reaches end of life on 2027-04-13, so upgrades have to happen soon.

It's still in support, and led to one of the most confusing release announcements in history: https://devblogs.microsoft.com/dotnet/servicing-release-advi...

ASP.NET Core 2.3 does go end of life in April 2027 however: https://devblogs.microsoft.com/dotnet/aspnet-core-2-3-end-of...

    (decimal)0.1f
    0.100000001490116119384765625

    > ...this could be a slam dunk runtime for an AI-native development environment.

    - Roslyn analyzers (C# code analyzers written in C# that run on the C# compiler)
    - Simple, stable tool chain
    - Language has largely been stable and backwards compatible for the two and half decades of its existence
    - Now have a very, very good type system that promotes good practices
    - Very good corpus of docs

It's actually crazy what the agent can do with that.

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.

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.

Other than that I totally agree with everything you said.

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.

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.

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…

Have to agree, PHP codebases also were nice organized, bigger repos, mostly web apps / company backoffice apps and so on. Personally, products were more interesting.

With today dotnet state, it really suits well for API development / microservices / integrations / we had many workers - jobs running, queue subscribers, K8S, good test coverage, open telemetry.

Even migrating from .NET Framework wasn't so big pain.

Job postings sucks nowadays for all stacks.

I prefer VS but for the performance, I use VS Code. Unable to work in Rider on 32 GB RAM.