What's up, everyone? Adam Stokowiak here, editor-in-chief of ChangeLog. We teamed up with some friends of ours over at Heroku to promote their podcast called Codeish. You can check it out at heroku.com slash podcast slash Codeish.
And today we're dropping a full-length episode of Codeish into the GoTime feed. This episode features Johnny Borsico, panelists on GoTime, on the mic with guests Ed Muller and Rashid Watson talking about Go at Heroku. Here we go. Hello and welcome to Codeish, an exploration of the lives of modern developers.
Join us as we dive into topics like languages and frameworks, data and event-driven architectures, and individual and team productivity, all tailored to developers and engineering leaders. This episode is part of our Heroku in the Wild series. Hello and welcome to Codeish. My name is Johnny Borsico, and I will be your host for this episode of Codeish.
Today, we will be talking about Go at Heroku. I am pleased to be joined by two of my colleagues, Ed Muller and Rashid Watson, who will share their experiences with the language and add some color to how they've seen it used within the organization. So let's begin with you, Ed. How long have you been at Heroku and in what capacity?
Let's see, I've been at Heroku now for eight years. And during that time, I've been on, well, pretty much all the teams. I started on our database team and transitioned through some infrastructure teams that worked on AWS and eventually metrics and logging. After that, I wanted a little bit of a challenge and became the Go language owner.
And eventually, though, found my way back to metrics and now into SRE land, where I'm working on Go tooling, some open telemetry stuff, and generally observability. But Rashab, I know even less about you and what you've been up to at Heroku. So how long have you been at Heroku? Yeah, so I've been at Heroku for about a year and a half.
I'm pretty new to the industry. This is actually my first job. And a bit of a brief history about myself. I recently graduated from UC Berkeley about two years ago after studying some computer science.
And prior to that, I was actually a Future Force intern on one of the other clouds at Salesforce called Salesforce IoT Cloud. And most recently, I've started as a software engineer on the runtime infrastructure team. Very cool. So as for me, I'm relatively new to Heroku.
Still, at least, you know, relative to the two of you. It's been, what, maybe my sixth? I think I'm entering my sixth month at Heroku. I joined as an SRE.
And Ed and I are also part of the SRE org within Heroku. And this has been an awesome journey for me. So, Ed, I know you've been at Heroku the longest. So I know internally right now that you're definitely one of the people who looks after the buildpacks.
So whenever there's a new version of Go that comes out, you're sort of one of the first people the org looks to to make sure that we're running the latest and greatest, we're patching, and we're basically keeping up with the release of Go. Can you give us a little bit of insight into sort of what the process is like? Is it something that's difficult to do, hard to manage? Like, you know, do you have automation around it?
How easy is it to keep a buildpack fresh and serving our customers? Keeping Go up to date in the buildpack itself is relatively straightforward. We have a little script inside the buildpack repo itself that we can use to do the work to bump versions. And then things like CI and CD for the most part, you know, validate that the existing tests and everything are good.
There are challenges supporting every new major release. So like Go 112 to Go 113, et cetera, et cetera. For instance, like the default is currently still one of the Go 112 lines because there are a whole bunch of implications with turning to modules being the default on. And yeah, we're not yet sure we understand all of the implications of it from the standpoint of the buildpack anyway.
And how that affects all the users of the buildpack. But the general process of like bumping for point versions and things like that is really simple. Pretty much just at Heroku, every new project, it sounds like it's being written in Go, but we still have a lot of projects that have been written in Ruby. Some new projects even are either Ruby and we have some Elixir as well.
So we're truly a polyglot organization. We have a set of go-to languages that we use, but Go is increasingly being a sort of one of the first ones we look at, especially for back-end kind of systems and services that need to talk to each other, that kind of thing. So this is how we do metrics and how we do sort of when folks hit the API at Heroku.com. That's most of the stuff is in Go, how private spaces are run.
That most of the stuff is controlled in Go. So we have a lot, a lot of Go. So does that mean, do you think, does that mean we have a lot of Go expertise in-house? And along those lines, perhaps Rashad, you can sort of chime into this one.
How have you, how easy has it been for you, right, coming out of school and this being your first job where you're doing Go, you know, at school? Or did you learn Go on the job? How easy has it been for you to sort of learn Go and be productive with the language at Heroku? At college, actually, I never even heard of Go.
The main languages that I used was actually Java and Python. And coming to Heroku and starting my first job, it was quite a bit of a surprise just hearing that I would be working in Go and Ruby and learning like a new language. So specifically, there were like a couple of resources that really helped me gain a bit of an understanding about the Go ecosystem and learn how I can actually like start writing idiomatic Go. For example, the runtime team, like specifically, we have a program called Runtime University.
And it has a huge section on Go, which it also references Go by example and other resources where an engineer who is like relatively new to Go or wants a refresher can actually go in and do some practical exercises and learn, for example, syntax about the language or like how to actually write good Go. Also, for myself, one of the biggest things that has really helped me learn Go at a good rate is reading a lot of Go code. So taking like an existing microservice that we have and then reading it end to end really helped me understand how to build a service in Go. And then also when I'm making changes to an existing service, reading that whole like code base was very helpful.
So I think overall, as like a new engineer, we have some patterns at Heroku, such as like Runtime University that really support a new engineer to learn some Go. So one of the things that you, as a Go developer, start to sort of hear as a new Go developer, you start to hear more and more of the more Go you do, is this concept of idiomatic Go, right? So you could write Go that looks kind of like Java a little bit or some other language that you're familiar with, you know, but you wouldn't be sort of doing it the way most Go developers do, right? And this is something that basically is more subjective than it is sort of a specific sort of, you know, if you don't write it a certain way, then your code won't compile kind of thing, but it's more along the lines of this is the expectation right out in the Go community.
And this is, you know, when you look at a Go code base and Ed, I know you've been sort of the leading sort of person internally behind our Go design guide. Maybe you can sort of add some flavor there as to basically how much of sort of the community's sort of concept, right, of idiomatic Go, how much of that basically is impacting or influencing how we approach Go development internally. I like to think of as our Go design guide. First of all, it's a living doc, right?
So I expect it to evolve over time. It's an attempt to basically try to get all the engineers on the same page about how to structure projects and how to write Heroku's version of idiomatic Go. I do feel that a lot of things captured in that guide are inspired by the things you see in the community at large. For instance, the guide has many call outs to everything from like Dave Cheney's blog to Jana's blog to the Go Wiki and things like that, and usually has text for purposes of clarification or to, you know, better relate the contents that are linked out to to the context of Heroku and the types of services and tools that we need to write.
And like I said, some of the main motivation for me starting it several years ago was as the Go language owner, then I would read a lot of Go code internally and different projects were trying different things, which is something, you know, we want to continue to encourage. But as the code bases go from experimentation phase into production and things like that, in order to have that code base easily maintainable and modifiable by a large swath of engineers, my opinion is that it's better if we do thing X in the same way across as much of our code base as possible. And the attempt for the design guide is to state what those ways are and the reason and motivation behind why we feel that that is the right way for us to do it and to provide examples and all that context for posterity. And again, since it's a living doc, though, it doesn't mean it's going Yeah, definitely.
So I think being very new to Go, just asking a lot of questions and always questioning like why something was done the way it was done. So just being open to like asking a lot of questions, especially to like senior engineers who've been like writing Go for a multiple of years. And specifically in pull review or pull requests, asking targeted questions to the reviewers and saying, hey, does this section of code make sense based on this pattern that I found here and really soliciting specific feedback. So yeah, I also definitely take advantage of like pairing while doing code reviews.
So we would hop on a call together, look at the code together, and I would explain and do some kind of like a walkthrough explaining the reasons why I took when writing a certain piece of code and really got a chance to add some more flavor to the code review process. So Ed, I'm curious, do you think your journey, I mean, you've been doing Go for many, many years. What do you, where do you see yourself at this point in your sort of a career in terms of, you know, your expertise with Go? Like, do you still think the language has a lot to offer you?
You still think there's a lot to learn? Like, is it the way you've written Go along those lines, has the way you write Go today, has that changed over the years? Oh, it's totally changed. Go is not my first language.
It's maybe my seventh, eighth, sixth, something like that language professionally. I did what everybody does, or at least I assume what everybody does when they first learn a new language. And that is mix in, you know, styles picked up and or used in their, in the language that they used previously most. Previous to Ruby, for instance, I had used Python a lot.
So when I first came to Ruby, I wrote my Ruby like Python and was quickly yelled at by a bunch of Rubyists. So when I came to Go, I wrote what I currently call Gooby, which is the mishmash of Go and Ruby, which I've seen plenty of. I've also seen plenty of Gython. I've seen plenty Gava.
I've seen all of these. And I'm not, I don't say that to like cast derision on the people doing that, but I believe it's also important to recognize that that's part of the process of getting like transitioning and learning a new language. As far as new people coming into Go, though, I think like, I think the best thing we can do for new engineers is pair with them and pair with them on specific tasks. I have offered and continue to offer pairing with any engineer on any project.
And those who have taken me up on it, the sessions have been most productive, I believe for myself as well, kind of experiencing the beginner mindset, which I'm so removed from now. So, you know, experiencing that firsthand. And then I hope for them as well, because I, you know, through that process of pairing, we can explore like the design philosophies that I think are idiomatic Go, where some early attempts at this, people I was pairing with attempted to use me as like a Go encyclopedia. And I feel like neither one of us, you know, neither party came away from that experience feeling like they had gotten a good use of that time.
So that's something else I recommend for more senior Go engineers when you offer something or do pairing with somebody, try to do it on a like, have a specific focus and a goal to accomplish, you know, refactor, implement something new, both of those, whatever, not just like, hey, look at this code and tell me how it could be better, because there's no, there's no absolute right answer to that. It involves too many contexts that are specific to the project, how the deployment, the engineers involved, et cetera, et cetera. And where, where do we see Go sort of going at Heroku? The, obviously we've already mentioned that a lot of our, a lot of our control plane software is written in Go.
And, you know, everywhere I turn, I think, you know, within the organization, I see more and more Go. Do you think that's, that's sort of the, the language, the bulk of the engineering teams at Heroku are going to be writing software for the foreseeable future in your mind? I'd certainly like that. I suspect a lot of Rubyists might be more immediately attracted to something like Elixir.
That's a theory, not something I know. But I think Elixir can give like the Rubyists some of the advantages that you would get from Go while keeping some of the things that they like about Ruby. And those are the same. A lot of those are the same things that kind of drive me crazy about Ruby.
And, you know, Ruby and Go are different. With that said, I do think Go is embedded into our infrastructure to the extent that it will likely continue to be one of one to four primary primary languages that Heroku engineering ends up using, especially while things like Docker and Kubernetes and stuff like that continue to kind of like dominate mindshare in the industry. So Rashab, what are you most looking forward to on your end with regards to working with Go? Do you, any project you get to work on that involves Go you're happy with or do you have a specific kind of project that you find the most fun to write in Go?
Like where, where's your head at? So currently I have the pleasure of actually writing a new service that actually deploys to our communities clusters in a secure and scalable fashion. And that service is written in Go. So it's been kind of like a journey for myself in the sense that it's like a foundational project where I get to actually like bootstrap a new service in Go and like really figure out for myself good design patterns and writing good Go code.
So it gives me the space and the time to actually experiment and learn, which I'm pretty happy about. Well, I am glad we're able to have this chat and I personally learned a bit more about how Heroku uses Go and knowing that there are folks who are sort of a brand new to go in the organization as well, that are sort of learning how to, how to write Go and how to write idiomatic Go and folks like Rashab and also folks like Ed who have been doing it for a while, providing some guidance and, and, you know, me having joined the organization and knowing, knowing that Go was a, was a determinant factors when me joining the organization. I'm glad to see that there's, there's a lot more to the org, a lot more to the services and everything else that we're doing that's written in Go and that makes me happy. So I am, yeah, I'm grateful that we're able to sort of get on the chat, have this chat, and thank you for being, I guess, my show today.
Yeah, thank you. Thanks for having me. Thanks for joining us for this episode of the Codish podcast. Codish is produced by Heroku, the easiest way to deploy, manage and schedule applications in the cloud.
If you'd like to learn more about Codish or any of Heroku's podcasts, please visit heroku.com slash podcasts.