1. 8
  1.  

  2. 12

    For a while I have considered it part of my professional responsibility as a PL researcher to respond to these types of articles, but I figure at this point there is enough Go criticism/apologia available on the Internet to satisfy the few people left who are still interested in this subject.

    I would however like to quickly point out how ironic it is to say this:

    “Innovative” is such an overused and abused word that it has lost a lot of power and meaning.

    and then proceed to repeatedly use “simplicity” as an argument for Go’s idiosyncratic design choices.

    1. 3

      For a while I have considered it part of my professional responsibility as a PL researcher to respond to these types of articles, but I figure at this point there is enough Go criticism/apologia available on the Internet to satisfy the few people left who are still interested in this subject.

      Truly, thank you for abstaining.

    2. 2

      Without going into all of the things that the Go ecosystem brings to the table on top of the language design, what should be clear from a shallow familiarity with the tooling is that Go has focussed on providing answers to some of the more difficult aspects of actually getting code that is both stable and agile into production.

      This would actually be a great thing for the author to go into. The sections Go is an Innovative Thing, Unifying, Paradox of Choice, all talk about the language itself.

      These things that were part of Go from the beginning have had to evolve over decades in other languages, often in fractured directions - again adding the paradox of choice. For example Go’s dependancy management attempts to solve a thorny problem, and while go get in particular is going through some teething pains, its inclusion from day one is illustrative of Go’s intention.

      But what are these things? Dependency management and …?

      It is this focus on the operational aspects of development, so early on in Go’s evolution that emphasises the reason Go was created, and is commonly overlooked in favour of low value critiques of the language itself.

      There is something of assuming the conclusion here. The author calls critiques of the language “low value” but why are they so low value?

      I would have liked it if the author had talked more about the use of meta-programming with reflection in Go, and the use of channels.