Fallthrough & Friends

Well, I am joined by Fallout Boy, I mean, Fallthrough Boys, Kris and Matthew Sanabria from the Fallthrough Podcast. What’s up, guys?

Just hanging out. It’s another nice day. It’s snowing again in New York, so it’s been a little weird. We haven’t had snow in a few years, so this is a new experience.

Yeah, it’s all good. I’m coming here from Vegas right now, on hotel connection. But it’s all good.

So all the timing of Matthew’s jokes will be off, but…

Yup.

…we’ll do what we can do. My partner in crime, unfortunately, has come down with the flu, so Matt – so Adam will not be here. Also, his name is not Matt. He will take offense to that.

I know you want me to be your partner. I get it. Don’t worry.

Well, you’re here. There’s three of us. This is a trio… So that’s some kind of a partnership. Let’s talk. Let’s talk about what’s going on in the world of tech, let’s talk about what’s going on with you guys… Of course, the spinoff pod of GoTime - I’m wearing my legacy GoTime T-shirt… And Kris, I see behind you, you still have your GoTime poster on the wall.

Yeah. It’s not going to come down for a while… It’s a piece of nostalgia, you know.

I was going to say, not until you get that Fallthrough poster up there, and then we’ll be dead to you.

Yeah, we’ll see… We’ll see.

Well, it is 2025, and there are things going on, but I thought it would be cool to maybe take a moment… I saw an interesting post on Matthew’s blog. “The 20 greatest Fallout Boy songs ranked.” Oh no, that’s an errant tab that I have open. It’s called “Tools Worth Changing To in 2025.” And there was all kinds of cool stuff on there. So are you using all these? You’ve got Ghostty, Fish, Helix, Jujutsu, Zed, Nix, Ollama. I assume since there’s more than one editor on that list, you’re not using all these… But what are you up to there?

I’m not using Zed full time. I just have it installed just in case I need it for something else. And I’m not using Nix. Everything else I’m using, though, full-time.

So the one that was not new to me, but I’ve never used on this list is Helix. We’ve had long time requests to do an episode on Helix. I think we even had an acceptance, a guest acceptance to come on, and then it just didn’t happen. But this is like inspired by Vim, right? So it’s kind of like Vim, but then I’ve read from your post that they changed some key bindings around… So it’s what’s the point, man?

Yeah, it’s very much inspired by Vim and Kakoune. And they kind of flip – Vim has like a motion verb sort of deal, and Helix is a motion like noun verb sort of deal. So you don’t say the verb of what you want to do and then the noun of what you want to do it on. You say the noun of what you want to do, and then the verb that you want to do. So it’s like kind of backwards. But it’s very Vim-like. It feels like Vim. It just kind of has first-class for selections.

So it’s kind of like you’re almost always in visual mode, in a sense, in Helix, and then you enter insert mode to do your thing. I really like it, though. It’s got a lot of batteries included for like LSP, and TreeSitter, and things of that nature… Whereas Neovim, you have to set that up yourself. So that’s why I really like Helix.

So you’re daily driving that then?

Yeah. Yeah, that’s what I’ve been using for the past couple of months now.

Okay. And Kris, you still have your Vim poster up, so I assume nothing’s changed on your front, tooling-wise?

Still Neovim… I feel like a year ago I went through and I just completely ripped apart my Neovim config, and redid the whole thing, and it runs much better now. But yeah, still doing Neovim. Love how much stuff is built-in. You have to configure it, but there’s TreeSitter built in, there’s the LSP client built in… So a bunch of nice stuff built in for Neovim.

[00:08:11.13] Well, I’m a Zed guy at this point. I was a longtime Sublime Text user… Always Vim, though. Vim’s like my second editor at all times. So I’ve never left it. It’s always right there. But I have actually officially moved to Zed. And this is the first time – 2024 was the first time, probably ever, that I replaced both my primary text editor and my terminal of choice. And now I’m using Ghostty. So that feels like a big change for one year. Both things. But neither one felt very foreign, so it didn’t feel like a big change.

I was very surprised to see that you changed your terminal… Because you were very adamant on saying - I think iTerm or Terminal.app. I forget what you were on.

I was on Terminal.app, mostly because I’m minimalist and don’t want to install things if I don’t have to.

That makes sense.

So I’m always like “Prove yourself as better than the built-in.” And I didn’t really have a good reason to switch, but then Mitchell gave me a good reason to switch. It was like, I didn’t realize I had limited colors. And then once I did, I was like “Oh…” It’s like when you switched from black and white to color, and then you’re like “I can’t go back to black and white.” So that happened. And also Visor mode is just too rad, you know? I like Visor mode.

Oh yeah, that’s a macOS-only feature, so I don’t use that… But I heard it’s really nice.

Yeah. That’s the major, I would say, complaint against Ghostty at the moment, is that the whole cross-platform thing is kind of like – you have to squint to call it cross-platform, because no Windows support yet, and the Linux support doesn’t feel native, I guess, depending on which distribution you’re on. I don’t know, I’m not on Linux, so I don’t have that experience, but I think other people have.

Yeah, I’m running GNOME, and it feels pretty native for a GNOME app… But those that are on like KDE or something else probably are like “This is not native.” But you know, Linux doesn’t really have a definition of native anyway, so it’s hard to do that.

Right. Kris, have you picked up any new tools in 2025, or last year, that you’ve actually adopted?

I have started slowly moving myself over to Ghostty. So that’s one thing. I’ve liked it so far. I like the ease of configuration. I’m a big fan of this whole, basically command line flags in a file. I like that. So simple. Very clean.

Yeah. That is cool.

But yeah, as far as software tools or software building tools, no. But as far as other tools, yes, because now that I’m doing post-production on a podcast, I’ve had to relearn Audition, I’ve had to relearn Final Cut Pro… Which is basically a completely different app. Because back when I got my degree, we were still on Final Cut Pro 7. And then Final Cut Pro 10 came out and we were all like “This is awful. Don’t use this. This is iMovie, but for prosumers. Bah, terrible.”

Right.

And in the decade plus since, it’s grown into a mature NLE. So I’ve been learning Final Cut Pro 11. It’s still got some things I don’t like about it, that still feel a little more iMovie/consumer-ish than a professional editing tool… But overall it’s been a pretty good experience. Re-learning all of my shortcuts… I’ve been using my trackpad way more than I like, because it just slows you down in a lot of ways… But yeah, it’s been a nice experience getting back into these familiar, but old tools. So like new tools, but they’re old tools at the same time.

So someone’s got to do it.

[00:11:45.19] Yeah. That is the hard part, isn’t it? Or the tedious part of podcasting, is the edit. What I find interesting about that, Kris, is that you have your toes in two different tide pools, so to speak, because you have Audition, which is an Adobe product, but then you’re using Final Cut Pro, which is an Apple product. And not Premiere Pro, which is Adobe’s video editing equivalent of Final Cut Pro. And I don’t think our listeners necessarily have any interest in audio/video editing tools like you and I do, Kris, because we are daily driving those suckers… But just that dichotomy of like going all-in on an ecosystem versus not. You’re giving up some integration and some crossover that only Adobe can do, in order to live in both camps.

