> Because Go is taking a strong stance that smaller languages are more productive, and I think they’re right.

As a face-value claim, that's obviously untrue. Forth, by any reasonable metric, is a smaller language than Go, but I think you'd have a hard time claiming it's more productive.

I'll generously assume that you mean that "languages with a carefully selected set of features are more productive", and there I'd agree with you. That's Python's "There should be one-- and preferably only one --obvious way to do it." But then the question becomes, "Which features?"

A very key choice you have to make up-front is the type system, and it's obvious that Go's type-system choices are bad[1]. Weak static types[2] gives them the worst of both worlds: the types don't get out of your way like a dynamic type system and they don't catch errors like a strong/flexible type system. Single-pass compilation for speed is the only attempt at a justification for this choice, but it's a bad justification: 1) this is solved by partial recompilation for all but the largest use cases[1], and 2) if you're using `go generate` to solve the obvious problems with the type system, you're introducing a second pass that saves keystrokes in exchange for giving up even more type safety. So you add a linter: congratulations, now your single-pass compilation is three passes. This isn't a tradeoff, it's just giving away all benefits of types in exchange for a veneer of minimalist aesthetic.

I'm not going to quote what you said on C#--I'll only respond by saying that if you read my post, you'll see I said it's not my favorite language. I'm not espousing it.

> Not saying Go is the answer or the way but I think it’s scratching a lot of people’s itches for something high level that’s restrictive enough that there’s only one or two “right” ways to accomplish a given task.

...which is extremely short-sighted. The "only one right way to do it" only lasts as long as there's no NPM-like ecosystem of libraries. Look at Python: most projects pull in at least a few common dependencies, and there's immense pressure on Python to integrate these back into the language--a pressure to which they have succumbed in many cases (which isn't necessarily a bad thing). Most projects also pull in some section of really, really bad dependencies that should never have been released into the wild and probably never will be updated. There's no way around subsetting: at least if you use the wrong language features, they'll be supported and deprecated responsibly, unlike the average 0.0.2-versioned 5 line function imported from NPM or PyPy[3].

Ideally you have a set of core features and a strong standard library that don't push people to import a bunch of terrible libraries, which is why Python has fared so well despite some really awful limitations (i.e. the GIL). But again, Go isn't that.

[1] They're probably not bad for Google: the people who made Go made it to solve Google's problems, and they're smart guys. But you are not Google (unless you are Google), and if you're operating at Google's scale, you can make your own programming language that solves your problems rather than Google's.

[2] Go fanboys generally don't know that weak/strong and static/dynamic aren't the same thing, and like to claim that Go has a strong type system because it has a static type system. This reinforces my belief that people choose Go because they don't understand type systems.

[3] NIH isn't even enforceable: good luck preventing people on your team from "importing" code from Stack Overflow using their keyboard's copy/paste function.