Pitching Go in 2025

Well, hello, hello, hello. Welcome to another episode of Go Time. I’m your host, Johnny Boursiquot, and today we have a special show. I think it’s special because in the age of great programming languages “Does Go still make sense?” That’s the question we’re here to ask. Where does Go still make sense? With all the changes that have been coming to modern programming languages, and taking into account some of the gripes folks have had with Go in the past, the features that have been added to language since then, the ecosystem that we now find ourselves in, in the age of AI and all these things, does Go still make sense? Does it still carry the same weight that it once did, 10 or 15 years ago? Is it still the language of the cloud, and all that stuff? So we’re here to talk about Go in this day and age.

Joining me to have this little discussion are a couple of folks. One of them is going to be familiar to you. He’s been on the show a few times to discuss everything, from being grumpy old tech veterans talking about old school stuff, to talking about AI… Please welcome back Mr. Kent Quirk. How are you doing, Kent?

I’m doing great. Thank you very much. Just note that I’ve been using Go for - I just was thinking about it - a decade now.

Nice, nice. You’re going to bring that perspective. And obviously, you’ve been using a ton of other programming languages and stuff in the past as well… So definitely looking forward to your perspective. Also joining me is Mr. Christian Gabrielsson. Christian, introduce yourself.

Yeah. First of all, the Go Time tune - one of the best; one of the best intro tunes that there is. So I’m really excited to be here… I’ve been in the industry now for roughly four years, going on five. I actually joined late. So in my late twenties I went back to college, and then I just did a career switch. So I’ve been doing this now for like five years. I’ve used Go on and off for roughly two years out of that, professionally for like a year and a half before I switched companies… And I’m sure we’ll get into more of that later. But yeah, that’s me.

Awesome. Welcome to the show. It’s always good to have a fan of the show. You’ve been listening to Go Time for quite some time… It’s always good to have a fan of the show actually come on the show. So if that’s you, if you’re listening to this show and you’re thinking “Hey, I have some things I’d like to talk about. I’ve got some things I’ve got to take off my chest”, definitely hit us up and we’ll see if we can make that happen.

But to give some context for folks, actually, Christian, you submitted a request, an episode request, because at the time - this was way back, over a year ago; at the time you were going through the process of proposing Go within the team at the company you were working with then. And it turns out, after we got in touch with each other, the project ended up, or rather the proposal ended up not going through. And I’d like to understand, as much as you can tell us, what were the circumstances around that proposal. It’s very rare that we hear a proposal, “Hey, here’s Go, and here’s what it can do”, and for folks to end up not going with it, even after seeing the benefits. So I’d love to understand some of the context around that, and why Go was not chosen.

Yeah, sure. So the company I worked at previously was using – I don’t know if you’re familiar with this platform… It’s called MuleSoft.

Yes, they’ve been around for a minute.

Okay. Terrible. Terrible, terrible, terrible. It is so terrible. And I say that with someone who knows the ins and outs. We built this giant booking engine thing, but this thing would take like 20 minutes to load up. It was terrible to develop on, because it was like a no code or low code solution. But what ends up happening with these - what I think just from the short term that I’ve been in the industry, with these abstractions, is they start falling flat in their face. It’s just not very performant to develop on it, and everything.

So I wanted to go ahead and create a POC just using Go, where we could get the same API – because these APIs are very simple. It was basically grab something – I worked for an airline. So it was basically grab something from Amadeus or Sabre, which is like a reservation system, do something to the data, and then return it in like a nice REST form. So it was very, very simple. And so there was no need for the whole MuleSoft abstraction to just do that API.

[00:07:56.16] As I created the POC, my boss and my boss’s boss was very excited. But then there is the issue of “Is the enterprise ready for it or not?” Everyone was really locked into MuleSoft. And MuleSoft comes with like a lot of great things as far as platform. The security, the pipelines… Everything is already included inside the box. And if you want to get out of that, especially in an enterprise setting, you have to figure out a good way of doing that, using like Kubernetes, and all this good stuff. And it was just too much work, and they weren’t willing to commit to it… Which is understandable.

So if I understand correctly, there was already an adoption or a comfort with an existing platform, an incumbent, where Go, or it sounds like really it could have been anything new, any language, did not have enough momentum to dissuade the people who are already comfortable with the tech, that they know and use to try something perhaps new or different. Basically, it took too much effort to try and adopt something new. Would that be fair?

That’s basically fair. Say you want to go ahead and create a Go app, and you want to like push it up so that you can publicly serve it. Well, suddenly, you need a gateway, you need a cloud somewhere to host… You need to figure all of these things out. And that was just organizationally too difficult to do for that given company.

