1. 35
  1. 9

    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.

    1. 2

      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?

    2. 7

      Interesting bits and pieces from the article:

      • it has learnt some lessons from [C/C++, Java, Python, etc.], and I think it is probably the best language of that generation; but it is definitely part of that generation
      • reading Go code is frustrating because you have to ignore so much of it or search for subtle differences
      • frequent inconsistency between what is built-in and what is available to users
      1. 1

        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 :)

        1. 1

          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.

          1. 1

            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.

        2. 0

          I think the author sums up my feelings pretty well.

          1. -2

            Great read!