The Changelog: Software Development, Open Source - Fallthrough & Friends (Friends)

Episode Date: January 24, 2025

Kris Brandow & Matthew Sanabria from Fallthrough.fm join Jerod to discuss tools we're switching to, whether or not Go is still a great systems programming language choice, user-centric documentation, the need for archivists & more.

Welcome to Changelog and Friends, a weekly talk show about obscure Go keywords. Thanks, as always, to our partners at Fly, the public cloud with push button deployments, scaling to thousands of instances. Learn all about it at fly.io. Okay, let's talk. Well, friends, before the show, I am here with a new friend of mine, Scott Dietzen, CEO of Augment Code. I'm excited about this. Augment taps into your team's collective knowledge, your code base, your documentation, your dependencies. It is the most context-aware developer AI, so you won't just code faster. You'll also build smarter.

It's an ask-me-anything-for-your-code. It's your deep-thinking buddy. It's your Stan Flo antidote. Okay, Scott. So for the foreseeable future, AI assisted is here to stay. It's just a matter of getting the AI to be a better assistant. And in particular, I want help on the thinking part, not necessarily the coding part. Can you speak to the thinking problem versus the coding problem and the potential false dichotomy there. A couple of different points to make. You know, AIs have gotten good at making incremental changes, at least when they understand customer software. So first and the biggest limitation that these AIs have today, they really don't understand anything about your code base. If you take

GitHub Copilot, for example, it's like a fresh college graduate understands some programming languages and algorithms, but doesn't understand what you're trying to do. And as a result of that, something like two-thirds of the community on average drops off of the product, especially the expert developers. Augment is different. We use retrieval augmented generation to deeply mine the knowledge that's inherent inside your code base. So we are a co-pilot that is an expert and that can help you navigate the code base, help you find issues and fix them and resolve them over time much more quickly than you can trying to tutor up a novice on your software. So you're often compared to GitHub co-pilot. I got to imagine that you have a hot take.

What's your hot take on GitHub Copilot? I think it was a great 1.0 product. And I think they've done a huge service in promoting AI. But I think the game has changed. We have moved from AIs that are new college graduates to, in effect, AIs that are now among the best developers in your code base. And that difference is a profound one for software engineering in particular. You know, if you're writing a new application from scratch, you want a web page that'll play tic-tac-toe, piece of cake to crank that out. But if you're looking at, you know,

a tens of millions of line code base, like many of our customers, Lemonade is one of them. I mean, 10 million line monorepo as they move engineers inside and around that code base and hire new engineers. Just the workload on senior developers to mentor people into areas of the code base they're not familiar with is hugely painful. An AI that knows the answer and is available seven by 24, you don't have to interrupt anybody and can help coach you through whatever you're trying to work on is hugely empowering to an engineer working in unfamiliar code. Very cool. Well, friends, Augment Code is developer AI that uses deep understanding of your large code base and how you build software to deliver personalized

code suggestions and insights. A good next step is to go to AugmentCode.com. That's A-U-G-M-E-N-T-C-O-D-E.com, request a free trial, contact sales, or if you're an open source project, Augment is free to you to use. Learn more at AugmentCode.com, that's A-U-G-M-E-N-T-C-O-D-E.com, AugmentCode.com. Well, I am joined by Fall Out Boy, I mean, Fall Through Boys, Chris

and Matthew Sanabria from the Fall Through 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. Yep. We'll do what we can do. My partner in crime, unfortunately, had 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 spin-off

pod of GoTime. I'm wearing my legacy GoTime t-shirt. Chris, I see behind you, you still have your GoTime poster on the wall. It's not going to come down for a while. It's

a piece of nostalgia. I was going to say, not until you get that follow-through poster up there, and then we'll be dead to you. 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 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 like all kinds of cool stuff on there. So are you using all these? You got Ghosty, Fish, Helix, Jujutsu, Zedd, Nyx, Olama. I assume since there's more than one editor on that list, you're not using all these. 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 just didn't happen. But this is like inspired by Vim, right? So it's kind of like Vim, but then I read from your post that they changed some key bindings around. So it's like, what's the point, man? Yeah, it's very much inspired by vim and cocoon um and they like kind of flipped like vim has like a motion verb sort of deal and like helix is a motion like noun verb sort of deal right so you don't say 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 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 they want to do. So, it's like, it's 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 like enter insert mode to do your thing i i really like it though it's it's got a lot of batteries included for like lsp and tree sitter and things like that nature whereas neo vim you have to set that up yourself so that's why i really like helix so are you daily driving that then yeah yeah that's what i've been using for the past couple of months now okay and chris you still have your Vim poster up,