Kent, you’ve been around for some time… And I mean that in the best possible way. [laughter]

What’s your opinion on MuleSoft? I want to know, I want to know…

I’m not going to talk about MuleSoft.

Okay…

Please. I’m sure you’ve come across situations like that… How often is this technology choice a cultural one, versus a technical one? Are there nuances? What have you come across?

I mean, this is the quintessential problem whenever you have – you can phrase it as “How do you eat your own lunch?” It’s the classic innovator’s dilemma. “I have something that kind of works now. Dare I try to replace it with something better?” …done badly, and - full confession, I’ve done it badly - you can try to switch to something and spend so much time doing the switching that by the time you’ve completed the conversion, you’re way behind in the market.

In other cases - you know, I came to go particularly in an organization where we were deep into a node deployment. And this was pre-promises, this is 2014, and we were in callback hell. We were doing some really sophisticated logic that was almost impossible for normal human beings to process, because we were trying to deal with 17 layers of callbacks. And it was a mess. And one weekend I read about go and said “Wait a minute…” and decided to sit down and try and recreate one of our services. We were kind of a microservices model. And I recreated an entire service in Go over the weekend, and came in on Monday and said “How about we switch to Go?” At least for the backend stuff. I mean, obviously not for the frontend stuff, but for some of the backend services… Because it was just so much easier to think about. And this was this was Go 1.6, or 1.7… Or 1.9. I mean, I don’t remember exactly which version. But it was a while back. But even then, the things that I still think make it a good choice were the choices we were making.

[00:11:53.12] But back to the larger question, every time – the company I work for now, we are doing observability in the cloud, Honeycomb, and we are trying to replace our competitors in the marketplace. We go in and we’re fighting with people who already are using some big competitor. And we’re saying “Hey, we can do it better. We can do it cheaper. We can do it faster.” Whatever we’re saying about that particular thing. And then those companies have to say “Well, okay, yes, but I’ve got a sunk cost.” And the question is, can you talk them out of – can give them a future that is looking better than the future they can see with the current thing, even given the cost of transition? You have to take it into account. But sometimes you have to say “Yeah, it’s worth it.”

So the definition of better… For a lot of companies, there’s a correlation with increased revenue, or profit, or something… There’s got to be an impetus. Simply, as a technologist, going in and saying “Hey, we should switch to language X, or framework Y”, there’s a cost to that. And while every engineer might be excited about the new shiny, businesses are not in the business of adopting languages or frameworks every other year. So there’s going to be a case that must be made… And I’m thinking in Christian’s case, where the company has tied their fate, for better or worse, to MuleSoft. And now here comes an engineer, with a solution which arguably could be better, by some definition, some technical definition, better than the status quo… But then the friction you’re running up against is not one of technology, it’s one of business.

So back to you, Kent - today I know Honeycomb uses a ton of Go, in all kinds of places. But I’m sure you probably already have other languages, or other technologies somewhere in there as well, because perhaps Go doesn’t do everything you need to do. But if you were to introduce and say “Hey, let’s try to change how Honeycomb does things”, from Go to, say, I don’t know, Rust, or Zig, or something… You’d probably run across the same barriers, wouldn’t you?

Well, yes. And again, as you noted, there’s a couple of different barriers. One of the barriers is just “Well, if we convert–” I mean, Rust is actually a big one. There’s a lot of people who are very excited about Rust, for a variety of reasons, some of which are, I think, good reasons, and some I’m not as excited about, but that’s okay. What’s the cost of that transition? Because you have to recreate what you have before you can move forward with the new way. Certainly, it might make sense in a world where you say “Well, we need a new service”, say, “and we’re going to try writing that service in Rust to see how it goes.”

Actually, I’m pretty involved in open telemetry, and one of the things that happened with open telemetry was like most of the underlying things like the collector and stuff is written in Go… It was kind of the first language of open telemetry. There’s many things and other things, but now what happened is there’s one major piece that’s being created, and somebody said “I want to try to do this one in Rust.” And so we’ve got this processing tool that is being written in Rust, rather than Go… Which has its own social issues, because a bunch of the people who’ve been working in Go for the last decade aren’t qualified to actually even review code in Rust. So you have to make that whole team transition. There are benefits to doing that stuff. But that’s the expense. And like I said, when I switched a team from JavaScript to Go back in the day, we were still pre-launch. We didn’t have a constrained thing. We were still building all the pieces before we could get it out the door, and we decided that actually we would save time by converting our services to Go, because at that time we didn’t have that much to do.

