Rails World 2025 Opening Keynote - David Heinemeier Hansson

I feel like I'm supposed to start with something upbeat. Like, Yeah, we're here in Amsterdam. It's amazing. But you know what? I'm not going to do that. I'm going to give it a little rant just at the start here instead, because I continue to be amazed by this curious paradox we find ourselves in our industry. In many ways, this is the best time it's ever been to be a software developer. There has never been more free, open source available. Computers have never been faster. Everything is supposed to be wonderful. So why is it sometimes that things don't feel quite as wonderful? Why is it sometimes that we can't recognize the progress we're all supposed to be enjoying and celebrating? Why is it, in fact, that many days we are frustrated by things going not not forward, but backwards. I think one of the reasons is that we've forgotten or pushed back the idea of figuring out what is the actual problem we're solving. We have slice so many of the big problems into tiny little problems, and then we work on that tiny little slice in our little isolated area, and we may make progress, we may make it better, but when you add all the slices up, we've actually gone backwards. It's a very curious phenomenon, and it's something that I've dedicated my career to and my work on rails to arresting. Thinking not of problems as tiny little slices that are isolated from each other, but thinking about the whole problem, all of web development. And as you'll see today, more than even that. Now, I've been around long enough in this industry to remember some of the things where we've gone backwards. When I got started in '99, we were editing the web application I was working on with PHP HTML in one CVS repository. And you know what? Somehow, we managed to ship great software that was used by lots of people on 1999 hardware, both on the development side of the machines. Today, it seems like everything needs everything all of the time with everyone involved to ship anything at all. What happened? How did we go from Big Dog to Little Dog? Even more curious to me is the deployment story. A single developer in 1999 could deploy a change to their web application in literally five seconds. I know because that's how I did it. I would drag my little file in my FTP manager to production and it would be live in five seconds. Today, This is actually wrong. It says, A 50 strong team in 2025 could deploy in 15 minutes. I've been talking to people for the last few days. No one's deploying in 15 minutes. They're deploying in 30 minutes, in an hour, in three hours, in eight days. Something has gone seriously, madly wrong when we have regressed from the ancient ways of deploying with FTP in five seconds to the modern world where it takes an hour. What the hell? The idea of how many moving parts and components we need to create our web applications today have also absolutely exploded. To do what exactly? Are we creating applications that are magically more wonderful than they were in 1999 using space-age technologies to accomplish glorious things? No, we're doing the same shit we always did. We're reading from a database and we're writing to a database. And then we're formatting that output, insert some HTML tables. Oh, yeah, we use CSS now. What wonderful progress. And in that complication and in all those moving parts, we have made things more brutal. We have gone backwards. It was very common in '99 to have three-nines of uptime. Today, it seems like people can barely manage that, even with all their Kubernetes, all their AWS, all their data dogging, all the everything, we aren't making things better. The common explanation for this is we're being conned by merchants of complexity. These devious companies who convince us to use their complicated tools and products, and somehow they just snooker us. We're really smart, and we wouldn't do that normally, but they're so devious. They're so clever. I wrote a blog post a little while back saying, You know what? I don't actually think that's the problem. I do think they're merchants of complexity. I do think most of the companies I mentioned before are merchants of complexity. Then they love to sell you complicated shit that makes the world go backwards. But you know what? The only reason they can sell that and grow so big is because you don't buy it. It takes someone to purchase from a merchant of a complexity for the merchant of a complexity to make any money at all, and they're making a lot of money. And why are they making all that money? It's because we have a psychological need to be seen as more than just crud monkeys. I'm a crud monkey. My career is crud monkeying. It is reading things from a database, creating records, updating those records, and occasionally deleting them. That's a very simple job at its essence. Using the web to do that job is a wonderful way of making a living. But you know what? It feels too simple. It doesn't feel computer sciencey enough. I have to employ my CS degree here, and now we need more complication. I actually think that's one of the root causes. We have to get back to embracing happily, proudly the monkey. And we are that monkey. And when we do, and we embrace the simplicity of the crud, we are free to begin solving problems end-to-end. And when we solve problems end-to-end, because we don't overcomplicate things, we can think about things at a higher level. Now, that doesn't mean paring everything back to the bone, because that's actually not end-to-end problem solving. Ruby and Rael, since the start, has been a mega framework. It has tried to do everything required for most people to create a web application with everything they need. And you know what? They need a lot of shit. This isn't about minimalism. In fact, in many ways, it's about maximalism. It's about solving all the little annoying problems that we all share when we're making web applications. And it takes a lot. It takes HTML templates, it takes database access and routing and sending emails and background jobs and all this stuff. I think this has fallen out of favor. And it's fallen out of favor from people who make these kinds of frameworks. The new frameworks you see announced every day, none of them are trying to do this. None of them are trying to address the whole problem. And if they are, it's because they just raised a Series A funding and just started a million projects. And well, good luck with that. But in the open-source world, world, I think we need to get back to solving full problems, as Rael has done since the beginning. And one way of thinking about this is the Roman Empire. I like to think not about the end of the Roman Empire, as the meme goes. I like to think about the height of the Roman Empire. And Paxraelsana is that height of the Roman Empire. That we have all these domains, all these provinces, and they're all working quite nicely. And the reason they are working quite nicely is because it's not just based on technology. It's not just a collection of frameworks. It's not just a collection of solutions. It is a philosophy of life. And that philosophy of life, I found, has given me the interest and the motivation and the ambition to keep going, to Keep expanding this glorious, peaceful empire further north, west, east, and south. And the way I think about that in the most glorious terms possible, libertas, proprietas, as Pietas. We have freedom to do whatever we want with this framework that we all share. It comes in a form of omikase, but you can change it however you want. It's just ruby code. You can literally do bundle open, see how everything works. And if you don't like it, you can just change it. Hell, you can monkey patch string to do something nutty. That degree of freedom to shoot yourself in a head is wonderful. I pride the fact that we use sharp tools in the rails community, and we are not afraid of our citizens. Proprietaires, we have full ownership of what we work on. No one is coming down to tell us that this is how it has to be done. This is how it has to work. There are suggestions. I will occasionally tell you that I think our specs syntax is ugly as sin, then you should stop using it. But you know what? You're free to ignore me, as many of you have done for many years, you bastard. And finally, pietas, duty. We are not just consumers of a framework. We're not just beneficiaries of some magic open source vendor in the sky AI dropping little packages on us and gifts. No, no. You're supposed to do your part for the empire. You're supposed to do your part for the framework. You're supposed to do your part for open source. So that's where I'm going to start. I'm going to start with my part, what I am doing for the Empire, what I am doing for the open source, what we have been doing in the past year at 37 Signals to bring gifts to all of you. And we will start Or we will commence in two ways. First, more. We will expand the borders of the Empire. We will conquer new territories, new problems, new provinces. And let's start with a little more. Little more is Markdown. Markdown is wonderful. It's a new lingua franca of AI. Ai It loves Markdown, and it also, for some curious reason, really loves emojis. Wonderful. Let's make it even easier for people to use Markdown in rails, to produce Markdown, to make that a common expectation. I've been writing a lot of Markdown recently. I've been writing a various manual for Linux adventures. It's all written in Markdown using a editor here we call House. I'll talk about that later. But that's the input part. And what I've found is we need to make all the stuff that we're making easier to consume by AI in a format that AI prefers, and AI prefers Markdown. So this is what it's going to look like in Rails 8. 1. When you want to do Markdown, you will simply do format. Md. You can do a render Markdown, and you could pass it any object, and we will try to duck type that object to call to Markdown. This is a PR that's still pending for writebook. I am going to ship this maybe during the conference such that you can download an entire writebook, the manual for a marchie or anything else as a single Markdown file, and it'll be running this exact code. But let's go up a little bit. We have a new text editor coming for Action Text. It's called Lexie, and the reason we need that might not come as any surprise for people who've been watching evolution of Trix, our current editor in ActionText. Trix has been a project that we at 37 Signals have been operating and using for many years. Didn't find a lot of people wanted to help us out improving that. So it ended up being just a project on the back burnerer... On the back burnerer of everything else we are making at 37 Signals, and it did not get a lot of love. So you know what? Sometimes you just got to accept when to throw in the towel, and we are throwing in the towel on Trix as the new default, and we will make Lexie, the new default editor in action text, and therefore in rails. And It looks like this, which is you have to squint to tell the difference from Trix, because Trix actually covered all the basics adequately. But we can cover it better than adequately. One example here for the Keynote server is that this It is a live view of the text editor that has live syntax highlighting. Live syntax highlighting for Ruby, live syntax highlighting for a lot of different languages. That is actually really nice when you are inserting code into your base camp or your other app that's using action text. What's also nice, following on the Markdown announcement, you can paste Markdown straight into this editor and it'll convert it to the busy wick and you'll be able to do that. You can get Markdown out as well, too. We're still working on this at 37 Signals. I actually just found a bug when I was recording this and I captured this. This is a screenshot from a new application we're working on 37 Signals called Fizy. We're We're using the lexy text editor in Fizzy, and it's pretty wonderful. But what is lexy? Lexy is a implementation or a use of lexical. Lexical is a text editing framework made by the fine folks at Meta. It powers WhatsApp and Instagram and Facebook, and about, I think they bragged, 1. 7 billion people every day use it. They have a team just doing that. Wonderful. Let's give some of our work and some of our load to other folks who are really motivated for it. And the people at Metta are very motivated to maintain lexical. Lexical powers webtext editing experience for hundreds of millions of users every day across Facebook, Messenger, WhatsApp, and Instagram. Love it. Love having an upgrade where we get all the benefits and someone else does the work. Or what I like to call performance optimization. Hello, Erin. But what about this guy? House. Last year, I talked about House, a new text editor for Markdown that we've been using actually in Writebook. And we tried to use House in two new products we were working on. One was fizzy and the other one hasn't been announced yet. And in both of those two cases, we found out that most people actually don't want Markdown. Markdown is a wonderful tool for developers. It's a wonderful tool for AI. And And a lot of people go, what's that hashtag again that you have to push to be the big headline? We switched over to lexical for both of those two products. House is probably not going to be something we're going to invest further into. We're going to move forward It's a little bit lexical. Another wonderful addition, the more we're adding here is action job continuations. It is a new way of structuring your jobs such that they can be interrupted and resumed without losing all progress. This was something we found was very needed at 37Signals when we moved out of the cloud, which we did a couple of years ago. We moved to Kamal, we moved to a setup wherever we deploy a new version of our We will shut down any container that's running with the old code within 30 seconds. Now, those 30 seconds are not very compatible. If you have a long job that's doing a big task, like exporting all of your base camp, that might take actually a few hours if you have a huge account. And being able to resume that in a step-by-step manner just means we're not throwing away work. It's a wonderful way of cutting these things up, making sure that all your jobs are resumable. Check that out. It's going to be in rails8. 1 as well. But those ideas are within the known borders of the empire. We also happen to border another empire, the empire of the native apps. And you know what? They're a little hostile over there, but we do have to trade with them. We cannot just seal off the border and pretend that the native frontier is there. We cannot pretend that you don't need native applications to make competitive competitive web applications. We found this to our slight surprise when we launched Hey about four years ago, and Apple unceremoniously tried to murder us. Now, thankfully, they were not successful, and I don't hold a grudge. I very, very much hold a grudge. We'll get back to that in a little bit. But grudge or no grudge. We still need to make native applications, and we need to make them better and better because that's what the competition is. And you can't just throw in your towel and fold your hand and pout and say, I don't want to, if you have a fucking business. And I happen to have a fucking business, and I'd like that fucking business to make some money. And that requires customers, and customers want native apps. So we suck it up and we do it. One of the things we've been building with since the start is hybrid applications, Hotwire native, everything And the first question anyone asks when they look at that and say, This looks amazing. But what if people need their travel email when they're on a plane and they don't have internet? What do they do then? You could build something. That's your problem. No, it's not. Everything has our problem. And if offline is the thing everyone needs, we should solve offline. So that's what we've been working on. Turbo offline is coming. We've We've been working on it for a while. This has been the work of Rosa working on it. We're going to tackle the problem. Yes. And the wonderful thing about solving it at this layer, solving it at the turbo layers, we don't just solve it for native, we actually solve it for all web applications wherever they're being used. And it's being solved in two steps. V1, which is shipping very shortly. It'll be a cache as you go. If you go to an email in, Hey, that email will be cached on that device and you can return to it without having a network connection. Step two will be cache, as I say, so you can preemptively cache certain pages like your travel folder without you having to visit individual emails. That's going to be awesome. Now, turbo is integrated into Hotwire Native, which is the all-encompassing framework for dealing with everything native on Hotwire. I'm going to talk Exactly zero about that because later today, we have the expert, Joe, in the last keynote of the day talking about Hotwire native 1. 3 that's shipping very shortly. It's going to be awesome. The other thing that's going to be awesome in the native frontier is finally solving push. Finally solving push notifications to native devices and more. This This was known as action notifier. When I was teasing it last year, action notifier morphed into action push. And today we actually have the first part of action push, the action push native part, because we needed to solve that equation very quickly because we are nuking our AWS account in just a few moments. And that required we stop using AWS Pinpoint to send out our native push notifications and switch to using directly notifications sent to Apple and sent to Google. Action Push Native does that for you, wraps it up beautifully, reduces all your push notifications to this lovely syntax. You create a new device with a new token that you will send to on a given platform that could be either be Apple or Google. And you can then design these or use these action push notifications, attaching metadata that's relevant either only on Apple devices or on Google devices and deliver those to the devices. You can even do things like silent notifications if your app depends on that for certain types of updates. It's really wonderful. This is the configuration schema for it. There's going to be a new config push YAML where you set things up for your Apple integration and your Google integration. You put in your keys and off you go. It's pretty awesome. And we've been using that in production for a few weeks after we did the cutover and it's sending, I don't know, I'm just going to make up a number, millions of notifications out already. It works really well. The other part of the equation is Web Push. I was super excited about Web Push when we launched Campfire a little while ago. Campfire has a native web app. It's not a native application you install through the app stores, but it uses all the latest and greatest native technology, including Web Push. And it works pretty well. It's not perfect. And that's one of the reasons why Action Push is not just Action Web Push. Native notifications still have some advantages. You can pull them back and deliverability is slightly improved. But if you're using Campfire during this conference and you're getting push notifications on your phone, it's coming through essentially Action Web Push. So That code looks something like this. This is code from inside of campfire. This is the action web push code inside of campfire. We have not yet extracted it. It's a little more cumbersome and a little more complicated to use than the native stuff. You have to do a little JavaScript dance to get the right keys and everything out. I'd very much like to see this extracted. I had meant to do the extraction, but you know what? I have a lot of shit on my plate, and therefore I'm going to do something even better. Instead, Instead of charging 2. 99 for campfire, we're going to give it away for free. Well, don't clap yet. Don't clap yet because free asterisk. I need actionweb push extracted. And one of you is going to do that. That's the deal. That's why you're getting it for free. We need this code out. Please go check it out. This URL is going to be active right after the keynote or shortly thereafter. We need this, extract it. I'd love for one of you to work on that. So that's a lot of more. That's a lot of more we're adding into the framework. There's a bunch of ideas here. Some of this is shipping already in rails 8. 1. Some of it is going to ship in the next version of rails. But to have a healthy empire, you need more. You need more territories, more conquest. And you also need to prune. You need to retract in certain areas. You need to realize where do we need less. Because this is the yin and yang of framework development. You can't just grow, grow, grow without also pruning away the dead branches and the dumb code. And we do have dumb code, and we do have dead ends, and we do have areas of the framework where things have evolved to a point where we don't need it anymore. Sometimes, because we simply realized we were wrong, other times, because the underlying technology moves forward. For many, many years, I use something called PUMA dev to run all our local development, and it was a whole dance of setting that up, and it didn't work very well on Linux. And then when I arrived on Linux, I said, What is this bullshit? And then I ripped it out and replaced it with the glory that is localhost. You don't need Puma dev. You don't need any process to run your local applications in rails. You just need localhost. And the reason you just need localhost is that in 2017, localhost was We made a secure context. There is no reason for you to run a SSL certificate locally during development if you run off localhost. I didn't know this. I found this out when I was annoyed by the fact that pumadev on Linux is six steps to set up, and they're all cumbersome and annoying, and I didn't want to do it. So I found out that localhost can actually do all this work. We don't need it at all. We just rip it out. And that's what we did at 37signals. This is what our development URLs now look What does it look like? They have explicit ports, which at first I thought, that's a little weird. And then I thought, no, it's fucking not. The port corresponds to a process running on my machine. So if I want to run base camp 3 plus launchpad plus Queen Bee, that is three different processes. They should each run on their own ports. And why can't we just make them explicit? Half the challenge of dealing with software is what is the problem? Is this worth A convoluted solution to get rid of these ports at the end. No, it's not. You could just write them down. Oh, yeah. 30, 10. That's the one for Queen Bee. So we just all use that. And then poof. Whole problem of how to boot up multiple local instances of your RLs applications, just go away. Wonderful. The other thing was that we, over several years, were toying with how to use Docker. Docker is incredible in a million ways and a total pain in the ass to use for development. That took us a little while to come to the realization that that pain in the ass didn't need to be there. We could get the best of Docker. What Docker does so exceptionally well is when you have services that are all-encompassing for the system, like running MySQL, and you need to run that in different versions because one of your apps needs 8. 0 another one needs 8. 04. It's really nice to be able to have multiple versions of that, and you can't do that if you install it natively. Now, that led to a realization for a lot of people, well, we should just do all our development inside of Docker. And then they ran into all the multiple problems there are with doing just that. You don't have to choose. We can just run native Ruby, which, by the way, now is managed beautifully by a project called Mees that makes it exceptionally easy to install different Rubies of different versions and keeping everything separately And you don't need Docker for that at all. But you still need Docker for your DBs. So that's what we did. We simply share a set of Docker DBs that are versioned such that if an app needs 8. 0, that's the process it It'll go to. That's the port it'll attempt running on. And if it needs 7. 1 of Redis, it'll do that. And if a different project needs something else, it'll do that. Really just solve the main hurt and the main problem we had with using Docker in development, isolated just for the databases. Even more consequential for us, an even bigger painful, I was about to say branch, but it actually almost feels like a broken tooth. Fucking system test. I stood up on a stage, not too dissimilar for this, 10 years ago and proudly declared that system tests were the future. System tests, in theory, are wonderful. You get to test everything end-to-end and flow through the browser and you test your HTML and test your back-end, and the shit doesn't work. It never worked. It never works. It's always briddle, it's always broken, it's always slow, and it's totally not worth it. That realization took even longer to arrive at than fumbling around with Docker. But finally, last year, we merged this pull request for Hey. Hey had a lot of system tests, and they took a long time to run, and develop developers were constantly battling how to make them stable, and we said, enough. What if we just nuke the whole thing from orbit? It's the only way to be sure, and leave only 10 system tests left as a smoke path of just does the whole thing work? Don't use it to test anything in-depth. And I've never heard of a single bug we pushed to production in hay that this shit would have caught. It was not worth it. Therefore, we are We're yanking the recommendation in rails 8. 1 that all new controllers should have system tests. We are no longer going to be generating them. The framework is still in there. I think it can make sense for smoke tests in a very small proportion, but for us, it was absolutely not worth the trade-off otherwise. And these are some of the realizations I think are really important to have, that you go in in a new domain, a new territory, and think, This is going to be great. And then when it's not great, you go back into the little hedge and say, System test? No. Speaking of tests, do you know what really pissed me off as we were getting out of the cloud? It was this fucking thing. The cloud test runner. This is I have a small text, so I'll read it for you. This was a test run on BCX, the second version of BaseCamp. They were still running a relatively small app, smaller than, hey, smaller than Base 3. It took 10 fucking minutes to run these, and it ran it in, let's see, Eight different paralyzed projects. They were all carefully set up on a cloud runner, and it took 10 minutes. Total pain in the ass, totally too long. But I didn't... What do you do? What But if we have a lot of tests. We have to run the test. We can't just kill all of them. Maybe we can kill the system test, but we're not going to kill everything. And then it was like, you know what? That made sense in 2019. We had Intel chips in our MacBooks, and they sucked. And they basically hadn't changed for six years because Intel just ran into the dirt and could not figure out how to get their new node out. You had all these cloud CPUs, AMD epis going awesome. Everything was great in the cloud. The development scene sucked. And then something magic happened. Tsmc, through the grace of Apple and others, really improved the chips we have in our local developer machines, to the point that the chips, the CPUs we now have are way better and way faster than the shit we rent in the cloud. Here's the Hey test suite. The base camp test suite, as I just showed, you have 13,000 assertions. The Hey test suite has 30,000 assertions. I saw a cloud run for the Hey test suite that took well over 15 minutes. You can't maybe read it, but you know what the fastest one is on the fastest AMD you can buy today? One minute, twelve seconds. Even on an Apple chip, an M4, it's under four minutes. This is totally doable to run locally for even a relatively large app like Hey. And many of you have smaller apps than that. And a few of you have much bigger apps than that, and none of this shit applies to you. You're not going to be able, sorry, to run the Shopify test suite locally. That's not happening tomorrow, but that's the 0. 001% of everyone making rails applications. The vast majority of you should be able to replicate these numbers and run your entire test suite locally. And if you do it on Linux, it's about twice as fast as doing it on a Mac. You got the M4 Max here, the fastest Apple machine I've tested, 2 minutes and 22 seconds. Right below it, you have 2 minutes and 5 seconds for my trusted Framework laptop. And then you have the Framework desktop at 2 minutes and 23 seconds. This is totally fast enough. You just run it locally and you can just blow up all that complexity of running cloud runners. Now, here comes the common objection. Well, if we allow developers to run things on their own machines, first of all, you're going to get, It works on my machine. Yeah. You think just because it fucking works in the cloud, that it, It works in the cloud, runner. That doesn't mean anything extra. What means extra is you pin down your dependencies, you pin down your versions. This is why we did the other stuff. We use the same version of the database, the Redis, the everything in Docker, and we can pin it exactly. We're not dependent on a random version in Home Brew to bail us out. We use Mies to pin exactly the version of Ruby that we're going to use. And between those two things, the Ruby version and the database versions, that's it. Any esoteric language or library you might find that isn't the exact version, it's not going to fucking do anything. We've been running this set up for quite a long time. We haven't had a single issue. And if you are, weigh it against the joy it would be to know whether your PR is ready for deployment in 1 minute and 12 seconds. Now, we actually do protect the PR, since they can't just be merged now that there's no Cloud Runner. We use a wonderful feature of GitHub where you can require sign off from a past test. You can install that with a tool that we have. And when you do, it requires a human to certify that they have signed off, that they ran the test and they all passed. This sounds like it shouldn't work because it sounds like it depends on trust. But you know what? Trust works. In most organizations, your employees are not shitheads. They're actually programmers who want to ship working software, and they know that if they lie on the attestation here, they will get fired. It's a really effective enforcement mechanism, I'll actually say. So not a problem. In Rails 8. 1, we have baked in a way to do all of this locally, not just a test. There's a brand new DSL for declaring your local CI run, where you can run your RoboCop, you can run your gym audit, and you can run all your tests, and you can do the sign off at the edge to clear the PR for merging. When we run this locally, it takes no time at all. Let's shift gears. All this benchmarking I did with different local computers around how fast they can run your local test and realizing why are we paying cloud providers to run slow tests when we can run them real fast with the machines we already have, reminded me of this. This is Fortnite. Fortnite has to render an entire scene of 3D graphics 120 times a second. They have eight milliseconds to render this fucking scene. And you're telling me it's got to take 15 minutes to pass some goddamn paper tests in the cloud? No, that's unreasonable. And when I thought about that, I thought, Do you know what? There's a lot of things that are really unreasonable. We are waiting way too damn long on way too many damn things. The example I gave at the start is a great illustration, FTP. We could deploy in five seconds. Now we're confident or content deploying in 15 minutes, half an hour, three hours, eight days. No, no, no. We're going to solve all this. We're going to apply engineering principles, and we're going to have a frame budget for everything. And where I'm going to start is we're going to have a bootstrap budget. The idea The idea that a new developer joining a new company should spend a few hours setting up their damn laptop is preposterous. At 37signals, this is our bootstrap budget. In 15 minutes, you should be able to go from cold machine that has nothing on it to having everything set up and a change deployed in production. That's our budget. To make that budget happen, I listened to Allan K. Isch. People who are really serious about software should make their own operating system. Let's do that. Let's make our own operating system. Let's do it right now. Let's see if we can be within budget. We have five minutes to set up Umechi from this little USB key on a brand new framework desktop. Here's the stopwatch. Let's go. I'm going to plug in the USB key. I can fiddle it in here. I'm going to turn on the machine and I'm going to start the stopwatch. Let's go. Now we're going to install Lomachi on a brand new framework desktop, as I said. There's nothing we're going to keep for it. We're just going to blow everything away. This is a project I have, I was about to say spent the last two months about. That's not true, obsessed the last two months about. Let my life be consumed entirely by a Linux God for the last two months as I've dived into the idea that it should not take hours to set up a new machine. And also, I should not have to ask Apple for fucking permission about anything at all. So we're going to set up this machine. I'm going to enter my username. I'm going to give it a quick password here. I don't need to enter the name or email address, the hostname. We just do Amachi. We are in Amsterdam. That's true. Everything looks good. And we're going to install it on the internal Nvme drive. Yeah, we're going to blow it away. Let's go. So as this thing is installing, let me tell you a little bit about Amachi. I switched to Linux about 18 months ago, and I did what everyone else does when they switched to Linux, I used Ubuntu. That is the most popular Linux distribution. It's really nice. Canonical did a great job at putting a Linux distribution together that will not be too foreign or too scary for someone moving over for a Mac. That's exactly what I needed at that time. Something vaguely familiar, but built on the underpinnings of Linux. And I had a really good time for about a year tinkering with that and changing things. And then I saw a YouTube video. And the bastard who made it and dragged me into this obsession is actually sitting right over there. It is Mr. Typecraft myself, who dragged me into the mysterious world of Linux, Ricing, and Tiling window managers, and Hyperland in particular. And what I found was like tumbling down the rabbit hole. What even is this place? What do you mean? I'm not using a mouse to move windows around anymore. What do you mean everything just resizes when I open things? And why does it look so good? Why does it look so magical? And why is everything a two-e? A terminal user interface? Wasn't that shit we gave up in the '80s? And then I thought, Oh, the '80s. I like the '80s. I remember the '80s. They were cool. I remember the '90s when I was on the Amiga and running a BBS, and we had cool Cool Asky graphics. Oh, like that. That's like the '90s. I remember BBSs. They were really fun. What if computers were fun again? Wouldn't that be great? Yes, It would be great. Computers should be fun. They should be cool. They should look a little bit like a hacker movie. That's actually an esthetic that's worth aspiring to. And what if we built an entire operating system in that image, in those cool vibes, in that cool esthetic? Oh, and also, build on fucking Linux, the operating system that runs 95% of every server in the world that drives the web. The system that has been optimized by a Finnish lunatic with a foul mouth for the last 34 years. Yeah, that's the system actually I would like to run. That guy is obsessed. And that obsession has produced the greatest largest open-source project of all time. Linux is truly amazing. I've been learning Linux for 30 years on the server, and I've totally been sleeping on the fact that you can actually run it on your computer, too, and it's gotten really damn good. Now, I know a lot of you out there tried some version of Linux at some time, and you couldn't get your fucking WiFi to work, or your printer wouldn't print, or any of the other anecdotes that everyone who's ever tried Linux in the last 30 years will have a roll of eggs of. Do you know what? First, I will say this. Almost all of it has been fixed. Do you know what? This is what happens if you just keep working on a problem for 34 fucking years. It ends up being really good in the end if you're that obsessed. We've seen it with Ruby. When I started using Ruby, it was version 168. Do you know how much faster, how much better, how much more featureful Ruby is today? Of course. Oh, shit. We're done? Are you kidding me? That's not even five minutes. That's four minutes and 44 seconds. And then I just got to unplug this thing. Whoa. That's pretty fast. Things get good if obsessed people keep working on them, especially open source, especially if you can gather up an entire community of people who are as interested as you are in making technology better. This is why open source is winning in every domain that we care about when it comes to rep development. Do you buy editors anymore? Do you buy databases? Do you buy web frameworks? No, you don't. You use open source ones that if they don't do what you like, you just fucking change them. Isn't that amazing? Oh, here's Amachi. Hello. Let's make a rails app. Because this, of course, has everything you need to make a damn rails app within the first five minutes of booting this ship. So we're going to hop in here, we're going to do Rails new blog. Of course, it's going to be a blog. Not a blog in 15 minutes, but a blog in five seconds. And when we start this, we also realized, you know what? That is still a little bit of work in progress. And if you run it on a low resolution screen like this, you're going to have to hop into a config file and change that a little bit. But does that matter? Are you afraid of a little config? No, you're not afraid of a little config. You're actually excited when you see NeoVim pop up and like, Oh, that's what all the cool kids use. Can I do it, too? Yes, you can. It's free. So we're going to do this. We now have our rails application here as a blog. We're going to generate R, by the way, because, of course, this has the aliases built in that I love to use just R, not rail, not bin rail, just R. R, generate scaffold, post, title string. We got that going. Then we need to migrate the database. And then we need to start it just on dev. And when we do this, we can hop over here. Oh, hello, rails. Hello, rails. Hello, rails. Hello, rails. Oh, isn't that nice? That's a nice air screen. And here's the real thing. Hello World with a brand new OS in about six and a half minutes. And not only just like Hello World, but fucking cool Hello World that could change it to green. What about that? Like, whoa, look at those windows. What if shit just looked so cool everywhere. What if you had a screen saver that was like the '90s? Wouldn't that be amazing? That is Omachi. I've been dedicating in the last two months on it. I'm going to make it the damn best way to develop Ruby on rails on it, and I hope you will give it a go. Check it out, even if you love your Mac. We actually have 200 USB keys with Omachi on it out at the Base Camp 37 Sequels booth. If you are serious about installing it. And before you get that key, it cost me $7. So I will look you straight in the eye and say, Are you going to actually install it? I'm not giving you a fucking souvenir here. So this is for people who actually want to install it, come out and see us at the booth. So let's get back to the presentation. Here are my backup slides in case the live demo blew up. It didn't, so we don't need them. Isn't that nice? I like when things work out. The great thing about making your own damn operating system is you can put in all the stuff you want. I'll give you just one quick example here. Omachi ships with Git, it ships with Mies, it ships with Docker, it ships with databases, it ships with everything a web developer would ever want. And let's dive into just one example of Git. So it ships with Lazy Git, which is an amazing twoy for managing your Git interactions. This is running inside of NeoVim, I used to use the GitHub desktop app. Nice app, not a TUI. This is much nicer, this is much quicker. I cannot believe that this project existed for years and I didn't use it. We set up common aliases like that R you saw. We can set up common aliases for all the Git operations. We can even preconfigure your username and your email address. It's your commit will actually work out of the box right away. We pick those out of the signup form. We can do everything. We can set up those aliases. As I said, we can have a nice Starship prompt out of the box that will tell you if you have any new files in the repo that are dirty and you need to check in. We can just do everything. We can do everything because it's ours, and we don't have to fucking beg Apple for a crumb. No, we can have a loaf of bread the size of your head. And then we can realize we don't have to stop there. After creating Omachi, I realized, actually, why isn't the entire Why are you set up of a new machine at 37 seconds exactly like this? It should be. So we've created a tailoring script that installs everything on the set up in just a few minutes, checks everything out, the developer is ready to use. As I said In that budget, we want to deploy in three minutes. That sounds crazy to a lot of people who might be spending hours, if not days. But here's a deploy of Fizzy, the new project we're working on. You can see it up in the corner, 58 seconds. We can make this so much faster, running local CI, deploying everything. Although I will say this is Base Camp 4. A few more servers. It takes about four minutes. I know, sad little dog. I'm a little ashamed of it, too. We will shave off that minute and get down to three minutes. I guarantee it. And we will get back to this. We will get back to a way of developing that feels way more like '99, that feels like it's free of needless complexity, and we will move much faster. And when we deploy things... Just a little aside here. I've gotten really into these little mini PCs. It's really amazing just how much performance you can crack into these boxes. These stacks here have 76 cores, and I think about 300 gigabytes of RAM. It's pretty cool. I took one of those boxes, and do you know what this campfire you guys have been using all week? Yeah, it runs in my closet. On literally that fucking machine. That's not a stock photo. That's me in my dirty utility closet taking a picture of the machine that runs campfire for everyone here and barely breaks a sweat. Oh, and it's 300 bucks. And do you know how much that would cost if I ran it in a cloud? Oh, here's a droplet. Oh, shit. That amount of performance would be 300 bucks a month. And I know really this is bad, and this is just in jest. I I know they're out there. Hi, Roku. This would cost upwards of 1,200 bucks a month to run this amount of performance that $300 runs in my closet. Do you know what? You can just do things. And this gave me an idea. And the idea was if this amount of performance is available to mere humans for hundreds of dollars, what could we do at an enterprise level? We've been running two main data centers for 37 Singles for many years, and we just created an out closed in Amsterdam. Actually in Amsterdam, right here. We have some hay servers standing right here. So if you're using hay in Amsterdam, it's going to be pretty fucking fast. But what if we went further? What if instead of having these mega data centers, we had micro data centers? What if it looked more like my utility closet than it did this big honking thing? So as I said a few times, we're working on a new product called Fizzy. And whenever I work on a new product, I want to push the boundaries. Sometimes that aligns very well with something that's good for the product. Other times, that's just hell of fun. And one of the boundaries I wanted to push was this idea that the Internet. The Internet just like, packages flying around the world and it's super fast because you know what? Packages over fiber, they fly at the speed of light. A little light bouncing inside of these glass cables, and it's about 300 million meters per second. Well, What was this math? I made this math like four days ago. The point of the math was, oh, the circumference of the Earth. The circumference of the Earth is 40 million meters. If you divide those two things, you have the theoretical time it takes for light to travel one time around the globe. It's 137 milliseconds. And that should be the theoretical boundaries for packages that they ship around. Well, it takes a little longer because not all the cables go straight around the Earth and not all the light goes in a straight line. It actually bounces inside of these cables. So when you actually measure it computer to computer, this is about how long it takes. New York to LA RTT is 70 milliseconds. If you get all the way from New York to Sydney, it's 220 to send one package and get a return. That's a lot of time. You guys have probably been looking at your performance charts for how long your X run times are. 220 milliseconds, for a lot of people, that's their budget, and you just blew it on a single fucking package. And you don't get to send one package. When you're making a POST request and it's the first one, first you got to do a TLS handshake. Oh, well, that's a package. And that's even highly optimized. It used to be like two or three packages. Now we got it down to one package, but 220 milliseconds. You post something to that, you get a response back with the location of where the browser should go to next. Oh, 220 milliseconds. You do a new get request to get to that location, 220 milliseconds. New York to Sydney on one post have spent almost 700 milliseconds just on the lag of light. If you do that experiment in other locations, if you do in New York to LA, it's still pretty damn meaningful because these are long distances. America is actually a pretty big country. There's like 210 milliseconds here of just light lag going back and forth between New York and LA. But I made some other tests, too. What if you move things a little closer? I'm in Copenhagen at the moment. When I ping my local Copenhagen website that is literally down the street, it's two milliseconds. That's pretty quick. Even when I travel the entire country, it's eight milliseconds. When I go to Falconstein, where Hertzner has a data center in Germany, it's 17 milliseconds. And when I go all the way here, it's 25 milliseconds. That's actually not that bad. And when we add that up, the lag of light on all of these connections is way less. 660 milliseconds from New York to Sydney, 6 milliseconds. If I could just stay inside of Copenhagen, that's a huge speed upgrade. Now, if you make an entire actual request here, you say your extra run time on the server for a post is 150 milliseconds, and you get 75 milliseconds, the entire operation of making that new post, New York to Sydney, is almost a second. Copenhagen to Copenhagen, 200 milliseconds, a little more than that. Do you know what else is about 200 milliseconds? A Formula One driver's reaction time when all the lights go out. That's what we should target. That should be the goal, that we do not exceed the Response time of a Formula One driver. How do we do that? We chased the white rabbit that the cloud industry has been chasing for a decade plus. Edge computing. And I saw a funny tweet this morning from at a level saying, Edge computing is all bullshit and no one has made it work yet. And you know what? I'm inclined to agree, but it also sounds like a fun challenge. If no one else could figure it out, let's figure it out. And the way we are going to try to figure it out with Fizzie is with this pattern of many small outposts. Essentially, the idea of the server in the closet being so cheap, couldn't we just have a lot of them? Yes, we could. But the first thing we need to do is we need to ensure that every data center we stand up does not need the entire beefy database that we need for every a single customer and running that for BaseCamber. Hey, that's what makes it expensive. It's actually the data, it's not the compute. Because once you start subdividing your users, you will have less need for a compute in that area, but you still need the whole database. No, what we need instead is for every database to store everything, all the data, but only serve a fraction of the queries. If we could do that, if we can accomplish that, we could have mini data centers everywhere. We could have these little drops everywhere if we didn't need all that complicated infrastructure. For Fizy, we could maybe have it everywhere here. And if we put Fizy in all of these cities I have on this list, almost all customers would be within 25 milliseconds of an outpost, and their response time would feel a lot faster. So to make that happen, we have moved heaven and Earth. The first piece of Earth we've moved is in a project called Active Record Teneting, because to make this whole setup work, we need to blow up the single build database for everyone and turn it into one database per customer so that we can put the database next to the customer or as close as we can to it. That has required an enormous amount of digging inside of the internals of active record and a million other frameworks. Mike has been working on this. We're going to push it out. There's been a few updates already resolved, but the fundamental idea is creating tenants, and tenants is one database to one customer and being able to flow all that through it. Not only does that have benefits for performance, it also has benefits for isolation, for backup, for privacy, for a million other reasons, and now you can place these databases around the world. But when you do and you place all these databases around the world, you need to sync them. That's the hard part. And to do that, we have spawned another project that Kevin has been working on and we'll be talking about later today, which is Beamer. And Beamer is a simple way of replicating SQL-like databases, which is what we're using for this project. You could use MySQL, too, but I I think SQLite is uniquely suited for the idea that every customer should have their own database. This setup keeps it in replication. If that sounds vaguely like LiteFS, it's because it is, but it's built for an entirely different on a different scale. It's built for tens of thousands of individual databases per customers. It's built for tens of thousands of transactions per second, because we're not just replicating one, two, or 100 databases, we're replicating one for every customer. And then finally, we need a way to route all of these things around the Internet so that people land on an outpost that's near them. We've extended Kamal proxy, adding in this geo component so that we can get a setup that looks like this that you might have databases in the US and you might have them in Europe. And if you're hitting a customer who's in the US on a get, you can either get routed based on geo routing to the app server in Copenhagen and the one in US East. That's all the readers. The readers are safe to access from anywhere, but we still have a dominant writer. That's the hard problem. We're not solving all of the distributed writers yet. But when you do that, you're redirected to the writer. To make all that happen, we need to go back to that magical year of 1999, where everyone knew everything and designed everything with perfect foresight for all of the Internet. This is from from RFC 2616 that defines the HTTP 1. 1 protocol. And what does it tell us? It tells us that get and head method should not have the significance of taking action other than retrieval. It's a really long way of saying, Don't fucking write when you're doing a get, that blows the whole thing up. So we are going to restrict all rights only to happen on posts and the other methods, we piggyback off post. And when you do that, you get the wisdom from 1999. Line forward, and you can make all this whole thing work. Finally, we use session affinity, of course, because if you do a write to a writer, you can get a stale read. If you're sent to a reader that doesn't yet have the updates, the standard way of doing this is just putting a finger in the air and saying, I think in a second, it's probably okay. That's a really poor way of doing it because it means when you write that comment, you're very often redirected to the read for that comment back on writer, which may be far from you. You want to get redirected onto the reader as soon as the reader is ready. If you run a really fast replication and you have this technique of doing it, you can do that. So instead of just taking a static number one second, we will boil it down to a transaction ID. And if that transaction ID, what we have written into the database, is available on the reader, we're good to go. And if we're not good to go, and the reader will know this, we will return a header that will redirect you to somewhere else. All right, that's our gift exchange. It's full of more. It's action, job continuations in rails 8. 1. It's action, native push out in beta right now. It's turbo offline, dropping very soon. It's hotwire native, 1. 3. Go see the keynote at the end of the day. It action text lexy, which is shipping today in beta. It's active record teneting that we still need to wrap up, so too with Beamer and Kamal geoProxy. It's less. It's the idea that you can just run native Ruby and Docker DBs. It's the fact that you can use local host for all your development. It's the realization that we no need system tests that we can run our testing locally, that we can do scripted setups, that we can have a new computer ready in 15 minutes, that we can deploy from local. That's a lot of stuff. Some of the good stuff is shipping in rails 8 Right now, after this keynote, that's Raphael. He's the release manager. He's going to push this out. I invite you to check out Omachi, check out Linux, update your quite possibly ancient ideas of what Linux is, works, or what it could look like. I invite all of us to do more end-to-end problem solving, to do more end-to-end open source, not to accept that there are parts of our stacks, whether it's the computer or the server or the framework, where we can't just change shit if we want to change it. We should be able to change everything. We should own everything because we want end-to-end freedom. We don't want people telling us what to do. I don't want people telling us what to do. I certainly don't want Apple telling me what to do or what I can do or where I can be or what I can't distribute. Fuck Apple. Before break, we'll be back at 11: 15. I want libertas, I want proprietas. I want pietas. I want freedom, ownership, and duty. And what you do with those virtues? Well, that's up to you, isn't it? Thank you so much.

At the Rails World 2025 Opening Keynote in Amsterdam, Ruby on Rails creator David Heinemeier Hansson announced Rails 8.1 beta, Active Job Continuations, Markdown Rendering, Local CI, Action Text Lexxy, Beamer, Active Record Tenating, Kamal Geo Proxy, booted up a new Framework laptop to install the Omarchy OS and launch a Rails app (all in 6 minutes), before closing with a call to fully own every part of your development workflow, end to end. #rubyonrails #rails #railsworld #webdev