Summarized using AI

Fireside Chat With David Heinemeier Hansson

David Heinemeier Hansson and Elise Shaffer • July 08, 2025 • Philadelphia, PA • Fireside Chat

Fireside Chat With David Heinemeier Hansson – RailsConf 2025

This fireside chat features David Heinemeier Hansson, the creator of Ruby on Rails, in conversation with Elise Shaffer at RailsConf 2025. The discussion reflects on the evolution of Ruby on Rails, current development challenges, the future of web application development, and the impact of new technologies like AI on Rails and web development.

Main Topic

David Heinemeier Hansson shares insights and retrospectives on the journey of Ruby on Rails from its inception to its present and future, focusing on the pursuit of simplicity, reducing complexity, and enhancing developer productivity.

Key Points Covered

  • Extraction and Evolution in Rails:

    • Rails favors extracting features that have wide applicability, rather than hasty abstractions from single use cases.
    • Lessons learned from over-eager extractions (e.g., Active Resource) emphasize the importance of maturing features before incorporating them into the framework.
  • The Ever-Advancing Web Platform:

    • The web is constantly improving, especially in browser capabilities, CSS (e.g., nesting, variables, layers), and JavaScript (e.g., import maps, modern syntax).
    • The advancement of the browser and web standards has allowed Rails to move away from complex build tools over time, aiming for a more direct, zero-preprocessing approach.
  • Full Stack Simplicity:

    • Rails aspires to empower full stack developers—individuals proficient in both front-end and back-end development.
    • Tools like Hotwire and Turbo allow for building feature-rich applications without excessive JavaScript, reducing the need for overspecialization.
    • At 37signals, the culture is full stack; every developer is expected to handle the whole stack, enhancing productivity.
  • Complexity in Deployment and Operations:

    • The industry has seen deployments regress from simple, fast FTP updates to complex multi-minute pipeline builds due to accumulated tooling.
    • David advocates for shorter deploy cycles (targeting 2 minutes, aiming for 30 seconds) by leveraging fast local hardware for CI and Docker image builds instead of relying solely on the cloud.
    • Simplicity is further promoted by eschewing unnecessary distributed systems where possible, favoring moving more of the stack onto a single machine (e.g., SQLite, reducing reliance on Redis).
  • Omikase Approach and Defaults:

    • Rails defaults (the "Omikase" approach) reduce barriers for new developers by solving common problems and enabling developers to focus on building rather than configuration.
    • Complexity and important concerns (like CSRF protection) are handled by the framework by default, letting developers postpone learning about edge cases until necessary.
  • Cloud, Digital Sovereignty, and Decentralization:

    • There is a renewed motivation towards data sovereignty and decentralization, highlighted by 37signals moving off cloud services (e.g., S3) in favor of self-hosted infrastructure.
    • This change mirrors the original purpose of the internet—to remain resilient, decentralized, and beyond the control of a single provider.
  • The Role of AI in Development:

    • AI is seen as both transformative and currently limited—capable of impressive productivity gains, especially in learning and routine coding tasks, yet far from replacing full system development or developers.
    • There is uncertainty about how AI will shape the future of programming and if it will fundamentally change developers' roles or just enhance productivity.
  • Lightning Round – Rails Features:

    • The chat concludes with a rankings game of legacy and current Rails features, highlighting some nostalgia (e.g., dynamic finders) and lessons learned from past features (e.g., plugins).

Main Takeaways

  • Rails and its community continue to prioritize reducing unnecessary complexity, empowering full stack developers, and embracing improvements in the web platform.
  • There is a focus on simplifying both the developer and operational experience, from framework configuration to deployment and infrastructure.
  • AI is a promising tool for productivity but remains unpredictable in its ultimate impact.
  • The value of strong defaults and resisting the urge to prematurely optimize or add complexity remains central to the Rails philosophy.

Fireside Chat With David Heinemeier Hansson
David Heinemeier Hansson and Elise Shaffer • Philadelphia, PA • Fireside Chat

Date: July 08, 2025
Published: July 23, 2025
Announced: May 28, 2025

RailsConf 2025

