Channels are Go’s fundamental tool for concurrent programming.
Buffered channels are a small, innocent-looking feature on top of channels. I’m going to try to convince you that they’re a monstrous abomination.
First, a quick recap of how channels work if you haven’t used Go in a while.
A channel lets you send data on one goroutine, and receive it on another, concurrent goroutine.
In a normal unbuffered channel, sending data will block until the data is received.
This blocks forever:
ch := make(chan int, 0)
ch <- 1
This prints “Received 1\nPossible”
ch := make(chan int…
In the 3 years since I wrote my post on Bazel, there have been a few changes to the Bazel ecosystem:
1) I've met many more large engineering orgs that have either partially adopted Bazel, or are investigating Bazel.
2) There are several different companies that build tooling around Bazel and consult with teams on how to use it. I've talked to the folks at flare.build and EngFlow. There are more listed here: https://bazel.build/experts.html
If you're a large company looking into Bazel, that's a lot of good news! There are more peers you can learn from and help you can…
When we first started developing Tilt, we broke ALL THE TIME.
Either Kubernetes changed. Or we had a subtle misunderstanding in how the API works. Our changes would pass unit tests, but fail with a real Kubernetes cluster.
I built out an integration test suite that used the latest version of Tilt to deploy real sample projects against a real cluster.
At the start, it was slow and flakey. But the tooling around running Kubernetes in CI has come a long way, especially in the last 1–2 years. Now it’s less flakey than our normal unit tests 😬. …
A common take on Kubernetes is that it’s very complicated.
… and because it’s complicated, the configuration is very verbose.
… and because there’s so much config YAML, we need big toolchains just to handle that config.
I want to convince you that the arrow of blame points in the opposite direction!
Kubernetes has a simple, genius idea about how to manage configuration.
Because it’s straightforward and consistent, we can manage more config than we ever could before! And now that we can manage oodles more config, we can build overcomplicated systems. Hooray!
The configs themselves may be complicated. So…
I found the first mention of Kubernetes in computer science!!
It comes from a book. “Cybernetics: or Control and Communication in the Animal and Machine” by Norbert Wiener. Originally published in 1948. (Yes, even in 1948, non-fiction book titles abused the colon.)
The book has its own Wikipedia page. So many people read it that he published a sequel!
It’s surprisingly hard to find. The New York Public Library has two copies offsite, only available on advanced request. The Brooklyn Public Library has zero copies.
I like to imagine I have the only physical copy in pandemic-lockdown New York City…
Welcome to the Commit of the Month, the blog post series where we highlight recent work on Tilt.
October’s commit is
Or for you humans:
When you’re watching a resource in Tilt, you used to see two tabs: Logs and Alerts.
The Logs tab displays the most recent output of building and running something on Kuberenetes. That includes image build logs, pod logs, events that popped up, etc. All of it is in recency order.
The Alerts tab displays messages that we think you should look at Right Now, like build failures or…
When I first started learning how to write Kubernetes configs, I would sometimes complain to people about it. “They’re so complicated!” they would complain back.
They would show me an example. Here’s a simple Docker Compose config:
command: sh -c 'node server.js'
And here’s the equivalent Kubernetes config:
- command: ["sh", "-c", "node server.js"]
- containerPort: 8000
“Why can’t Kubernetes configs be as simple as my Docker…
Software Engineer. Trying new things @tilt_dev. Formerly @Medium, @Google. Yay Brooklyn.