Are rewrites from Go to Rust for performance reasons really that common?
Re:Go 1.27
by nasretdinov on Thursday August 20, 2026 @08:39AM
(#49373816)
Hard to say tbh, but there are some high-profile examples, e.g. from Discord: https://discord.com/blog/why-discord-is-switching-from-go-to...
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.
I think it only really happens when companies run into GC problems
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!
Re:Go 1.27
by nasretdinov on Thursday August 20, 2026 @09:09AM
(#49374140)
Yeah, Odin's auto-SoA looks nice indeed
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.