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 copilot 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 Copilot. 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 engineers. 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 fallout boy. I mean, fall through boys, Chris and Matthew. So now we're 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, but... Yep. We'll do what we can do. My partner in crime, unfortunately, had come down with the flu. So Matt, 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 Go Time. I'm wearing my legacy Go Time t-shirt. And Chris, I see behind you, you still have your Go Time 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 fall through 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, 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, jujitsu, Zed, Knicks, Oh llama. I assume since there's more than one editor on that list, you're not using all these, but, uh, what are you up to there?
I'm not using Zed like full time. I just have it installed just in case I need it for something like else. And I'm not using Knicks. Um, everything else I'm using though, like 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 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? 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 they want to do.
So, it's like sort 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 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 NeoVim, 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, 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, right? You have to configure it, but there's trees that are built in, there's the LSP client built in, so 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. Then also visor mode is just too rad. You know, I like visor mode. Oh yeah. That's a Mac OS only feature.
So I don't, 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 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.
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, that's one thing I've liked it so far. I like the ease of configuration. I'm a real, I'm a big fan of this whole, like basically command line flags in a file. Like I like that. So simple. Yeah. Very clean. That is cool. But yeah, I mean as far as like, like, um,
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 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 awful.
Don't use this as iMovie, but for prosumers, get rid of that. Blah, terrible. And 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 that still feel a little like more iMovie consumer-ish than 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. Mm-hmm. 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...
You're giving up some integration and some crossover that only Adobe can do in order to live in both camps.
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, you know, 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 Apple. 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.
Um, and so I was 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. Um, But I think I figured it out now, gotten it down.
I'm just sitting here crying in Linux. Like, 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, you know, like keeping a Windows box around, for instance, or switching between Adobe and Apple or, you know, running WSL, which is cool.
And better than not WSL, but you know, 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 all we need 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 like life splits for me. Maybe I should have just got a Mac book or something and kind of that's, I feel like, 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 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. Perfect. I'm the only one nervous here. They already... Have demitigated? No, you mitigate risk. You don't demitigate it unless you want to live dangerously. Oh, 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 was saying it like jujitsu, like the martial arts. Right. But the spelling makes me want to say jujitsu. 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.
Exactly. Exactly.
And is it a command line tool for you?
Yep, it's a CLI tool. JJ is the tool name. And 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 branching and whatnot. It just kind of treats everything as 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 like 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, gitsem.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. 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 back end. But its front end, like 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 like 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 like do any sort of like get 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 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 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 like the the best underlying platform and since i'm already so familiar with the tooling i just i don't really look for something new if you know my workflow isn't broken if i'm not 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 jujitsu mostly out of curiosity and interest and like trends and directions. And for myself to actually adopt a new tool, I've, I've spent the many, many years it takes to understand get well enough that I can pretty much handle any situation I find myself in.
And if not, you know, 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. 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. Mm-hmm. 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. 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. 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. 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. Yeah.
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.
Like he was very much just like, these are all great things. I, I chose Zig for ghosty. I like Zig and he wasn't very, uh, I was gonna say flamboyant, but that's not the word flambation. I don't know. He wasn't in trying to fuel any flames. Uh, he's 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, you know, 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.
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 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 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 the molex or the malex 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...
I would say 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, you know, 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 as 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 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 it's the strangest. Now I think it's 100 microseconds is 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 with you know 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 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? 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 know, true iterators like that or true generics. They all feel like bolt-ons to the language. And, 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 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 one of those 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. Or there's, there's also career trajectory to think about. Right. Which honestly drives a lot of our decision-making is like, can I make money doing this and how much? Yeah.
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 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, I'm 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 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 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 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 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 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. And that, you know, I guess technically you could say that's backward incompatible or backward, you know, 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 EEG 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 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. 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 go mod file and like the go directive in there and the tools directive now. They're using the versions listed there for tool chain conditionals. I keep forgetting about that and that is true. They can probably get a long way with that especially since the tool chain is built into the language.
You don't think though that like iterators and generics are kind of, they 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 I think that's a lot of where their problem comes from.
Like, I like generics for the things that it does. 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. Or 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 can't, but it's not... 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 would say 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, right? 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 ChangeLog. 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 this 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 Tigress 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 gotta 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 anti-cast 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 instruction set and then you only look at it when you have to kind of a thing?
I mean, if this is the case, right, I mean, you know me, 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 see, 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 the artifact, right? Like, 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 is it, right? So, I think I agree with what Chris 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 prose 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 and i agree like what's the point of it
Well, you 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 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.
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. And you don't actually see the diff. Yeah. But no, 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, I just...
it's it's 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
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 we'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 an 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, 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, 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. Um, but while we're talking about writing and these kinds 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. Um, 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 Ferry 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 like 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. 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 he 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 if you get past, you've already chosen it, right? 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. I think at 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 like, oh, like, start looking here or like, 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 that gives us troubleshooting or 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. But 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, 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 point.
Does this, um, require you to go down the levels here or the actions? Like, for example, do you have to do a praise 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. 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. I, I, 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 like OpenTelemetry does this pretty well.
Like fails pretty well, I guess is what I'm trying to say. 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 OpenTelemetry, 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 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, I mean, I joke about that. In the small, you know, 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. 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.
Think, 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. Chris, is there a world in which we end up with too many docs?
I mean, that's when, when you first said that, I thought, man, you know, sometimes you can't find what you're looking for in the, in the world of prose. Cause there's just so many things, but are we just so far away from that? It's,
I mean, it's kind of, I guess I see that question as the same as like, 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, like you think about libraries, like 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 Fall Through that's going to be shipping on Monday after this episode ships about the fact that, you know, 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, you know, your search, I believe I talked about it on an episode when they're 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. Okay. 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 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? 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. And you had to be able to find things.
And 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. 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 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. And you have to, you know, 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, you know, 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 we've, like what Chris was saying, we've digitized a lot of this stuff and we kind of just forgot to add that metadata, right? 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 like, at least the digital world is, you know, 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 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 like, 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 like 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 found it. Not the most common way to go about life. It just isn't. But we've made it difficult to do that, right?
Like using your trash example. Let's, let's, let's, I 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 going to 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 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, 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. Like, 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 slowed down. And 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'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, right? Like 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, you know, 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 can create like a an archiving seminar or 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, Chris. Come on, man. It's on the list, Jared. 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 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 things in the queue. There's things in the queue, Jared. We will get there.
Well, let's close on the podcast. This is fallthrough.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 steaks and all things open. We also had a pretty almost record-breaking... I was going to say Puzzle House. What are those called? Escape Room?
Oh, yeah. 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 do you 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. The first person I thought of was Matt. And I was like, oh, got to try and get Matt on. And I was like, who else? I'm like, oh, Dylan. Got to try and get Dylan on.
And thankfully, both of them said yes. Awesome.
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 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 as 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 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 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. 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 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, you know,
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, 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, you 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. We can cover things like Zig and Rust.
We can cover things like the cloud and Kubernetes and all these other Go adjacent things, but not necessarily strictly related to Go. So I'm really excited about that stuff. 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 into these nuanced topics. 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 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 have to or want to use as a software engineer.
I definitely started... one of the things that i realized after i became a software engineer and kind of left college in college i was you know heavily doing audio and video you know i was uh 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
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 you know, if I was back in college, I would've 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, 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 uh 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 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.fm as well. The whole podcast scene has a kind of a problem with discoverability of 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 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 um up i guess versus out i don't know we don't want to scale it at all in terms of headcount uh happy to be the size that we are we just knew we could never serve all those needs and
And so the idea to focus in on our main show and then create this kind of grouping of like, you know, this universe of shows that we think are awesome and we're participant in will be a place where it's like, 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're not going to, 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 possible. a real valuable resource for folks and for all of our shows. Cause 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.
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 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 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.
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. All right, 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 in a while. 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.
All right, that is your changelog for this week. Thanks for friendsing 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 combo 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 and some other rando We love that you loved 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 changelogging friends from Adam and Sharon in Silicon Valley.
No one gave a gag or come to an end, but honestly that will probably be our finale. We 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 Lock and Friends, with Adam and Jerry and people you know. Change Lock and Friends, time to get back into the flow.
Change Lock and Friends, Change Lock and Friends, it's your favorite ever show. Favorite ever show.