I can't imagine a better setup for a language flame war :). I really like debating languages, so I hope it doesn't go that direction.<p>One of the standard caveats with this particular benchmark game with respect to Go is idiomatic optimizations are prohibited. To use the btree example, Go's memory management is low latency and non-moving, so allocations are expensive--any Go programmer writing a performance-sensitive btree implementation would pre-allocate the nodes in a single allocation--an absolutely idiomatic and <i>trivial</i> optimization--but the benchmark game requires that the nodes are allocated one at a time. In other words, the C# version is idiomatic, but the Go version is expressly contrived to be slower--not a very useful comparison.<p>Mad respect for .Net though; it's really impressive, I like the direction it's going, I'm glad it exists, etc.
When you see how much effort it takes to C# and Java to optimize the runtime, there are a lot of people working on that. C# is fast but you see that it uses between 2 and 32 times the memory that Go needs.<p>Overall you can see how fast Go is, it has little optimization compare to C# and it's as fast. Compare this: <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-go-3.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a> and overly complicated C# version: <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-csharpcore-6.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a> ( avx, Intrinsics etc ... )
The focus on performance since Core is really nice to see, dotnet 6 is continuing the trend as well: <a href="https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/" rel="nofollow">https://devblogs.microsoft.com/dotnet/performance-improvemen...</a>
I prefer C#. But here the Go code actually looks like normal production code while the C# examples look like something made by a low-level optimization wizard.
I enjoy using both languages. The significant performance difference between the two for me is compilation speed. Size of binaries produced is also important if you’re shipping them around.
I say modern .NET is a marvel of features, development tools, interoperability, performance and even ships with its own cloud environment (Azure).<p>Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today.
I was always under the impression that Go never had a great optimizing compiler. It was never a primary focus given the limited developer resources.<p>I couldn’t find a direct C# to Rust comparison but Rust trying to compete with C++ means performance is a goal, if that’s what you are after.<p><a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a>
I'm not really concerned with such small differences in speed, to be honest. The thing that I look for is: how productive am I when using language X?
It's 2021 and .NET developers still argue which coding style they should adopt and how they should enforce it. It's totally mind numbing that team members are split between implicit and explicit variable naming. Contrary, in Go you just write code because those nuances should not matter.
I've never understood why folks treat the Benchmarks Game results as indicative nor representative of anything useful. The code specimens they use are often unpolished nor idiomatic, without even commenting on whether they could be made to perform better through Byzantine, careful by-hand optimization.<p>Why does their web site have no contact nor link to where the source code for the project can be checked out, contributed to, or amended?