[steveklabnik]

Sorry, just to be clear, I don’t know anything about Go’s crypto implementations, I was purely responding to the parent who claimed they were wrappers around asm.

I think we’re making two different points. I am talking about at a very high level, when people say “yeah it’s safe but there’s unsafe under there” that that is always the case at some point in the stack. Even a pure Go or pure Rust program ends up needing to interact with the underlying system, whose hardware isn’t safe. There is still some code that has to reach outside of the ability of the language to check that it conforms to their abstract machines in order to do things at that level.

I don’t disagree that minimizing the amount of unsafety is a good general goal. Or that because there’s unsafe inside, that the code is not overall safe. Quite the opposite! I’m saying that not only is it possible, but that it’s an inherent part of how we build safe abstractions in the first place.

(Oh and to be honest, I wish Rust had gotten the same level of investment around cryptography that Go has had. Big fan. Sucks it never happened for us. I’m glad to see continued improvements in the space, but like, I am not trying to say Go is bad here in any way.)

[GrumpySloth]

There is also the compiler. A language may claim to be implemented without any unsafe code in the standard library, but all that happened is the unsafe code got hidden in the compiler, in how it generates code, in intrinsics etc.