4 ms·
Definitely possible! However, I prefer to avoid cgo wherever possible for more than just the overhead. In my experience: - It complicates builds by requiring
by camdencheek 3y ago
Definitely possible! However, I prefer to avoid cgo wherever possible for more than just the overhead.
In my experience:
- It complicates builds by requiring a C toolchain
- It makes single, static binaries more difficult
- It makes portability more difficult (not that assembly is portable though)
- It causes difficult-to-debug issues (I recently ran into an issue where MacOS signing changed, causing all my cgo binaries to be killed on startup)
- Debuggers don't work across Cgo boundaries (they do with go ASM!)
I think Dave Cheney said it best: https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go
- pjmlp 3y agoThe whole "cgo is not Go" bashing is a kind of joke, maybe if Go 2 ever comes to light, one of the first breaking changes should be to remove cgo. There, beautiful Go code from that point onwards.
- beautron 3y agoDear Lord, no! I depend on cgo for my game! What's more, I have no complaints about cgo. It hasn't been a performance problem at all (my game runs smoothly at 240hz). And the interface for binding to C is quite simple and nice to work with (I made my own bindings to SDL2, OpenGL, and Steamworks). Cgo did make cross-compiling trickier to set up, but I managed to do it with a fair amount of elbow grease (Windows and MacOS builds on my Linux desktop).
- pjmlp 3y agoThat is my point with my sarcastic remark, cgo should be embraced for the workflows it offers, instead of the whole "cgo is not Go" drama.