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.
So how about we get off our proverbial soapbox and enjoy the fact that we are lucky enough to work in an industry where we can choose the tools we like.
This reads as, "My personal preference is for people not to argue for their personal preference." Before you go on to argue for your personal preference.
> So how about we get off our proverbial soapbox and enjoy the fact that we are lucky enough to work in an industry where we can choose the tools we like.
Sure, we can choose the tools we like provided those tools are popular enough to have an ecosystem of jobs, or we're willing to shoehorn ourselves into a narrow set of jobs.
...which is why I'm sick of languages getting popular based on hype rather than pragmatics. Every Go job is a job that I've either got to reject based on the tool, or use their terrible tool.
I haven’t argued my personal preference though. All I’m saying is that arguing that your personal preference is anyway more “correct” than others is about as sensible as trying to discuss the science behind religion.
Yes you have, and you're still doing it.
Your "preference" in this case, which you are arguing for, is to not have people argue for their language preferences.
I used Forth instead of Awk recently. What I wanted to do required to be more proficient than I am in Awk, while I am proficient in Forth. As you probably know, Forth is not exactly a string-oriented language.
There's no language more productive than others. But there are triplets (programmer, language, task) that are more productive than others.
Well, any data on any such triplet will be highly nontransferable, to the point that it's useless. The challenge is finding minimum maps of generalized knowledge.
C# has all these features because C# has every single feature and facility that every programming language has ever had thrown into a single ungodly soup of keywords and syntax.
Don’t get me wrong, this means C# is bloody powerful but once you involve more than one dev you get into the problems of every dev understanding and/or preferring their subset of C#. Every PR is 50% policing style and structure desperately trying to keep the codebase grokable by everyone and politics about everyone’s favorite pet feature and design pattern. C# rewards cleverness with incredibly slick looking but utterly incomprehensible code unless you wrote it two minutes ago.
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.