so I assume nothing's changed on your front, pooling-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, right? You have to configure it, but there's trees that are built in, there's the LSP client built in. There's a bunch of nice stuff built in for NeoVim. Love how much stuff is built in. You have to configure it, but there's trees that are built in.

There's the LSP client built in. There's a bunch of nice stuff built in for NeoVim. 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 Ghosty. 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 on what, 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, was like I didn't realize I had limited colors. And then once I did, I was like, oh, it's like kind of 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. That's the major, I would say, complaint against Ghosty 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 map um 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. Chris, have you picked up any new tools in 2025 or last year that you actually adopted? I have started slowly moving myself over to Ghosty. 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. 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 a podcast i've had to relearn audition i've had to relearn final cut pro um which is basically a completely different app because back when i you know got my degree we were still on final cut pro 7 so and and then final cut pro 10 came out and we were all like this is this is awful don't use this asovie but for prosumers get rid of that blah terrible right um and you know in the decade plus sense 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 uh that still feel a little like more iMovie consumer-ish than professional editing tool but overall overall, it's been a pretty good experience.

Relearning 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. Someone's got to do it. That is the hard part, isn't it? Or the tedious part of podcasting is the edit. What I find interesting about that, Chris, is that you have your toes in two different tide pools, so to speak, because you have Addition, 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, Chris, because we are daily driving those suckers. But just that dichotomy of 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. It is, 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, you know, 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 figured it out now. Gotten it down. I'm just sitting here crying in Linux. 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. And so 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

just programming environments because we're just like, 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. 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. 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 I.O. 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% of the time there'd be an issue. And that's really high. I believe it. Well, give yourself, give the listeners a big sigh because I am running Linux right now.

So let them have it. Well, if they're listening to this it was successful so perfect you know i'm the only one nervous here they they already have uh d mitigate demitigated no you mitigate risk you don't demitigate it unless you want to live dangerously well we've 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 jujitsu or jujitsu i don't know how you say it i actually don't know how you say it either i i was saying it like jujitsu like the martial arts right but the spelling makes me want to say jujutsu and that, 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. Yep. 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 getting 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? Yep. It's a CLI tool. JJ is the, is the tool name. And you're just going to do, you're 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 kind of just mutate your commits and and revisions that way that's very interesting we had scott chacon on the show last year and we were asking him like

what replaces git because here he was 10 or 15 years since he first helped get get so popular with github and really the documentation sites get sem.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. Does it also have 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 front end, like the way you interact with it and use the CLI tools is very good. You know, it's a different kind of paradigm and it solves the problems that gets 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 Git reset or restores or whatever. Really nice. Chris, have you tried this?

I have not. I'm kind of, you know, 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 and figure it out but for me i'm just like that 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 and switch to try and find a more, like 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. Like 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 the best underlying platform. And since I'm already so familiar with the tooling, I don't really look for something new if my workflow isn't broken, 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 Juj-Jitsu mostly out of curiosity and interest and 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 so yeah i mean it's 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 jujitsu jujitsu um and everyone's like, oh, you know, you should try it. I was like, okay. So I got kind of, 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 like kind of peer pressure, I probably wouldn't have tried it myself. Well, you work in a very early adoption company, don't you? Like Oxide Computer Company.

Everything's kind of bleeding edge, right? Yeah, we have a lot of people here like to try bleeding edge tools or at least stay on like the main branch for different tools and build things from source. That's how I found Helix. That's how I found Jujutsu. And, you know, I've kind of started to take this mantra of not just installing my tools using like a package manager, but instead building them from source.

And like, 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 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 Gen 2 or Gen 2? I don't know. I call it Gen 2, 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 the same three commands, like 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?