Yeah… It’s sort of painful, I will say. I see that “Export to a Premiere” button or menu item in Audition, and I’m like “I should just be doing this…” But I’m on a Mac, and there’s a lot of really deep integration that Final Cut has with the hardware that I wanted to take advantage of if I could. And unfortunately, Apple does not have a similar level DAW, digital audio workstation, for podcast editing. Like, they have Logic, but that’s definitely more of a music-based DAW, that you can sort of squint at and turn it into like a spoken speech kind of thing. But it’s like, Audition is definitely the gold standard for this type of audio content. And so it’s just like “You know what? I’m just I’m just going to use Audition, and I’ll just deal with this weird flipping between Final Cut and Audition.” I think I’ve gotten it down after editing a few episodes now. It was kind of a mass jumping back and forth between the two… But I think I’ve figured it out now. Gotten it down.

I’m just sitting here, crying in Linux… Like, I can’t run any of these things…

Right. Yeah, that is the drawback. I mean, there are certain tasks that certain environments are just not built for, and there are other tasks which they are. This has us often doing things that we otherwise wouldn’t do, like keeping a Windows box around, for instance, or switching between Adobe and Apple, or running WSL… Which is cool, and better than not WSL… But, for instance, wanting Linux tooling on Windows and stuff like that, where it’s just like - I think as developers, we probably have the messiest programming environments, because we kind of need all the things at different times.

I really like development on Linux. I really don’t like content creation on Linux. And that’s where life splits for me. Maybe I should have just got a MacBook or something, and kind of – I think that’s the best of both worlds, personally.

Well, I don’t want to be a hater, because I love Linux, but for the last 10 years anytime somebody came on the show and said they’re running Linux, me and Adam just collectively sigh… Because it’s like, there’s probably going to be issues on this particular episode.

Well… Do your sigh…

But Riverside and in-browser tooling has helped that quite a bit, where we’re not reliant on Audacity not crashing. Or sometimes Audacity will actually grab the microphone IO from the browser, for whatever reason… But aside from that, back when we had to have Audacity run flawlessly in order for the show not to fail, we were super-scared to have a Linux guest… Because the failure rate was honestly like 30 percent of the time there’d be an issue. And that’s really high.

I believe it. Well, give the listeners a big sigh, because I am running Linux right now… So let them have it.

Well, they’re listening to this. It was successful. So…

Perfect.

I’m the only one nervous here. They already have demitigate – demitigated? No. You mitigate risk. You don’t demitigate it, unless you want to live dangerously… [laughter] Well, we demitigated all of our risk, so now we’re at ultimate risk. Funny.

The other one I saw on your list, Matthew, which I also haven’t tried is Jujutsu. Or JiuJitsu? I don’t know how you say it.

[00:15:54.22] I actually don’t know how you say it either. I was saying it like JiuJitsu, like the martial arts… But the spelling makes me want to say JiuJutsu… But that sounds weird.

I was hoping you’d tell me.

Yeah, I love it. I don’t even use Git anymore.

This is a Git replacement. This is a distributed version control system?

Correct. Yup. It’s a version control system that has its own concept of storage backends, and Git is just one of those storage backends that you can use. So you can literally drop it into your workflow today and just start using it. And I haven’t used Git in months now. It’s great.

Okay, so it’s gitting for you in the background, and you’re using its interface then. It’s –

Exactly. Exactly.

And is it a command line tool for you or?

Yup. It’s a CLI tool. JJ is the is the tool name, and you’re just going to do commands like jj new, jj commit, jj describe… Things of that nature. And you work with your source code that way. And it doesn’t really have a concept of like branching, and whatnot. It just kind of treats everything as like a detached head state, and you just mutate your commits and revisions that way.

That’s very interesting. We had Scott Chacon on the show last year, and we were asking him what replaces Git… Because here he was, 10 or 15 years since he first helped Git get so popular with GitHub, and really the documentation sites; gitscm.org was him, or .com… And he was like “I don’t think we’re going to replace Git. I think we’re just going to build things on top of it, and in front of it. Because as a primitive for version control, it’s just really good. But as a usable tool for humans, not so much.” And so that’s interesting that JJ does that; it also has its own storage engine?

I see JJ as like – it’s going to be very successful because it’s compatible with Git in the backend, but its frontend, the way you interact with it and use the CLI tools is very good. It’s a different kind of paradigm, and it solves the problems that Git’s CLI is a little cumbersome to use for humans. It solves those problems. But you have to learn JJ’s kind of paradigm of working. And once you get over that hump, you’re like “Wow, this is actually pretty great.” My rebasing and all that stuff is much safer and easier to do in JJ than it was in Git. And JJ’s undo operation is very safe, because you can just do something, say “Oh wait, I didn’t mean to do that. jj undo”, and you’re back to where you were without having to do any sort of like Git reset, or restores, or whatever. Really nice.

Kris, have you tried this?

I have not. I’m kind of – I sat down, I learned Git very deeply… So – I mean, I personally don’t find much problem with the Git CLI and how everything works. You can see why it’s difficult for new people to kind of get in and figure it out. But for me, I’m just like “Git works well enough for this class of version control system.”

I do think that some of the work that is being done by places like Ink & Switch to try and find a more… I guess less a source code and more of a prose style of version control - I’m super-interested in that; the kind of continual, we’re always kind of keeping track of what you’re doing, and then you kind of snapshot it and you can upload those snapshots. I like that kind of seamless workflow. But as far as how we kind of move source code around at the moment, how we do source code version control, I think that Git is pretty much like the best underlying platform. And since I’m already so familiar with the tooling, I just… Yeah, I don’t really look for something new if my workflow isn’t broken, or if it’s not painful at the moment, which for me it’s not.

I’m kind of in that same category. I would look at JJ - or Jujutsu - mostly out of curiosity and interest, and like trends and directions. And for myself to actually adopt a new tool… I’ve spent the many, many years it takes to understand Git well enough that I can pretty much handle any situation I find myself in. And if not, I’m just an LLM away from a conversation about how to do a particular thing. And they’re right 90% of the time, and that’s actually good enough for something like version control.

[00:20:11.27] Yeah, I mean… I probably wouldn’t have even tried JJ if we didn’t have a whole like channel for it at Oxide. We have like a whole channel discussing Jujutsu. And everyone’s like “Oh, you should try it.” I was like “Okay.” So I kind of like fell for the peer pressure a little bit. But then when I went there on the other side, I was like “This is actually pretty good. I see why you all are using it.” So if I didn’t have that kind of peer pressure, I probably wouldn’t have tried it myself.

Well, you work at a very early adoption company, don’t you? At Oxide Computer Company everything’s kind of bleeding edge, right?

Yeah, a lot of people here like to try bleeding edge tools, or at least stay on the main branch for different tools and build things from source. That’s how I’ve found Helix, that’s how I’ve found Jujutsu… And I’m kind of starting to take this mantra of not just installing my tools using like a package manager, but instead building them from source. And it’s been really nice. It’s kind of like a different paradigm than I’m used to, but it’s nice to be able to monitor an issue or something and say “Oh, this thing that I was having issues with is fixed. I just build from source. I don’t have to wait for them to release anything. This is great!” So that’s kind of the Oxide way, so to speak.

