Most languages share a runtime and stack model with C. Go is "unique" among popular languages in that it decided to do its own thing, which results in much slower FFI calls. Like sure, so did GHC, but most people don't expect GHC to behave like C.
TBH it's enough to put me off of the language outside of writing servers. There's just too much to draw from in terms of libc-based libraries and the drawbacks in Go are too severe to make its interesting concurrency ideas generally worth it.
EDIT: Not to mention if you have WASI as a target go is a terrible choice for the exact same reasons—it has its unique memory and stack model that don't work well with web assembly.
Again, people throw around "much slower" and it comes off like it's 100ms or something. It's not that much slower, it's not even close.
It's only an issue if you're planning on making tens or hundreds of thousands of FFI calls per second, routinely. That describes a non-zero set of software people may want to write. If you are writing one of them, you need to know that. But it doesn't describe anything like a majority of software cases in general.
It is one of the things you need to know, but you need to have a correct view of the costs to make correct decisions, or, at least, not one that's off by orders of magnitude and leads to people running around claiming Go is "uniquely slow" at FFI and bragging about how much faster Python is when it turns out "uniquely slow" Go is actually faster than Python. Costs aren't a matter of feelings or what reinforces your decisions about what language to use or how much you hate that Go doesn't have sum types. Costs are what they are.
My personal favorite, and bear with me because this is going to be generally a negative for Go, is the number of databases that for some reason are getting written in Go. My rule of thumb is that Go is 2-3x slower than C/C++ (and, increasingly in that set, Rust). On the grand landscape of programming languages, this puts it distinctly towards the faster end in a general sense; there are very popular languages clocking in at "generally 40x-50x slower and also can't use more than one CPU at a time". But if you're writing a database, you're going into a market where it's virtually guaranteed that's going to be a problem. Maybe don't do that. But then deciding that you aren't going to use Go to write your command-line app to hit an HTTP API because it's not the fastest language for databases is not a correct engineering conclusion to draw.
The idea that a feature isn't that slow if you don't use it much isn't very persuasive.
You could also flip this argument on its head. What is go good at? Writing evented servers. If you're writing one of these you'll know it.
Also, I admit I was wrong; go doesn't have uniquely bad ffi. It's just worse than C++, rust, D, jvm, .net, and any compiler lisp I've ever used. Perhaps go is uniquely well suited to writing stuff other than evented servers in way I just can't see yet.
(And FWIW I am still baffled how python managed to be this slow without needing to switch stacks.)
Most languages share a runtime and stack model with C. Go is "unique" among popular languages in that it decided to do its own thing, which results in much slower FFI calls. Like sure, so did GHC, but most people don't expect GHC to behave like C.
TBH it's enough to put me off of the language outside of writing servers. There's just too much to draw from in terms of libc-based libraries and the drawbacks in Go are too severe to make its interesting concurrency ideas generally worth it.
EDIT: Not to mention if you have WASI as a target go is a terrible choice for the exact same reasons—it has its unique memory and stack model that don't work well with web assembly.