Not trampling, just holding at arms length. Recognising the reality of the economics of most projects. Unless you live in a completely deterministic world, devoid of human fallibility, or perhaps omnipotent, or simply have unlimited time or resource, at some point you are going to have to admit you just don't know, and you are managing the percentages. Delusional overconfidence is more close to magical thinking than recognising the reality that complex systems will fail in surprising ways, and that it costs ever increasing resource to reduce the risks with ever diminishing returns, until you are forced to stop. The ruleset the computer abides by probably represents a fraction of the factors affecting success. If you feel you have never got to a point where there is an element of faith involved in your choice, then Im envious.
hmm, yes, this was always going to be a contentious point, and highly subjective. I think the main issue here is it was in a large part also a very human impact, which is much harder to measure. I think it was fair to say that our build system at the time was more rigid and testing fully both flows not within our grasp. I discussed this point about 'hope' with a colleague, I think I agree with his conclusion: "Google actually designs some of the chips it uses! And runs its own power stations - I think if anyone could legitimately say "Hope is not a Strategy" it might be them."
Regarding Gazelle, yes, the CI would break early if it detected a none porcelain repo after running Gazelle itself. I think others may have configured their editors, but for me the occasional 30+s run time (and as mentioned in some workflows 3-4 mins) on file save - plus the already creaking VSCode plugins was too much to bear.
To give a tool a fair chance I think it has to be used daily to really grok the pleasure / pain. We were aware of some of the problems, but perhaps overly confident about managing them, and underestimated the frustration and lack of agency. Possibly we let it embed too far before we decided we have tried as hard as could be expected. Around 6 months in, once a number of us formally proposed that it be reverted, we took the bold decision that we should persevere no further. Having worked in C codebases in the past - I can imagine it is almost a miraculous improvement there.
I probably should have made the context clearer earlier in the post - later on I mention :
"To set the scene, our codebase is mainly Go, including vendor directories, and a considerable amount of data compiled in, we have 2.5M lines of code, a full build from a clean clone on one of our Jenkins slaves takes 1 minute.
We had between 8 and 20 engineers working on that codebase. Importantly we all develop on Mac, but run in production in linux."
I would contribute to a federated non-repudiable system.
Moderation can be just as auditable. (Perhaps with some emergency actions that then require a follow up consensus to make permanent)
On some occasions the original content must be purged, but the signatures can remain. Communal censorship is vastly different from changing the content.
Fair point, just differing levels of hoops to jump through, or general expectations of best practice. In that sense I would say Java and C# do not allow you to 'ignore' exceptions.
I suspect your "pray" == monitor closely and fix fast (often never).
I agree it can be problematic that there is nothing in the language that indicates that the author is explicitly in 'pray' mode. It could well be that even a brief defence of a missing error check during a PR code review is not worth avoiding (un-triggered) err handling.
I would tend to agree, based on instinct, that Go is poor for data science work (as it happens I am about to find out for real in the coming weeks :| ). To build systems to feed data into some other analysis platform: definitely, but dynamic number crunching, not so much. Rob Pike probably knows this better than most; Sawzall would probably not exist otherwise.
The irony in all of these comments is that they almost all fall back to, or start with, discussing language design, and on the whole ignore the tools and processes that have a consistency from Go team to Go team. The value of this power and consistency is probably overlooked in this and many other conversations because they are complex to discuss, and it is simply easier to focus on the almost provable value of the language features, missing or present (maybe another availability bias at work?). The point of the article was to try and refocus on Go as an engineering tool in a much broader context.
Thank you, and may I say what a well written comment.
Poor old Tony Hoare (algol was mentioned earlier (rightly) as an exemplar of innovation) but Null in a safe memory managed context is a different beast to a true Null reference.
Null appears then as something between a known state and an not quite an exception, it carries different semantics from either, and whilst this could be seen as more complexity, I think the "I just don't know" case in practicality is useful, if harder to reason about.
Your point about the runtime is very true. Partly because of this - error checking is overrated! Yes I said it! We have go code that has been running in a reasonably high scale production environment for over two years and there are `if:...;err != nil` blocks that have never been touched in millions of calls per day, for 2 years. We have redundant services and trap panics in the rpc handlers, the nil becomes very clear and the rest of the system makes good progress. We save lines, save tests, and release a single binary fast. One example of where Go helps us deliver value faster, by being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie.
I'm no language historian, but I did limit my timeframe to my personal experience of 36 years of development for a reason. There was necessarily incredible research in the 20 years prior to that, which made it into useable languages, of course this is no hard cutoff, just an arbitrary personal choice, and I am happy to stand corrected. My point was simply that at least in the languages that make up 2σ of all code running in production in the last 20-30 years very rarely do they include "language" features that did not appear as truly innovative sometime before that. It may be argued that simply including some prior research in a useable language is innovative, or that the incremental improvements are themselves innovation, but then we are bogged down in semantics. In summary every time anyone in recent years has claimed to be innovating in language design someone else counters it with prior art, and that Go never pretended to be innovative in this direction. Given the lineage, and experience of the Golang authors it is more likely, in general that they considered and rejected, rather than ignored.