The Oxide way. That was my way in college, when I had all the free time in the world… I thought it was very cool to compile everything. I even loaded up - is it Ghentoo, or Gentoo? I don’t know. I call it Gentoo… Where everything was built from source, at least back in the early aughts. Maybe they have packages now. And you just built everything. And I just felt very much like a hacker doing that… But then over time, I realized all I was doing was like the same three commands: autoconf, make, make install, or whatever… And other people could do that for me, and then distribute to me the end result, and that would save a lot of time and headache. And so I stopped doing that.

But there’s something to that, especially if you are interested in what’s new, and like to live on the edge of things, because you can actually - like you said, not wait for the official release, but get your bug fix now.

And a lot of people, they pull in things that aren’t even merged into the default branch, right? They’ll go to the main branch and pull in some PRs that are not yet merged, and build that, and that’s what they daily drive. And I think part of it too is that the commands for building these things now are better than what we used to do in the past. Ghostty is just one zig build away from using it and having a nice binary. And same thing with like Helix. You just cargo build it, and you install it and it’s done. You don’t have to really worry about autoconf, configure, make, and all that stuff. You just use the tooling for the language, and you have everything you need, which is much nicer.

So you brought up Zig… I’m thinking about programming languages, because I was reading on the Golang Subreddit –

Oh no, I’m scared where this is going… [laughter]

Oh, no…!

In response to something that Mitchell Hashimoto said, either on our show or another show, where he was talking about Zig, and Rust, and Go, and C… And his overall point was like “This is my preference for this project.” He was very much just like “These are all great things. I chose Zig for Ghostty. I like Zig.” And he wasn’t very – I was gonna say flamboyant, but that’s not the word. I don’t know. He wasn’t in trying to fuel any flames. He was being very level-headed and non-controversial. Of course, that doesn’t mean there isn’t gonna be controversy around what he said anyways, because language wars, you know? They’re a thing on the internet.

I believe the word you were looking for is inflammatory.

[00:23:52.18] Yeah, inflammatory. Thank you. All I could think of was flamboyant, and that paints an entirely different picture. Okay.

So he said what he said, and then there was a conversation that kind of keyed off on that on the Golang subreddit… Which was basically kind of “Okay, it’s 2025. Go, Rust etc. Systems languages.” And there was a person named Catastrophysics, which is a nice portmanteau, I think… Catastrophysics… Who said, “In my humble opinion, with a lot of new offerings in terms of low level languages, Go feels a lot less compelling as a pick in 2025. I still love writing Golang, but compared with a few years ago, where it was almost the only sane choice out there for some domains, the landscape has changed a lot.” And then themallex or themalex replied and said “I do also agree. Having tested Zig, Rust and Odin, Go still is great and feels nice, arguably even better than what it used to be. But nowadays, I could see some cases in which those other languages could also be viable, or even superior, which was not the case a few years back.”

There was, of course, hundreds of other comments, but I thought those were interesting in their agreement. And neither of those either are being flamboyant or inflammatory. They’re just their opinions on 2025. As Gophers – of course, your new podcast, Fallthrough, has kind of broadened, I think, your opportunities there. But as Gophers yourselves, I’m curious your thoughts on that sentiment, and the landscape of - let’s just call them systems-level programming languages? I don’t know. General purpose programming languages, in the year of our Lord, 2025.

I think I would say that Go is a systems language, but it is more of a cloud systems language than a low-level systems language. I think that’s where the split is. If you’re going to go build something for the cloud that is just cloud-native or at the cloud level, Go is a language you want to do that in. If you want to go lower and be close to the hardware, I think that’s where Zig and Rust and these other languages fit much better, because they have that closer integration with C, they have that closer connection with hardware. They have much more control over memory. They aren’t trying to protect you in the same ways that Go is trying to protect you.

So I think that Go is still a very good systems language, but it’s just like a higher level systems than I think what people have traditionally thought. And I think people have in the past just kind of bucketed all of systems together, and I think we’re starting to see that they’re splitting apart. They’re becoming more nuanced, more bifurcated in what they are, and the languages are separating into the different parts of that to serve those communities.

Is the separation garbage collection versus non? Is that the big distinguishing factor?

I don’t think so. I think that the separation is more about, I think, first of all, who is your target audience? I think for Go, the target audience is we want to make sure that the super-experienced programmers and engineers can write good, efficient code, but we want to make sure that average programmers can also just pick this up and run with it, can go implement things.

I think with things like Rust, and to some degree Zig, these are languages that probably don’t cater to the average programmer in that same way. They’re very much like “No, you really need to know what you’re doing. You have to want to have every single tool at your disposal. You need to understand all of these lower-level concepts, and then you can go do these really powerful things.”

So I think it’s not even about garbage collection. I mean, Go’s garbage collector is fantastic. We have, I think, on the high end, at most a millisecond pause, and usually much less than that. Or no, I think they just changed it. Now I think a hundred microsecond is like the longest garbage collection pause you will have. And for most real-time systems, that is absolutely fine. I know people want to say real-time is like some super – real-time is a very broad category of things. And being able to do things with a hundred millisecond delay some of the time is just not going to affect your real-time system all that much.

[00:28:14.11] So I think garbage collection is not the big defining factor as far as the split here. I think it’s much more about the language ergonomics itself, and how the languages are designed.

Do you agree, Matthew?

Yeah, I agree overall. Part of the negative attention Go is getting right now I think has to do with the cloud repatriation effort that’s going on, where people are just kind of fed up with the cloud in general. And since Go is more of that cloud-focused language, people by definition are fed up with the tools around the cloud too, and Go just kind of gets caught up in the middle.

Go is a simple language, right? There’s something to be said about the average developer being able to read a piece of Go code and understand it, because it’s a simple language. But also I know that it doesn’t have all the bells and whistles like other languages that it’s competing with does, right? Like, you don’t have reduced, and fold, or whatever. You don’t have true iterators like that, or true generics… They all feel like bolt-ons to the language.

I’m at Oxide, and we build a cloud computer. And you would think that cloud and Go go hand in hand. And that’s very true. But most of Oxide is written in Rust. But we do have a lot of Go in the places where we have to integrate. So think like Kubernetes integrations, TerraForm integrations, Packer integrations… All that stuff is still Go. So I’m responsible for all that at Oxide, and it’s like, that’s all going to be Go stuff. You don’t write that stuff in Rust, because all of the integration points are Go, and have Go libraries for that.

So I don’t know, I think the kind of negative attention Go is getting is somewhat warranted, because it is a language that hasn’t really evolved so, so much in comparison to its competitors… But it’s still a good language to choose, especially if you’re dealing with any sort of cloud environments, or Kubernetes.

Yeah. I think it’s tough when simplicity is a core imperative or a principle, to compete in a landscape of progress and change and advancement. You’re trying to keep it simple, and that’s hard to do… And also backwards-compatible… That’s one of those things, is really strong backwards compat. And eventually, you just have no more shiny things to point to over time. And people just, they get bored and want to move on. And of course, there’s good reasons to want to move on, and then to seek other languages for certain use cases. There’s also career trajectory to think about… Which honestly, drives a lot of our decision-making. It’s like, “Can I make money doing this, and how much?”

