Memory issues are amplified a bit by garbage collection though, in that every pointer must be stored twice, and collection will take time and evict things from cpu cache etc.
If you were struggling with this, turning to Rust might be a thing people would try, even if it wasn't fixing the first order problems, and only addressing the 2nd order ones.
A bit yea, but it is somewhat telling that their first instinct was to find a GC "knob" and twist it around until they could go back to ignoring their basic architecture.
Go and Rust are great in that they let you write code at good speed, although, I think this just highlights the well known problems of over optimizing a single metric.
I would call this a language issue as you need to understand the various abstractions and how they interact which is endemic to almost all languages, ideally a language would type system to express resource usage
I assume it's tongue-in-cheek; because "rewrite in Rust to improve performance" is such a meme, the headline is subtly calling attention to the fact that this is rarely good advice and certainly not the first lever an engineer should reach for upon running into a performance problem.
It's not the first lever an engineer should reach for regardless of the languages involved. Calling out Rust specifically feels like a bit of a cheap shot
And Go too! It's always fun to see posts from around 2014/2015 complaining about how every submission to Hacker News is now "I wrote X in Go", while now Go is the boring stuff and Rust is the hot new thing. I wonder what will be the next Rust though.
They are, but they also are too big, so at some point people will want to replace them with something simpler/smaller. Go has been used for this for some projects in C++ and Python.