4 ms·

As someone who doesn’t know a lot about go: why is CGo-free a feature? In what situations is CGo (which is basically just calling C libs from go, right?) bad?

cedws 2y ago
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.
- cle 2y ago
  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.
  - Onavo 2y ago
    Why don't they just compile to C to Go like modern c does for SQLite?
    - masklinn 2y ago
      https://news.ycombinator.com/item?id=42271142 https://news.ycombinator.com/item?id=42271142
      - Onavo 2y ago
        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.
danenania 2y ago
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.
- wild_egg 2y ago
  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.
  - AYBABTME 2y ago
    Example? Curious, can Zig can be used to simplify CGO dependency management in general, or only for Zig programs?
    - wffurr 2y ago
      Zig is a C compiler. Much like D, you can use it to cross compile any C code.
    - rockorager 2y ago
      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.
    - kristoff_it 2y ago
      https://zig.news/kristoff/building-sqlite-with-cgo-for-every-os-4cic https://zig.news/kristoff/building-sqlite-with-cgo-for-every...
  - karel-3d 2y ago
    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?
wokwokwok 2y ago
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.
- AYBABTME 2y ago
  It can be slower than pure Go options in some scenarios.
  - wokwokwok 2y ago
    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.
- paride5745 2y ago
  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.
tedunangst 2y ago
By eliminating cgo, they cut the supported platform list in half.
int_19h 2y ago
FFI mess is the price Go pays for having its own bespoke green threads (goroutines).
kunley 2y ago
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 https://dave.cheney.net/2016/01/18/cgo-is-not-go
tc4v 2y ago
https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go
binarin 2y ago
CGo compilation can be insanely slow.

cedws 2y ago

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.

cle 2y ago
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.
- Onavo 2y ago
  Why don't they just compile to C to Go like modern c does for SQLite?
  - masklinn 2y ago
    https://news.ycombinator.com/item?id=42271142 https://news.ycombinator.com/item?id=42271142
    - Onavo 2y ago
      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.

danenania 2y ago

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.

wild_egg 2y ago
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.
- AYBABTME 2y ago
  Example? Curious, can Zig can be used to simplify CGO dependency management in general, or only for Zig programs?
  - wffurr 2y ago
    Zig is a C compiler. Much like D, you can use it to cross compile any C code.
  - rockorager 2y ago
    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.
  - kristoff_it 2y ago
    https://zig.news/kristoff/building-sqlite-with-cgo-for-every-os-4cic https://zig.news/kristoff/building-sqlite-with-cgo-for-every...
- karel-3d 2y ago
  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?

wokwokwok 2y ago

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.

AYBABTME 2y ago
It can be slower than pure Go options in some scenarios.
- wokwokwok 2y ago
  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.
paride5745 2y ago
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.

tedunangst 2y ago

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

int_19h 2y ago

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

kunley 2y ago

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 https://dave.cheney.net/2016/01/18/cgo-is-not-go

tc4v 2y ago

https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go

binarin 2y ago

CGo compilation can be insanely slow.