Like they'll pull in, 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, right? Like you can just, like Ghosty 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, right? And you install it and it's done. You don't have to really worry about, you know, 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. 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 Ghosty. I like Zig. And he wasn't very, I was going to say flamboyant, but that's not the word. Flambation? I don't know. He wasn't trying to fuel any flames.

He was being very level-headed and non-controversial. Of course, that doesn't mean there isn't going to be controversy around what he said anyways, because language wars, they're a thing on the internet. I believe the word you were looking for is inflammatory. Yeah, inflammatory, thank you. All I could think of was flamboyant, and that paints an entirely different picture. 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 like, okay, it's 2025, Go, Rust, et cetera, system 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 Go lang, 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 the Mollix 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, Fall Through, 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 to the 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. 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. like about garbage collection i mean goes garbage collector is fantastic right we have i think on the high end like at most a millisecond pause and usually much less than that or no i think it's changes now i think it's 100 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 at 100 millisecond delay some of the time is just not going to affect your real-time system all that much. 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. I think 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. And Go is a simple language, right? Like, 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

reduce and fold or whatever. You don't have, you you know true iterators like that or true generics they all feel like bolt-ons to the language and like like i'm at oxide right 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 So think like Kubernetes integrations, Terraform integrations, Packer integrations, all of that stuff is still Go. So I'm responsible for all that at HashiCorp, or sorry, HashiCorp at Oxide. And it's like, that's all going to be Go stuff, right? 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. When you try to keep it simple, and that's hard to do and also backwards compatible that's when it goes things is like really strong backwards compat and eventually that's just like you you 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 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, the wins we're trying to sniff, even more so than what is purely the best technology for this particular thing I'm trying to do. 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 at 25 keywords, you know, you know them 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 reevaluate and say, we're going to do a go-to. 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? I actually kind of feel the opposite. I think Go is potentially going to be the first language that undefines backwards incompatibility, right? That makes it so that 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. 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 forward, 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. 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. 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 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 how what is this module code written in oh it's in 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. 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 Go mod 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 feel out of place in the language syntactically? You don't feel like they're just kind of 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 well. 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. Like 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 that i think that's a lot of where their problem comes from like 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 some reunion types i don't think generics are bad because you can't attach a method can't have a generic method right 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 that you can't but it's not I don't 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 I I would say that it like that's that's where I'm okay if someone were to say, here's GoTo, I'm going to take all of those things that are kind of warty in the language and clean up their syntax for a GoTo.

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. I mean, even 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. Okay, friends, I'm here in the breaks with Annie Sexton over at Fly. Annie, you know we use Fly here at Change. We love Fly.

It is such an awesome platform, and we love building on it. But for those who don't know much about Fly, what's special about building on Fly? Fly gives you a lot of flexibility, like a lot of flexibility on multiple fronts. And on top of that, you get, so I've talked a lot about the networking and that's obviously one thing, but there's various data stores that we partner with that are really easy to use. Actually, one of my favorite partners is Tigris. I can't say enough good things about them when it comes to object storage. I've never in my life thought I would have so many opinions about object storage, but I do now. Tigris is a partner of Fly and it's S3

compatible object storage that basically seems like it's a CDN but is not. It's basically object storage that's globally distributed without needing to actually set up a CDN at all. It's like automatically distributed around the world. And it's also incredibly easy to use and set up. Like creating a bucket is literally one command. So it's partners like that that I think are the sort of extra icing on top of Fly that really makes it sort of the platform that has everything that you need. So we use Tigris here at Changelog.

Are they built on top of Fly? Is this one of those examples of being able to build on Fly? Yeah, so Tigris is built on top of Fly's infrastructure, and that's what allows it to be globally distributed. I do have a video on this, but basically the way it works is whenever, like let's say a user uploads an asset to a particular bucket. Well, that gets uploaded directly to the region closest to the user. Whereas with a CDN, there's sort of like a centralized place where assets need to get copied to. And then eventually they get sort of trickled out to all of the different global locations. Whereas with Tigris, the moment you upload something, it's available in that region instantly. And then it's eventually cached in all the other regions as well as it's requested. In fact, with Tigris, you don't even have to select which regions things are stored in.

