「Rustは素晴らしい、誰も見なければ」――DHH発言のファクトチェック（第316回）

Thank you for listening to Data Science at Home podcast with Francesco Gattoleta. You are about to get cutting-edge insights from the people who are reshaping the world of technology with machine learning, data science, and artificial intelligence. It's time for Data Science at Home. Welcome to the show. The black pill is for losers. Don't be a loser. Yes, that's what David Heinemar Hansen, DHH, for those who know him, told a room full of Rails developers in Austin at the end of September. It was the 23rd of September. Now, who's this guy? He's another guy who's very talented. I mean, I cannot deny that. very old school developer who kind of converted to the magic of artificial intelligence and yet another guy

with an impressive career who's actually telling now very different things from what he said a few years ago or he was used to say a few years ago so who's the guy? the guy is the guy who created Ruby on Rails and he just told the people who love his framework that writing code by hand is over, you know, and that's kind of harsh because well, you will understand why then he added a lot of you know, a lot of statements, he made a lot of statements in that speech and he added a punchline hey, which is email service is getting its back end rewritten completely in Rust by AI. And about that, Rust is said, and I quote, Rust is amazing if you never, ever, ever even using that voice

have to look at it yourself. Which is also very weird and very sad to hear for the reasons that I will try to explain. so that's the statement I want to attack today not because Russ is bad but because of what it says about how we are supposed to think about code now and the sad part of all this is that the experts are actually supporting this in my opinion nonsense but of course feel free to jump on these conversations and actually let's have one on YouTube as well as on the Discord channel of datascience.com.com You find all the links, of course, in the show notes of this episode and clearly on the official website as well. So, who's actually talking, right? Let me give you a quick disclosure because, you know, this is not a guy

who just learned how to code or, well, who never coded in his life. As many, of course, of the guys who actually are claiming that artificial intelligence solved the programming problems, right? So the Rails World keynote is real, and press coverage confirms, in fact, all these big claims. And there is, of course, there are footages of these folk speaking on YouTube and on many other channels. Now, the thing is that I'm not arguing about the situation I'm arguing literally with DHH But of course, before doing that I need to give the man the credits that he deserves So DHH is not the typical LinkedIn hype guy This is a guy who for 20 years has been shipping real software, a very good one.

He pulled also 37 signals off the big cloud, which is his company. It's called 37 signals. And he literally, you know, pulled this company off the big cloud and onto its own hardware when everyone, literally everyone said that would have been crazy. Well, it worked. So when he says something, it deserves more attention than, you know, a founder farming, likes, right? I want to be very clear on this, and this is not a guy, okay? So, when these people talk, I personally listen, because they have a lot of years of experience with coding and project management and IT experience, for sure. So, that's exactly why it deserves a real check, because now, you know, it seems that a lot of people kind of went mad about traditional coding, so it's worth spending a few words and, of course, share what I think.

So he says that he used to write something like 30,000 lines of code per year, and now he writes something like 150,000 lines a month with agents, of course. So if you do a quick math about this, you know, this is really stupid math. 150,000 times 12 is what? Is 1.8 million lines of code per year, against 30,000 per year. So that not a bit faster that like 60 times faster For those who don understand lines of code I hope not so many Lines of code is definitely a terrible way to measure things, but more on that later. But let me give you the analogy. Imagine a chef telling you, I used to cook something like 30 plates a night. And now I cook 1,800. So you would ask, you know, one question, which would be definitely, who is eating the food, right?

Did anyone get sick? Now, jokes apart, it's a lot, okay? It's just a lot. And as I was saying, lines of code is a terrible way to measure work anyway, especially this type of work. I find it very sad finding myself citing Bill Gates but in fact Bill Gates said it's like measuring an airplane's progress by its weight a heavier plane isn't definitely a better plane maybe the opposite is true now compare it with the one real controlled study that we have the METR study from the last episode it's a good episode I think because there are real numbers about all vibe coding stuff and especially numbers that people tend not to mention in hyped posts on LinkedIn from

this study it turns out that experienced developers predicted AI would make them 24% faster and afterwards they believed they'd been 20% faster. And the clock said, so the actual thing was that they were 90% slower. So predicted faster, felt faster, measured slower, right? So I'm not calling DHH a liar, absolutely not, but I'm saying that nobody outside of 37 signals can check the numbers that he claims. And that's also a shaky base for a whole keynote. This episode is supported by OutShift, Cisco's incubation engine for frontier technology. Multi-agent AI is in pretty much every enterprise roadmap right now, but there is a problem with that, and we are all facing it. Agents can pass messages, but they cannot think together. So these systems silently underperform through cognitive failures, things like misreadings,

