As horrendous as I find Go as a language (🔥), it's runtime performance is very good, especially for a GC language. Where I've seen it fall short is when context switching between many goroutines, as one would do with many connections in a proxy. Perhaps this is better now.
Ultimately Go has been great for @lyft and as with many choices in technology I think it's the least bad option for a general purpose programming language right now. I'm happy we went with it as our Python replacement.
As for why @EnvoyProxy was not written in Go? I knew I could build something high quality in C++ quickly using rock solid foundational libraries. I also knew that I would eventually be competing with HAProxy and NGINX perf and the ridiculous horse race benchmarks that come with.
Could Envoy have been written in or be ported to Go? Sure. Do I know the real performance delta? No. Do I care? No. Why?
Because as much as hot take, thought leading, FUDster, tech 💩bubble Twitter would have you believe that the world has moved on to Go and Rust here are a few facts:
1) I would estimate that 90% of the software in the world is still written in 3 languages: C/C++, Java, and Python. Net: It's not hard to find high quality C++ programmers.
2) Memory safety is great, but I have 10,000 problems and the lack of memory safety in C++ does not crack the top 9,689. Why? Because modern tooling catches almost all such errors.
3) Language is a component of project success, but it is nuanced. C++ is not what makes Envoy great. It's an implementation detail. What makes Envoy great is community and feature set. If there are enough people with interest that know the lang it's irrelevant (see point 1).
As much as I love making fun of Go, Python, and Rust, it's all trolling. I don't care what language something is written in as long as the product adds value.
I like getting shit done, and I choose what is in my opinion the right tool for the job. For Envoy, 3 years ago that tool was C++. I would still likely make the same choice today, even though I know it selects out some folks. Though, *something* always selects out some folks.
Beyond that, as in most of my tweet storms, I would encourage focusing on product market fit and building a community and user base. Sure, language is a factor, but it's far from the only one.
So to answer the original question: C++ is not preferred for proxies. Every project is a mountain of tradeoffs. We make our choices and move forward. Ultimately, for OSS, the market/community will sort out the winners and losers.