You just get these regions for free. And then on top of that, it is so much easier to work with. I feel like the way they manage permissions, the way they handle bucket creation, making things public or private is just so much simpler than other solutions. And the good news is that you don't actually need to change your code if you're already using S3. It's S3 compatible. So like whatever SDK you're using is probably just fine. And all you got to do is update the credentials. So it's super easy. Very cool. Thanks, Annie. So Fly has everything you need. Over 3 million applications, including ours here at ChangeLog, multiple applications have launched on Fly.

Boosted by global Anycast load balancing, zero configuration private networking, hardware isolation, instant WireGuard VPN connections, push button deployments that scale to thousands of instances, it's all there for you right now. Deploy your app in five minutes, go to fly.io. Again, fly.io. Let's move up a level, get slightly more hypothetical, and imagine a world where the source code that we write today is the bytecode of tomorrow.

Chris, I'm sure you're going to 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 construction set and then you only look at it when you have to? If this is the case,

I'm extremely skeptical of the idea 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? Like, what's the point in having this intermediate language? I don't think there is one i think that if the thing that we 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 into a high level language and then translate it down to something because like 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 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. Like what's, what's the artifact, right? Like that's, that's my question is 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, what is it? Right? So I think I agree with whatris is saying for the most part but there might be some benefit into that intermediate representation in a language that is the artifact and that way because you know the average human can't read assembly at all right that's more for machines to read and checking in pros is not technical enough to understand like 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, like, what's the point of it? Well, you kind of want to go from the non-deterministic step to something deterministic. And so your pros, current state of the art they're going to produce different output you know 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 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. Feels like it turns into protobuf, but instead of a protobuf to go generation, it's pros to go generation. And it's like, I can just see it now in GitHub. Binary file too large to include or whatever. Like, it was just, you know, and you

don't actually see the diff. Yeah. But no, I think it's an interesting this topic of discussion because it would really be nice sometimes you you can only express what you want to do in like natural language and you don't really know what the code is going to look like and you want to like 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, I just, it's kind of like saying we should get rid of all of mathematical notation and just write all math problems with prose. It's like there's a reason we came up with mathematical notation, right?

It's much more precise and it's much more like, you know, 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. Like I, 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, right? Like 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 you're kind of replacing languages with languages whereas like to some degree there's a machine readable element of this

you know there's 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. Oh, you know, my code doesn't have any comments because it's self-documenting, Matthew. So I don't need, I dismiss with such nuance. Just read the code, man. It says what it does. 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're like in, you know, in schooling. And he says says it means what it says that was that was his response what does interesting mean interesting means that something's interesting it just means what it said yeah you know what it said that's what it means so you know not how you get an a in any sort of context um but while we're talking about writing and these kind of things I'm thinking with Chris I was thinking about documentation because Chris is like gung-ho on documentation and archiving, librarian

he thinks that every company should have an archivist or a librarian 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 have 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, Chris, 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. 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. 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 got it 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 like 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 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 here you you've already chosen it right you kind of get it help me explore you know 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. I think, 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 a specialty, what was it? There was one that was 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 here's the basic architecture that you can then use to understand how this code base 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 code base i am fully in favor of anything gives us troubleshooting or like faqs, anything like that also definitely I'd 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 writing the source code. Not writing the source code, I end up right in the source code. Because it's like, 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 like 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 a hand the most basic of handholding you know like a paragraph that said like here's how i'm laid out would like time warp me you know hours probably into understanding so good good point. 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 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. You just go straight to like troubleshooting, you know? Um, so he did put them in like a order

that he thought made a lot of sense, but it's not like you must do them in this order. Gotcha. Okay. Yeah. I, I, I tend to like my opinion on this whole documentation thing is I agree that we have few, we have too few documentation or what is that? We have not enough documentation out there, um, 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 like open telemetry does this pretty well like fails pretty well i guess is what i'm trying to say i'm gonna say no no no like you know 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. Like, 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 like an animosity using your tooling. Like, is that what you really want?

