Comment by tptacek
Given the total lack of empirical evidence (that is: language-specific vulnerabilities in the myriad large high-profile Go projects run all over the Internet; instances of bug classes not found in other mainstream memory-safe languages --- "memory-safe" here just to factor C/C++ out of that set) for those security concerns, why do you prioritize them?
We of course continue to find SQLI, authz, SSRF, metacharacter parsing and cryptography vulnerabilities in Go codebases, the same way we do in literally every general-purpose programming language; what the the vulnerabilities we actually see, over 15 years of explosive growth in use, that are distinctive to Go? It's been 4 years since I was a full-time software security person, but I keep up, and did a lot of work in Go before then, and I'm not aware of anything beyond "if you skip the ,ok on a type conversion you might panic something".
I must say that I really appreciate your patience in addressing these comments. If the possibility of race conditions leading to UB and the lack of sum types in Go are so bad for security, then it shouldn't be difficult to observe exploitable vulnerabilities in real-world Go code bases.