"Memory corruption vulnerabilities" != "concurrency bugs" or even data corruption. The last thread I was in about this, someone pointed to Go segfaults and said "see! memory corruption!" (obviously: no).
An easy response to claims like this: there's a huge tower of software written Go at this point, including the entire K8s ecosystem. Show me the memory corruption exploits.
The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword.
The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind.
Unsafe in a language like Go is very rare, mostly because people do not program at such low system level to get the max performance out of it.
Rust code with unsafe: 1.7M
Go code with unsafe: 400k
and for comparison, Go has about 2.3x the amount of repo's. So Rust has about a 10x more usage of the unsafe keyword.
I didn't downvote you and couldn't have (you were replying to me).
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
tptacek