I think it is because I generally look at a given benchmark there and don't browse below the "optimized" section to look at solutions that use intrinsics directly. Being able to use intrinsics directly is a great feature, but doesn't fit in with the whole "fast but not so fast I need to worry about safety" theme. When you exclude solutions that use intrinsics, go is faster. I use rust as my daily driver at work and home. I don't think I'd select either go or c# for a project. When I just want something that works, and I'm not worried about performance, rust is easy to use. It is only when I'm trying to squeeze out performance it gets hard. It is hard to convince go that it is safe to skip bounds checks, and while writing intrinsics isn't hard, it isn't very portable and you have to write lots of versions unless you metaprogram it, which I find harder than idiomatic code in any of these languages. Squeezing out performance is easy in c++, even in c++17, but it usually entails doing something that will "probably always be ok". Doing stuff like that repeatedly adds up to frequent issues.

> I generally look at a given benchmark there

Which? Just curious.

Some-of the spectral-norm programs seem quite similar:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Hi! Thanks for the update! I usually look at your curated list of "idiomatic/optimized/non-portable and unsafe" but in the list you noted the c# solutions faster than go had intrinsics.

Those benchmarks were debunked, they don't represent anything.

Where were they "debunked" ? Please share.

You just need to look at the c# implementation.

Here's a Go program and a C# program. Please explain your comment —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...