I think all the points that the author complains about are valid. I believe some libraries like Arrow chose a completely different approach to supporting Go altogether: https://github.com/apache/arrow-go#performance . They effectively compile C code to Go assembly and thus avoid paying the cost of cgo, and get the benefits of having a lot more control over performance and data structures layout that C gives. I am obviously not suggesting that the author should do the same, but it's just a confirmation that achieving the last 50% of the performance is indeed sometimes an impossibly hard task in Go