Not "stupid" but "inexperienced".

Rather obviously, people who implement OSes are usually the opposite.

Specially given that even the Dart team managed to implement generics,....

> opinionated (in the "users of this language are stupid" direction) Pike, et. al. seem to be

Such a strong statement, wrapped in quotes to make it seem that this is Pike's literal words, should really be substantiated with a reference. Otherwise you're putting words in Pike's mouth that he never said.

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” – Rob Pike

You have supported what I said; they were not his literal words.

Where does he say "users of this language are stupid".

What do you mean? It's a direct quote from the page.

Fuchsia is meant to be used in variety of contexts like IoT [sic], and embedded stuff, Many time Go doesn't play well in such areas.

People coming from language like C++ and senior enough to write OSes may be startled how inexpressive Go is.

Even Java that started as a blue collar language, or modern Basic dialects that started as introduction to programming, are more expressive than Go will ever be.

On the same line they mention memory / cpu usage, I don't read it as we had bad experience using the language but more than Go doesn't suit well xyz because of memory usage.

Hence the word implementation accompanying experience, which was not omitted in the citation you're responding to.

Why can’t it be both?

You might not agree, but the idea is that you should devote your cognitive resources to the problem you’re solving and not working around complexities in your language (such that brilliant developers such as yourself and “stupid” developers like me can be even more productive than we would be with C++ or Haskell or whathaveyou) or choosing stylistic standards for how contributors are to program (because the language is so expressive that the solution space is astronomical). “Go programmers are stupid” is a deliberately uncharitable interpretation.

You might not agree, but there are programming languages that, unlike Go, don't take a "programmers are stupid" opinion, that are incredibly productive. Here are some other ways you can make developers productive (just off the top of my head):

1 - give programmers access to powerful jedi tricks, but make those just annoying enough that novices aren't terribly tempted to build them and put them into prod (but not so annoying that they aren't tempted to play around with them not-in-prod and learn something about the runtime)

2 - make "doing the right thing" easy, like, tests, documentation, sane package management, cryptographic primitives, comments, tests, etc, also, did I mention tests? Tests should be easy and you should want to write them.

3 - Make tests blazingly fast and parallelizable. That means, you can write two (or more) tests that hit the database (or some other source of state) and it doesn't matter that they are operating on different views of the universe, they shouldn't collide.

4 - be opinionated about deployment, so that those rube goldberg tricks you have to do to put into prod are testable and reproducible.

> Tests should be easy and you should want to write them.

I must be using go wrong then because I've always felt they were easy and wanted to write them. The last big project I built with it had great test coverage.

> be opinionated about deployment, so that those rube goldberg tricks you have to do to put into prod are testable and reproducible.

Of all the languages I feel like go's deployment is probably the simplest, if it's hard for you you're probably doing something pretty wacky.

> Of all the languages I feel like go's deployment is probably the simplest, if it's hard for you you're probably doing something pretty wacky.

100% agree with this. Statically compiled binary is basically the easiest thing to deploy.

…until you update your OS, and your binary breaks because it tries to make raw syscalls.

Considering how infrequently this happens and how utterly trivial it is to recompile, I'd take this every time over complex deployments on the happy path.

Deploy isn't just dropping a binary into place, it's everything else. If you're in ec2, what sorts of vms or security group are you using, how do you talk to AWS, if you're on a bare Linux, are you putting in apparmor and fail2ban? If you're in eks, the reams and reams of yaml. What is your restart strategy for your process when it crashes... How do you connect your process to the cluster and instrument it with secrets...

I mean your mileage may vary on usage but we generally just build a new ec2 image, basically Amazon Linux + Go Binary, set the autoscaler to use that, and if we need the old one cycled out fast kill the older instances. We rarely need to do that, we try to avoid it.

We let the AWS autoscaler health monitoring just kill unhealthy ec2 instances. No need to worry about any sort of restart policy. It is VERY rare we actually get a Go process in an unhealthy state.

We’ve always handled banning in app, so that’s never been a consideration. Our rules around that are very complicated as we sell into institutions that have thousands of people behind a single IP address, so blocking a full IP incorrectly could mean institution wide downtime and possible loss of a client.

Our secrets get set with a little come-online script in the ec2 image. Secrets change? Kill the instances and autoscale more. Instrumentation is via REST api.

It’s basically the same way we deploy anything else but without worrying about library and language versions. Its reasonably simple, and been very easy especially compared to the previous ways we used to deploy apps.