[00:15:51.26] Now, for Honeycomb it would take a major act of Congress or something to cause Honeycomb to switch away from Go, simply because there’s just so much code, and there’s so much stuff that works well, and is in production, that switching it out for just because there might be a benefit someday…

Yeah, it’s a hard sell. So Christian, you mentioned you’ve been – relatively, at least, to Kent and I on this podcast, you’re relatively new to software engineering overall. I think you mentioned something like four or five years. Is that right?

Correct. Yeah.

So in your experience to date, the – obviously, you went through the crucible of proposing something that didn’t go through, and you got a sense of, well, while you might have a technically sound solution, the decisions are not always technical ones at heart. What else have you gathered so far in your software engineering journey around how technology decisions are made? …especially now that you transitioned to a different company, how are you – so what have you picked up? What is your perspective now, compared to folks like Kent and I, who’ve been around for a while?

I think one of the frustrating parts - and Kent, you mentioned this; and you as well, Johnny - was this sunk cost fallacy. If you’ve been throwing so much money at something, and so much time at something, it is just very, very hard to switch people away from that. And I think something that Kent just mentioned, and for something to me that I think is unacceptable, is I’ve worked with people who are - say they really like Java. And then we are switching to Go. They just simply won’t. They’re comfortable with Java. They don’t want to learn a new language, and stuff. And that is a real friction. If you have a bunch of people doing one thing, and don’t want to switch over to another thing, then that becomes even harder. And I’ve seen that as well with engineers. And that is kind of interesting to me, because just in my four years that I’ve been in the industry, four or five years – I mean, right now I’m doing Airflow, mostly.

Okay. Airflow. What is it –

So Python.

Yeah. Can you explain a little bit about what – I think you mentioned Python. What is that technology, framework, or stack?

Yeah, so Airflow is for data pipelines. So it’s like an orchestration tool. It was originally an Airbnb, then they open-sourced it, and now it’s in the Apache Foundation. So it’s Apache Airflow. So it’s used for – in American Express, they use it for a lot of things, but I work in finance, so it’s used for reporting, for like the federal requirements, for like financing, with banks. So that’s what I do now. But previously, I was doing Go. Previously, I was using MuleSoft, so Java, and then previously I was on the frontend, so Angular.

There’s so many different languages, tools, and frameworks that you consistently use… And I think one thing that I’ve learned just in my short term is that you have to be continually a) learning, and b) being able to switch between languages. Because I think that that is the future.

So the ld adage of every tool for the – the right tool for the job, kind of thing… Which, interestingly enough, in my experience that typically means – like, very seldomly am I on a team where people will say “Use the right tool for the job”, and it doesn’t end up being the tool they know the best. [laughter] In some cultures, in some team cultures, perhaps everybody kind of accepts that, and they’ll be like “Well, we picked this language, or we did the due diligence, we identified this language as the thing we all love and want to use”, and so that implicitly becomes, “Well, why not use the thing we all said we were going to use?”

[00:20:08.15] I mean, that drove an awful lot of Node adoption, because people are like “I’ve been coding in frontend in JavaScript, so why can’t I code the backend in JavaScript?” And that was in large part why the team that I had worked on was using it. And once you realize that there is a bright line separation between those two, there’s no particular reason that doesn’t justify, in my view, wanting one language. The languages are pretty fungible. You can you can switch between different languages and get the thing done. It’s the systems around those languages and what they give you, and that’s one of the big benefits of Go. I think, from my point of view, the most enormous benefit of Go is the fact that if I went back to the code I wrote in 2014, I could even compile it with the current Go compiler. I can read it, I can maintain it. And Go, beyond – like, the JavaScript code we had at that time wouldn’t even run today. And it would be considered five generations old. And one of the major, major, I think, advantages of Go is its long-term maintainability.

The Go 1.0 compatibility promise has been really, really important. And the fact that that code - I can still read and write the same code, in the same styles, for a decade… It turns out software lives a long freaking time; a lot longer than you wanted it to. I’ve got stories about that too, but man, you’ve got to be able to keep working on it. And the pain of – you know, we just watched the team switch from React 16 to 18… That was a painful multi-month effort, by multiple people.

Was it painful? I’m assuming it was painful because, just like in Python, there’s dependencies upon dependencies upon dependencies. And Go doesn’t generally have that issue. You’re not trying to npm – make sure all of these packages are all compatible with each other, and that they also can be upgraded.

Not usually. Sometimes it still happens. But in general - yes, dependency hell is much less of a problem in Go… Although it took Go a long time to get there. The go.mod stuff, I think, came out okay in the end… But boy, there were a few battles back around - was it 2017, 2018? It was kind of a nightmare.

