Agreed. I've recently translated a pangram generator project written in Rust [1] leveraging SIMD to do the same in Go [2] to see how it fairs in terms of speed - the results are pretty close. In my local machine I'm getting ~3GHz in Rust vs ~2.4GHz in Go, which I think is really impressive.
I still believe that SIMD support is one of the most underrated new features in Go.
It's relatively straightforward to read and to write code using Go's SIMD package (the caveat being that you have to convert your data to SoA manually), and it gives comparable performance to other languages, since there's little in the way of GC overhead, bounds checking, etc, in this case.
So SIMD not only increases performance on its own, but it also closes the performance gap between Go and C++ / Rust, which has been a major cause for rewrites in the past. The memory usage overhead due to GC doesn't go anywhere of course, so there are still performance reasons to "Rewrite in Rust", but it's now become much easier to just optimise the hell out of Go code instead.
Odin solves this by letting you declare all arrays as either normal (AoS) or SoA, which helps with this use case a lot. Otherwise very similar ideas, except all the memory goodies. Underrated language!
This was one of the times where it made some sense. A lot of their complaints were about GC, which Discord has had issues with in the past on other things. Notably, Discord switched from Cassandra to ScyllaDB for their messages, and cited the Java GC as a big reason.
Sure a SIMD expert writing assembly can probably do a better job than an LLM using these new intrinsics, but it’s still massively faster.