Solid write up. If anyone's interesting in knowing more about how probability _came to be_ 'regarded' as real, i highly recommend Ian Hacking's "The Taming of Chance".
Thought provoking in so many ways.
> I don't like it when we go off script, because it's hard to compare with previous candidates.
Wow. Meep, zorp, hire me. The beauty of this section of the interview (as someone who also has done countless of these numbing, repetitive 'script' interviews), that it allows for candidates to be tiny bit unrestrained. Go on, ask whatever you think is important. Or funny. Or something that can give you insight into this job you're tyna get into. That's the part where you can actually differentiate between robots who memorized answers (whatever answer they might be) and people who are actually interesting that YOU, and your team, would find pleasant to work with.
What a wild generalization. I skimmed the article, and I see his point in "Go was designed by people working at Google to make it easier to write Google-relevant software, in particular network-resident servers", but that doesn't mean Docker and Kubernetes (and other tools that enable communicating with/usage of cloud infrastructure) being written in Go made it become the de-facto standard, and especially not "the language of cloud infrastructure". What about ALL the other components NOT written in Go?
Go certainly has a lot of mindshare in this space, and that can't be ignored. Some components of my production infrastructure I've used over the last year: cert-manager, concourse-ci, docker-registry, cilium, coredns, loki, grafana, prometheus, jaeger, influxdb, kubernetes, open-policy-agent; all those are Go. It's at the point where if you're in the business of writing software to run software, you're kind of surprised if you show up at some Github repo and it's not written in Go.
But, the joy of 2020-era design is that nothing is forcing you to use Go. Everything is coupled with network APIs these days, so you can generate your protocol buffers for whatever language you want and write your chunk in that. You don't have to look at the success of Go in this space, think "but I don't like it", and leave the field. You can do whatever you want. But, I do think it's accurate to say that Go has a lot of mindshare in this sphere of the Universe. It is what it is.
That is my exact observation as well, whenever I go to use and examine a piece of narrow and self-contained piece of Open Source software I'm not surprised to find the good ones are often written in Go. Some things that come to mind are Hashicorp Nomad, nsqd, InfluxDB/Telegraf, restic, etc.
I think the common thread here, and what separates this from internal tools a la "Amazon is 90% Java" is that these tools are Open Source from the beginning and want to encourage community contribution as much as possible. I don't like using go myself, but even I can't deny that if you're running an Open Source project and would like to encourage contributions from people of different levels of involvement and general programming proficiency, go is one of your safest bets.
Huh? I am sure 80%+ of AWS is Java and probably 90%+ of Azure is C#. I doubt it is going to change any time soon. Kubernetes is but one successful cloud product out of Google, and it just happened to be written in Go. There are even rumors in that thread about it starting as Java.
80% of AWS existed before Go was invented. Why would they rewrite that stuff? They're already #1. They have nothing to gain and everything to lose.
I think to get an idea of what mindshare looks like, you have to look at people that started from nothing today. These are the people that are making architecture decisions with an eye to the future, growth, and immediate productivity. When you're inside a huge org, you have to think about what is easiest to integrate with, and what skills you can get from other teams. At a company that's 80% Java, that's Java. It would be insane to switch, and likely to fail.
Sure, but Go has enabled a lot of great software in a very short amount of time. If you are in the cloud business, you'd better take a serious look at Go if you don't want to be out competed. It hits a sweet spot between performance and ease of use - feels almost like Python, performs almost like C++.
I feel like "Go has become the language of cloud infrastructure" is a bit of an inflammatory headline for this forum--I'm sure there are many cloud infrastructure components which aren't written in Go. The ones I think of tend to be AWS services that are written in Java or a handful of odds-and-ends things in Rust like AWS's Firecracker or some of CloudFlare's high performance networking systems. But especially in the open source world, there seems to be a lot of cloud infrastructure written in Go, and it seems to be accelerating. So in a sense I can understand saying "Go is the language of cloud infrastructure", but that framing seems unlikely to yield any interesting conversation.
> What about ALL the other components NOT written in Go?
Out of curiosity, which components are you thinking about?
> Out of curiosity, which components are you thinking about?
I could start listing off OS kernels, and then I'll move on to device drivers and hypervisors.
"The Cloud" is enabled by the fact we can efficiently separate applications and users running on the same hardware. The software which ultimately enables this is not written in Go... or Rust... or C++... or any other "hyped" language, but it is still an essential part of any cloud service.
Systems Thinking, mainly through reading Russell Ackoff's books. The Art of Problem Solving is good, Turning Learning Right Side Up is eye-opening (and definitely one of my favorite books lately) and currently reading Redesigning Society. Highly recommended.
I started it couple of months ago, but couldn't get past the first few chapters. It was too dry for my taste. Even though she's a brilliant scientist (I'd recommend checking her classic The Limit to Growth), it seemed like the earlier resources about the topic are much better explained rather than the newer stuff.
