Whether FIPS 140 is actually a good target for cryptography is another question
Answer to that question: it is not. It's a thing you only do when you are forced to by some requisitions process.
Answer to that question: it is not. It's a thing you only do when you are forced to by some requisitions process.
We're going through a FIPS compliance project right now and it's nothing more than a miserably expensive set of check boxes. Contractor they hired is incompetent so that isn't helping either.
With OpenSSL installed system wide you can turn on a flag and the library will force it into FIPS mode internally, with Go unless you build your binaries to link against OpenSSL like this Microsoft Go release seems to be doing you don't get that instant on system wide.
It's just unfortunate for the many orgs delivering software that eventually customers start demanding this and it was really painful in Go.
Golang projects however don't compile against OpenSSL instead using the internal cryptography. In many cases rebuilding and repackaging a Golang based tool is a no-no since now you are accepting ownership of it in an audit, when instead you want to point to an upstream vendor, or source code is not available.
So in many cases in production while the system itself is in FIPS mode (Linux kernel), and applications using system crypto libraries (OpenSSL primarily) are in FIPS mode, Go binaries are not in FIPS mode and may end up using algorithms that are explicitly disallowed by the FIPS standards.
We created software and we wanted it to be secure (by ourselves). When it came to FIPS compliance, we had to pay for certification, but we were already compliant anyway, so it was only procedure.
It's definitely not as strict as the latest developments in crypto would demand, but it does cover the product in its entirety. Like, oh, you have encryption, but you have a backdoor here: not FIPS-2 compliant.
So, yes, plenty of software and products are FIPS compliant. And if it's mandated, then the provider is not chosen.
If you're already compliant (implying you are using FIPS compliant crypto in all situations), the matter is tautological.
My experience lies mostly in C and embedded applications, where the physical security was also in question and that is where the most of the effort to certify went. Software was relatively easy by using the right versions. So, maybe not just a certification, but non-fretting one.