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 y

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.