Fallthrough & Friends (Friends)

29:10I'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 of that at HashiCorp, or sorry, at 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.

29:44So 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 it's just like 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 want to move on and then to seek other languages for certain use cases or 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 you know like that's a lot of what I think developers like the wins were trying of sniff even more so than like what is purely the best technology for this particular thing I'm trying to do is like I don't want to be investing in something that's going to be irrelevant or I also would rather make more money than I'm making right now and all the up-and-coming jobs are TypeScript or Rust or whatever you name it but it's just a tough thing like when when you're all about simplicity which is one of Go's main things when everybody wants to say what else can you do?

31:25It'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 to would look like. Cause if they, if they maintain this backwards compatibility is this, is the thing and simplicity is the thing. And all of these like 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.

31:59It'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 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.

32:36If the Go team decides to invest in a few more tools, right? We've already, 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.

33:14So, 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 GoFix 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.

33:59If you just build that into the compiler as well, and the compiler can just do this for you automatically, then it can just look at the context of what is this module code written in. Oh, it's 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 GoTo. 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.

34:39This 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 too overly verbose or not a first-class citizen, so to speak? I think there's definitely some warts around them.

35:12But 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.

35:45So 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 summer union 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 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.

36:18We can't do this thing. Yeah, that's fair. I would say that it like that's that's where I'm okay if someone were to say here's go to I'm gonna take all of those things that are kind of warty in the language and like clean up their syntax for like a go to I'd be okay with that is it something I think is gonna happen probably not but I'd be okay if they announce that I mean even with the way go mod 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 go backward and forward compatibility system

37:14okay 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.

37:54I'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 it's 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.

38:30So 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.

39:04Whereas 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.

39:37It'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 wire guard 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.

40:20Let'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 the 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 kind of a thing i mean if if if this is the case right but i'm i mean you know i'm extremely skeptical of the idea of swapping out very precise languages with natural languages.

41:07But 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 llvms 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.

41:53Just 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, And I'm extremely skeptical of using English or any natural language to write code or anything approaching code. Like what's the artifact, right?

42:29Like 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.

43:06so 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 kind of want to you want to go from the non-deterministic step to something deterministic and so your pros and 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.

43:44Because now you can look at it and say, okay, here's what I have based on the prose I wrote, and I 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 the CPU. Feels like it turns into protobuf but like instead of like 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 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.

45:05It'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. We're kind of replacing languages with languages, whereas to some degree, there's a machine-readable element of coding, of programming languages, because they are unambiguous.

45:48Whereas 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.

46:24Just 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. 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 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. Yeah. You know what I said. That's what it means. So, you know, not how you get an A in any sort of context.

47:00But while we're talking about writing and these kind of things, I'm thinking with Chris, I always think 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.

47:37A 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 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.

48:26And 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, 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.

49:06And then if you're trying to get past, 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, and I think, you know, off the top of my head, I want to say like, sure, seven actions, like the action scene, pretty good.

49:43I'd say try it. I'd say try as many different things as we possibly can at this point. I think my biggest gripe right now is just how few docs we have, how little documentation so many things have. But if there was a way, I think there was especially, what was it? There was one that was 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, 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.

50:26That 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. I don't think it was 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.

51:00That'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 hand holding 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.

51:44So good point. Does this require you to like 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 um 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 tend to like my opinion on this whole documentation thing is i i agree that we have 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.

52:36And 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 was going to say this a lot pretty well. 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 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.

53:06And 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 to like 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 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 doesn't that's 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 world of prose because there's just so many things.

54:24But are we just so far away from that? 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. Like 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, right?

55:00They 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 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.

55:46And 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?

56:16Request for discussion. Request for discussion, yeah. We have, I think, over 500, 600 RFDs now, somewhere 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, you know, as a new employee to Oxide, you know, that makes it difficult for me because if I search generic keywords, I get maybe hundreds of results back.

56:53And 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, it's not an unsolvable problem either. It's not that 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.

57:30We 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 on boxes on 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.

58:00And 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, you know, 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?

58:35Which 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.

59:10You 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.

59:51So next time someone else can find it with that keyword. And I think that's another part of the digital world that we as engineers tend to forget is that this stuff is very malleable. You shouldn't be afraid to change something even though it's like a five-year-old document. Right. You know, 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.