But yes, dependency hell is a problem. Just people going “Well, we’re going to make a breaking change. It’s time to make a breaking change.” And the acceptance of breaking changes, if you’re always staying current… Or your model is “I write new frontends all the time, and I don’t go back and fix the old ones.” I mean, that’s the kind of thing that happens with mobile apps. You build a mobile app once, and you maintain it for a few weeks, and then it stops selling, and then you go on to the next mobile app. You don’t really need 10 years worth of maintainability. But when you’re working on backend code, that stuff lives forever.

Break: [00:23:16.13]

So at some point – or rather, I keep thinking that folks that are sort of comparing the fine tooth comb languages, or whatever camp of your favorite language is today, at some point I think ultimately, at least for me, it became clear that… I think you touched on this earlier, Kent - ultimately, the language may not matter. Once you have a sound foundation for a choice of a language or technology, whatever the case may be, at some point that choice doesn’t matter, in the sense that once the business, once it’s in production and the business is making money on it, there’s a certain threshold where whatever gains, whatever changes you want to make, they have to be additive. You can’t go back and change something that is working, by some definition, you can’t go back and change that. Whatever new thing you want to add is going to have to be a new thing that you add on top. It has to be additive to increase revenue, reduce costs, whatever the case may be. When I say it doesn’t matter, your attention, perhaps as you sort of came to understand very vividly, Christian - there was no way the organization or even the team was going to move away from Java and MuleSoft in a sense, because those decisions had been made and cemented. You kind of had to pick your battle – in this one you kind of picked the wrong battle, if you will.

Yeah. And then on top of it, I don’t know if I if I mentioned this in the email, but I switched over to a team within that same company, that actually used Go. And one of the reasons I went to that team - and funny enough, led it, even though I didn’t have that much of Go experience; they just knew I was really passionate about it - was because it was a dumpster fire. It was just – and it wasn’t anything, obviously, with Go…

The project or the team?

No, not the team. The developers there, all of them were really, really, really amazing. They were really hardworking and really smart. It was just they – foundationally, they didn’t figure out how to make AWS work with the given product that they had. They didn’t figure out all these things - the pipelines, and everything. So it was just a complete mess. So then they had like a comparison. They said, “Well, the MuleSoft thing isn’t too exciting, but it works. But then you have this new thing, Go, but that’s just a dumpster fire. So we’re not going to even try to switch to that.” And I see that. If I was an executive and I started – I can explain all day long why this doesn’t work and this does work… But if it doesn’t provide value, it doesn’t provide value. You know what I mean?

So let’s switch up the conversation a little bit to something else that I’ve also been contemplating. In my line of work, because I have to wear many hats, I end up solving different kinds of problems, which are not always solvable with Go. Sometimes I have to switch to put on my Python hat, because I’m doing some large language model AI development work, sometimes I have to put on my – I’ve even had to write some Lua recently… Different problems call for perhaps different tools, in different languages. But I’ve found myself relying on modern tooling, by which I mean gen AI style, large language model powered chat bots, the ChatGPTs and the Copilots and everything else to help me move forward. Which - it kind of dawned on me ultimately that perhaps here too the language did not matter… In the sense that what I’m trying to accomplish is solve a problem. If solving this particular problem means I have to be in this ecosystem, I have to use Ruby on Rails to spin up a quick CRUD app, a proof of concept that basically solves that particular problem quite well, that’s a stack for it… Then I can use one of those Copilots to help me spin up this code.

Heck, last night I was – I never used Tailwind, and I needed to quickly come up with a static website, and I’m like “Hey, you know what? Tailwind seems to be the new hotness, at least for a much improved experience from dealing with plain vanilla CSS”, at least from how I remember it, from a couple of decades ago. So I used Tailwind, and I asked ChatGPT to generate some CSS for me. “Give me a template, give me a – whatever it is”, and I was able to copy-paste, make some tweaks, and then I was done by the end of the night. My job was done. I had a solution, it got shipped, and I moved on in my life.

[00:29:56.28] Now, am I going to be doing Tailwind all day, every day? No. I had a specific problem, and I solved it using these new tools. So I’d like to hear from both of you, are you sensing this tug away from the fanaticism, if you want to call it that, around specific languages or technologies, now that we have these AI tools that are entrenching themselves in our lives as software engineers, as professionals? Are you sensing this tug as well, that these things ultimately don’t matter that much?

