When Gophers Meet Dinosaurs

A weekend or two ago, we attended GopherCon in Chicago! It was exciting, fun, and illuminating to talk to so many Go developers. We got so many opportunities to learn about what people are working on and what they find interesting, and also hear their thoughts on Temporal.

Go is one of the more popular languages to use with Temporal, which makes GopherCon a natural place for us to show up. And, whether any given Gopher has heard of Temporal or not, shared experiences — like seeing seas of if err != nil in your nightmares dreams — make conversations go smoothly.

Case in point: on Day 2, I did a 7-minute lightning talk about Temporal, building up from a skeleton of a program and progressively adding more and more error checking. At the point my less-than-10-line function had turned into a 200-line program (rendered in 2pt font), the uncomfortable chuckles emanating throughout the room told me we were on the right track. As a member of the audience told me afterwards, “You walked through the exact story that we’ve painfully gone through so many times.”

And it’s a story we talked through every time we spoke to anyone at the conference, with questions like:

• How do you handle failures in the application?
• If a node in your pool dies and Kubernetes brings a new one up, that’s great, but what happens with the application that was running on the now-deceased node?
• How do you manage processes, API calls, tasks that potentially take a long time, longer than the expected lifespan of a single node?

Inevitably, queues, databases, pollers, timers, event sourcing, event streaming, key/value stores, and other patterns and architectures enter the conversation. Software engineering as a field has developed strategies and patterns for handling these situations, all in an effort to mitigate the effects of the fallacies of distributed systems.

Most of us would scoff at being asked to implement in-memory quick sort in an established language, so why should we all continually have to reimplement 200 line programs for a simple 3-step process?

That is the story I told on stage, leading right into a demo of a Temporal application. Think about a backend service you’ve written before, something that has the potential to take a while. If you kill it and restart it, what happens? With Temporal, we did this live in front of all of GopherCon: start a workflow, kill the worker after a few seconds, modify the code, and restart the worker. If you know Temporal, you know what happened next.

When Dinosaurs Meet Gophers

We didn’t just blabber on at people though. We let others do a bit of talking, too! 😉

Learning about people’s use cases, applications, and current best practices (whether they’re followed or desire to be followed) was probably one of the best parts about the conference.

Lots of Gophers care about error handling, failure mitigation, and building interesting systems for these things. What they’re doing it for is all over the place. Banking and finance, infrastructure management/provisioning, SaaS, observability, eCommerce, OS-level high-availability, business operations, logistics & shipping, media, consumer electronics, real estate, and more.

Brainstorming with Gophers about whether and how their use-case could fit into Temporal was enlightening and exciting!

Take SaaS for example. Imagine you were trying to build a “Webhooks as a Service” service. How would you do that?

I had a great conversation on exactly this question. If we tried to imagine this being backed by a Temporal Workflow, how would it factor in? Does it manage the infrastructure, the requests coming into a webhook, or some combination?

I can’t promise any answers, but I can promise more questions leading to deeper conversations.

See you at the next GopherCon, gophers!

And if you’re interested in the source code from my talk, you can find it all in this GitHub repo.