It makes cross-compiling a lot more difficult. Instead of being able to build on whatever OS/architecture you use and produce binaries for any other OS/architecture you want to target with a single command (one of Go's superpowers), you need a complex build pipeline.

I've been using zig's toolchain in CGo projects for a couple years now and cross compilation _just works_. Maybe there are libraries it doesn't handle well but so far all of my use cases have been covered perfectly.

Example? Curious, can Zig can be used to simplify CGO dependency management in general, or only for Zig programs?

It could definitely work for that. You have to think of zig in this context as a build system which can download and compile C/C++ codebases.

Zig is a C compiler. Much like D, you can use it to cross compile any C code.

I have personally hit some roadblock before that I cannot really remember anymore, so I just gave up and used debian docker image.

(Which needed to be old enough that it had old glibc, so someone with 10 year old OS doesn't complain. Linux.)

zig gets around that by using musl, right? or does it use old libc?

Note that modernc/cznic stuff is not really actual go but C trans-compiled to Go, the trans-compiler having specific quirks for every platform,.

So it's not technically possible to compile to all platforms that Go runs on, only the platforms that the trans-compiler supports. And the resulting Go code is not that readable.

https://gitlab.com/cznic/libtcl9.0/-/blob/master/libtcl9_0_l...

https://pkg.go.dev/modernc.org/ccgo/v3

But it still improves cross-compiling, and results in a libc independent static binary, which is nice. And the work done on the trans-compiling is great.

FFI is an additional headache. Instead of having a single hermetic build process that just works, with FFI you now have to deal with shared libraries which may or may not be present, and may or may not support all the architectures or operating systems you want to target. FFI is why so many Python projects blow up when you run pip install. Then it takes sometimes hours to untangle that horror show.

This is using purego which is still using FFI, it is dynamically linking the C libs so you still have the same shared library issues. You don’t have to setup a C compiler toolchain though which is nice.

Why don't they just compile to C to Go like modern c does for SQLite?

I mean why don't they do it for the source library too? There are very few operations in C that can't be done in Go (mostly inline assembly and some pointer manipulation) under a standard userland assumption.

It’s not a technical thing.

It’s not bad.

It’s a misguided community thing.

Cgo is the correct choice for many domains (ui, gamedev, systems stuff) where you can’t use a network boundary as your “interacts with other languages”.

The language is opinionated; it’s not good at playing with others. It’s good at other things (network services, etc)… but you can and it’s not bad.

…it’s just hard, and people don’t like hard things.

It can be slower than pure Go options in some scenarios.

Purego is ffi and is slower than cgo.

That library (like this) claim “no cgo” when they use ffi is just ridiculous.

This one is particularly egregious in even supporting cgo!

Pure go my ass. You’re invoking c functions. It’s not pure go.

The distinction is in the tool chain; cgo is a better, first party solution.

Purego is an unstable (it is, read the repo!) workaround for people who a) don’t like the word “cgo” or b) dont like having a c tool chain.

…but realistically you have to interop with c code in many domains.

Sure, a pure world is great, but that’s not always possible.

People who don’t like cgo and choose purego are doing it for, mostly, optics (cgo is bad! This isn’t cgo… it’s ffi… totally different) and appear to fail to appreciate the technical distinction more complicated than they imagine, and they are still using c.

Cgo in server projects makes using Alpine as a base a headache honestly.

If I can I always pick pure Go solutions just for this reason.

By eliminating cgo, they cut the supported platform list in half.

FFI mess is the price Go pays for having its own bespoke green threads (goroutines).

Being CGo-free is very desirable when you can't/don't want/don't bother to link C library deps for some reason. On example when you don't want to do that is cross-compiling for another architecture and not really being able to control what runtime libraries are installed on the target.

So, it simplifies build pipelines, at the cost of being a bit slower in the runtime.

This is also nice to read about the topic: https://dave.cheney.net/2016/01/18/cgo-is-not-go

CGo compilation can be insanely slow.