I think the world is open to more solutions than it used to be, I think because, as the internet has exploded, and like you said, with the ChatGPT and all the other Copilot, that kind of stuff, it’s easier to switch tools and platforms. I think there’s a difference though between “I need to solve some little problem, and I’ve just got to get in, get out, and I don’t care what language I use to do it, I just need a solution” and “I’m going to build my business on this, and hire engineers to work on it. And it’s going to run for the next umpty-ump years, possibly at really significant scale.” And those decisions require more thought. And you need to think about what are the strengths and weaknesses of the solutions you’re considering.

So for example, I love Python. I do almost all my small stuff in Python. It’s a great little language for an awful lot of things. Everybody I know who deploys it at scale ends up running into massive, massive problems when you try to really scale Python because of just the nature of the way it works. And so deployment’s a problem, the global interpreter, the GIL lock is a real issue… So running a lot of the things you need to do when you scale to really big scales becomes much harder in Python than it is in languages like Go, or for that matter Java, or .NET. Those have systems that are kind of made to just do that, and it works.

So if you’re going to scale at that level, then I would really question whether Python is the right choice for you. On the other hand, Python is a great way to get a business up and running at first, and so maybe it’s worth having that pain; it’s a good problem to have. How do you scale it? And then maybe it’s time then to think about “Can I reimplement parts of my backend in a different language that’s more performant, or easier to scale, or whatever it might be?” Anyway, I’ve now kind of forgotten the point I was trying to make. It’s the big problem versus small problem decision. Big decisions need more consideration than small decisions.

So is the decision then around ecosystem? Mindshare? How much historical stuff is around?

And who you can hire. Your available talent pool, which includes who and who your talent pool knows, because that, especially early in the life of a startup… You know, your collection of people that you hang with makes a difference. And so yeah, Python might well be the right choice for you, because those are the people you’ve been working with and growing up with, and so you deal with those problems later. You’ve got to survive first.

So yeah, I think there are languages you can choose that will make your life easier, there are languages you can choose that will make your life harder… It also depends on what industry you work in… If you’re working in finance, you’re going to be able to choose a different language than if you’re working in software as a service, than if you’re working in games. So yeah, all of those things…

Christian, how’s your life impacted as an engineer in light of these new toolings and access to all this new fangled stuff?

[00:34:00.19] You mean the AI assisted tools?

Yeah, exactly. Well, perhaps a more specific question - given that you didn’t start out as an Airflow expert, perhaps not a Python expert… How did you ramp up, to be effective enough to get the job done? Did you use those Copilots and ChatGPTs, these new tools to help you ramp up?

Yeah, for sure. So I definitely used some of the ChatGPT… But honestly, so some of the documentation can be better or worse. For Airflow the documentation is really, really well done. So honestly, whenever I look at a new tool or or a new process, I like to look at the documentation first… Because I understand there are AI tooling, and that’s really helpful. I use Copilot during during my work. We have access to Copilot. But there’s something to be said about learning whatever it is. So you mentioned Tailwind. Yeah, first of all, with Tailwind - I’ve built a website using Tailwind. I’m not the biggest fan of like the markup in the HTML code. But that’s just like an unpopular opinion, I guess… I like my CSS to be on the side. But no, what I was going to say - you’re sort of blind… When I was learning Go, for example - I have two or three different books in Go that I that I read… Because I don’t think you can just fundamentally just rely on these AI tools to learn a language. You fundamentally have to know how it takes before you can effectively use it. But that might just be my opinion. You know what I mean?

So as a relatively new engineer, you’re still thinking, and hopefully I’m interpreting this correctly, that knowing language or the tool at a deeper level, as opposed to a shallow level just to get the job done, is something that’s still important to you, right?

Yeah, 100%. Because fundamentally, if AI can do what I can do - well, then there’s no purpose for me. That’s just how capitalism works.

Well, I mean, if you –

You can supply the energy to run the batteries… [laughter]

Like, no one’s gonna pay me money if like the AI tool could do what I can do. It’s supposed to be a supporting role. But if I don’t know anything about a language, or… I think just in general, these software patterns - then yeah, It’s sort of like the blind leading the blind, I think.

So there’s a guy, Ryan - I’ve forgotten his last name - that kind of created Node originally. He has now created Deno, which is like Node, N-O-D-E, D-E-N-O. And Deno has some really interesting features that kind of bring it into the realm of some of the reasons I chose Go. It compiles to executables, that kind of stuff. And it’s pretty cool… Deno has also got the problem of JavaScript, which is they released a 1.0, and that was cool, and then we learned a lot from that, and now we’re doing 2.0. And I was trying to play with Deno the other day, and I wanted to write some - what I hoped was fairly simple code… And it got into this really messy thing, because all the examples and everything that Copilot is trained on is all based on Deno 1…

