Exactly. Every programming language is a tool in your toolbox, and you should choose the appropriate one for the job at hand. For me, that's Go around 95% of the time.

I have no need to worry about a 24 byte overhead for a slice allocation, if I did have to worry about that, I'd probably use C or Rust.

And since Go is so readable, theoretically getting the core functionality out and rewriting it in a more specialized language would be fairly straightforward. And while it's an investment in time and effort to rewrite a chunk, at least you know what you're writing already.

But that's a point made in the article, that Go is also good for prototyping. But there's a few languages good for that, e.g. Ruby which powered a lot of the HN startups in their early days until parts needed to be rewritten for performance / scalability.

But writing a new, unproven product in a high performance, high difficulty language from the get-go is cargo cult; you hope you will need the performance and correctness offered by the language. Meanwhile, halfbaked hack jobs like Facebook and Twitter exploded in popularity and revenue, and while their performance issues gave their developers headaches, at least they knew what problems they had and had to solve instead of guessing and hoping.