And they now have to deal with the same kind of timing attacks related stuff as everybody else https://github.com/golang/go/issues/49702 (and they'll likely lag behind)
Do you know of any cryptography implementation that sets the Data Independent Timing flag? We've been trying to figure out what others are doing about it, because as far as I can tell nobody is.
Anyway, not sure why relying on C/C++ would have helped us here.
The point is not about relying on C/C++, it's about using existing implementations instead of re-inventing the wheel all the time. This is a cultural thing when it comes to Go and it has bitten them multiple times, like when they tried not to use the system's libc on MacOS or when they had issues when dealing with memory pages on Linux.
Good to know there's someone in charge specifically of the cryptographic stuff for Go at Google though.
Go has good reasons not to bring C/C++ into every build, starting from the ability to cleanly cross-compile.
I can't comment on the rest, but the security track record of the crypto libraries is stellar compared to pretty much any other library (and it already was before my tenure).
(BTW, I am not at Google anymore, although I still maintain specifically the crypto libraries.)
Anyway, not sure why relying on C/C++ would have helped us here.