[sluongng]

> For performance, Go using CGO is going to be closer to Python than Go.

This is not true. In a lot of libraries, unless there are asm implementations on the pure Go side, the CGO implementation often outperforms. Zstd used to be one of the most notable example.

> CGO is slow and often still painful to build cross platform.

This is true. I found that using Bazel to manage the entire build graph made CGO a lot easier to deal with. By adopting Bazel, you formalize the cost of operating a cc toolchain and sysroot up front instead of hiding it inside nested layers of environment variables and CI container images. Bazel also made your build faster and cross-platform CGO easier.

> Go is no longer able to be built into a single static binary.

The "C" portion of CGO can be made static as well. It often results in a much bigger binary than a dynamically-linked binary though. In setups where you control the runtime environment (i.e. web servers), I don't see a clear benefit in shipping duplicate bytes inside a static binary. Even for consumer-facing use cases (i.e. devtools), a static binary can be too big and unwieldy versus just a set of pre-built binaries targeting specific platforms via Github Release.