That’s a lot of what I think developers, like the winds we’re trying to sniff, even more so than what is purely the best technology for this particular thing I’m trying to do. It’s like, I don’t want to be investing in something that’s going to be irrelevant. Or I also would rather make more money than I’m making right now, and all the up and coming jobs are TypeScript, or Rust, or whatever; you name it.

But it’s just a tough thing when you’re all about simplicity, which is one of Go’s main things… When everybody wants to say “What else can you do?” It’s like “Well, I’ve showed you everything. 25 keywords. You know them all already”, for instance.

I think at some point the Go team is going to have to rethink their backwards compatibility promise, and maybe even think about what a Go 2 would look like. Because if they maintain this backwards compatibility is the thing, and simplicity is the thing, and all of these features that we have to add have to be added in a backwards compatible way, I think they lose in the long run if they keep that mindset, personally. I think at some point they should re-evaluate and say “We’re going to do a Go 2. It’s going to be backwards incompatible. It’s going to have breaking changes, but it’s going to allow us to add these things to the language that we’ve been wanting, in a way that feels better than what we’re doing it today.” And I think that that might be something that they want to consider at some point in the future. But I don’t work on the Go team, right?

[00:32:16.06] I actually kind of feel the opposite. I think Go is potentially going to be the first language that undefines backwards incompatibility. That makes it so that backwards incompatibility is not a thing at all. I think there is a very good opportunity for Go to do this with the way it’s set itself up so far, if the Go team decides to invest in a few more tools. Go has pretty much already jettisoned the entire idea. I mean, it was never really an idea that Go version 2 would ever be a thing… It was just a name to give to kind of next gen features. And with the way that modules work now, where the version in the module dictates what feature set you’re going to use, it is possible to change the language in the future in ways that would be backwards incompatible in another language, but continue being compatible because the compiler can switch out its tool chain at will.

So yeah, you can still compile that old code using your current Go command. It’s just going to go grab a different tool chain and compile the code with that. And I guess technically you could say that’s backward-incompatible or backward breaking change… But for the consumer, it doesn’t really feel that way at all. And there’s a small effort to take some of the ideas from Go’s distant past with Go fix, and with this tool called Eg or Example, to actually be able to rewrite code for you, so if you do make a backward breaking change, the code will just be rewritten automatically to the new thing… Which I think also really reduces the amount of like “What is a backward breaking change?” If you just build that into the compiler as well, and the compiler can just do this for you automatically, then it can just look at the context of “What is this module code written in? Oh, it’s this version, and we have this other version. I know how to map these two versions together, so I can just automatically translate it.” And you just reduce or remove almost all of the backwards incompatibility things that you might come up with.

And I think if you add that with the ability to do the v2 modules, you really just remove the need to ever create something like Go 2. Like, I don’t know what would be in Go 2 that would be something we can’t use the current tools or some of the upcoming tools to remediate.

This is true. I keep forgetting that they’re becoming more load-bearing on the Gomod file, and the Go directive in there, and the tools directive now. They’re using the versions listed there for toolchain conditionals. I keep forgetting about that. And that is true. They can probably get a long way with that, especially since the toolchain is built into the language.

You don’t think though that iterators and generics are kind of - they feel out of place in the language syntactically? You don’t feel like they’re too overly verbose, or not a first-class citizen, so to speak?

I think there’s definitely some warts around them. But I think that’s mostly because it’s difficult to design generics or iterators that work. I think people are very used to the things that are already in languages, so they’re much more likely to overlook how awkward those things can be. And since Go hasn’t had them and they’re trying to add them, it’s this new thing. So you have people on both sides being like “This isn’t as good.” People that didn’t have them are like “Why do we need these things?” And people that are used to them in other languages want them to look like those things in other languages, and don’t like that they don’t look like that. So I think that’s a lot of where their problem comes from.

I like generics for the things that it does. I want something like a sum or a union type. I think the language badly needs it.

But I don’t think generics are bad because we don’t have sum or union types. So I don’t think generics are bad because you can’t attach a method, can’t have a generic method. I think it would be nice if we could do those things. I understand why we can’t. It’s a little bit of annoyance that you can’t. But I don’t think it’s a show-stopping thing that people usually make it out to be, like “Oh, this is so terrible. We can’t do this thing.”

Yeah, that’s fair. That’s where I’m okay if someone were to say “Here’s Go 2. I’m going to take all of those things that are kind of warty in the language, and clean up their syntax for Go 2.” I’d be okay with that. Is it something I think is going to happen? Probably not. But I’d be okay if they announced that.

With the way Gomod works, you can even have syntactic changes to the language. That’s not something that can’t be done while still keeping the Go backward compatibility system. Really, the Go backward and forward compatibility system.

Break: [00:36:54.20]

Let’s move up a level and get slightly more hypothetical, and imagine a world where the source code that we write today is the bytecode of tomorrow. Kris, I’m sure you’re gonna be quite skeptical of this future… But there’s a lot of money going into making that happen. And potentially, it could happen. In a world like that, do you think Go thrives when you are outputting Go source code from a maybe more human written instruction set, and then you only look at it when you have to, kind of a thing?

I mean, if this is the case - but you know me, I’m extremely skeptical of the idea…

I know you are.

…of swapping out very precise languages with natural languages. But if that were to happen, I don’t really see a reason why we would have the language spit out Go, or Rust, or even C. Like, why would you not just spit out assembly? What’s the point in having this intermediate language? I don’t think there is one. I think that if the thing that we’d want to do in the future is say “We’re just going to write prose, and that prose is going to turn into eventually instructions that a machine can process”, maybe you have an IR, like LLVM’s IR, or something like that. But I don’t think you would translate it into a high level language, and then translate it down to something. Because translating into a high-level language implies that you’re going to sit there and tinker with it. But that doesn’t seem like that would be the goal of “We want to be able to use, say, English to write our code.” Just like now most people don’t spit out the assembly… You don’t take Go and spit out the assembly, and then tinker with that, and then send it off to an assembler. You just run the Go compiler, and that spits out your machine code. So I think like that’s more of the flow. You wouldn’t have these intermediate steps. I don’t think that makes sense.

So I think in that future, most of our languages can kind of just be thrown in the trash, for the most part. But once again, I’m extremely skeptical of using English or any natural language to write code, or anything approaching code.

What’s the artifact? That’s my question. If I’m using natural language or prose to describe what I want to do, is the artifact that I’m kind of storing and versioning - is it going to be assembly? Is it going to be the prose? What is it?

So I agree with what Kris is saying for the most part, but there might be some benefit into that intermediate representation in a language that is the artifact. The average human can’t read assembly, at all. That’s more for machines to read. And checking in prose is not technical enough to understand what it’s actually doing. So maybe there is a value in that intermediate representation being like Go, or Rust, or Zig, or something, and that’s what we check in. I don’t know, but I don’t think we’re going to get there. And I agree, what’s the point of it?

