Rust Re-writes & Chesterton's Fence

Añadido: 2026-05-19

[00:00:00]to say I've been harsh on many of the Rust programmers out there who have been aggressively rewriting battle tested existing longdeveloped software. That would be an understatement. I have been very critical and very harsh of the wide variety of Rustbased rewrites out there in this world uh such as the rewrites of the GNU core utilities among many many others. But I wanted to take a moment and step back and point out that this sort of problem is not a new one. This the issue of developers coming in and and tossing out software that had been developed over years and in some cases decades and thinking they can just simply rewrite it from scratch and make everything wonderful is not a new problem. In fact, it's not even a problem that's exclusive to computer programming. This sort of an issue has existed for pretty much as long as there have been humans and people have been complaining about this sort of problem for centuries and centuries. Um, one of the most common one of the most common analogies that gets brought up to to talk about some of the problems with this is something known as Chesterton's fence. Uh, and I want to talk to you a little bit about Chesterton's fence today. And here's the here's the amazing thing. Chesterton's fence, Chesterton's fence. I can say this correctly eventually. It was something that was included in an essay in a book by GK Chesterton, Gilbert Keith Chesterton, uh, back in 1929.

[00:01:48]And that book called the thing why I am a Catholic has nothing to do with computer programming or software development.

[00:01:59]He he's talking about uh you know politicians making and and government employees basically making bad decisions. Um but it applies truly fundamentally well to computer engineering as well. And and honestly, I think computer programmers and software developers in general should probably read this 100year-old book, which is about Catholicism.

[00:02:23]It's it's just it's a it's a it's a good read. Um but I wanted to I wanted to walk you through this here. Um, I posted this up over on X, this this hypothetical uh quotation that I just created out of thin air to summarize how it seems to me the various uh engineering managers and the various Rust programmers what they're using logically to decide to do these rewrites. Follow follow me on this one. quote that 30-year-old project there has a bunch of old code in it that I'm sure nobody needs. And the reason that I'm sure that nobody needs any of those that code is because it's old and I don't know what it does. It's probably just handling extra scenarios and edge cases and and I don't even think those are real words. So, we're going to just toss it all out and rewrite that 30-year-old project from scratch. We can do it in a few months. It'll be totally easy, barely an inconvenience. Who who needs those extra scenarios and edge cases anyway? It'll be super easy and won't cause any problems for anybody.

[00:03:40]And if anyone thinks that this is a bad idea, they probably don't understand programming. End quote. That to me generally appears like what the pro let's rewrite everything in Rust argument is. And and here's a little picture that I feel is not exactly right, but it kind of summarizes it. The people who are looking to rewrite things, they think, "Oh, I'm going to rewrite uh uh a calendar utility or a or a utility that causes the system to pause for a moment." Oh, that's super simple. So easy. The requirements are just a simple little function. It's totally totally easy. But then they go and look at you go and look at the code for the original tool that that did that super easy thing and you realize it's crazy crazy complicated. uh to just to drive the point home. Um recently I covered this uh was it back in the beginning of April. one of the core developers of those Rust rewrites kind of had to admit finally that this really was the case that that what they were dealing with rewriting software that had been developed over the course of 30 some cases 40 years and covered an absolutely quote absurd number of edge cases um such that that they simply didn't know what they needed to cover.

[00:05:13]They didn't even understand what the edge cases were. They were just deleting all of that old code that covered those edge cases because, well, they weren't using that edge case. They didn't even know what it was. Therefore, nobody needed it. This is where GK Chesterton comes in. Now, GK Chesterton that wrote this book called The Thing in 1929. Uh, it's also known as uh why I am a Catholic. It's a it's a collection of essays and one of one of those essays uh discusses Chesterton's fence and the idea behind Chesterton's fence is really really dog simple.

[00:05:57]If you are um uh own a piece of property, if you run a government, whatever, and you see a fence, there's a literal fence that's built somewhere on a piece of land, and you think, you know what? I'm going to take that fence down.

