Author here. I have read somewhere (and have two links in the post) that the FFI transition between native code and Go has huge overhead because of Go runtime and bookkeeping Go has to do for making such call safe. But calling Rust e.g. from C# P/Invoke has the same cost as calling C library. So the point is that writing a complete program in Go is probably better or equal, e.g. some network utility. But if I write a shared library that I call a lot from C# via P/Invoke, Go will have much higher overhead. This may be wrong for the latest Go versions, I researched that around a year ago.
I mean talking to Go from C or any other language as if Go was replacing a C library. Could not find low-level detail on this, but I remember it used to be very slow. E.g. PInvoke has an overhead of between 10 and 30 x86 instructions per call, which is quite small.
Actually I'm not sure if that is possible now to call Go from C via some C ABI/ABI. I looked into CGO in the past.
Alternative to Go, the ease of talking to C could get simple, V language which transpile into C code with minimal overhead, still infancy at this stage, the end goals is to translate C source to readable V code.