And you hit it right on the head, Jared. Like, a small paragraph describing how things are laid out or kind of like the 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 so get out there and write that paragraph y'all yeah write the paragraph especially like arkans i mean i joke about that in the small 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 the head of your team, that's the only place it lives. 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. 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. Chris, 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 so many things. But are we just so far away from that? I guess I see that question as the same as, is there a world where you have too many books? 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, 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,

or 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. For the most part, we don't do any of that in tech. We talked about this actually on the episode of Fall Through 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 stuff 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 when they 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. Request for discussion, yeah. We have, I think, over 500, 600 RFDs now, somewhere in between 500 to 600. And you're right, like we have search

and it's like full text search. You get to search the title of the RFD and the content as well. But you're correct. There's no like 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, right? But still, there's no cataloging. It's more just word of mouth experience. Too many docs, man. I mean, like it's not an unsolvable problem either, right? 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. We 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. You had to be able to find things. You couldn't just go to a terminal and just punch in some keywords. You had to go to somebody who could help you find it.

We had archivists and all these people that would organize this information so it was findable. 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 search algorithms for 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 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, right? You can find what you need relevant to the things you're working on. And it's like what Chris was saying, we've digitized a lot of this stuff and we kind of just forgot to add that metadata.

You know, 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? Sounds like the perfect application of AI slop. You know, just slop some categories on there, slop some metadata,

and everything's good, Chris. We don't have to hire anybody. Come on. Unlike the physical world, though, at least the digital world is malleable, right? You can mutate this stuff. So if you did find some sort of RFD or some document somewhere, and you were like, hey, I, 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, 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. You know how rare those people are though? Because 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 good will. 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 found it.

Not the most common way to go about life. It just isn't. Well, we've made it difficult to do that, right? 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. 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, right? We all know that like the change I'm gonna make is correcting it, but I have to be subject to a PR review and approval,

CICD, all of this crap just to clean up some garbage. And it's like that disincentivize 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, right? It's just a typo. I shouldn't need three reviews from the SIG person to do it.

Like, come on, you know, let's just, 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. You're paying software engineers, like total comp, even for mid-level engineers is 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 like millions of dollars a year to just talk to each other instead of just having them read some document right 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 like 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 slowing 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. 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. It was like, oh, there's this problem. And oh, yep, 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. 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. If you can create an archiving seminar or booklet or thing, which shows that in tangible terms that an executive can 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, Chris. Come on, man. It's on the list, Jared. It's on the list. It's on the list. There's a few other things that are in the way. I'm busy editing podcasts, Jared. Come on, man.

I'm a cut pro. I'm trying to spin up this whole writing, publishing career. And also now i have a whole podcast i'm doing there's just there's there's things in the queue there's things in the queue jared we will get there well let's let's close on the podcast this is fall through dot fm i'm speaking with half of the team of course ian lopshires 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 go time uh matthew long time changelog listener community member friend etc we got together and had uh stakes and all things open we also had a pretty almost record-breaking puzzle house. What are those 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 joined the cast and then Dylan Burke. How did you all meet Dylan? I met him at Gpher con a number of years ago and uh yeah i spent a whole bunch of time with him at gopher con in 2024 and i when you know we were like oh we're we're you know gonna spin off go time he was like the second person the first person i thought it was matt and i was like oh god i'm trying to get mad on

i was like who else i'm like dylan gotta try and get dylan on And I was like, who else? I'm like, 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 Borsico. 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 who actually joined us for an episode that we recorded yesterday,

the one that's going to ship out on the Monday after this episode ships, of Angelica Hill. So she has joined us 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 Fall Through. It's a real spinoff now. It's like a, it's awesome. So I mentioned it earlier, but of course, Fall Through 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 fall-through 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 fall through 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 you want to fall through to another case, you just write that explicitly. Yep. Okay.

Interesting. But it's such an obscure keyword that it doesn't, 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 struggled with over the years, is like, 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 Fall Through is also a keyword in other languages, so other languages have picked it up since Go has included it.

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 vibe as what Go Time was. I think a lot of Go Time'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 that would 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 Fall Through is on the list.

So very cool. Matthew, this is your first time podcasting or no? 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, you know, to echo what Chris said about fall through, you know, if Chris approached me and was like, hey, we're doing a Go podcast, I probably would have said no. But, you know, we talked about what we were doing and more nuance than that and being able to expand. And know 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 you know we