1.0… [laughs]

[00:37:49.20] …and the stuff I was trying to do was all being marked by Deno 2 as “Hey, that’s obsolete. You should do it this other way.” Except there wasn’t any example I could find in the other way… And it was like, it’s really an interesting thing what Christian has pointed out - you need to use your brain to decide if the thing that the AI bot is telling you is actually useful. And so in this case, it wasn’t. [laughs] So that kind of touches on this whole thing of technology choices, and all that kind of stuff. I mean, it looks to me like Deno 2 was going to be really cool, but I’m going to come back in a few months and see where it is.

Right. Until the dust settles.

And to Kent’s point - so I think where this shines the most, and where I sort of… I haven’t yet looked into more codebases that it uses, because I know everyone likes using Copilot for tests. And we all know we can make tests pass a hundred percent. But justbecause they passed doesn’t mean they’re useful, or reliable, or anything like that. And so when you start to stray away from test-driven development and you have Copilot write them - well, is it actually doing something useful? Is it testing what you needed to test, or are you just writing a test to write a test? So that’s for me where the jury is out, where it’s sort of like the blind leading the blind type of scenario.

Last question, AI related, at the risk of turning this into another AI episode… So for you, Christian, specifically - because obviously you are still maturing as an engineer, and hopefully you go on to accomplish great things, and continue to contribute to the craft… But are you worried about the role that AI is going to play, and how it might affect your trajectory?

So I’ll answer this by saying that I am a stoic by heart. And one of the core principles of stoicism is the fact that there’s things that I can control, so internal things that I can control, and there’s external factors that I can’t control. I’ve already switched careers once. If I need to switch again, I guess I’ll do it.

I don’t think it’s going to. I think it’s going to help. I don’t think software engineers are going to disappear, just because there’s just terrible codebases out there, and someone has to maintain them. There’s always an issue. These low code solutions haven’t really worked out, as far as I can tell, from my short part of the industry… But if it does - hey, great. I always said when I retire I’ll either be a goose farmer or I’ll open up my own scuba shop. So I don’t know. I honestly don’t know. That’s being funny, obviously, but… I don’t know what’s going to happen in the next five years, let alone 20 years. And honestly, is there a point in worrying? Not really.

Yeah, that’s definitely the stoic approach to it. Yeah, for sure. For sure. And I think, Kent, if you were to answer the same question, I think by virtue of having been around for much longer, I’d say you have more options by definition, in terms of where your career takes you within tech. Would you say now that AI is commonplace for our profession, does that affect – is that occupying a lot of time in your head right now?

It really isn’t. I mean, I enjoy ranting about AI, but I find that AI is not solving the problems I’m being asked to solve. I saw a quote the other day that was something like “Junior engineers write code, senior engineers delete code, and staff-level engineers eliminate the system, or redefine the problem.” So I think we’re at the point where AIs can write a fair amount of code, but they can’t write good code, and they don’t know if they’re writing the code that is actually useful or.

[00:42:00.17] If you can describe the problem clearly enough, you can probably get the AI to kind of mostly write a lot of it for you… So they can be a helpful additional productivity tool. But I don’t think they’re even close to replacing people at the level of staff engineers in scalable organizations. So I’m not worried about it.

Right. It’s interesting to to know – and Christian, I know you want to chime in here… It’s interesting to know that in the beginning I think folks were saying similar things, but they were saying, “Hm, I don’t think this is good enough to to replace a junior engineer.” Then it became “Hm, I don’t think this is good enough to replace a senior engineer.” Now we’re saying, “Hm, I don’t think it’s good enough to replace a staff engineer.”

That’s not quite what I said…

[laughs] No, no, I’m not saying you said it. I’m just saying – but please, please. Add some nuance.

I think the nuance is that I don’t think it’s even good enough to replace a junior engineer. Because it can be told to write code conforming to a specification… It still takes an engineer’s mind to write a specification that ChatGPT can implement accurately. If the problem you can solve is so trivial, like you’re just cranking out a generic CRUD app that nobody cares about, and nobody cares about usability, and nobody cares about design, and nobody cares about whether it works right or not… If you can make a business out of that, more power to you. But I don’t think you can. And I’m saying that you can get a productivity boost, but you’ve still got to have somebody who’s going to swing the hammers. And I think it’s a more powerful hammer, but it’s not the constructor. It’s not the carpenter.

Christian, do you want to add anything?

Well, I was going to follow up then. So in 20 years, do you think that engineers are going to be replaced, or are their roles going to be fundamentally different than –

Are we turning this into an AI podcast? [unintelligible 00:43:55.24]