unverified claims, and of course, false consensus. You know, all the stuff that conventional monitoring cannot detect. OutShift by Cisco is building this fix, the Internet of Cognition, which is an open source foundation for building multi-agent systems from design to production, with shared contacts, shared memory, and guardrails to drive the results that we actually expect from artificial intelligence. So read the paper, experience the demo, grab the code from outshift.com. That's O-U-T-S-H-I-F-T dot com. With this said, again, numbers, you know, this is not like a game where measuring lines of code makes you a better person or a better project. sometimes elegance, efficiency. There are so many metrics that you can use

and you should be using instead of just observing the lines of code. It's an indicative way of saying how big the project is, but it can be 100,000 lines of copy-paste stuff and code repetition, and you understand how bad that project is even though it has a lot of lines of code, right? With respect to, for example, a much more sophisticated product or project with, let's say, one-fifth the lines of code, like 20,000 lines of code, which is, you know, you can do a lot of stuff with 20,000 lines of code when you know how to write these lines, right? Now, the official Rails doctrine, and I go back to DHH and Rails. So the official Rails doctrine has a pillar which was called, or is still called, I don't remember, optimized for programmer happiness. For real. So that's the whole reason Rails exists. To be very honest with you, I always prefer to stay the sad developer.

I never embraced programmer happiness in my life, so I never got close to Rails for many reasons. I'm not here to judge that programming language, but whatever. now the same person says developer happiness is almost a non-factor so maybe it's a real change of mind after 20 years that, you know, give me that so maybe it's DHH being DHH because if you know the guy as much as I do not directly, we don't know each other in person but I know how his statements have always been a bit provocative in the years and he has kind of a long record of, you know, loud public U-turns, if you allow me the term. Now, I don't need to decide. I just want you to notice that probably it's happening again, right? Now, here's the part that made me laugh out loud. Hey, which is the email service that he's building, in fact was Rails showcase okay It was built you know the proof that a small team could ship a serious product with Ruby

I know, it's kind of counterintuitive. Okay, it's a burn. It's just me being me. Now, what happens? Like, jokes apart. I don't have, I don't know these products. I'm just mentioning that Hay was written in Ruby. And the idea of, hey, was indeed to show to the public, hey, we build this thing in Ruby. So it can be done. And I believe it was done, you know, nicely and correctly and according to best practice. Because, again, the guy is a very senior developer. And now its backhand moves to Rust, right? Entirely. So the framework's own creator is walking his flagship product out the door. Okay? That's what was happening. That's at least what has been claimed. So to be fair, this isn't Rails dying. Basecamp 5 shipped in June 2026 and stays on Rails.

And hey, the email service isn't only changing language. It's also going from web pages served by the server to six native apps. So there is less work for the server, which means, of course, less CPU, no matter what language you pick. What's the decision behind this? It's out of my knowledge. Probably I can understand that, you know, the day you decide to run away from public clouds or the big clouds, you know, you have to be cautious about how much CPU and how much compute you use with your product. And so doing that type of exercise and economy is, you know, it makes sense. But this, you know, brings us to the numbers now. 99% less CPU, 95% less memory. DHH himself called them back of the envelope estimates on unfinished work. And I was quoting, two big changes happened at once. So nobody can say how much came from rust. It's like moving house and switching to a smaller car in the same week and then crediting the car for your lower bills.

You know, there is a confounding factor there that we don't understand which one is actually bringing you the, you know, lowering the budget of your life. Now, let's attack the Rust line because this is, you know, I took it kind of personal. I know I shouldn't. It's a programming language. But Rust is a good language. Okay. I've been a paladin of Rust and I'm still a very, you know, aficionado of Rust. you can consider me an ambassador I've been using Rust very very much in the last 5 years and it's great, it's fast it catches a whole class of memory bugs before the program even runs we have spent a lot of episodes speaking about Rust and why Rust makes sense as a language, there's a reason also security people like it because memory bugs and low level memory bugs are pretty much possible because it has a different paradigm, you know, programming language paradigm.

So why is the joke outrageous, in my opinion? Well, because great, as long as nobody ever looks at a programming language in this case, is the opposite of how good engineering actually works, okay? That's what is said about all this. So if you think, you know, again, I like to give you analogies for people who are not really familiar with the programming languages, but think of a building inspector, right? A building, you know, construction, right? Imagine a builder saying, you know, this building is perfect as long as no inspector ever goes inside. I mean, I wouldn't move in this place, right? So wouldn't you? So Rust's whole selling point is that humans can read the rules and trust the result. That's the whole point, you know? take away the human and you have kept the expensive part of the language and thrown away the reason you chose it. You get my point, right? Also, Rust stops one kind of bug.

