Awesome stuff, as usual in .NET releases! The runtime async support is surprising to me... I get that stack traces are more friendly without state machines in the code, but I didn't expect they could switch to a runtime version and have equivalent performance. Cool!
They don't need to mark functions as needing special compilation / rewriting to support asynchronous use since the runtime provides the necessary mechanism to pause and resume (e.g. stackful continuations). So 'async' is unnecessary and 'await' can be a library function (or remain a keyword of course).
Does runtime async mean stackful coroutines? It's not obvious what exactly the state machines are replaced by, if not automatically inserted yield() calls.
I took it to mean that coroutines are still stackless but that yielding is now an operation the runtime knows about instead of being compiled out by the compiler.
For the features that overlap between golang and .Net, can someone please let me know why people choose .Net over golang for non legacy systems? As far as my limited knowledge goes, go is much more efficient in syntax and memory.
The languages are very different. C# has much more powerful abstractions and is a much larger language in general. That is both an advantage and a disadvantage. Modern C# is also very fast, I wouldn't bet on Go winning that comparison.
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.
Modern .net is surprisingly performant while also being very high level if needed. So it is very close to being a "learn once" ecosystem. This means you use it to write code for a much broader range of usecases than others, you will have a broader / more mature ecosystem than others, and your potential hiring market is more vast.
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.
Go is not much more efficient, compared to NativeAOT - though it can be faster in some areas. The big reason why someone would want to use C# is that it's a more expressive language. You can even write your DB queries with LINQ (C# lets you express code as data), making them type-safe.
I know it's not quite as important in the agentic world, but the .NET tooling (across Visual Studio, JetBrains Rider, and C# Dev Kit for VS Code) is just awesome. Some people might frown upon full-blown IDEs, but sometimes they're just incredibly handy.
To all the .NET outsiders, C# is indeed the .NET darling but you can also use F# if you feel like living in the future. Or VB if you feel nostalgic. So in .Net land, C# is not destiny. It is a choice
Awesome stuff, as usual in .NET releases! The runtime async support is surprising to me... I get that stack traces are more friendly without state machines in the code, but I didn't expect they could switch to a runtime version and have equivalent performance. Cool!
They did that after the learnings with experiment of having a Erlang, Go, Java like implementation for async, await.
Is this a joke, like "hen's teeth"? Those languages don't have async/await.
They don't need to mark functions as needing special compilation / rewriting to support asynchronous use since the runtime provides the necessary mechanism to pause and resume (e.g. stackful continuations). So 'async' is unnecessary and 'await' can be a library function (or remain a keyword of course).
No joke at all, not that I said "like implementation", not that they have async/await.
https://github.com/dotnet/runtimelab/issues/2398
Be sure to read all the way to the bottom,
Does runtime async mean stackful coroutines? It's not obvious what exactly the state machines are replaced by, if not automatically inserted yield() calls.
I took it to mean that coroutines are still stackless but that yielding is now an operation the runtime knows about instead of being compiled out by the compiler.
For the features that overlap between golang and .Net, can someone please let me know why people choose .Net over golang for non legacy systems? As far as my limited knowledge goes, go is much more efficient in syntax and memory.
The languages are very different. C# has much more powerful abstractions and is a much larger language in general. That is both an advantage and a disadvantage. Modern C# is also very fast, I wouldn't bet on Go winning that comparison.
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.
Modern .net is surprisingly performant while also being very high level if needed. So it is very close to being a "learn once" ecosystem. This means you use it to write code for a much broader range of usecases than others, you will have a broader / more mature ecosystem than others, and your potential hiring market is more vast.
Go isn't as much fun. And is usually slower for my work until I bump up the GC and then it uses roughly the same amount of memory.
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.
So for a requirement where both golang and .net would suffice, would you choose .Net over golang?
Yes. Unless I really need CSP, but then I would much rather use f#+hopac because CML is the bee's knees.
For general concurrency where async doesn't suffice, go is nicer than C#, but hopac is nicer than go.
If go had proper concurrentML I am pretty sure I would use go a lot more. Again: this is for hobby projects where I get to choose freely.
The tooling and development UX.
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.
Go is not much more efficient, compared to NativeAOT - though it can be faster in some areas. The big reason why someone would want to use C# is that it's a more expressive language. You can even write your DB queries with LINQ (C# lets you express code as data), making them type-safe.
I know it's not quite as important in the agentic world, but the .NET tooling (across Visual Studio, JetBrains Rider, and C# Dev Kit for VS Code) is just awesome. Some people might frown upon full-blown IDEs, but sometimes they're just incredibly handy.
Even the non-visual stuff is pretty awesome, claude is able to trace and profile .NET code without skills or MCPs.
That is an urban myth, CLR was designed with support for C++ in mind.
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.
At former jobs, because people know it and switching from .Net <-> Go generally isn't worth the time to learn other language.
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.
Native interop is much better in .NET, that matters a lot for some systems.
What's go's equivalent of LINQ?
To all the .NET outsiders, C# is indeed the .NET darling but you can also use F# if you feel like living in the future. Or VB if you feel nostalgic. So in .Net land, C# is not destiny. It is a choice
I am looking forward to async stack traces being more legible. It might encourage developers to actually read and use them.