Edit: the Lobste.rs markdown cheat sheet doesn’t have bullet lists, and doesn’t match the Wikipedia article on Markdown. Sorry.
I was an engineer on Google’s indexing system when Go was being developed. When Go was announced internally, I remember being disappointed in a few things that I didn’t feel were defensible tradeoffs:
* Repeating Hoare's Billion Dollar Mistake (conflating optionality and indirection in its formulation of nil, and not forcing checks)
* Its "C foreign function calls" didn't (still don't?) use the platform ABI, so you need to use a custom C compiler
* Allowing non-exhaustive switch statements is just too error-prone
There were also a few design trade-offs that I personally wouldn’t have made. It’s fine that Golang targets a different type of “systems programming” than I was doing and makes engineering trade-offs I wouldn’t have made:
- Allowing shared mutable state instead of just declaring it bad practice
- Pervasive garbage collection (not suitable for some types of "systems" development)
- Their early attitude toward generics reminded me of excuses made back when Linux support for threads was poor
- No way to force an interface to be explicitly declared (pervasive structural subtyping without nominal subtyping)
On pervasive GC: when I started at Google, I was a big believer in Java. I bought the Java apologists’ line that soon Java was going to be just as fast, if not faster than, hand-optimized C++ in nearly all cases. (I now think the safety, tooling, and productivity advantages of Java usually make it a better choice than C++ where speed isn’t absolutely critical.) I had a choice between a Java position on the Stubby Team and a C++ position on the Indexing Team. I joined the Indexing Team to really fill out my skill set by giving me solid C++ experience. I quickly realized Java was nowhere near ready to replace C++ for the stuff I worked on. At any given moment, there were literally approximately 1,000,000 threads executing in my component (though, most of them were I/O bound on BigTable). When 5 or 10% performance translates into real money, and you’re paying for top-notch developers who are used to thinking in terms of ownership semantics, pervasive garbage collection is a hard sell. It’s fine that you’re not going to see any efforts to replace C++ components with Golang components in Chrome, analogous to Firefox’s Quantum. Golang just isn’t targeting that performance niche.
Markdown note: it looks like you have leading spaces before the * and - you’re using as bullets. Maybe remove that and preview to see if that fixes it?
Interesting bits and pieces from the article:
The funny thing is that I agree with almost everything the author has said. Yet I still enjoy writing programs in Go quite a lot. Maybe I am not a real programmer :)
Yes, Go is definitely not perfect, but I still very much enjoy using it. It’s relatively easy to predict how Go will behave in a number of cases and there aren’t too many surprises. The opinionated formatting and error handling makes it quite easy to pick up someone else’s code and follow it.
Another aspect that I enjoy is its fast compilation. Languages that have more complicated types tend to be much slower to compile and I don’t like to wait around.
I think the author sums up my feelings pretty well.