It doesn't stop, for example, wrong logic. You can still write things wrong in a logical way, right? Yes, it prevents you from a buffer overflow. It prevents you from a double free memory allocation. but it doesn't stop from the fact that you are, you know, making a logical mistake. It cannot stop you from there. It doesn't stop a login check that lets the wrong person in, if you get the point. A memory safe program can still hand your inbox to a stranger very efficiently, okay? And this is an email service and I'm referring to, hey, every private message, every password reset link, every contract, every awkward conversation. You know, this is not a to-do app that is managing your growth release, right? Remember from last episode, the receives from the Vibe coding episode, there was Vera code, 45% of artificial intelligence generated code failed security tasks, and 86% failed to defend

against cross-site scripting. Then we had CodeRabbit I just you know reporting the same numbers as last time 470 pull requests AI code had 2 times more security vulnerabilities than human code Of course nobody has to look at it It not a security model dude It an incident report with a delivery date if you know what I mean So now let me be even more critical because then I always rant about all this stuff. If coding is bad, then why isn't everyone fired? You know, if handwritten code were truly over, you know, you'd see mass layoffs. And instead, the U.S. Bureau of Labor Statistics projects 15% growth in developer jobs from 2024 to 2034 in the next 10 years. But of course, there is the bottom of the ladder that you have to look at. Entry-level hiring is down 25% year over year.

Entry-level jobs. developers aged 22 to 25 are down almost 20% from the 2022 peak so the honest story here is not coding is dead it's that the bottom rung is being sewed off while demand for senior judgment keeps growing that's how I read these numbers and that's the real question in fact DHH can trust his agents because he spent 20 years learning what bad code smells like. You know, he built that nose the slow way. If juniors never get to write their own mediocre code, where does the next DHH come from? Project this. Don't just believe these numbers and these claims. If someone spent 20 years improving how to read code, how to write code, knowing the architectures, knowing the best practices,

and now is using artificial intelligence generation to write code or to generate code is because this guy, as many as all the other, as well as all the other senior people, they know how to control that AI-generated code. They know how to spot the things that a junior would not. Okay? now there is one part of what it gets right in fact of that speech in my opinion every app needs a command line and that command line is for machines not for humans that's real, I agree with that and it's the same idea behind the model context protocol MCP software is starting to be used by other software I wrote a book about it so that's a point taken to DHH for sure I'm being honest. I'm being honest. Now, split is plain in two, in my opinion.

Typing every character by hand is becoming optional. Yeah. And I'm quoting. It's probably true. It's been having there since autocomplete. Okay? 15 years ago, we had autocomplete, and now we have autocomplete on steroids. The second statement is expertise, review, and judgment are optional. This is a flat wrong, in my opinion. Every data set that we have covered says so, plus the real breaches at Moldbook, Lovable, Base44, and EnrichLead, they all support my statement. DHH's own code is only safe because DHH is the one reviewing it. And that's the part of the story that it doesn't tell. okay and so it's the same part that many other folks out there especially the senior people are not telling the big public they keep saying yeah AI let me generate a middle line of code every week

but they don't claim the fact that their eyes and their brain is a 20 plus year experienced developer brain right so they spot they smell things when I even I see code written by or generated by someone, I can smell it's generated because there is no, sometimes there's no elegance, there is no consistency, there are many things, there's no flavor, okay? And I have plenty of these metrics, maybe I should dedicate an episode about, you know, how to judge good code from bad code, but more on that another time. So, here's my counter-provocation. The loser move in 2026 is not writing code by hand. It's shipping a mountain of code that nobody reads into people's private inboxes and calling review a personality flaw. And by the way, Rust is amazing, but only if somebody is looking at it.

Talk to you next time. Hey, quick one. I wrote a book, The Mythical Token Month. Here's the idea. AI coding agents feel like magic, but they don't remove the hard part of building software. You know, they just clear out the busy work around it, as we all know. What's left is indeed the actual thinking. Now, I have to say that no AI wrote a word of this book. I have to say that. It's a self-claim, but you have to believe me. It's out now as an e-book, NoDRM, the website mythicaltokenmonth.com. Links in the show notes. Thank you. You've been listening to Data Science at Home Podcast. Be sure to subscribe on iTunes, Stitcher, or Podbean to get new fresh episodes. For more, please follow us on Instagram, Twitter, and Facebook, or visit our website at datascienceathome.com.