Well, you want to go from the non-deterministic step to something deterministic. And so your prose, current state of the art - they’re going to produce different output when given repeatedly. And so they’re non-deterministic, the output of the machine. And so if you can go from there to something that could be deterministic, now I can actually reason about that, which is why I think Go is a decent programming language for something like that. Because now you can look at it and say, “Okay, here’s what I have, based on the prose I wrote.” And I’ve got to flip this bit in order to actually get the outcome, or something like that. I also am skeptical of this… But I think you do want something in between “I’m telling a machine what to write in common language, English, or whatever language you speak” and “It is executing code on a CPU.”

[00:44:06.05] It feels like it turns into protobuf, but instead of a protobuf to a Go generation, it’s prose to Go generation. And it’s like, I can just see it now in GitHub. “Binary file too large to include”, or whatever, and you don’t actually see the diff.

[laughs]

But I think it’s an interesting topic of discussion, because it would really be nice… Sometimes you can only express what you want to do in natural language, and you don’t really know what the code is going to look like, and you want to have that translation. But are we there yet reliably? Definitely not.

I mean, as someone that writes a lot of prose and has a degree in writing prose… It’s kind of like saying “We should get rid of all of mathematical notation and just write all math problems with prose.” There’s a reason we came up with mathematical notation. It’s much more precise, and it’s much more – you can easily find a mistake, and it’s not like “Oh, I misunderstood the context of this word.” It’s like, no, we have these symbols; these symbols mean specific things.

I find it interesting that people are so quick to kind of buy into the idea that “Oh, we’ll just replace all of coding with writing prose”, but they’re not saying “Let’s replace all of math notation with prose.” That’s just not something I’m seeing anybody really talk about or anybody really suggest, even though these are two basically equivalent things. In fact, you could say there’s more reason to replace math with prose, since math is just a language, and we’re kind of replacing languages with languages… Whereas to some degree, there’s a machine-readable element of this – a machine-readable element of coding, of programming languages, because they are unambiguous. Whereas some math equations can be ambiguous if you’re not careful. So they’re much more closer to natural languages, I think, than they are to programming languages. But I think it’s because a lot of us feel like we’re writing a natural language when writing code, that we get tripped up by this idea and it becomes very alluring.

Well, not when I read my own code. Do I think it’s natural language? I’m always like “What was this dork trying to say…?”

And that’s what comments are for.

Yeah, exactly. Well, you know, my code doesn’t have any comments, because it’s self-documenting, Matthew. So I dismiss with such nuance. Just read the code, man. It says what it does…

[laughs]

Oh, yeah, I’m sure. I’m sure. You know what? Send me a link. I got you.

That reminds me of something my oldest son said one time, who - we will never let him live down, and we make fun of him all the time. I asked him what a specific sentence meant, or something… We were like in schooling. And he says “It means what it says.” That was his response.

What does interesting mean? Interesting means that something’s interesting to me.

It just means what it said. You know what it said… That’s what it means. So you know, not how you get an A in any sort of context. But while we’re talking about writing and these kind of things, I’m thinking with Kris, I always think about documentation, because Kris is like gung-ho on documentation, and archiving, librarian, he thinks that every company should have an archivist or a librarian… And he’s convinced me that that’s not – he hasn’t convinced me that’s true, but he at least convinced me that’s a pretty good idea for people to consider. And I was reading a post recently - I should’ve sent this to you guys beforehand so you could have thoughts prepared, but we’ll just go ad hoc style. “The seven action documentation model.” I actually put this in Changelog News just yesterday. A very interesting post by Fabrizio Ferri Benedetti about docs. And I won’t – I’ll spare you all the details, Kris, but what he proposes is that the way we write documentation as technical writers, and with a lot of the tools that we have, they’re very much oriented not on the end user, but on like the output of what you’re trying to cover. Almost like test coverage. Like, you have to have this kind of thing, this kind of thing, this kind of thing. And he proposes that instead, we think about it what user actions the docs are meant to satisfy.

[00:48:17.05] He comes up with this seven action model, which goes like appraise, understand, explore, practice, remember, develop, and troubleshoot. And that’s roughly the order that he thinks that you should do it in. And so he thinks that we should organize docs around that. Oh, you [unintelligible 00:48:34.03] in the chat already. Cool. So I was going to just send you the link, but Matthew already got you the link.

I think that’s kind of interesting. As a person who reads a lot of docs, I definitely was very attracted to this idea of like, well, if I’m trying to appraise a tool, or a library, or what have you, it’d be really interesting if it actually like specifically said, “If you’re appraising this thing, here’s what you need to know. And now, if you are then past that phase, and you’re trying to understand it at a deeper level, or learn about it, we have like specific docs for that.” And then if you’re trying to – you get past, you’ve already chosen it, you kind of get it… Help me explore all of the different areas of this library, for instance.

And so it’s kind of like formatting documentation, or thinking about it from that perspective, versus kind of our traditional way of writing docs. Just off the top of your head, is this attractive to you? Do you think this is doomed to fail? Do you think this is potentially interesting? What are your thoughts?

I think anything that gets us to write more docs is good. And off the top of my head, I want to say “Sure, seven actions…” The actions seem pretty good. I’d say try it. I’d say try as many different things as we possibly can at this point.

I think my biggest gripe right now is just how few docs we have, how little documentation so many things have. But if there was a way… I think there was especially – what was it? There was one that was like the discover and learn steps. I am very frustrated often at libraries that I want to go in and understand, and there’s no “Oh, start looking here.” Or like “Here’s the basic architecture that you can then use to understand how this codebase is laid out, so you can go read the code and understand how we’ve implemented all of these things.” That documentation is almost always completely missing.

So anything that gets us closer to having that documentation, and having a way for people to actually go in and learn more about a codebase, I am fully in favor of. Anything that gives us troubleshooting, or like FAQs, anything like that also - I’d definitely like to see more of that.

Yeah. And then reference, of course, is there. We already do reference somewhat well. I mean, that’s kind of one of the things that we do, is reference docs, where it’s like “Here’s my API. Here’s all of the names, and here’s how you call these things, and the options you can set.” That’s a very small sliver of all the things… You’re kind of at the end of it at that point. You’re like “Okay, now I’m just referencing the exact details of how I use a particular thing.”

But I agree with you that once I get past appraisal, oftentimes, and I want to learn more about a library, I just end up right in the source code; not writing the source code. I end up right in the source code… And I have no idea. I mean, that’s usually how you get it figured out. You’re like “Okay, there’s probably a main function somewhere”, and then “Okay, I can see their imports, or where they’re includes”, and I start following that little rabbit trail… And eventually, I feel like I get some knowledge. But man, the most basic of handholding, a paragraph that said “Here’s how I’m laid out”, would time-warp me hours probably into understanding. So good point.

[00:51:46.02] Does this require you to go down the levels here, or the actions? For example, do you have to do appraise and understand before you can do explore? Is that what the author is getting at? Or can you kind of just do any of the seven actions?

He says the order of the actions, and that’s the order that I read them in, is intentional, but it’s not strict. So it’s not that you couldn’t jump… Maybe you’ve appraised it. It’s pretty simple, you understand it, and you just go straight to like troubleshooting, you know? So he did put them in like an order that he thought made a lot of sense, but it’s not like you must do them in this order.