00:00:18.880 Thanks everyone.
00:00:24.080 So, how is how's the first day of RailsCom treating you? It's been awesome. I mean, as always, it
00:00:29.840 is a pleasure to spend time with people who are passionate about programming, passionate about computers, and passionate about Ruby on Rails.
00:00:36.000 Yeah, I I I think the it's been just a great day. I do have a bunch of questions that are uh we're going to
00:00:41.520 kind of break it up into three sections. We've got the past, the present, and the future. So, sort of on theme. Uh I'm going to start by asking, you
00:00:49.440 know, Rails is a framework that is primarily extraction from uh existing
00:00:56.079 code that's in production. Has there ever been anything that you've wanted to extract but it just hasn't felt like you
00:01:01.120 could or it wasn't the right time and like what was Yeah, I think there has also been
00:01:06.400 examples of things I have extracted that I shouldn't have. And I think we talked about some of these things Robbie
00:01:11.920 touched on active resource which I thought was a great example of a framework that was prematurely extracted
00:01:18.400 from having basically one use. I had one integration case where we were using it
00:01:23.840 at third time signals and I thought like wow we've solved it and it was a great lesson in realizing that great extractions don't happen on
00:01:30.960 the first reuse. It happens on the second because if you just have one case of something it might very well just be
00:01:36.799 a one-off. It might very well just be one particular solution to one particular problem. Not something you
00:01:42.159 can make generic. So I've tried to learn my lesson and I tried to temper how
00:01:48.479 eagerly I extract things. I try to reach the second use. At least I find that
00:01:53.600 that's when the most successful extractions do happen. But the applications I work on are still full of
00:02:00.560 unextracted Ruby code that could be turned into frameworks or could be turned into
00:02:05.920 libraries. And I have this wish list of things I want to pick out. There's just an endless amount of work.
00:02:11.440 Yeah. It's actually funny because I think when we when I released Rails 10, I thought, do you know what? Maybe in six months
00:02:18.319 we're done. like the framework is going to be complete. We will have solved all the problems there is to solve with
00:02:24.239 building web applications and then we could just lean back and use the framework. That turned out not to be
00:02:30.160 true. I'm glad because I've had 22 years of fun continuing to build this framework, continuing to extract new
00:02:36.879 things, continuing to keep up with the web. I think that's the other part that I really took a while to realize that
00:02:43.440 the web wasn't done. In 2005, we were not finished creating and improving the
00:02:49.519 world's greatest application platform, the web. And this is one of the things that's really inspired me over the last,
00:02:55.840 let's say, 3, four, five years even, is that the improvement on the fundamentals of the web has sped up, not slowed down.
00:03:04.319 we're making the web faster or the improvement of the web, the technologies and the tools we're using with with CSS,
00:03:11.280 with JavaScript, what's built into the browser is getting better faster than perhaps it's ever gotten. And it's taken
00:03:19.440 some of the extraction that not that I made that others made for example with um with SAS for CSS pre-ompilation. The
00:03:27.360 fact that it took 12 years I think for CSS to adopt nesting the probably the
00:03:33.280 primary feature of why people would use CSS pre-processor sort of seems ridiculous but then now you look at what
00:03:40.159 has happened with CSS just in the last two years and for me I just get super excited. I'm like we can do so much in
00:03:46.640 the browser. No pre-processing just the straight text files the no build style that I've
00:03:52.560 become such a big fan of. Yeah, I the the just progress of CSS like I think
00:03:58.799 some of the things that are just happening there like the browser the browsers are so good now that you you
00:04:04.560 kind of don't need all of this extra complexity like between you know I think
00:04:10.319 nesting and variables are kind of the easy ones but even like CSS layers even like there's tons of stuff happening
00:04:15.760 there that's like super super exciting and the same happened on on the JavaScript side which I probably touch
00:04:22.160 more than I touch CSS we have some wonderful designers at 3M signals. So I don't write that much CSS myself, but I
00:04:28.240 do write a fair amount of JavaScript. And the fact that the browser was able to get us all the way to import maps,
00:04:34.080 was able to get us modern include systems, was able to get us a syntax that's actually legitimately enjoyable
00:04:39.759 to use was a bit of a shock to me. Like it kind of crept up on me like, hey, I kind of like writing this JavaScript now
00:04:46.000 in a way I would never have said 10 years ago. Like I was not necessarily the biggest fan of of vanilla JavaScript
00:04:52.240 in the ES3 age, right? Like this was why we got CoffeeScript because that was a nicer dialect that felt more Ruby like
00:05:00.880 and now uh JavaScript itself has gotten up to a level that's just really good. So keeping up with how the web platform
00:05:07.840 evolves. Now we're getting things like pass keys and other things that continue to push that boundary um is actually it
00:05:15.520 feels like there's more work than ever. It feels like there's more extractions than ever. There are more aspects of
00:05:20.560 creating compelling applications that are not just competing against other web apps. That's the thing that I really
00:05:26.160 came to realize that the fight with the web is not so much with the web itself, but with the proprietary platforms like
00:05:33.039 the mobile ecosystems that the web has to stay current in order to be a
00:05:39.120 reasonable alternative to a native iOS app. And
00:05:45.199 I like my phone most of the time, but I don't enjoy being kind of
00:05:52.560 putting to a point here, imprisoned by a proprietary platform that tells me whether I get to publish an app or not.
00:05:58.080 That to me is just an intolerable state that I sort of just have to deal with as
00:06:03.360 part of building things for a modern audience who who want to have native apps. But whenever the choice of going
00:06:08.800 with the web, the free open web that you don't have to ask for permission to publish a new application, you don't
00:06:14.160 have to ask for permission to to go into business. I go like yes, this is why we
00:06:19.199 need to be more forwardlooking, more aggressive about evolving the web platforms, not stuck in the past because
00:06:25.120 our competition, it's not just other websites, it's the native platforms, it's the proprietary platforms.
00:06:30.240 Yeah. I So going back a little bit to Yeah.
00:06:36.639 going back to the web getting better and being able to rip out, you know, being
00:06:41.919 able to get rid of some of this complexity on the front end and get rid of this JavaScript complexity. Do you uh
00:06:48.479 there is a thing around kind of feeling like, oh, JavaScript is not as bad as it used to be, but is there is there a is
00:06:55.360 there a part of that that feels inevitable looking back on it? No, that's the big surprise to me.
00:07:01.759 Yeah. I remember when we added Webpack to Rails 5, I knew that this was the
00:07:08.160 kind of extraction that I hoped wouldn't last forever. I knew that going in. I knew, you know what? This is a temporary
00:07:14.319 bridge for us to get to somewhere better. We got to do it right now. I don't love it, but if we don't, we're
00:07:21.440 turning our back on where the innovation in the web is actually happening. All the advances in writing better more
00:07:28.800 modern JavaScript was happening in the pre-mpilation st is happening with the transpilers. And if we just hold our
00:07:35.199 noses and say we don't want to touch that, people are going to go somewhere else because they can't build the kind of apps they want to build with Rails.
00:07:41.840 And then you can look at that and go we can either be a purist and say we don't want to touch any of this JavaScript stuff. We just want to stay over here
00:07:48.560 and they got to worry about that and then realize that's the road to irrelevance. And I was not willing to
00:07:53.759 make that trade. I'd much rather than just hold my nose and go like, you know what, don't love this. Don't love the
00:07:58.879 complexity. Don't love what it does to the onboarding experience of someone new to Rails. But also,
00:08:05.680 people are adopting Rails. They're choosing to use it because they want to build something. And if we're telling them, here's this entire class of
00:08:11.919 applications that you just can't build with Rails, that's not a healthy path.
00:08:16.960 But I knew going in that was probably the one extraction where even before it shipped I went like I can't wait until
00:08:22.879 we can unhip this. Yeah. I I think a lot of us um you know
00:08:27.919 I think because the browser has just been getting so much better and because things have been getting so much better
00:08:33.599 there's there's a a feeling at least I have felt this way that with all of the stuff around hot wire with stimulus it
00:08:40.479 sort of feels like we are getting back to the like I'm going to say the good
00:08:45.760 old days but it feels like we're we're getting back to where it it's a being a full stack Rails dev is a real
00:08:51.680 possibility. Yes. in a way that for a little while it felt like you kind of had to either
00:08:57.200 front end and back end. Front end or back end. Yeah. Now what's interesting is I felt like the lone man on the island kind of
00:09:03.120 keeping the flag of the one developer, the integrated stack, the full stack developer. Like it almost became a joke
00:09:08.160 for a hot minute because people refused to believe that you could do both because there was so much complexity on
00:09:13.760 the front end that it felt like well you need a PhD just in build tools to figure that out. you can't do that and also be
00:09:20.720 an expert in the back end. And I'm really glad we didn't give up on that because sometimes those kinds of values
00:09:26.880 and those kinds of aspirations, you go just go like yes, it is a hard moment for that ideal. It's not that easy to be
00:09:34.800 able to fulfill the full stack developer notion. The one developer framework is
00:09:40.880 having a little bit of a hard time because there's so much complexity on the front side. But if you can just hold
00:09:46.160 on, I trust the web is going to figure this out. I trust that we're going to get over this path of complexity, this
00:09:52.640 bridge of complexity, and we're going to end up in a place where we can get back to that. And that has been the great joy
00:09:59.200 for me over the last few years is to realize, you know what, that's true. We have been able to get there. Not for
00:10:04.320 everyone, not for all applications. There's still a bunch of shops that set it up split up. They have the front ends
00:10:10.560 and then they have the backends and that's separate. But that's no longer a necessity to be competitive on the web. The way we build
00:10:17.920 applications at 37 signals, everyone is a full stack developer. We don't have anyone who just does JavaScript or just
00:10:23.200 does backend. Everyone is assumed to be able to use the whole thing, which means that we can build features with one
00:10:28.720 developer, one designer, which is a wonderful productive pairing. And even
00:10:34.800 if that doesn't work for everyone all the time, I think it is undoubtedly a better answer for anyone getting
00:10:41.279 started. If you're just learning Rails now and you want to build something, you don't wanna what am I a front-end
00:10:48.000 developer? Am I a backend developer? Where does all this go? No, I just want to build things. I want to get an application onto the web. What do I need
00:10:54.880 to do? Tell me because I don't know already. And we're able to offer a complete end-to-end solution for full
00:11:01.760 stack developers who can use Hot Wire, who can use Turbo, half the time not even know what Turbo is. that Turbo is
00:11:09.120 just this thing that makes a web application feel fast when you use Rails. I'm not even writing any JavaScript and still it feels pretty
00:11:15.920 good. Ultimately though, Turbo falls in the same category a little bit like Webpack. I can't wait until we can unhip
00:11:23.920 Turbo. I can't wait until the browser has all the stuff that Turbo does to
00:11:29.440 make applications feel amazing just built in. all the preloading, all the things that we do make iframes great
00:11:37.519 again. That would be amazing. Like what iframes weren't stuck in 2003 and we
00:11:43.200 updated them for modern lazy loaded um web components? That would be awesome. I
00:11:48.800 think the browser can actually get there. And Turbo to me is again one of those crutches that we need right now.
00:11:54.320 Like we needed coffecript for a period of years while JavaScript was kind of a little bit not the greatest. And then we
00:12:01.680 can let go when the browsers get up to date. Have you seen uh there a few years ago
00:12:06.959 there was some research at Google around an element called portal which is kind
00:12:12.720 of a modern iframe kind of thing. Uh it it it's be I think it's still behind a
00:12:19.279 flag and it's like not like you can't turn it on really but like like someone in the browser build would have to turn
00:12:24.959 it on. Uh but it was like kind of along that same line of you would preload in this like portal and then you could
00:12:30.320 transition the portal so you could get like page and this is what I really like about what's been happening both at Google and
00:12:37.519 to some extent Apple. Neither of those two companies are necessarily my
00:12:43.200 favorite kinds of companies in the world. But the work that they've been doing on the browser absolutely is excellent. and the way that work has
00:12:49.680 sped up and the way that the people who are working on those browsers now actually seem to pay attention to how
00:12:55.600 web developers build web applications and they actually look at how things are built in the real world and go like you
00:13:01.200 know what could we make this easier and we had a long walk in the desert for
00:13:07.279 about 10 12 years where it seemed like browser builders had never looked at how
00:13:12.480 web apps were actually built in the real world. There was no overlap between the web app development world and the
00:13:17.760 browser development world. And then something magic happened. I still don't have the full thesis of how or who, but
00:13:24.240 something happened. And now browsers actually seem interested in how we're building applications. So I do have some
00:13:29.839 faith that these ways we're still ahead of the browser. The browser will catch up. And the more the browser can catch
00:13:35.839 up, the more we can take out of Rails, the more complexity we can flatten, the more we can just send text files. And I
00:13:42.800 think that is a throwback to the to the good old days. And you know what? Sometimes the good old days is seem as
00:13:48.480 just sort of nostalgia. This is for old people reminiscing about when they were young, right? Like, oh, the best music
00:13:54.720 in the world just happened to be when I was 15 and it was just really whatever, right? Like that's the time capsule. And
00:14:01.760 there's something to that, but there's also some reality to it. Like I've been spending a lot of time on on the deployment problem. How do we get
00:14:07.920 applications deployed to servers so the users can use it? I remember the good
00:14:13.360 old times when I could FTP a Ruby script up to a CGI server and the instant next
00:14:19.839 reload would have the new code and it took less than 1 second. And then I also remember a build pipeline we had at 37
00:14:26.320 signals where I literally sat and stared with growing animosity and anger at a
00:14:31.839 counter that showed 15 freaking minutes to deploy a twoline change. And I
00:14:36.880 thought what have we done? How was I complicit in this? This is a great moral
00:14:42.959 fa failure that we went from 1 second FTP deploys to 15inut
00:14:48.959 wildly complicated CIDI blah blah blah deploys where there's a million
00:14:54.880 containers involved along the way and what to deploy the same twoline change as I would have employed on FTP 20 years
00:15:02.240 ago in a fraction of the time computers are literally 10 time 10,000 times
00:15:07.600 faster and I'm spending thousands of times more weight on the deployed that
00:15:13.199 seems completely preposterous. And I think that was the work I tried to pour into Kamal. How can we take some of the
00:15:19.199 things that are better, right? Like it's not like everything was just amazing when you were FTPing up a a new file to
00:15:24.959 CGI server, but there are some things there we should hold as a benchmark. We should not accept that level of
00:15:30.959 regression that changing a web application should take 15 minutes because that's how long the build
00:15:36.079 pipeline takes for all this nonsense to go through because how much better is it really? Would you rather feel like you
00:15:41.920 have some certainty that there's a build pipeline that has run a bunch of tests and then it takes 15 minutes to deploy and then if you realize there was still
00:15:48.000 a mistake, it takes 15 minutes to fix it or would you rather just FTP upload that one file, realize there's a bug and fix
00:15:54.399 it with VI straight on the damn server in about two seconds. What's actually better?
00:16:01.519 Like it's not actually apparent to me that we have improved things even with modern tooling like Kamal and so forth.
00:16:07.600 What's VI on the server actually by better? I mean I I this terrifies me. The idea
00:16:13.759 of like doing editing a thing on the server kind of terrifies me a little bit. The bugs I fixed like that.
00:16:19.519 I can tell stories for days. And and not only the bugs I fixed like that because where this really hits the
00:16:25.839 15-minute thing is when you actually have a real problem, right? You've caused part of the application to be down. You know what the answer is. Oh,
00:16:33.519 it's a twoline change. It's in one file I've identified. And now you go like, "Wait, you tell me I can do nothing? I
00:16:39.920 now have to just wait 15 minutes for that to roll out. Give me vi back on the damn server. I'll SSH in myself and just
00:16:46.480 change it." Do do you think that part of this problem is just all of the added
00:16:52.399 complexity? Because like the reason we have a 15-minute build is because now we
00:16:57.440 have all the stuff that we have to do before we can even ship it, you know, that we think we have to do.
00:17:02.480 That we think we have to do, right? the road to hell is paid with good intentions. And every single step of that built pipeline, there was
00:17:08.959 someone who either once cut their fingers and went never again or someone went like it would be much more pure if
00:17:14.799 we just if we just what built a pipeline that took 15 minutes. Like it's the accumulative effect of tiny little
00:17:21.839 changes over 10, 15 years where we just get boiled. And now I I heard feedback
00:17:27.839 when I shared the 15-inute deploys where people say like you should hear how long it takes at our company. Raise of hand,
00:17:34.799 how many people does it take more than 10 minutes to deploy your application? Oh my [ __ ] god.
00:17:41.919 I mean what I this is just unreasonable. I mean this is also one of the things
00:17:47.840 that actually gives me more information because I get like I could feel my my heartbeat is going up a little bit because like I'm angry. I am like this
00:17:54.000 is just like we did this to ourselves. There weren't any aliens that came from [ __ ] space and said like this [ __ ]
00:18:00.400 now this is how you do it. No, we went like I would like a little bit of this, a little bit of that and then 10 years later 10 minutes.
00:18:07.039 Yeah. No. So what? Okay. So let's let's let's let's start there. We're at the 10-minute mark. What would have to
00:18:13.440 happen to get us down to say a 30 second deploy? So the goal that we've set at 37
00:18:19.120 signals after I saw that 15-minute deploy one time was the goal now is 2 minutes. Okay. So part of it is is how do you build
00:18:26.000 your your images? I actually do think that Docker is good. I do think there's some complexity in it that's not
00:18:31.520 necessarily the greatest. But the fundamental idea that you can encapsulate an entire system into a container. That's a final product.
00:18:38.080 That's actually good. The problem is how do we produce this? Problem one. We build in the cloud. Sometimes these
00:18:44.080 cloud builders, they their caches just get overwritten. They're doing clean builds all the time. Things cycle in and
00:18:50.400 out. You get a you get a noisy neighbor. All of the sudden your cloud build takes forever. What we've done is we pulled it
00:18:57.120 all home back to developer machines because now the fastest computers you
00:19:02.480 can buy, which is actually amazing. The fastest computer you can buy is the one that sits on your desk. Like we spend an
00:19:07.840 enormous sum of money on very fancy AMD epic machines that live in the cloud and
00:19:14.160 many of them have like 64 cores, 96 cores. Those cores run at between 2.4
00:19:19.520 GHz and 2.7 GHz because that's how you make that many cores fit on a single die chip, whatever. The chip you have in
00:19:26.480 your local computer that might run at 4.7 GHz. It might run at 5.1 GHz. If you
00:19:32.240 have a desktop computer, you might be running at 5.7 GHz. The difference between the 2.4 GHz and 2.7 like that's
00:19:39.840 almost double. Like the fastest cores you can buy today are the ones that run
00:19:45.039 in your personal computer. That's where we should be building. That's where we should be running CI for a lot of
00:19:50.240 systems. It is the literally the fastest way to do it. We had a CI system that were running in the cloud where our CI
00:19:56.880 build alone was first of all subdivided in all these little sections because that's the way you make it fast, right?
00:20:02.480 Like if anyone has looked at the Rails test suite and how that runs, it basically cuts it up into I don't know
00:20:08.160 40 different segments at this point to be able to run it fast. Um, we pulled it
00:20:13.440 all home. Now I can run the entire test suite for hey.com that we use is about 30,000 assertions in a minute and 12
00:20:22.720 seconds on the fastest machine I own. A minute 12 seconds. The entire thing that needs to run this multi-million dollar
00:20:29.120 SAS thing. How many people run their CI system in one minute?
00:20:47.600 Shopify and you have four million lines of code, no, that's not going to happen. But most people are not freaking Shopify, right? Most people are closer
00:20:54.480 to 100,000 lines of code or 200,000 lines of code. At that scale, absolutely you should be able to run your CI in low
00:21:02.080 singledigit minutes on local computers. So that's one thing we can do. We can make the CI part fast 1 minute. Then you
00:21:09.280 can build your images close to your code and you can keep your caches warm. We've also moved the building of the images
00:21:15.120 onto the local machines. Docker locally is actually really fast, especially if you're using an x86 computer.
00:21:22.400 That was a Linux commercial. just going through whatever. Um, and you can do a
00:21:27.919 bunch of these things and you can get it down to about two minutes. But I think there's even more we can do. I have a bunch of ideas of 30 seconds. I think is
00:21:34.559 actually a very reasonable target. I remember when it first took 30 seconds with Capistrano back in 2007. I was
00:21:40.640 like, this is so slow. Like I was annoyed at 30 seconds back in ' 07 and now we're like accepting 10 mill
00:21:47.600 10-minute deploys in 2025. I think that's just such a clear illustration of how as an industry we're able to regress
00:21:55.280 sometimes for like good intentions, right? Like reproducibility or containers in general or cloud or blah
00:22:02.159 blah blah and then we end up in a place where if you had told us in advance where we were, right, you were sitting
00:22:07.520 there with your app going out in 30 seconds and I was like, do you know what? What if you put it in a container? All you have to do is wait 15 minutes.
00:22:13.440 You'd be like, yeah, no, no, no, no. I don't want that. Right? We did not end up with that in one hop. We ended up 10
00:22:20.320 years a boiling frog. But this is the story like this is also the story of a lot of the complexity
00:22:25.679 that we have now is that is that you know we we created one thing because it solved a tiny problem and
00:22:31.600 then you have to that but then it leads to another problem. Then you have to create another thing to patch that problem and then that leads to another
00:22:37.280 problem. You have to patch that problem. So then you keep building up until you get to the 15-minute.
00:22:42.320 This is why Rails is a full stack framework. This is why the entire
00:22:47.760 picture is so much more important than any one individual part, right? Because
00:22:53.039 you can really get boiled when you have teams and projects that are just focused on this part of it and then everything
00:22:59.039 else is not their problem. Well, in Rails we say the whole [ __ ] thing is our problem, right? The whole problem of
00:23:05.600 building greater web applications, deploying them to production, getting customers, that whole thing our problem,
00:23:12.159 right? From end to end. And then we can go like then we own it. We can't just like well that's their problem. That's
00:23:17.600 their problem. Right? That's where things just you get boiled and you feel like there's nothing you can do. With
00:23:22.720 Rails, we've said from the beginning, no, no, that's not how we're going to we're not going to roll like that. We're going to solve the whole problem. And to
00:23:29.200 solve the whole problem, we actually have to compress complexity. Because the only way the whole problem fits into our
00:23:35.919 squishy little human brains is if we really smash it down into a little block. And then we go like, do you know
00:23:42.159 what? There are benefits to method A, but it comes with too much weight. I'm not going to take it. I'm gonna wait a
00:23:48.080 second. I'm going to wait for method B that's maybe 95% as good, but 5% of the complexity. Oh, that fits into the box.
00:23:54.640 And now the box fits into my goddamn brain, right? And like we just have to accept our
00:24:02.080 brains aren't that big, right? Like we really need to take the big problems and make them into small problems and then
00:24:08.720 we can solve a handful of small problems. That's what fits right and anything that doesn't fit that is any
00:24:14.559 system that cannot be understood from end to end by a single developer is a broken system when you start out again I
00:24:21.520 use Shopify because now I'm on the board so I get to say we because at Shopify
00:24:26.720 like we we don't get to do that right like four million lines of code does not fit into any single human brain but
00:24:32.400 again that's a 1% problem that you should be so lucky to have right by the
00:24:38.000 time you get to hundred billion dollars of market cap. You can have all the problems in the world. None of them
00:24:43.039 matter. None of them [ __ ] matter. You have all the money in the world to hire literally 9,000 people and 3,000
00:24:48.960 programmers to deal with them, right? It matters on day one. It matters to use
00:24:54.400 the Shopify example when Toby is sitting at home building Snowevil, the first app
00:25:01.760 that turned into Shopify. That's when the compression of complexity really matters. the transition from zero to
00:25:07.360 one, from there's nothing to there's something. And that's what Rails needs to keep its eye on. Even as we get all
00:25:14.159 these great successes and we get all these unicorns and we get these fantastically valuable companies with thousands of programmers and developers
00:25:20.720 in them, we got to think like, you know what, we need to make sure that the next Shopify can happen, that the next
00:25:27.200 unicorn or the next base camp or like there's room all across the scale, right? Like it doesn't have to be just all about mega companies, but it does
00:25:34.080 have to be about one programmer, a tiny team, no funding, spare time, freelance
00:25:41.039 project that can turn into something. And the only way we ensure that that remains true is by continuing to be
00:25:47.679 vigilant about a single programmer being able to understand the whole damn thing. So uh yeah
00:25:59.279 so there there is an element here I think about like not just the solo
00:26:04.559 developer experience but there's also the omocas kind of you have stuff in the
00:26:09.919 box already right and that allows you to kind of ignore
00:26:15.440 details that don't matter today right and then maybe they matter in the future but you can deal with them in the
00:26:20.799 future Yes. And I I think that there's like that kind of piece of it too. It's a huge part of it. Omicazi to me is
00:26:29.760 about two things. First, I'll take the uh noble part and then I'll take the less noble part. The noble part is that
00:26:35.200 Omicazi reduces the barriers of entry because any developer who comes into Rails tomorrow and doesn't know all the
00:26:41.919 things don't have to know all the things because they just work until they had problems and then you learn a little bit
00:26:48.159 about that problem. They don't realize that we literally have I don't know how many lines of code that we have, but we have a lot of lines of code and we solve
00:26:54.720 a lot of problems including a lot of sort of gnarly security issues and other things that are just taking care of you.
00:27:00.559 You don't even have to know what a CSFR token is, right? Like you're starting on your expectation blissfully aware that
00:27:07.919 we're making sure that your form isn't getting hijacked as it's being submitted to the server. That might have been a lesson you had to find out because your
00:27:14.240 whole damn app got hacked, right? And we go like, "No, no, no. We got you." like you don't even have to know about it.
00:27:19.679 Now one day you might want to know about because you want to do something special. That's a problem for another day. And the main benefit of the costa
00:27:27.360 thing is basically to take all these problems and delay them as late as possible. If we can take a problem that
00:27:34.880 in an earlier stage you had to learn about and you had to get good at figure out how to solve on day one and we can
00:27:41.679 push it to day 1000. Holy [ __ ] Major win. major comp compression in
00:27:47.279 complexity, right? The other part is that the reason I'm still here 22 years later is that omicasso also means like I
00:27:54.480 have really strong opinions about how things should be built and they happen to be the default in Rails
00:28:00.480 and that's why I'm still interested, right? Like for me a big part of it is an expression of I care about 10,000
00:28:07.679 different things and like I care about like lighting it up like no that's not
00:28:12.799 right. There we go. Now it's right right like that level of sort of detailoriented
00:28:19.120 then there's a bunch of things I also don't care about and there's tons of other people in the community who care
00:28:24.159 greatly about and then we can take all these things I take my 10,000 things that I care about and then there's another 10 million things to care about
00:28:30.720 that everyone else have contributed their opinion on because they have expertise and they have insight into it and I just go like yeah that sounds
00:28:36.880 great you sound like a competent person the code looks correct congratulation you now own that part of the code Aaron
00:28:43.520 Um, and that's how we can sort of distribute this kind of stuff in in a way that
00:28:49.039 works and we can get buy in and all these other things. But I think there's a symbiosis, there's a harmony here where people starting out um, they don't
00:28:56.559 have to even know what to care about. There there's no paradox of choice. And I think that's actually an obligation as
00:29:03.039 full stack framework developers is to ensure that whatever choices someone
00:29:08.159 would want to make, that's a day later problem. No choices on day one.
00:29:14.159 Everything has a default and the default is good. You don't have to change anything. You may want to someday down
00:29:20.480 the line when you really care about it or you hit an edge problem or you're at the frontier or you just develop a
00:29:26.640 sensibility that's different from what I have or what Aaron has or whoever else has put their mark on the framework. But
00:29:33.200 you don't have to do it up front. And I think that remains perhaps the most heretical part of the Rails framework.
00:29:40.080 The part that has never not never but increasingly less been copied. I thought
00:29:46.480 in 2004 when I pushed out Rails like all right set your clock we got 18 months everyone is going to have full stack
00:29:52.640 frameworks everyone is going to do a masa menus and then we got a little bit of it we got jangko like yep it's coming
00:29:58.399 and then it just stopped it seemingly the entire industry lost interest in solving complete problems and started
00:30:04.000 focusing on narrow little subsections and went like oh I have a new rendering framework and how you fit that in with
00:30:10.559 everything else well that's your [ __ ] problem right like that's what basically the JavaScript world is that's your
00:30:15.919 [ __ ] problem. That sort of sums up the tagline of trying to piece everything together peacemeal by peace
00:30:21.840 meal. That's your [ __ ] problem. Um I think uh you you touched on
00:30:27.679 something about wanting to make sure that you can delay as long as possible,
00:30:32.960 like day a thousand or whatever. Um I I'm curious because you've said in the
00:30:38.640 past that uh you thought that you would have these problems at 37 signals. The one that comes to mind is like database
00:30:44.960 sharding, but then you would just keep getting bailed out because chips would be fast, storage would be like you could
00:30:50.399 always scale and you just kept getting bailed out. Um, maybe we can transition a little bit and talk about like near future stuff.
00:30:57.120 Is there anything that you think of that you you think like might be something that you're bailed
00:31:03.600 out on next? I mean, first of all, I love getting bailed out when you get to get other people to solve your problems for you.
00:31:09.840 It's amazing. I highly recommend it. um you should try to take as many of your problems and give them to someone else
00:31:15.039 who would like to solve them for you. That is a wonderful strategy. Um for us, I think this the database sharding one
00:31:21.600 is amazing because I think we started thinking about charting as a probable
00:31:27.760 event in event. What is that word? Inevitability is what I'm trying to say. in like 2008 seven
00:31:34.960 maybe we were like oh my god if like we keep growing the database and then this is how big this thing we're going to run
00:31:40.399 out of what a single database can do and it never happened like we ended up moving single tables up but we never had
00:31:46.640 to do the full classic sharding different clients on different databases and so forth and now it's never going to
00:31:54.240 happen literally never I don't have any problems any applications where I ever think that I actually have to do
00:32:00.880 sharding Because storage is getting faster at an insane rate. We went from
00:32:07.200 uh NVME drives have literally doubled their throughput performance every
00:32:12.320 generation. Like 3 to four went from whatever 2 GB a second to 5 GB a second
00:32:18.320 and now we just jumped again to 10 gigabytes a second. Like 10 gigabytes a second. Like that's I'm never going to
00:32:23.840 get close to that. Like it's so far out of the kind of problems that I deal with. So I absolutely love that. in
00:32:29.679 terms of sort of bailing out. Um, I have this evergreen vision that I want to be
00:32:35.440 able to run every single application we have for all the customers that we have on a single computer I can hold in my
00:32:42.080 hand and like that's where I want to get bailed out. I want to take all the whole data center and everything, boil it down
00:32:48.000 into one computer. And you know what? If the business I had was maybe a little
00:32:53.279 smaller, I can I can squint and I can see the future. I can squint and I can see that that could be possible. The
00:32:59.200 power of a single mini PC server today is way larger than the data center
00:33:06.399 installation we had in let's say 2008 when Basecam was doing many millions in
00:33:12.880 ARR right like I can actually squint and see the future like you know what we're going to be able to do it we're going to
00:33:18.880 be able to take the entire data center and we're going to boil it down to one box and I actually think that reality has already happened for probably like
00:33:25.519 96% of all web apps could run on a single single goddamn computer. Then there's 5% that has more needs and there
00:33:31.760 are other reasons why you wouldn't want it on a single computer and redundancy and blah blah blah. But the compression of complexity that happens when you take
00:33:38.480 a distributed system and you turn it into a not distributed system is probably the greatest single compression
00:33:45.840 of complexity we have in computing. When you can translate distributed system
00:33:50.880 multiple interrelated stuff network calls into IPC calls into method calls
00:33:59.279 that's like orders of magnitude of comp complexity that just disappears right
00:34:04.880 networks are fallible things they break they disconnect they do all sorts of stuff and error handling has to happen
00:34:11.440 that does not have to happen when you call a method on a Ruby object right if the process is running that method call
00:34:18.079 is going to go through. You're not going to be like, did it go through? What's the latency on my method call? Right? None of that has to happen. So, I think
00:34:24.720 that kind of compression of complexity is the end game. How do we reduce every single system we have to one computer
00:34:31.679 running it all? I think uh one thing that's interesting about that is I know for a lot of the
00:34:38.399 once products, you're using SQLite uh and you're doing that because you have
00:34:44.000 to deploy, you have to let somebody else install it. And the easiest way to do that is SQLite. Um,
00:34:49.520 I'd actually say slightly different. That is the outcome. Like that's what we're trying to do. But the reason I do
00:34:54.560 it is for the comp compression of complexity. What's better than like having a process that runs a database
00:35:00.400 separately from your whole thing is not having that. It's having a [ __ ] file. Like a SQLite is a file. Well,
00:35:06.079 technically now it's three files. Let's be honest. There's a wall. There's a bunch of stuff, right? But like in theory, there's just a couple of files
00:35:12.880 and then there's your app talking to those files. That's an enormously wonderful reduction of complexity. You
00:35:19.119 take a whole system that you used to run and configure and be an expert in, right? How do you operate this MySQL
00:35:26.079 thing or this Postgress thing like it just goes poof doesn't exist anymore. Now there's just a file, right? We did
00:35:32.400 the same thing. Um Ros's wonderful work on solid Q was exactly in that service.
00:35:37.920 How do we take the fact that we used to run Reddus, we need to run Reddus in order to do job handling. What if we
00:35:44.079 could just delete delete reddus? Now there's a whole class of operational concerns and keeping things in sync that
00:35:50.640 just goes away. You just have the database and then you take the database and like you throw away the database and
00:35:55.680 you're left with files. You're like, I like where this is going. I like where this is going. We're really just going
00:36:00.800 like boop boop boop boop down the ladder of complexity and we end up with a handful of files. And how can we do
00:36:06.160 that? We can do that because computers are getting faster. Because SQLite is a modern wonder of the world, like
00:36:12.160 literally deployed to billions of devices and has been around since the early 2000s and is incredible. And some
00:36:19.280 of it is that like we're just realizing things that have been true for a while, but we haven't internalized. I I love
00:36:25.680 those things. I love this and I talked about it at the Rails World keynote that Reddus is a product of 2009.
00:36:33.680 Reddus is a product of I need to store things in RAM because spinning this piece of metal around until it hits this
00:36:40.800 little drive head that can read a bite off it is really slow. It's really slow.
00:36:47.440 You take that and replace it with essentially another type of RAM NVMe and suddenly all the solutions we were
00:36:53.920 devising to deal with the spinning disc, they don't make sense anymore. Like oh I just I don't even need that. And then we
00:37:00.800 can go like all right delete. And you know what? If there's one thing I love, it's [ __ ] the leading lines of code.
00:37:06.560 It's the leading lines in my infrastructure. It's the leading services I need to run. It's the leading
00:37:12.640 just complexity. And go, do you know what? This is what the future's supposed to be. The future's not supposed to be.
00:37:19.119 We went from 1 second changes and deployments to 15minute monstrosities.
00:37:24.240 The future supposed to be I needed to run five computers in the past. I needed
00:37:29.599 to manage a MySQL database. I needed to have a Reddis instance and figure that stuff out. And now I just have one
00:37:35.599 computer writing to three files. Life is good. I think one one thing here if we can get
00:37:42.160 to things that run on a single chip. Um this is just sort of a bit of personal
00:37:47.200 lore, I guess. I've been like recently trying to like exit the cloud personally. So like putting photos on
00:37:53.359 like a network uh drive. But I'm I'm curious if if we can get to a point
00:37:58.480 where you could build Rails apps that are just running on something on something in your house and are backed
00:38:06.320 by SQLite and then maybe those things can talk to each other. Like that seems
00:38:11.520 like an interesting world. I don't know if it's one we want to actually be in, but it seems like an interesting possibility or an interesting
00:38:16.800 I think it's deeply interesting and I think it's deeply appealing and I think a lot of folks who did not give two
00:38:22.079 hoops about things like data sovereignty and so forth, especially if they're from Europe suddenly care a lot about digital
00:38:28.720 sovereignty, suddenly care a lot about who owns the data and who can turn off the power, right? These are suddenly real concerns
00:38:35.839 in a concrete way that it seemed like it was just nutty people talking about abstract goals like 5 minutes ago. I can
00:38:43.280 tell you I've testified for Danish Parliament. The Danish politicians care very much about where their applications
00:38:49.119 that run the [ __ ] country are and who gets to have the onoff switch, right?
00:38:54.480 like that is a critical concern that I think actually is going to motivate folks to look into new architectures and
00:39:02.000 that's really exciting because I think it was already all here. All we were lacking was the motivation and I think
00:39:09.040 that motivation is super interesting. I'd actually go as so far as to say like this is the part of the puzzle, the pie,
00:39:14.720 the deployment that I care most about pushing these things further out. Obviously, we left the cloud um two
00:39:20.960 years ago with uh compute and we've just left the cloud with with file storage. We literally moved out of AWSS3
00:39:28.480 um four days ago, I think 5 days ago. We deleted the last bucket. That was like uh whatever 10 pabytes worth of data
00:39:35.760 distributed all over AWS's different stuff. And now we host it on our own hardware. Um granted a little more than
00:39:41.680 the computer. It doesn't quite fit into a single box yet, but that is there. And
00:39:48.000 like I can see the straight line from where we are now to that holy land. And it feels pretty exciting. And I feel
00:39:54.640 like it feels like there's a mission here to accomplish the ethos of the original design of the internet. This is
00:40:00.880 something I've talked about a lot about that the DARPA design for the internet was okay,
00:40:06.640 New York is taken out or Langley is taken out by a nuclear bomb. How do we
00:40:12.240 still operate an information system where Seattle is online? Right? like we don't have a single hub that control
00:40:18.560 everything. And we took that beautiful, incredible design and we traded it for a
00:40:24.640 bit of convenience and put everything into US East one. What the [ __ ]
00:40:31.920 And I mean the funny thing here is it's not even a theoretical concern. US East one was literally just down when was
00:40:37.760 that? A month ago. And a third of the internet went dark. I think it was an
00:40:43.119 interaction between US East1 and some Cloudflare stuff. But whatever it was, it was centralization,
00:40:48.560 right? We kept on trucking, right? We were out of that [ __ ] Like Basec Camp was up. So was a lot of other things.
00:40:55.280 But the fact that one provider can take down a third of the internet is an absolute perversion of DARPA's genius.
00:41:03.599 And I think we got to get out of that. We got to get back to an idea where we have an actually distributed network
00:41:09.920 where single nodes can go offline where entire countries can go offline and it
00:41:15.040 doesn't affect the rest of the world. And I think that's a mission very much worth dedicating my time to. Awesome. I Yeah, I think I think
00:41:21.839 resiliency and just kind of like uh for for me it's it's been about just like I
00:41:27.440 want to have my own stuff on my own network. Um, I want to shift gears though because there is kind of a a a
00:41:34.079 big elephant in the tech world right now. Uh, so I thought maybe we could spend a little bit of time talking about
00:41:39.200 AI. Um, I'm curious how you see AI fitting into Rails
00:41:44.480 development. Um, and for Rails developers and people here who might be using these tools, like how do you think
00:41:50.800 we should be using them? How do you think we should be working on? I think AI is beyond this mission I just talked
00:41:56.640 about probably the most exciting and interesting thing that's happening in technology right now. And I say that
00:42:02.960 while half the time swearing at how goddamn stupid chatbt can be, right?
00:42:08.240 Like how much it still hallucinates config options on Unix tools that don't exist that it would like to exist. I
00:42:15.359 actually appreciate it a little bit because when it hallucinates a a config variable, it's like, yeah, that should
00:42:21.359 T-Mox should do that. Why doesn't it take like a config like that? Can you also just patch the code and upload it
00:42:28.480 and release it and then I can install it? That'd be great. But right now, it doesn't do those things, right? So, we
00:42:33.760 exist in this magical moment in time where I think anyone who's actually used AI, at least a little bit, have at one
00:42:41.359 point or another been, "God damn, that's impressive. I I you're very different
00:42:46.960 kind of human than me if you have not experienced a how does it do that moment
00:42:52.000 with AI but then you're also perhaps not a very experienced programmer if you're not experienced how can it be so dumb so
00:42:58.720 stupid and who are these people who are telling us that all programmers are going to be out of a job at by the end of the year have they seen the code
00:43:06.319 like do they know what it produces do you know where it ends up if you just ask it like build the system for me and
00:43:11.839 you go like oh yike Like that's just these two things exist
00:43:18.319 at the same time like this extreme optimism and excitement for real advantage real productivity games that
00:43:26.160 are here right now. I would probably not have done a bunch of the Linux work that I've done recently if I hadn't had AI to
00:43:33.119 speed it up because I would have gotten too frustrated trying to find some hyperland configuration object four
00:43:40.640 layers deep in some esoteric forum on Tumblr, right? Like that just that's not
00:43:45.680 a pleasant experience and AI makes that way more pleasant to figure out. like finding the clues on what's wrong with
00:43:51.839 your system and how to set it up and so forth. is really nice and I'm imagining that that's basically I mean I haven't
00:43:57.680 learned actually I shouldn't even imagine that I learned bash recently because I've been building all this uh
00:44:03.359 this uh Linux stuff and you know what I knew bash because anyone has used bash but I didn't know no bash right like I
00:44:08.880 didn't have I hadn't actually built a ton of bash scripts and now I had to build up a ton of bash scripts and I I
00:44:14.400 learned it with AI I kept asking it like here's the Ruby I would have written what does that look like in bash and
00:44:19.760 then I went like oh my god take it away But then I I still internalized what
00:44:24.960 what just an if statement in bash looks like and why all these semicolons are in the weirdest places and where the do
00:44:30.240 comes after the semicolon. Like why? But I learned it and I learned it faster I
00:44:35.599 think um than I would have otherwise. But it doesn't solve full systems and we
00:44:42.000 don't know what it's going to solve. Right. Is it actually going to come to this problem? They keep like oh yeah in
00:44:47.200 like six months that's what's left. Right. Yeah. They also said that 12 months ago and 18 months ago and I think
00:44:52.319 24 months ago, right? There's there's a lot of things that are very hard to divorce from the fact that if you hype your AI startup to the hilt, you might
00:44:59.119 raise $100 billion. I guess that's a pretty compelling reason to lie the [ __ ] out of your teeth, right? You're like,
00:45:05.200 if I just like am a little more optimistic, I get a hundred billion dollars. I mean, we're all weak in the
00:45:11.920 moment here, right? Like I can understand the incentives to be delusional to the point of almost being
00:45:18.000 a fraud while there's something real, right? Like can these things be true at
00:45:23.599 the same time? Of course they can be true at the same time. Do we know what it's going to look like in a year? No, we don't. Strap in, enjoy the ride, and
00:45:30.560 be amazed that we're making freaking sand do this.
00:45:35.680 Like we're we're these silicon chips. Sometimes I'm like I don't know if you've used the the thinking model like
00:45:41.359 the deepseek where it shows you the how it's thinking and like I keep wanting to like pull back the
00:45:46.720 curtain like there's got to be a human back here somewhere like this is eerily similar to how I would think about a
00:45:53.520 problem how I would break it down and it's not at all clear like what is this is this just a fancy stochastic token
00:46:02.720 guessing machine or is this actually an insight into how human brains work? Am I token completing with you right now?
00:46:09.599 Right? Am I just going like what's the next token in the line? I don't know. Maybe it's entirely possible that this
00:46:15.760 is actually an explanation for human intelligence and we just don't know it. And I love that uncertainty. Like how
00:46:21.119 often are you blessed with that moment where you don't know what it's going to be? Like the internet for me when that came out and I got onto it like 95 felt
00:46:28.240 a little like that. There were folks in 95 who went like I think Paul Krugman from the New York Times famously said
00:46:34.800 that in I think 96 in 18 months this internet thing is going to be over. It's just a fancy fax machine, right? And
00:46:41.599 you're like that's actually kind of funny to say the internet is a fancy fax machine. There's a little bit of truth in that but obvious delusional, right?
00:46:48.160 Like the internet literally rewrote society. Is this is this that or is this like I
00:46:54.880 don't know the QC cat or one of these other things that have gone through time that like didn't end up mattering the se
00:47:00.480 the what was it called the segway is that what it's called the the thing that was going to rewrite cities right like like now you look at those early clips
00:47:07.920 from 60 Minutes and just laugh your ass off that like you thought I was gonna you look like an idiot with my little
00:47:13.520 helmet and look no one's gonna want to do that right but then the AI thing like
00:47:19.359 you know what it could be the internet it really Yeah, I think one of the things we were talking about uh just before coming on stage is that uh there like we don't
00:47:27.280 know where we're going, but I think that there's like a fear that it's just going to replace work, but I think like your
00:47:35.359 your view is not that that's what's going to happen. It's going to change things or we don't know like what
00:47:40.400 I my view is we don't know. And do you know what? It's actually almost pointless to guess. This could be like
00:47:46.240 the industrial revolution and we go from 97% of folks working in the fields to 2%
00:47:52.000 of folks working in the field to feed us all. That's possible. Does anyone have any nostalgia for going back with like a
00:47:58.960 horse and a hatchet and plowing the ground by hand to just produce a lot of jobs? I don't think so. Any of you want
00:48:06.000 to go back to the assembly line and like put things together? I don't think so. Right. So sometimes maybe
00:48:13.920 to a future us, we're gonna look back like you were putting code together by hand like a little robot. Like that's
00:48:20.240 really cute. Um I sort of hope not because I really like
00:48:25.280 programming. Yeah. And I think like you know what, even if programming stops being an economically viable activity, like I'm going to be
00:48:31.040 like the saddle maker. Like I I know we don't use these horses for transportation anymore, but like I
00:48:36.319 really like saddles, so I'm going to continue making them. But we don't freaking know. It could also be like the ATM. So when the ATM came out, the
00:48:43.680 automatic telling machine, everyone's like, "Oh my god, this is the death of the bank teller." And what happened instead was the number of branches that
00:48:51.200 each bank had absolutely exploded and more people end up as bank tellers than before the ATM, right? Sometimes there's
00:48:58.000 I forget what there's some law that basically says as you lower the cost of something, you get more usage of it.
00:49:03.839 It's entirely possible as individual programmers become more productive with AI more people want more programs
00:49:10.559 because the price of those programs go down and we actually increase the number of programmers who are who are working right now. What is that job? Is the job
00:49:19.200 prompt engineer? I don't know maybe then I am going to stick to my saddles or potato farming or
00:49:25.680 something else. I don't know if that's what I want to do. But it is entirely possible that we just we have more
00:49:30.960 programmers, prompt engineers, whatever you want to call it going forward. We just don't know. And isn't that amazing?
00:49:36.319 Like we got all these smart people in the entire world trying to figure this question out and no one has the [ __ ] answer. Love it.
00:49:42.559 Yeah. I think there's a an an element of the just kind of like the uncertainty of
00:49:48.559 it. That's you know, you kind of have to lean into it. you you just sort of have to uh eventually get there, you know,
00:49:55.839 like and also be thankful you're alive at this moment. Like there's been
00:50:02.480 thousands of people before you, there'll be thousands of people after you. This may be the singular moment. This may be the singularity. Like you were there.
00:50:09.200 You were conscious at the moment where like Skynet booted up. Holy [ __ ] you're
00:50:16.400 going to be able to tell everyone about the campfire that like you were there before it all like you know that's what
00:50:23.680 a gift I I think I I think that there is I I really would be sad if I never got to
00:50:30.160 like if if like five years from now I'm not writing Ruby anymore and I'm just like talking to a computer. I think I
00:50:35.839 would be sad because I feel like we're giving the fun part of the job to the computer. I do agree with that but I also don't
00:50:40.880 think it's true, right? Like people still play the guitar even though they're better people than you to play
00:50:47.119 the guitar, right? Like the songs that you're playing, the vast majority of them have already been recorded by better musicians than you. And yet you
00:50:53.520 choose to play the guitar. Maybe we choose to still write a little Ruby just as a little bit of sort of hoppy
00:50:59.280 entertainment for ourselves. Um, entirely possible. But again, we don't know. So we might as well just choose
00:51:05.119 optimism, right? Because what the hell else are we going to do? like sit and just fear the future over in the corner.
00:51:12.000 That's a miserable way to live. Yeah. Okay. I have one uh final lightning round. So, uh there's a
00:51:18.480 there's a thing that was sort of a meme on the internet for a little while where you get you do a blind ranking of
00:51:23.760 things. So, I have five features of Rails. Uh you have to rank them one to
00:51:29.440 five, but you don't know what's coming next. Okay. And when you rank something, you can't taken that spot.
00:51:35.440 Yeah. You've taken that spot. So you can't rerank it. Go.
00:51:42.800 Okay. So the first one, prototype.js.
00:51:48.079 Yeah, that's going to be a five. Okay. Uh Okay. Let's do sprockets.
00:51:57.599 I like sprockets. Let's give it a three. Three. Okay. Uh how do you feel about dynamic finder methods?
00:52:04.400 Oh man, that's got to be a two. I still love them and they were murdered by someone who cared about performance or
00:52:09.839 something. And I'm like, no,
00:52:15.119 can't we just wait until computers bail us out? Aren't they getting faster all the time? I still miss dynamic find. I
00:52:21.040 You know what? I tried to write a dynamic finder not too long ago and I was like, "Holy [ __ ] it doesn't work anymore." No,
00:52:28.240 they took it away from me. We might bring it back. Computers are fast enough now.
00:52:33.599 Should we bring it going to get bailed out. What do you think? Let's bring dyninders back. It's happening. Rail 9. Here we
00:52:40.000 go. Okay. How do you feel? Where do you feel the asset pipeline, the original asset
00:52:46.800 pipeline goes on the list? Oh, I kind of feel like it's got to share a spot with sprockets, but if I
00:52:52.800 can't do that, um, [ __ ] now I can't rerank. Uh, I didn't use four, right?
00:52:58.000 You did not use four. Yeah, I like the original. I think we were actually real pioneers here. If I'm
00:53:03.119 going to pat ourselves on the back, we did bundling before the Java script folks woke up to bundling and we did it
00:53:09.280 for many of the same reasons just in advance. I think that was really cool. I think we're It is now like Yeah. No,
00:53:16.400 it's not great. But what kind of code you wrote 15 years ago is that great. So
00:53:21.920 just like introspect a little please. Yeah. Uh let's give it four. So uh are you
00:53:27.280 So now it's number one. It's got to be amazing. Better be amazing. Don't say active resource.
00:53:34.000 That's not that's not what I had written down, but now that you mention it, maybe. Uh, no, the last one was going to
00:53:39.359 be Rails plugins. The old Rails plug-in architecture from like the Rails 2 days.
00:53:48.640 So, that's coming back in Rails 9 too then, right? No.
00:53:55.119 Yeah. That's the problem with this game, isn't it? You don't know what comes last. I got I got roasted on that one. All
00:54:01.200 right, fair play. Yeah, do you know what? It's um I mean I love gems.
00:54:06.480 Um but I don't actually love plugins in the original conception of it. I like
00:54:12.000 library gems. I like other framework gems. I don't so much like the I'm going
00:54:17.680 to change Rails in that way gems. Um and I have never actually successfully made
00:54:23.760 sort of the sub project gems thing work. I know other people have. Um, we've done
00:54:29.680 things where we've embedded like login systems and so on that had full HTML and so forth and I've usually ended up
00:54:36.240 regretting it and just went, you know what, you can take dry too far and sometimes just [ __ ] copy the file,
00:54:42.800 right? like especially if it's a kind of easily datable asset type like an HTML
00:54:48.640 file where you may want to alter how something looks over time and then you realize it would have been a lot easier
00:54:55.119 if this code lived here and not inside some plugin that might be difficult to update because there's other five other
00:55:01.440 apps that I don't want to update the thing like that's actually a real example from signal ID that we have
00:55:06.800 which our login system we use across multiple apps and that experience of like you know what we have some apps
00:55:12.319 that we stopped working on 15 years ago. I still have to deal with that problem because I want to update the plugin
00:55:18.400 we're using in that plus the latest version of Base Camp and that kind of sucks. So, I've personally been burned by that to the degree that like
00:55:25.520 it burns that it's number one. But so goes the game. Okay. So, why don't we do this? I'll give you one
00:55:32.319 reorder. You get to move one, but you have to replace it with what you're Yeah. with another one
00:55:37.520 with what you're swapping. I mean, now dynamic finders have to be number one. Yeah. So, I mean, we just committed to it. It's
00:55:43.040 happening in Rails 9, so number one. Yes. Nice. Awesome. Uh, well, thank you so
00:55:49.680 much. Uh, and, uh, this has been a really fun conversation. Thank you everyone. Hopefully, we'll get to see you at the, uh, at the happy hour here
00:55:56.559 in just a couple minutes. Awesome. Thank you so much. This is really great.
00:56:02.079 Thank you.
Explore all talks recorded at RailsConf 2025
Ben Sheldon
Sam Poder
Rhiannon Payne
Joe Masilotti
Josh Puetz
Wade Winningham
Irina Nazarova
Tess Griffin
+77