can cover things like Zig and rust you can cover things like the cloud and kubernetes and all these other you know 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 Chris goes off on his monologues, I'm like, yeah, yeah, you get it. You know, I'm just like clapping there like, yeah. So I'm excited to be able to, you know, have those conversations live with Chris and go and go into these nuanced topics. But yeah, no, it's interesting being a podcast host. I mean, you know, scheduling is interesting. And look at me, I'm in a mobile setup right now, right?

I brought my stuff with me to the 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, you yourself using tools like Adobe Audition, which I 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 words. And it's powerful. It actually can do a lot of things. But these kind of things that you just don't love it, but I've learned all the words. And it's powerful. It actually can do a lot of things. But these kind of things that you just don't have to or want to use as a software engineer.

I definitely started, it's one of the things that I realized after I became a software engineer and kind of left college. Because 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. 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 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 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 are kind of coming together in a way that I love. Yeah, we're not stopping there either. Like 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, you know, guests and

whatnot. That's a very difficult thing to keep synchronized. So for sure, we have some plans to tackle that too. We've taken some inspiration from what you all have done with Changelog, where you have this wonderful backend system that distributes and does all the fat stuff for it. And we just want to kind of take that idea and expand upon it. Because there's a lot of stuff too, even in the production work. 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 like dot fm as well like the whole podcast scene is has a kind of a problem with discoverability of finding new podcasts you know because if you go to your your average podcast player they're just gonna shove

you whatever algorithm down your throat and say, hey, here's the podcast 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 gems 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 to focus in on our main show and then create this kind of grouping of this universe of shows that we think are awesome and we're a participant in would 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 it's like, 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. Helping good podcasts get found is something we can help hopefully help with as well so and in

the spirit of this episode like 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 that's a tall order matthew I was just going to put an index page up there and see what happened. Okay. Well, maybe I can hire Chris to come in and consult. I'm telling you, Chris, that dog could hunt. If you can formalize that thing into a real pitch, 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 value capture there that companies aren't having that would be a competitive advantage for a lot of companies since it's like 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 can be

cool so i know you got lots of things going on and you're coming back home to audition and and final cut but i would consider exploring that Avenue a little further. All right. That's enough advice from me. Matthew has a plane to catch. Don't you 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. Those things are so cool. So cool. All right. Assuming they let me take pictures. I will. I will. Those things are so cool. So cool. All right. Assuming they let me take pictures, I will. All right. That's all for now. I guess we'll just say goodbye, friends, and check out fallthrough.fm.

Bye, everyone. Thanks, guys. See you. Bye, everyone. All right. That is your changelog for this week. Thanks for frenzying with us. Check out what Chris, Matthew, and the

whole Fall Through gang are up to at fallthrough.fm and leave them a review if you like. That'd be cool. Oh, and leave us a five-star review while you're at it. That'd be twice as nice. One more thanks to our partners at Fly.io and to Augment Code for sponsoring the pod. Please check out what they're up to and support them because they support us. And thanks, of course, to the one, the only, the Breakmaster Cylinder for keeping our beats so fresh and so clean. Next week on The Changelog, news on Monday,

Globber Costa from Terso talking about their big rewrite of SQLite in Rust. That's on Wednesday. And Dan Moore joins us for an It Depends style convo about auth strategies, magic links, OTPs, passkeys, all that right here on Changelog and Friends

on Friday. Have yourself a great weekend. Share Changelog with your friends who might dig it. And let's talk again real soon. Finally the end of changelogging friends With Adam and Jared Some other rando We love that you loved it and stayed until the end But now it's over

It's time to go We know your problems should be coding. And your deadline is pretty foreboding. Your ticket backlog is an actual problem. So why don't you go inside? No more listening to change-locking friends. The battering chair in Silicon Valley. No one gave a gag or come to an end

But honestly that will probably be our finale You best be slinging ones and zeros And that makes you one of our heroes Your list of to-do's is waiting for you so why don't you go inside no more listening to change locking friends that i'm sharing people you know change my new friends time to get back into the flow. Change, love your friends. Change, love your friends. It's your favorite ever show.

Favorite ever show.