[jaen]

C# is a great language with almost unlimited power and great ergonomics (as the article shows), but the .NET CLR (runtime) is a bit overcomplicated with a distinct "Java smell", and packaging and distribution is still meh.

If they could make the developer experience similar to Go, it would rule the world...

[Rohansi]

> If they could make the developer experience similar to Go, it would rule the world...

You can already AOT compile .NET software to an executable to run on whichever platform you need, just like Go.

Libraries need to be published into a package manager (NuGet) which is more friction than just importing from Git repos but it's not that bad.

[hnrodey]

AOT is not a panacea and comes with some restrictions/trade-offs that need understood before depending on it in production.

[Rohansi]

You also have the option to do single file deployment where it self-extracts the runtime when you run it. It's not as nice but it works and maintains full compatibility.

[hnrodey]

While that is nice it’s not AOT, is it?

[Rohansi]

Yes, but it's still a single-file deployment option that can easily cross-compile. Just with slower startups.

[ziml77]

Losing dynamic PGO by using AOT compilation could be a detriment to performance in long-running applications, right?

[peter_griffin]

wouldn't you have the same restrictions/tradeoffs using go (or other compiled languages)?

I've never used go, am curious

[Rohansi]

Pretty much, yes. For example reflection is severely limited in .NET AOT vs. JIT, runtime generated code is more common than you'd think and cannot be done AOT. Go was designed for AOT so they already built everything around the limitations because it never supported more.

It'll just take time for .NET to catch up where the dependencies you need automatically work with AOT builds.

[Rohansi]

shaddap

[landl0rd]

I actually really like the CLR developer experience next to java ngl. I reach for C# in lieu of java (less J2EE SingletonBeanFactoryManagerInstance slop) but particularly F# is pretty nice to use. Haskell has bad tooling, OCaml is getting better thanks to JaneStreet (and if OxCaml gets wide adoption unboxed types are a big perf win) but if nothing else lack of a Rider-esque debugger is just a big time sink.

[karmakaze]

I drank the Go kool-aid, then tried to do some high performance things the Go way: didn't work (channels are slow) and I got over it. Still think Go is great for web backends and the like with production grade stdlib.

Great post with details, not a I'm vibe coding...

[benterix]

> tried to do some high performance things the Go way: didn't work (channels are slow) and I got over it.

What did you choose instead?