Our promise was this was the last question, but yeah, let’s bring our attention back to the matter at hand here, before we transition to unpops. And perhaps we can bring back the AI thing for unpopular opinions. I keep thinking about Go’s future. Go is 15 years old now, and growing… I think like Java before it, it is now enterprise-grade, and I don’t think anybody’s going to dispute that. Go has been the language of the cloud since its inception, and continues to be used for pretty much any cloud-native sort of services, backends, subsystems… You name it. Probably three quarters or more of the CNCF projects are written in Go, and whatnot… So we know Go’s not going anywhere. Like other languages before it, the C, C++‘es of the world, the Javas of the world, these systems are still running critical components of our modern society. These things are not going to go away. I think there’s always going to be a need for people who understand these things… It’s just that for a while there we were looking for – I’m not sure if we still are, but we were looking for people who still know how to write COBOL and Fortran, because a lot of government systems are still using those things, those mainframes.

So I think at some point Go, like everything else - and this is the cycle of life. Something comes in, it’s popular, lots of mind share, people want to learn and people want to use it… And then it gets replaced eventually by the new hotness. So I don’t think we’re at the stage yet for Go to be replaced by the new hotness. I don’t even know what that would be. I think the problem is going to get redefined, to borrow Kent’s staff engineer analogy. So we’re going to stop defining the problem as we always have, and then now we’re going to try and solve the problems with new tools, in different ways, because we’re asking different questions. But until then, Go’s fit for the future, or basically the current market we are in now… How do you see – are you using the same metrics that you used to pick Go 10 years ago, 12 years ago, or in your case, Christian, when you first came across it and you saw it three, four years ago, like “Wow, this is amazing…” Are you all still using the same criteria to pick or to stick with Go? Or is that changing, or should it change?

[00:46:19.27] I think fundamentally it’s always using the right tool in the toolbox, is what I’ll say. Java is known for this. The JVM cold boots takes a few seconds… So if you need a process that works right away, honestly, don’t use Java. But in that case, obviously, use something that’s more performant right out of the box, like Go, that doesn’t have that cold boot sequence.

Similarly to – I know not everyone is a big fan of Python, but for data sciences, all the libraries and everything, you might as well use Python. For frontend, JavaScript. I don’t think these these things change very often. I think one thing that Go has, that not many languages have done well so far, is that backwards compatibility. And I think that is going to be – for like the next 10, maybe even 15 years, is what makes it still very relevant, is the fact that it is backwards compatible. Like what Kent said, you can have a project in Go from like 5, 10 years ago, and it will still run, versus if I were to boot up one of my old JavaScript projects I did like three years ago… I guarantee you it won’t work. And that is for maintainability, in large teams, that’s everything, I think, personally.

Yeah, I think there are key reasons to choose languages. Again, as Christian mentioned, certain kinds of performance require certain kinds of things. Compiling to binary is a different thing than running on a VM. And a VM like Java is different than a Python style interpreter, slash VM… And interpreter is a terrible word for that, but you know what I mean.

So choosing your languages - I think the interesting question is like… Okay, so as Christian pointed out, Go’s backward compatibility means that it has more longevity. There isn’t a push. The interesting thing about JavaScript is because it changes so rapidly, at some point you have to make a big change. Well, if you have to make a big change anyway just to keep JavaScript, then you could start considering whether there’s other options. I mean, Node to Deno, or maybe start rewriting the backend because the old backend has gotten crusty and you can’t maintain it anymore. That’s a really interesting inflection point that a language like Go resists because it’s so stable.

So I think Go will still be around. I mean, it definitely will still be around in 10, 15 years. The question is how popular is it, and does somebody else invent a slightly different paradigm, or a more important paradigm, or whatever? And the answer is I don’t know. But whatever it is, we’ll be there to play with it, right?

Break: [00:49:03.20]

Alright, who brought the heat?

First of all, again, the theme of this show - second to none. I love it. I love it.

[laughs] Nice.

I’ve got an unpopular opinion that’s been brewing for quite a bit. When a given team chooses to use “insert your language tool or framework” in order to prevent a lot of pain from happening, I would highly suggest just reading the Getting Started guide on “Should you use the tool? What’s the use cases for it? What’s not the use case for it?” Because even in my short period of time that I’ve been a software engineer, too many times have I seen tools, frameworks or languages used in the incorrect way for the problem at hand. So that’s my unpopular opinion, is read the Getting Started guide. 90% of problems solved. [laughter]

You’d think this wouldn’t be like a controversial issue, but us engineers, we just like to jump in, bang our head against the wall… The answer could be in the readme, but no, no; let’s experience some pain first… [laughter] Kent, what have you got?

