I am specifically talking about how the seem to have forgotten (omitted?) parametric polymorphism, the absence of sum types, presence of "nil", lack of type inference?
This is a Go specific problem, which was created with a very explicit anti-intellectualist stance and threw out 40 years of PL theory and practical research.
They're easier to pick up and support the idea of plug and play programmers that is very popular among managers.
Productive as a consequence of the above, maybe; in that more code is written in Go; but certainly not as a quality of the language.
And there's numbness and denial involved. I've been writing Go full time for about a year now at work. Every time I use another language I'm reminded of how much time and energy I'm wasting.
People change jobs and you need to choose a language you can either easily hire for or train someone up in. Go fits the second requirement very well, and as more people learn it, starts hitting on the first. I introduced Go at two different companies to great success not because it's my favorite language (I would much prefer Rust, Haskell, Clojure, etc) but in reality, in my role as a leader of a tech org, hiring smart people and getting giving them the means to be productive as soon as possible for however long they want to work with us is key.
It seems to me to be the wrong trade
Separately, I don’t buy the notion that a language that has a bit more boilerplate is less productive than one with virtually none.
From a coders perspective, using sub-optimal tools and churning out boilerplate day in and day out makes the difference between keeping a job and looking elsewhere.
Which turns it into a managers problem, because if your developers are not happy, you won't be either in the long run.
There are diminishing returns on programming features I guess. At a certain level of complexity the difficulty in learning the feature will kill adoption despite the usefulness of the feature - e.g. monads; after months I think I sort of get it ... sort of.
> Every time I use another language I'm reminded of how much time and energy I'm wasting.
Wasting writing Go or wasting writing in the other language? Sorry, just clarifying. I really can't tell which you meant.
Manual loop implementations of basic functional concepts, manual error propagation, finding ways around arbitrary limitations in the name of simplicity, the list goes on and on.
JavaScript, PHP and C are also widely successful, despite their design flaws.
Technical excellence doesn't driver adoption, unfortunely.
The thing is that productivity of a language depends on many factors, including many softer ones that are typically forgotten or discounted by language geeks. It also depends on the target audience. In some important ways, PHP was/is brilliant.
A technically brilliant language should be able to recognize the adoption driver mechanisms and build the necessary infrastructure. The point of a language is not (only) to build a theoretically sound framework, but to be an ergonomic vehicle for expression of ideas.
Go was designed for internal use at Google, and one of the primary goals was to reduce compilation time for huge codebases (the size of Google monorepo). For such amount of code even `javac` was too slow for them. To solve this problem, Go was designed to be compiled with 1-pass compiler (similar to Pascal and Modula-2) which makes features like generics and type inference very hard (if not impossible) to implement.
ISO Modula-2 common extensions (including generics),
https://modula2.awiedemann.de/manual/comp3.html
While using Go is certainly better than plain C, most of its design steams from the authors' bias.
I was under the impression Go originally avoided generics more for a perceived abstract complexity for developers, the idea being they are hard to understand for new recruits.
Creating a new general purpose language with such a limited feature set - that it’s likely to result in even more code - seems to be an odd solution.
There's more to designing a useful language than is found in Pierce's book. The Go design team had some very specific things they were trying to do, and they did pretty well at doing them, and they produced a language that some people have found to be useful for writing some kinds of software. I'm going to guess that they had a lot more experience at actually writing software than Pierce did. So maybe you shouldn't automatically assume that Pierce is the final word, and that anyone who decides different has to be wrong.