[cesarb]

> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture.

I've also seen something similar with Java, with its culture of "pure Java" code which reimplements everything in Java instead of calling into preexisting native libraries. What's common between Java and Go is that they don't play well with native code; they really want to have full control of the process, which is made harder by code running outside their runtime environment.

[kelnos]

I think it's important for managed/safe languages to have their own implementations of things, and avoid dropping down into C/C++ code unless absolutely necessary.

~13 years ago I needed to do DTLS (TLS-over-UDP) from a Java backend, something that would be exposed to the public internet. There were exactly zero Java DTLS implementations at the time, so I chose to write JNI bindings to OpenSSL. I was very unhappy with this: my choices were to 1) accept that my service could now segfault -- possibly in an exploitable way -- if there was a bug in my bindings or in OpenSSL's (not super well tested) DTLS code, or 2) write my own DTLS implementation in Java, and virtually guarantee I'd get something wrong and break it cryptographically.

These were not great choices, and I wished I had a Java DTLS implementation to use.

This is why in my Rust projects, I generally prefer to tell my dependencies to use rustls over native (usually OpenSSL) TLS when there's an option between the two. All the safety guarantees of my chosen language just disappear whenever I have to call out to a C library. Sure, now I have to worry about rustls having bugs (as a much less mature implementation), but at least in this case there are people working on it who actually know things about cryptography and security that I don't, and they've had third-party audits that give me more confidence.

[cesarb]

> or 2) write my own DTLS implementation in Java, and virtually guarantee I'd get something wrong and break it cryptographically.

Java doesn't have constant time guarantees, so for at least the cryptographic part you have to call to a non-Java library, ideally one which implements the cryptographic primitives in assembly (unfortunately, even C doesn't have constant time guarantees, though you can get close by using vector intrinsics).