1:00:24That 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.

1:00:58I 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 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 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 it's just a typo i shouldn't need three reviews from the SIG person to do it.

1:01:31Like, 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. But 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?

1:02:11So 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. You're like everything is slowing down. And I think the only reason this is tolerable is because everybody's doing it, right? If there were a couple of companies that had their information organized well, they'd be running circles around everybody else.

1:02:40Like 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. them 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 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.

1:03:19It'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.

1:03:55I'm busy editing podcasts, Jared. Come on, man. I'm a cut pro. I'm trying to spin up this writing, 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.

1:04:30Okay. And so two of you from go time. Matthew, longtime changelog listener, community member, friend, et cetera. We got together and had stakes at All Things Open. We also had a pretty almost record-breaking puzzle house. What was it called? The escape room? Oh, yeah. The escape room was great. We almost broke the record at the local escape room for completing the room in like 29 minutes or something. Very impressive teamwork by us. So you've joined the cast. And then Dylan Burke. How 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.

1:05:12and when we were like, oh, we're going to spin off Go Time, he was like the second person. The first person I thought of was Matt. I was like, oh, got to try and get Matt on. 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. 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 and Go 1.24 episode with Carlana. Awesome. Okay, that's news to me. I love that.

1:05:48Yeah, 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, We're 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?

1:06:26I don't know. It's part of, 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 and 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.

1:06:55So 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're 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.

1:07:35And so I think it's nice that you guys have escaped that particular... Yeah, we see ourselves as... Because fallthrough is also a keyword in other languages. So other languages have picked it up since Go has included it. 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.

1:08:15Originally, 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 GoTime was. I think a lot of GoTime's most successful episodes had very little to do with Go and they were much more general.

1:08:51So we're taking that trajectory and trying to hone in on our own little kind of niche within that, within the whole ecosystem of, you know, 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.

1:09:38That 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.

1:10:19So 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.

1:10:52You know, we can cover things like Zig and Rust. We 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, you, 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, it's interesting being a podcast host.

1:11:22I mean, you know, scheduling is, is interesting and I'm, look at me, I'm in a mobile setup right now, right? Like I brought my stuff with me to hotel to, 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.

1:11:55And after years and years of use, I'm like, well, it's slightly better than trash. I still don't love it, but I've learned all the warts. and it's powerful. It actually can do a lot of things. But these 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 and mass communication. So I was doing a lot of video editing, video production and I kind of did an audio minor.

1:12:30So 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 just known how to write software so now that I know how to write software and now that I have a thing that I'm doing video and audio with I'm super excited to actually start building things like I'm already seeing things in audition where uh you know if I was back in college I would have been like I guess it's 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, uh, gives me new shortcuts that I can do so I can move things around so I can edit faster.

1:13:09Uh, 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 guests and whatnot. That's a very difficult thing to keep synchronized.

1:13:42So 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 of that 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.

1:14:15These 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.fm as well. Like the whole podcast scene has a kind of a problem with discoverability of finding new podcasts. You know, 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.

1:14:50but there's some really nice gems out there and i think you know cpu.fm could help get those gems out to the world and 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 head count 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 like you know this universe of shows that we think are awesome and we're a participant in would 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.

1:15:48Just 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. 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.

1:16:22That's a tall order, Matthew. I was just gonna 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 could be cool. So I know you 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.

1:17:08All 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.

1:17:38All right. that is your changelog for this week. Thanks for frenzing 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.

1:18:20Globberkosta 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, pass keys, 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.

1:19:08Finally the end of changelogging friends with Adam and Jared and some other random. We love that your love didn't stay until the end, but now it's over. It's time to go. We know your problem 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, lock and fence Without a moon chair, but it's still a calm valley If no one gave a gag, we'll come to an end But honestly, that will probably be our finale

1:19:57You best be slinging ones and zeros And that makes you one of our heroes Your list of to-dos is waiting for you So why don't you go inside No more listening to Changelog and Friends Adam and Jerry and people you know Changelog and Friends Time to get back into the flow Changelog and Friends Changelog and Friends It's your favorite ever show Favorite ever show

1:20:34Thank you.