Gotcha. Okay. Yeah, my opinion on this whole documentation thing is I agree that we have too few documentation, or - what is that? We have not enough documentation out there in relation to the code and to the things that we have available. And if I have to go look at the source code to understand what things are doing, that’s a failure, in my opinion. And open telemetry does this pretty well; fails pretty well, I guess is what I’m trying to say.

I was gonna say, [unintelligible 00:52:47.21]

I’m not trying to be mean, or anything. Yeah, I’m not trying to be mean, or anything with that. I’m really not. It’s just, when I was working with open telemetry, I found myself always having to go to the source code, because there was either no docs, or the docs were far out of date and not kept up, and they were kind of meaningless at that point. And it’s like, if you’re telling your users to do that, then you’re going to suffer… Nobody’s going to know what your program does, adoption is going to suffer, people are going to be upset using your thing… And it just breeds an animosity using your tooling. Is that what you really want?

And you hit it right on the head, Jerod - a small paragraph describing how things are laid out or kind of like the concepts and ideas can go a long way to unlocking your mental model to understanding what it is you’re doing, and looking at it.

So get out there and write that paragraph, y’all.

Yeah, write the paragraph. [laughs]

Especially – I mean, I joke about that… In the small, a five-line function can certainly be self-documenting, as long as it’s simple enough. But your architecture that lives in your head, and in the head of your team - that’s the only place it lives. I mean, obviously, there’s a call stack, so it lives there as well… But it takes one person a half an hour maybe to write that paragraph. I mean, assuming they think through it very clearly, you probably write it in five minutes, and then edit from there… And it’s going to save a lot of people a ton of time. So definitely worth doing.

Kris, is there a world in which we end up with too many docs? When you first said that, I thought “Man, sometimes you can’t find what you’re looking for in the world of prose, because there’s just so many things.” But are we just so far away from that that it’s –

I mean, it’s kind of – I guess I see that question the same as “Is there a world where you have too many books?” And the answer is, I think, in the simple, no. I think the way we could wind up in an effective too many docs - and I think we are already there, to some degree - is if we don’t have good cataloging systems. One of the things that allows us to have so many books and actually be able to find them… Like, you think about libraries; big libraries, like the Library of Congress. The reason you can find things is because they have very good cataloging systems, what’s called bibliographic control. They have good ways of saying “Here’s their metadata, here’s what you can search for, here’s how we arrange everything.” And for the most part, we don’t do any of that in tech. We just kind of – I mean, we talked about this actually on the episode of Fallthrough that’s going to be shipping on Monday, after this episode ships, about the fact that lots of people just store things as flat files. You just chuck a bunch of into a wiki, and then you just rely on the web search feature to find things, and how much that falls over and how much that fails.

And I think that if we don’t develop good cataloging systems along with our increase in docs, we’re going to find that it’s very difficult to actually find the information that we want to search for, the information we want. And I think in that case, yes, we do wind up with too many docs. But that is also a very fixable problem. And I believe that Oxide is running into this a little bit with your RFD system, where it’s like you’re trying to figure out how to find stuff. And it’s challenging, because your search – I believe I talked about it on an episode where we were talking about RFDs, about how difficult it is to find things based on search, because there isn’t, as far as I know, a robust cataloging system for the RFDs… Even though you’ve produced a very large number of them.

What are the RFDs? Is that a request for something?

Request for discussion.

[00:56:17.18] Request for discussion, yeah. We have, I think, over 500-600 RFDs now; somewhere between 500 to 600. And you’re right, we have search, and it’s like full text search, and you get to search the title of the RFD and the content as well. But you’re correct, there’s no organization structure to them. Unless the author of an RFD put in enough keywords that will like be generally searchable and accurate, it’s kind of difficult to find them. And as a new employee to Oxide, that makes it difficult for me, because if I search generic keywords, I get maybe hundreds of results back, and now what’s actually relevant to me, right? What do I actually want to read and go into? Now I have to go talk to a human and say, “Hey, I’m doing XYZ. What should I be reading out of these RFDs?” and they give me like the number based on their experience. But still, there’s no cataloging, it’s more just word of mouth experience.

Too many docs, man… [laughter]

I mean it’s not an unsolvable problem either. It’s not that like Oxide’s RFDs are bad, or whatever. No, they’re great. At least we wrote the stuff down, and they’re there. Now it’s a matter of someone has to go through and comb through these documents and organize them.

You need a librarian.

Right, yeah. We need a librarian.

That will always be something that baffles me about companies, especially large companies. If you go back 50 years, before we had digitized everything, every company had a team of corporate archivists, because you had so much paper. You had all of this paper. Boxes and boxes and boxes of paper, and you had to be able to find things. And you couldn’t just go to the terminal and just punch in some keywords. You had to go to somebody who could help you find it. So we had archivists and all these people that would organize this information so it was findable. And we went digital, and now we have orders of magnitude more information that our companies produce, and we’re like “Yeah, but we don’t need all those people anymore.” Because it’s not physical, we are just like “Oh, well, it should be easily searchable”, even though digital search algorithms are very terrible at finding things if you haven’t cataloged them. They’re pretty good when you’ve cataloged things, but they’re not good at all when you’re just doing full text search, because words have so many different meanings.

It’s basically a guess of “The person who wrote this, are they going to use the same words that I’m using to try and find it?”, which is just a not fun matching game if you haven’t already decided on the words you’re going to use, and what those words mean, which is effectively what cataloging gives you.

It reminds me of like your favorite detective series or whatever, where they have to go into the evidence room and find evidence, and it’s tagged very well, the case files are there, you can find them, they’re dated, there’s keywords, there’s identifiers… And it’s like, that’s pretty decent, actually. You can find what you need, relevant to the things you’re working on. And like what Kris was saying, we’ve digitized a lot of this stuff and we kind of just forgot to add that metadata. We just kind of left that behind. And it’s actually more important than ever because we’re generating so much digital content that now we have the problem of finding it. It’s like, why did we do this to ourselves?

It sounds like the perfect application of AI slop. Just slop some categories on there, slop some metadata, and everything’s good. Kris, we don’t have to hire anybody, come on.

[laughs]

Unlike the physical world though, at least the digital world is malleable. You can mutate this stuff. So if you did find some sort of RFD or some document somewhere, and you were like “Hey, I thought this was going to have the keyword foo for this, and I didn’t see keyword foo. I can update it and put foo there.” So next time someone else can find it with that keyword. And I think that’s another part of the digital world that we as engineers tend to forget, is that this stuff is very malleable. You shouldn’t be afraid to change something, even though it’s like a five-year-old document, to make it better for future people to find it.

[01:00:08.25] You know how rare those people are though? Because… You know there’s people that go out on the side of the highway, and they just pick up other people’s trash? And they put it in a bag and they throw it away. And unless they’re told to do that by some sort of community service, they’re just doing that out of their own goodwill… That person is incredibly rare. And so is the one who’s just like “I’m going to leave this place a little better than I’ve found it.” Not the most common way to go about life. It just isn’t.

Well, we’ve made it difficult to do that. Like, using your trash example… Let’s have an analogy real quick of trash on the ground somewhere, to a typo in a documentation on a website. Let’s make that analogy real quick.