[00:06:15]Before taking it down, you need to make sure you understand why that fence was put up in the first place, right? Uh they show they show a little p person picture of a person there. Why is there a fence in the middle of nowhere? What's the point? It's so stupid. Take that fence down. The fence was put there for a reason. Now maybe maybe that reason no longer applies now. Maybe.

[00:06:46]But until you know what the reason was, if you take that fence down and that reason still exists, you're going to be real sorry you just removed a fence and you're going to end up needing to rebuild another fence. You'll have just not only wasted time, but potentially caused catastrophe u of of unknown proportion because you had no idea why the fence was there in the first. People don't just go around building stuff and spending a lot of time on it, dealing with difficult edge cases for no reason.

[00:07:23]And you look at you look at the the the pieces of software um uh like uh uh like the the the core utilities and the like and they are filled with untold numbers of edge cases because these system these tools run on a wide variety of systems used in untold number of environments and under a wide variety of circumstances.

[00:07:51]And those edge cases help to deal with all of those. It's just the way it is.

[00:07:57]You throw all of them away. Well, now any piece of other software, any tool, any workflow, any person, any company, whoever that relied on that utility working under that edge case, under those scenarios, well, they're suddenly now broken and you just broke them.

[00:08:18]This is this is this is the problem that we see right now with all of the Rustbased rewrites. It's the problem is not and I I I've said this a million times and I'm going to say it again and and the Rust zealots out there will probably not hear me this time either, but I'm going to say it anyway. The problem is not in the usage of the language in particular, right? It's not necessarily the problem being rust. The problem is in disregarding decades, nay centuries of basic logic.

[00:08:58]It is ignoring Chesterton's fence. It is ignoring the the basic lessons that we as engineers and engineering managers or program managers and the like have learned not just over the last few years but over decades and decades of building complex computer systems.

[00:09:18]If you have built quality software and developed all the edge cases and and with every edge case you found and fixed all the flaws you found and you decide to chuck it all out and rewrite it from scratch cuz you don't even know what the edge cases are. Those don't make sense.

[00:09:38]They're stupid. Why would anyone build a fence in the middle of nowhere? That's dumb. Delete it. we got a real problem.

[00:09:49]Now, I've talked about I've talked about uh uh this this particular rule from Joel on software in the past and I think it's worth repeating here. Um Joel on software Joel Spolski wrote a blog post in the year 2000 entitled things you should never do part one specifically talking about Netscape um and and how Netscape well just did a did a massive blunder.

[00:10:16]quote, "They did it. They made the single worst strategic mistake that any software company can make. They decided to rewrite the code from scratch."

[00:10:29]Now, this and this this this particular mistake is is a common one. Engineers across the globe have made this mistake.

[00:10:38]I've made this mistake. Every engineer who has existed and worked for more than a handful of years has made this mistake.

[00:10:48]The key is you want to make this mistake early in your career. And when you're not developing software that could impact millions upon millions, potentially billions of people. And what we have right now is not people going around and saying, "Oh, well, I I made this little uh utility for myself that three guys and a dog use. I'm just going to rewrite it." That's fine. Have at it.

[00:11:20]Go nuts. What we are experiencing right now today is people coming along and saying, "Huh, this battle tested software that deals with 8 and a half bazillion edge cases, that software that billions of people rely upon every second of every day, we're going to chuck it out because in part, we don't even know what the edge cases are.

