|
|
|
|
|
|
by _ph_
2405 days ago
|
|
|
Which isn't a contratiction to the statement, that for the programmer the C interop is simple and elegant. Which I think mostly it is. The slowness comes from what goes on behind the szenes. Mostly the different way of handling stacks between Go and C creates quite some effort when calling into C and returning. Those languages, which use "C compatible" stack and register layouts get much faster C calling. That doesn't mean, they can call C as easily. So calling C from Go for small functions isn't a performance gain. You should write those in Go. The calling of C is great for linking against larger libraries, which cannot be ported to Go. And for that it works nicely and is fast enough. |
|
|
I find I use Go quite often to build relatively compact tools and services that need to use some features of a fully-featured and popular C library to perform some complex function that would be expensive and time-consuming to implement.
A recent example of this is using `libusb` and `libgphoto2` to enumerate DSLR cameras attached over USB and capture images from them in response to some other events, with a small web UI on top. It's maybe a few dozen lines of Go to call some enumeration and capture functions, and then I get a nice byte slice with all the data I want. There is minimal friction, the interaction is clear, and any performance cost is worth paying because of the simplicity of the interaction.
It's entirely true, and a well-known caveat, that the C FFI is slow. This makes it inappropriate for some use-cases, but entirely suitable for others.