Okay.

In the trash example, I can fully autonomously pick up the trash, take it and dispose of it, without having to get an approval, without having to get a review for it, without having to verify if the trash really is trash, any of that stuff. I can just do that automatically myself. And that makes it easy for me to do, and simple. Whereas that typo on the website, we all know it’s correct, we all know that the change I’m going to make is correcting it… But I have to be subject to a PR review, and approval, CI/CD, all of this crap just to clean up some garbage. And it’s like, that disincentivized people from wanting to clean up garbage, because we’ve subjected them to these processes that actually are a hindrance. It’s like, why did we do these things? It’s just a typo. I shouldn’t need three reviews from the SIG person to do it. Come on, let’s get it in. And then we wonder why there’s so much garbage.

I also think part of the problem here is that no one really understands… I think especially executives do not understand the insane amount of money that they are throwing in the trash because they have not organized their information properly.

But you’re paying software engineers total comp; even for mid-level engineers it’s sometimes in excess of a quarter million dollars a year, and you’re now paying people that you’re paying like a cumulative half million dollars a year, or if you have a meeting, millions of dollars a year to just talk to each other, instead of just having them read some document. So now you’re having them waste hours of time to go read – instead of reading something, to go talk to someone, to coordinate, and now they’re blocked, and now your entire system has slowed to a crawl, because you can’t actually get the information to the people when they need it. And you’re having more bugs, you’re not building as many features… Everything is slowed down. I think the only reason this is tolerable is because everybody’s doing it. If there were a couple of companies that had their information organized well, they’d be running circles around everybody else. Like, their products would be higher quality, they’d have fewer bugs, they’d have fewer problems, just because they wouldn’t run into the typical things that we all as engineers experience every day. But it was like “Oh, there was this problem.” And “Oh, yup, I called it out, but I couldn’t talk to the team, or the team didn’t want to listen to me. Or we had the same meeting five times, we made five different decisions each time.”

The lack of having information where we want it winds up with us losing a lot of money, and losing out on market opportunities we’d have otherwise. And I just think that the executives who are in charge of caring about this money and caring about this don’t understand that this is happening. It’s completely opaque to them.

There you go again, convincing me that this is a pretty good idea. You should package that sucker up, you know? If you could create like an archiving seminar, or a booklet, or thing, which like shows that in tangible terms that an executive could understand, like “Here’s why you need this thing”, and then also provide a system, or maybe even just consulting services on helping create that system inside of these organizations… I mean, you’d be printing money, Kris. Come on, man.

It’s on the list, Jerod. It’s on the list. There’s a few other things that are in the way.

[laughs] “I’m busy editing podcasts, Jerod. Come on, man. I’m in Final Cut Pro…”

[01:03:59.27] You know, I’m trying to like spin up this writing, whole writing, publishing career… And also now I have a whole podcast I’m doing… There’s just – there’s things in the queue. There’s things in the queue, Jerod. We will get there.

Okay. Well, let’s close on the podcast. This is fall through.fm. I’m speaking with half of the team. Of course, Ian Lopshire is another quarter of the team… And then the fourth quarter, which is not a basketball reference, but it’s a quarter reference… I don’t know the fellow’s name. Who’s the other person on the show?

Dylan Burke.

Dylan Burke. Okay. And so two of you from GoTime. Matthew, longtime Changelog listener, community member, friend, etc. We got together and had stakes at All Things Open, we also had a pretty, almost record-breaking… I was going to say puzzle house. What was it called? Escape room?

Oh, yeah. The escape room was great.

We almost broke the record at the local escape room for completing the room in like 29 minutes, or something. Very impressive teamwork by us. So you’ve joined the cast. And then Dylan Burke… How did y’all meet Dylan?

I met him at GopherCon a number of years ago. And yeah, I spent a whole bunch of time with him at GopherCon in 2024, and when we were like “Oh, we’re going to spin off GoTime”, he was like the second person I thought of. The first person I thought of was Matt, and I was like “Gotta try and get Matt on.” And I was like “Who else? Dylan. Gotta try and get Dylan on.” And thankfully, both of them said yes.

Awesome.

And actually, we do have a fifth member. We now have a producer and a reoccurring guest host. So a reoccurring guest host is the wonderful Johnny Boursiquot. He’s already guest-hosted an episode that will be shipping soon. The “What’s New in Go 1.24” episode with Carlana.

Awesome. Okay, that’s news to me. I love that.

Yeah. And we have - a producer actually joined us for an episode that we recorded yesterday. That’s the one that’s going to ship out on the Monday after this episode ships… Of Angelica Hill. So she has joined in a producer role to help us with producing, and booking, and scheduling, and all of that.

That’s awesome. So for those who are not GoTime listeners, Angelica and Johnny were also GoTime co-panelists. So… Happy to see so many of the GoTime crew getting involved in Fallthrough. It’s a real spinoff now. It’s awesome.

So I mentioned it earlier, but of course, Fallthrough is a Go – I guess, is it a keyword? I don’t know, it’s the last thing you do in a switch statement, right? It’s like your else, or your default state of a switch statement. Or am I wrong about that?

No, so fall through is actually a very rarely used keyword in a switch statement. Unlike in many languages, when you hit the bottom of a case statement in a switch statement, you exit out of the switch statement. And what fallthrough allows you to do is go into the next switch statement, which is the default behavior in languages like C, which is why you have to put a break at the end of every case statement, to make sure you don’t go into the next one. So fallthrough allows you to have that old style functionality of going into the next case statement of your switch statement.

I see. So you don’t have to break by default in switches. But if you want to, or if you want to fall through to another case, you just write that explicitly.

Yup.

Okay. Interesting. But it’s such an obscure keyword that it doesn’t necessarily have to be Go on the nose, right? I mean, that’s kind of one of the things with Go Time which we’ve struggled with over the years, and we just kind of let it fly to a certain extent… But we were always kind of just tied to go… Which we were happy to be tied to, but also, it can be somewhat limited in certain ways. And so I think it’s nice that you guys have escaped that particular –

Yeah. We see ourselves as – because fallthrough is also a keyword in other languages. So other languages have picked it up since Go has included it.

Okay.

[01:07:48.19] And we see ourselves as definitely like a – we’re going to cover Go content. As I said, we’re shipping a “What’s new in Go 1.24 episode”, we’re still going to try and have the Go team on… But as we’ve started producing episodes, what we’ve realized is that we’re not nearly as much of a Go podcast as what Go Time was. So we are starting to be more of a general podcast about computing, and technology, and software… Originally, we wanted to do this from the Go perspective thing, but what we’ve realized is that we’re really just from a nuanced perspective, from a subtle perspective; that’s what a lot of our episodes have in them. This level of subtlety and nuance that isn’t really on display in many other podcasts, or many other forums.

So that’s kind of the new thing we’re aiming for and we’re trying to do. Still having a place for the Go community to have their Go content, and still in the same kind of a vibe as what GoTime was. I think a lot of GoTime’s most successful episodes had very little to do with Go, and they were much more general. So we’re taking that trajectory and trying to hone in on our own little kind of niche within that, within the whole ecosystem of developer pods, and within the ecosystem of technology podcasts, and things like that.

