3 ms·
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 a
by buybackoff 7y ago
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.
- gameswithgo 7y agoThe higher overhead of talking to C from Go (as compared to C#/Java) has not changed, and likely won't. And of course, C# and Java also have overhead.
- buybackoff 7y agoI 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.
- proyb2 7y agoAlternative 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. https://vlang.io https://vlang.io
- kjeetgill 7y agoI think you and the parent agree. Go and Rust don't overlap/compete enough to be interesting comparisons, especially considering how often the comparison comes up
- deleted 7y ago[deleted]