3 ms·
Trading this for simplifying the remaining 99% of my code is a tradeoff I'm willing to make. The vast majority of projects don't use CGo, and of those that do,
by cube2222 4y ago
Trading this for simplifying the remaining 99% of my code is a tradeoff I'm willing to make.
The vast majority of projects don't use CGo, and of those that do, the majority doesn't call CGo in a tight loop, making the performance impact mostly irrelevant.
So it's really coming back to the performance-orientedness of a language.
- int_19h 4y agoThe practical end result is an insular ecosystem that tends to rewrite code "in pure Go" rather than reusing existing libraries. To the point where this attitude resulted in the standard library of Go breaking on occasions because they tried to go around libc on macOS and use syscalls directly (which are not guaranteed to be stable). .NET is the opposite - it was designed from the get-go from cross-language and cross-runtime interop. Back when Java folk still had to struggle with JNI to use anything native, .NET 1.0 had P/Invoke and COM Interop. And now that it has async/await, it's all mapped down to a C-compatible ABI for interop purposes, so you can easily write async code in C# that calls into async code written in C++ that calls back into C# etc.