Excited about it. Excited to hear more, and also excited that you all will be part of the Changelog Podcast Universe. So cpu.fm, we’ve talked about it once before on a Kaizen episode of Changelog… And we’re starting to formalize exactly what it will look like. More details to figure out, of course, but it will be a loosely networked group of developer pods that we think are awesome, or that we are helping produce, or just hanging out with. There will be cross promos, cross collabs… We plan on having a super-feed, so that anybody who’s been a fan of the Changelog Master feed will probably be a fan of the CPU super-feed… And so you can get all your Changelog Podcast Universe pods in one place.

We may or may not do custom feeds for that, like we did for our own shows… I’m leaning towards we will, but it depends on how much programming time I have. And it should be a cool thing. So… Happy that you all are going to be part of that. We’ll be announcing more participants, or network pods as the days go by. But Fallthrough is on the list, so very cool.

Matthew, this is your first time podcasting, or no?

Yeah, yeah. It’s my first time being a host on a podcast. I’ve been a guest a few times before that, so I’m excited for that. And to echo what Kris said about Fallthrough… If Kris approached me and was like “Hey, we’re doing a Go podcast”, I probably would have said no. But we talked about what we were doing, and more nuanced than that, and being able to expand… And I think it’s really reflective of the Go community is also in this kind of state as well, where people are curious to what else is out there… We can cover things like Zig, and Rust, we can cover things like the cloud and communities and all these other Go-adjacent things, but not necessarily strictly related to go. So I’m really excited about that stuff. And I’ve always found myself listening to Go Time, and every time Kris goes off on his monologues, I’m like “Yeah, you get it!” And I’m just like clapping there. So I’m excited to be able to have those conversations live with Kris, and go into these nuanced topics.

But yeah, no, it’s interesting being a podcast host. I mean, scheduling is interesting… And look at me, I’m in a mobile setup right now. I brought my stuff with me to hotel to record an episode, so… Things I didn’t think I was going to do.

Well, it’s always fun to challenge yourself in new and different ways. And I can definitely say that as a software engineer, podcasting is definitely a completely different thing. And you find yourself using tools like Adobe Audition, which you never otherwise would have touched. And in fact, when Adam first showed it to me, I was like “This is complete trash. I don’t know why you think this is any good.” And after years and years of use, I’m like “Well, it’s slightly better than trash…” I still don’t love it, but I’ve learned all the warts… And it’s powerful. It actually can do a lot of things. But these kinds of things that you just don’t have to, or want to use as a software engineer.

[01:12:12.10] I definitely started – it’s one of the things that I realized after I became a software engineer and kind of left college. So in college I was heavily doing audio and video. My second major was broadcasting mass communication, so I was doing a lot of like video editing, video production, and I kind of did an audio minor. So I was doing tons of audio stuff. And when I got out of college and started programming, I realized that there’s so much that I could have done more efficiently, or better, or expanded my creativity if I’d just known how to write software.

So now that I know how to write software, and now that I have a thing that I’m doing video and audio with, I’m super-excited to actually start building things. Like, I’m already seeing things in Audition where if I was back in college, I would have been like “I guess this is just the workflow I’ve kind of got to deal with.” But now it’s like, I can write JavaScript, I can write a plugin for Audition that gives me new shortcuts that I can do, so I can move things around, so I can edit faster.

So there’s a whole bunch of stuff like that that I’m really excited to do now that I’m marrying together these two different – I guess these two different parts of who I am. Kind of like my recent, current and my distant past kind of coming together in a way that I love.

Yeah. And we’re not stopping there either. We have plans to write some software for the other side of podcasting, which is scheduling, and coming up with show ideas, and notes, and all of that. It’s surprisingly difficult to schedule across different people and guests and whatnot. That’s a very difficult thing to keep synchronized.

For sure.

We have some plans to tackle that, too.

We’ve taken some inspiration from what y’all have done with Changelog, where you have this wonderful backend system that distributes and does all of that stuff for it… And we just want to kind of take that idea and expand upon it.

Cool.

Because there’s a lot of stuff too, even in the production workflow. I like Riverside a lot, but there’s all these little warts that I’m like “Could we potentially build something better?” I don’t know, but we’re going to take a shot at it and see what happens.

Nice. Well, consider us beta testers and/or guinea pigs if you have new ideas. These are problems that we deal with on the daily, so we’d be happy to give new tools a try, and provide feedback that would probably be valuable, because it’s from real world users. So happy to do that as you guys build some stuff.

Definitely. And we’re really excited for cpu.fm as well. Like, the whole podcast scene has kind of a problem with discoverability, with finding new podcasts. Because if you go to your average podcast player, they’re just going to shove you whatever algorithm down your throat and say “Hey, here’s the podcasts you should listen to”, and it ends up being the same tech podcast again and again. But there’s some really nice gems out there, and I think cpu.fm could help get those out to the world, and to new listeners.

Yeah, that’s kind of our hope, is we always had a limit on what we could do ourselves inside of a portfolio. We took that approach for years, and we turned down lots of ideas, and lots of suggestions and requests because of that. And because we don’t want to scale our business up, I guess, versus out… I don’t know. We don’t want to scale it at all in terms of headcount. Happy to be the size that we are… We just knew we could never serve all those needs. And so the idea is to focus in on our main show, and then create this kind of grouping of – you know, this universe of shows that we think are awesome, and we’re participant in.

We’ll be a place where if you are a developer and you’re like “I would love some developer pods”, it’s like, all of us could just point you to cpu.fm, and you won’t go wrong. Just go there, you’ll find something you like; you’ll probably find more than one thing you like, and you can be done. And I think that that’s potentially a real valuable resource for folks, and for all of our shows. Because like you said, discovery is hard, but also just getting your ideas out there, because there’s so many shows, there’s so many other things going on…

Totally.

Helping good podcasts get found is something we can help, hopefully help with as well.

And in the spirit of this episode, some of the content we covered, information organization and whatnot… So don’t forget to be a librarian with cpu.fm, and organize it in the way that’s best for people to consume.

That’s a tall order, Matthew. I was just going to put an index page up there and see what happens… Okay. Well, maybe I can hire Kris to come in and consult… I’m telling you, Kris, that dog could hunt. If you can formalize that thing into a real pitch…

And I think there is absolutely a lot of value capture there that companies aren’t having, that would be a competitive advantage for a lot of companies, since everybody sucks at it right now. Eventually it becomes table stakes, but if you can get a competitive advantage right now, move faster, don’t break things… That could be cool. I know you’ve got lots of things going on and you’re coming back home to Audition and Final Cut, but I would consider exploring that avenue a little further.

Alright, that’s enough advice from me. Matthew has a plane to catch, don’t you?

I have to go to a data center to install an Oxide rack.

He’s got a data center to catch. He’s got to go – take a picture of that Oxide rack, man. I haven’t seen one [unintelligible 01:17:17.24]

I will, I will.

Those things are so cool. So cool! Alright…

Assuming they let me take pictures, I will.

Alright, that’s all for now. I guess we’ll just say goodbye, friends, and check out fallthrough.fm.

Bye, everyone.

Thanks, guys.

See ya!