.NET team member here. We haven't invested any effort into this particular benchmark. We're happy to invest in benchmarks that have well-defined (and enforced)

.NET team member here. We haven't invested any effort into this particular benchmark. We're happy to invest in benchmarks that have well-defined (and enforced) rules on entries. Our understanding is that the "game" part of "benchmarkgame" is appropriately descriptive. We have put a lot of effort into the TechEmpower benchmarks. In terms of .NET performance, we've made significant improvements [1] with each release. If there was a gap between C# and other languages before, it is likely that it is much smaller now due to our efforts. We have a balanced view on performance. We are investing in application throughput, latency, memory usage and disk footprint. Most .NET users care about multiple of those things. We also hear from users who care disproportionately about just one of them. This motivates us to care about all of these things, although throughput and memory usage is where the biggest gains are. I have this (not very good) joke that many .NET developers until recently would not have been able to accurately describe what structs were (as opposed to classes). To a large degree this was because we used them in very narrow ways in the products. That has changed a lot in the last few years. ValueTuple, ValueTask and Span are all good examples. The culture of the .NET has changed and so is the .NET community around us. This will result in higher performance code more generally within typical .NET applications (as opposed to some theoretical outcome). If this happens, and I do believe it will, .NET will be forever changed in a pretty radical (or at least "rad") way. [1] https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/ https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performan...