My point is that with C++, the programmer must often play a puzzle of avoiding common pitfalls with e.g. memory allocation - on top of the actual problem the programmer is intending to solve.

Both Rust and Go are more free from this kind of extra mental overhead.

This isn't entirely correct. Rust you do still need to worry about those same problems, it just gives you much better abstractions for modeling and thinking about them, and the tooling of the language "checks your homework" so to speak to make sure you didn't make any mistakes in how you were thinking about it. The upside is that you can be very specific about how you handle certain tasks allowing you to be super efficient with resources. The downside is that you do still need to worry about those resources at least a little bit. If you wanted to you could write Rust like Go by just making every variable a Box<Arc<...>> and using .clone() like mad, but your performance is going to take a hit.

Go (and other GCed) languages on the other hand, do entirely free you from having to worry about memory utilization in a general sense as the language runtime takes care of that for you. The downside is that it often does a poor job of doing so, and if you do run into one of the edge cases it's not so great at your tools for dealing with that are severely limited. Further it's very easy to accidentally screw up your memory usage and use far more than is necessary leading to excessive heap churn and serious performance degradation. Because the language makes it easy, even if what you're doing is wrong, and it lacks the tools to alert you to that problem before you trip over it at runtime.

Having a simple and verbose language is not necessarily a downside.

As programmers, our bread and butter is abstractions. We use abstractions because in a very real sense what we do day to day if we removed all the abstractions would be a herculean effort that not even the best of us could manage for any period of time. Go's idea of "simple" is limiting the number of abstractions that the language provides, and so it's up to the programmer to use that small handful to construct more powerful ones. Every code base becomes a snowflake where each team rolled their own solution, or everyone just uses the same sets of libraries that provide the solution. You haven't removed the complexity, you've just shifted it out of the language and onto a 3rd party. It's better to have a consistent set of abstractions provided and maintained by the language and centrally developed by everyone, rather than a hodge-podge of abstractions by random 3rd parties.

It is fair to compare speeds, I just think it's probably the wrong argument to focus on if you're trying to convince people of the value of a language. It's definitely a supporting point, but at the end of the day, most programs don't actually need to be blazingly fast, they just need to not be dog slow. Ease of writing (correct) code and even more importantly maintaining and debugging code are generally far more important factors in a languages success, and those are all areas that Rust excels in.

The problem with a purely speed focused argument is that it's always possible to cherry pick examples in both directions. You can find some piece of idiomatic Go code that just happens to be faster than the equivalent idiomatic Rust code and vice versa. The fact that it's undoubtedly much easier to find idiomatic Rust code that out performs most Go code (idiomatic or not) is a much harder argument to use to convince people. The Go proponents will just argue that the ease of understanding the Go code outweighs whatever speed gains Rust has. That's why I think it's important to also point out that Go might be easier to write small snippets of, but for any realistic program it's going to be harder to write and maintain, and it will be more prone to bugs.