FWIW I think that cgo itself is rather underrated — or rather,
undersold by purists. You *don't* have to give up anything
significant, except for some convenience at the interface
(pointer-passing rules to avoid confusing the garbage collector), and
some build time (which is still acceptable). And sure, if you use
shared libraries, you have to ensure that they actually make it to the
target machine. That's inherent in the definition. But you're not
locking yourself out of anything in terms of performance,
expressiveness, or safety. My company has products that simply
wouldn't fly without cgo, because there are some codebases that you
simply can't port wholesale, and cannot replace with a half-baked
At least for me, cgo means giving up some of Go's biggest strengths.
With the C dependency, cross-compilation and library management is just
as troublesome as it would be with C. (Yes, I do both often in C.) I
really like Go and enjoy programming in it, but C is still my personal
favorite programming language. If I'm going to accept the worst parts of
C, then I'd rather just do the project in C in the first place.
If you really want to avoid C, then I completely understand how cgo is a
great tool for doing so.