[00:11:48]Therefore, we don't think they're important because we're inexperienced young developers and we've never done this before. So, we're going to throw it all out and rewrite it. And not only that, but we're going to force people to use it. We're going to make it so that the the the replacements that we're making that don't cover more than 1% of those edge cases, well, those are going to be default long before they're ready within months of starting the project. Even though they're replacing software that took 30 years to build, it's there. It's it exact again, it's not just ignoring uh Joelon Software's things you should never do rule number one. Uh they're also ignoring Chesterton's fence. um which which has been a a kind of a common under well understood problem for decades centuries I mean I mean the when he wrote this down when GK Chesterton wrote that down the idea of uh don't tear down the fence if you don't know why the fence was existing in the first place wasn't new he didn't suddenly come up with that he came up with a well-written analogy So we can oh we can visualize that we can all go oh yeah what if that fence was there for a reason but the core concept we've understood this forever for so so very long as long as we've understood consequences to our actions we have understood this core lesson and yet here we are in the year 2026 and Abuntu Linux and all these other big enterprisegrade distributed across the globe. Distributions that form the basis of massive servers and workstations across Earth are committing the most obvious, most simple engineering uh pa massive engineering mistake you can possibly make. And the more it's pointed out to them what an obvious mistake it is, this is what this is fascinating. the more they have dug in.

[00:14:12]After I began uh doing a a series of of posts and shows last year highlighting Abuntu's decisions and whatnot, they immediately dug in. The the the the management team at Abuntu, the Rust developers, etc., they're like, "Fine, we're going to ship it even harder now.

[00:14:32]Oh, oh, now now people are talking about how this is going to be a big problem.

[00:14:35]Well, I guess we better make it We better move the timet up. We better better double down and commit extra hard to shipping the rewrites that don't deal with all the problems that our current software already deals with, which suggests to me a couple of things.

[00:14:55]And then there's multiple possibilities here um about why the why they're pushing these changes. One is that they they may just not be all that experienced. I mean, really, they may not be all that experienced. They got called out on it and now they want to save a little bit of face by proving how right they were to begin with, which is, oh boy, we're just going to end up with bad software because of it. Okay, that's one possibility. Another possibility is that there is an ulterior motive or possibly multiple ulterior motives and they need to get this done before the project stalls out or before enough people get upset about the project that they they get forced to stop it. Such as rewrite the software so that it can use a different license. The software they're replacing is GPL licensed. The new software they're writing is MIT licensed. Maybe that has something to do with it. Maybe it doesn't. But but it's worth thinking about. Um there there could be a wide variety of reasons for it. But whatever the reason, I would highly recommend highly that all the engineering managers and the software developers that are making these sorts of bad decisions.

[00:16:06]If if if a longstanding experienced software engineers and programmers from decades upon decades uh past, if all of their experience and wisdom will not convince you to stop what you're doing, to stop rewriting well-written software, maybe GK Chesterton will. Go read GK Chesterton's The Thing. It's a lot. It's mostly about other stuff. Uh, but at least read the part in there about Chesterton's fence. Or heck, just look at this picture. This one. This one right there. That's enough.

[00:16:49]Learn about that fence and stop taking the fence down before you understand why it was put up in the first place. Uh, thank you to the London Duke Journal subscribers for allowing me to rant about a book from 1929.

[00:17:04]Uh, that's not about computer software.

[00:17:08]What what can I what can I say? This is what you get with the Lunduke Journal.

[00:17:12]Uh, go to lunduke.com.

[00:17:14]Uh, grab a subscription if you want a subscription. Uh, if you want to support the work that I do. Um, or there's just a million different ways that you can grab the Lunduke journal. Substack X, Rumble, YouTube Locals, Tik Tok, Patreon, Facebook, Telegram, the podcast feed, iTunes and Substack and Spotify and all that sort of thing. Uh, Telegram Tele for Tele freaking Telegram. Oh my gosh, it's everywhere. Uh, go to Londuke.com. The links are all up there.

[00:17:40]Uh, lifetime subscribers can also get their name added to the lifetime subscriber wall of shame. There are now seven walls. Uh, and they're expanding regularly. I'm continually adding more and more names to all of the walls as the new lifetime subscribers come in.

[00:17:59]Thank you. I couldn't do this without you. Uh you are absolutely amazing. If you have already requested your name go up on the walls uh and you don't see your name up there yet. Uh never never fear never fear. I have an I have an ever growing backlog of names to get up on the wall. Uh and I'll update I update them about once a week or so. Uh, and with that, ladies and gentlemen, boys and girls, nerds and nerdats across the inner tubes, I do declare end podcast.