Con: The Fuchsia Platform Source Tree has had negative implementation experience using Go.
i.e. they tried it, because they're from Google and they basically had to, and it wasn't great.
Not surprising, honestly, given how opinionated (in the "users of this language are stupid" direction) Pike, et. al. seem to be.
Rather obviously, people who implement OSes are usually the opposite.
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.
Where does he say "users of this language are stupid".
People coming from language like C++ and senior enough to write OSes may be startled how inexpressive Go is.
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.
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.
100% agree with this. Statically compiled binary is basically the easiest thing to deploy.
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.