I’m going to jump on the same theme… I think that Go is an interesting place in terms of its level of complexity that it supports, and its syntax. And it has been criticized for being aggressively simple, and I think that is actually largely its secret to success. And that more – languages, whether you’re talking about like Haskell and OCaml, or whether you’re talking even about something like Rust, they’re going to have trouble sustaining… Like, they have bursts of interest, but they never sustain it in production. And it’s because they’re too technically difficult. They require too much brainpower to get right. You can’t code those languages badly and succeed. And so that means that you have to choose your engineers from the cream of the crop, and over time, that doesn’t scale. You have to get more average engineers to be able to build a business that scales to large scale. And so it’s going to be hard for those kind of languages to ever gain really sustainable traction.

My unpop is one I’ve arrived to recently. If you recall back in the day a lot of folks didn’t – some of the gripes against Go was like “Well, it doesn’t have generics” or “It doesn’t have -” insert my favorite feature, from my favorite language. Blah, blah, blah. Or I don’t like how it does error handling. The typical set of things… Some of those things you don’t hear anymore, because the language has added those things as features. But I’m of the opinion that unless you have a very specific use case for some of those language features - I’m talking like generics, or iterators, or things of that nature. If you find yourself not reaching for those things on a regular basis, despite the hype and the fanfare around them, you’re not doing anything wrong. You’re not using Go wrong because you’re not using iterators.

[00:55:55.00] I think those things, those features are very useful for a very specific kind of problem. You’re going to find great use for these things if you’re trying to create abstractions, or a general-purpose utility for certain things. If it’s something you want to be able to work with different kinds of data types, and things of that nature. These generic - using the term loosely here… These generic approaches, they solve a particular kind of problem, a particular class of problems, that for your day to day writing line of business code to move data from here to there, if you don’t find yourself reaching for those things constantly, or even thinking about them, that’s okay. It just means that your use case doesn’t call for them. Just because a feature is in the language doesn’t mean you have to use it. That’s perfectly fine. It’s perfectly okay. It’s okay if you never use generics in your code, if you don’t ever need it. And it’s okay if you go the long way on certain things. It’s okay if you never use iterators. It’s okay if you never use fuzz testing. It’s okay if you don’t use those things, because not every feature of the language needs to be used.

Again, this is for me using the right tool for the job. I’m thankful and I’m grateful that Go has so many tools that I can reach within that one tool belt, and then pick out the one thing that I need to use for this particular instance. I’m grateful for that. But just because I don’t reach for that specialized [unintelligible 00:57:14.19] in my toolbox, because I rarely have use for it, that doesn’t mean – me knowing that the tool is there in case I ever do want to use it, knowing that it’s there is sufficient. But I’m not going to think “Oh, I’m not using the language to its full potential because I don’t reach for this specialized tool.”

Is there a use case for generics in Go?

[laugh]

Yeah, I mean… Generics in Go are a subset of the problem other languages have tried to solve with what they call generics. With Go, it’s basically types as parameters. And so I want to make a container… I recently had need to build a set that had a time to live on the elements that are stored in the set. And I wrote a generic implementation of that because it was actually just as easy to write it in generic form as it was to write it for ints, or for strings. And so I could make the generic version of [unintelligible 00:58:12.01] And then even though in my particular application it’s only useful once, it’s now in the library of tools that other people can reach for. And that was worth it. So that’s the kind of thing you do with it. You have to be careful though, because I’ve certainly seen situations where you write four lines of generic code and 100 lines of comment to avoid having to write the same four lines twice. And that’s probably over the top.

Yeah. And this is the kind of thing that I think a staff engineer is going to call out, or a senior engineer is going to call out for a junior engineer, that perhaps AI might have a I have a hard time discerning when does it make sense to use that versus another. So there’s a higher level thinking that needs to happen there to understand the short term… “Oh, this is cool. Very, very sneaky, very intelligent-looking code”, versus long-term maintainability. If you have to answer a page at three o’clock in the morning and you have to look at this code… Which one are you going to be grateful for?

Alright, alright… Well, I thank you both for coming on the show and discussing this slight nuance right on a topic that has has come up time and again, Go versus - insert some language, or some technology. It’s been great having the perspective of a veteran, and that of a relatively new engineer… And I hope everybody listening has also had their own a-ha moments. And please, if you do, if you did, drop us a comment on the socials, and let us know what you think, both of the content and of the unpopular opinions.

Alright, thank you, Christian, and thank you, Kent, for coming on the show.

Delighted.

Thank you so much. I appreciate it.