0:11Well, welcome everybody. I feel like we're all having one big conversation.
0:16Uh, this has been a conference unlike any that I've ever been to. I feel like you can take the R, L, and S out of that leading word there because it's AI everything. Now, we're here to talk about uh shaping the future of Ruby and Rails. And uh David's keynote yesterday left a lot of things open. How are we shaping Ruby? How are we shaping Rails?
0:43And it was a bigger look at uh what the programming world as a whole is facing. And at these times, I keep hearing people ask about the future and wanting predictions. And it seems like at the time when the future is most uncertain is when people most want predictions and safety and a sense of what's next. So I feel like we can lead off from there given that we don't know still.
1:12What can we say? What do you see by the end of the year, by the end of next year? Start with you Matt.
1:22You know the everything changes so quickly in the last few years. So the it's and it's the we we cannot tell the you know direction. So the you know two years ago I cannot imagine I stopped using Emacs as a key code editor. I I still use emat though but like I use my whole my code is with my cloud code right now since uh last November or something and uh things were totally different from
2:03that that's quite you know challenging for me David, I think you're exactly right. What we're dealing with now is not certainty, but probabilities. And the probability I see is that by the end of the year, as I said yesterday, it won't be most people. It'll be virtually all people who are programming like mats through their agents.
2:30Now, I also understand why that feels quite uncertain. uh changing things up and mixing things up like that is uh a big wave and you don't know how to stand or where to stand to make it through that. But I think that's why we have a collective responsibility to lean in and help each other first get to acceptance. This is happening. None of us has the power even if we wanted to.
2:56We're speed running the stages of grief here.
2:58That is what's going on. And I know a lot of people have moved on from anger and are in some stage of bargaining with the future. It does not work. The AI will tell you and listen to you, but it will not change its trajectory. So the faster you get through the bargaining stage and uh hopefully a quick dash through depression and then on to acceptance is really the only path forward as I see it. And then once you
3:28get to acceptance, I hope you experience what I've experienced, what so many people have experienced, that the other side is amazing. It is wonderful and fun in all the ways that programming is wonderful and fun. That we make machines do new things. We have ideas and we see them come to life and with AI it just happens much much faster.
3:52Yeah. I think something that is particularly puzzling about this time is that people are having that experience, but they're also having the other one simultaneously of you get to use an agent and see things come to life. But there's also I mean I feel like a rubist. I feel like a Rails programmer and yet I haven't been in Vim writing Ruby code in months.
4:16And so where does where does my identity lie? And yesterday David asked for a show of hands about uh who's writing Ruby code but going to ask for another show of hands. Who feels like a Rubist?
4:34So we're in a different where do we where do we fall on this path when uh when identity in a sense can outlive our practice?
4:43When we call ourselves Rubious but we're not writing Ruby. what is what's the residue that's left behind you know even though the technology changed our life but uh I think now we can choose how we feel in our you know activities daily lives for example uh when the technology raised in the say 80 years ago the we they worry about
5:12that every you know the jobs are taken part uh taken away from humans and every you know manufacturing or something is done by the machines and then the they created the movie like a modern times by chaplain and then but things happen different way so that we reduce the burden of the manufacturing
5:42or we work different way from 100 years ago. That kind of things could happen in the next decade or so. And then probably our lives as a software maker would be different from the present time. But uh but still we can choose you know comfortable creation creative activity of software and then
6:17instead of the you know kicking out from the you know high high pay job or something like that. I think now is the time to choose the the direction our direction our how I feel and how how we behave with the AI.
6:35I think that really sums up the difference. I had a keynote some years back where I talked about the fact that I did not see myself as a software engineer. That was never an identity that fit on my shoulders. That sounded too serious, too rigorous. I saw myself as a software writer and have seen myself as a software writer for many years. So for the folks who were in that camp where the software engineering hat already didn't fit, I think you're much
7:04better positioned to adopt the new role of software maker that is a broader perspective. There are actually more things to consider, more things to learn than just to perfect a craft of handwriting code. And my big revelation is that it is more satisfying to be a software maker than merely a software writer. And I loved being a software writer. But the making part,
7:32the whole enchilada is just more satisfying. And I think our sensibilities as rubists is uniquely well tuned for this time. What is the human value we add when we're working with agents? It is taste.
7:53It's a sense of proportion. It's a sense of beauty. Everything we've cared about writing Ruby code, the abstraction of that is what's going to make a good software maker is going to make a good agent driver. So I see this as a cause for celebration that the class of Topcon here is so well positioned because this isn't about Rails. It's not even about Ruby. This is
8:22the part of the online discourse I find so puzzling as though this was somehow unique to our little community. What's happening? Are you blind? This is coming for everyone, for all domains, for all libraries, for all frameworks, for all languages. And there's a weird myopic focus on, oh, so Rust is the next thing.
8:45I don't give a about Rust. Like, I'm not opting in to be a Rust programmer because that role has been abstracted away from me. Rust is simply now the most efficient tool. And if tomorrow someone launches a better Rust, I will switch over with none of the grief that is currently being experienced in this room for the Ruby stuff because I will have no ego
9:12invested at all in Rust. And I think it's entirely possible that quite soon rust is not even what we're using. We will go straight to assembler and the fact that it is not portable will not matter because we will simply write the machine code required for every platform we want to be on and by rust. So don't get attached to this idea that oh I have to jump over in another camp. The camps are gone.
9:43We're we're not building new ones. I'm going to touch on what might be optimal for agents a little bit later.
9:51Um, I I think you hit on a core anxiety when there's the pitch that if you feel the energy, it's out there and it's available, but if you're not feeling it inside, then there's a gulf between what could it's almost like what's expected of you and uh but I know anxiety and quailing against the uh the forces of nature that how can I stand up to this?
10:17Each individual needs to go through this experience themselves. It's like being told there's going to be a mass layoff and well if only you reskill you go to uh whatever uh you learn to code and now what? So when we say uh professional energized maker are people feeling that and people who felt it all all along already have that sensibility. So it's not a new thing but for people are being asked to adopt it
10:47that is a totally new discipline. Yes. And some of it simply requires the function of time to apply to the ego. This is why we have the five stages of grief to explain to people that it is not instant. It wasn't instant for me.
11:05Maybe I bet run through it a little quicker than most, but I still had to go through those stages. And I think that's perfectly fine. There should be room to be a little nostalgic about something you really liked before you're able to transition to something you may like better or not. Every single paradigm shift we've had in computers have left some people wishing it didn't happen. The internet was exactly the same way.
11:32Mobile was exactly the same way. There were people who simply didn't want to get on the train and stayed on the station. There's going to be room for that, too. Now, what strikes me here is that I got into Ruby with no interest in the economic value of it.
11:49Like I I liked Ruby because it was Ruby and it was fun to do and it was and the sense of uh when people in your example with portraits and where do people get redirected when you can no longer have the economic recognition of that talent and expertise? Well, what if you never needed it in the first place? Rubies perhaps is going back to its natural form.
12:12Yeah. Uh the unlike DHS, I have huge ego toward Ruby and you know my whole life is depend on it and so but uh but I think I am partially responsible for say global warming
12:40and consuming much much energy. And then in the AI is sort of you know purely economical in the financial uh aspect the Ruby is not the way of choice but we have hu huge momentum and inertia to for the huge Rails code base or Ruby code base so that the this year I'm started working on the
13:13alternative compiler of Ruby named Spinnel which is the compile Ruby program into uh native binary and uh it runs quite brilliantly fast and uh consume much less memory about um as we tried the realistic real world program runs in uh and
13:4120th of memory. So that maybe your real application consumed 100 megaby of memory. The spinel compiled applicative binary consumed 20 megabytes. So that that's what it's it's five uh 20 5 megabytes. I mean uh the you know I just started
14:09spinner in March so that it's it's only a baby but uh it's it has quite uh possibility and then maybe next time he would choose Ruby again and then compile to the native binary to create a back And
14:37Matt, I'd like to hear more about that because you've had the idea of spinel for for many years and u and you've worked on M Ruby for many years and each has a different kind of uh placement within the engineering and software development world.
14:54So you've had that mind of What does Ruby have to offer in case of M Ruby to an embedded environment or what does Ruby have to offer to humans and now spinel seems to be what does Ruby have to offer to agents?
15:10Um what makes Ruby Ruby? You take things away and is it still Ruby?
15:16Yeah, that's not the clearest of clear things, but I you know trial and errors to define what Ruby, what is not Ruby and the result is the Cub we have that almost everyone use and then but uh you know one size doesn't fit all. So the some people prefer Jub for the
15:43enterprise thing and then uh Ruby C Ruby is too big for the embedding micro devices and then or maybe uh Ruby itself is uh too slow for uh even with Jet compiler we uh recently provided. So the you know the kind of the performance subset of Ruby language uh can
16:11be compiled into the native binary and run brilliantly fast and then that means the at least right now only I can I can draw the line what what is Ruby and what is not.
16:28And thinking about the the role of of Ruby in things like Roundhouse, um if if not everybody knows about Roundhouse, it's a uh it's um a way of treating Ruby as kind of or a Ruby Rails application kind of like a conformance oracle that an agent can look to as a spec and then it'll generate either pure Ruby without Rails or other languages.
16:56Um is Ruby scaffolding there or is it a means of preserving Ruby or is it something that uh that would be a a single step and then you would set the Ruby application aside?
17:09uh you know people vise um the software creation has different aspect and then uh most probably I will uh foresee that most of the people focus on the you know the product directing product market managing and then but some people are very motivated to the know you know the coding side of the program so that that
17:37that would be at least as a as a you know career that would be taken that will be taken away from us in the quite uh near future but at the same time so that we are learn to focus on the solving our problems then and then and if
18:05in the past we like the ability, skill, experience to to provide create the you know solution but uh agents can help us now so that without enough knowledge but we can create we can create a solution anyway.
18:30uh that's the situation but still but still uh as far as I see the not everyone is a go is going uh not everyone is going to create the solution the most of us most of the human being are just waiting for solutions so in that cases the you know solution providers kind of the
18:59chosen wants like like we we here. So that the enhance your only we can do is to enhance your ability and uh provide a solution for the entire human being and then that's more important than uh providing specific technology and focusing on specific technology as DJ says but still but still uh Ruby's nice language
19:34and the favorite language of many people and the and Ruby itself motivate people and uh even in the AI age the motivation is the most important resource uh that can be provided by humans not only provided by humans not from AI.
19:57I think Ruby has a wonderful role to play in its return to form. I remember when I first learned Ruby, it was through articles in it e magazine by Dave Thomas and uh others who described concepts of code using Ruby and I thought they were writing pseudo code. I thought it was not executable, but it was. And I think as we move into this
20:25realm where we will not be writing the majority or most of any of the lines of code ourselves, we occasionally will want to understand the algorithm and we will want to understand how it works. And Ruby is the best programming language for explaining concepts. So if instead of Dave Thomas explaining concepts to me in it magazine, I now have an agent who will explain my Rust
20:53code to me in Ruby. That seems like an amazing return to form. The other thing I'd say is that I think most people have a difficult time with thinking beyond the fixed pie.
21:09And I think this is where some of the anxiety is coming from. They imagine that the world of the future will have the same number of applications that we do now. And then they imagine that we will need a lot fewer programmers to make those applications. And that's going to be true. The number of applications we have in the world today will require vastly vastly fewer programmers to maintain and evolve. But
21:35we can make more. We will make more. This is the whole exuberance of the moment is that we're making so much more software. Every single statistic you're looking at from GitHub and why it's falling over every 5 minutes is because there's an explosion of software creation. That's the bloom.
21:57That's the bloom. We will have so many more applications to tend to and we are going to need people to do that. So that's why I have this enormous optimism on behalf of programmers who accept the future and lean into their new role as software makers. We will be working on so much more stuff and that's exhilarating. It's good. It's job security.
22:23But it's not going to happen if you hold on to the pencil so tight that you can't imagine the calculator helping you out.
22:34It's interesting thinking back to the early 2000s and the rise of extreme programming and um and when having a a very fluent language was so worth the cost of the runtime cost of a language pald in comparison to the development costs and and the of course the price of changing a spec and having a tight development loop and introducing things like test-driven development uh
23:02and feel no small irony in where we sit now and what are the artifacts of our work. Is it markdown?
23:10Uh is it specs? Is it everything that came before extreme programming that we got rid of because of the negative characteristics of long cycle time and high cost are now zero cost. So are we back to big design upfront waterfall methodologies?
23:29I don't know. the the the specific concrete methodology is less important in these days because of the you know the code structure means less because we don't touch code anymore but uh now we have to you know formalize and uh learn we have something to formalize and
23:54learn for the uh the next few years is uh how to create the vision of the software, what the solution should be and determine what the solution should be and then what is and you know the manage AI to build up this uh build up the solution you know uh you
24:23all know the vibe coding and then the and then you you also heard uh that you know the B coding failure stories like you know it's okay to create the games like Tetris but uh once you try to create a realistic application the many of the many of the trial uh miserably falls failed and but uh
24:52you know in contrast the people around us around me like the Ruby committee just try to vive code uh in the tools like part part of the Ruby in in the Vive coding way and they surprisingly uh they have surprisingly high rate of success and then that that means that you know we some kind experienced the
25:18programmer know how to direct the uh software making or we know how to define uh the goal for the the agents. that kind of things can be you know uh we have to formalize them and teach to the next the following generations
25:42for uh of the software makers and then for example I am the leader of the Bible coding because since uh last 15 years I was b coding I been by coding because you know I'm a you know the leader of the Ruby Ruby develop
26:09core community and I asked uh committers about the okay how about having this feature and then organic intelligence the intelligence created software and I tested review that okay it's we going to merge
26:33And how about improving the garbage collector like this? And the committers come up with code. Okay, we have improved this much. Nice. That's how we work right now. Everyone has core committers around you. That that is that is how we work. That is how I from now on.
27:14Now, sometimes you get promoted into a job you don't want, but I think this promotion, if you give it five minutes, is going to be immensely satisfying because I've had exactly the same experience as Matt says that with Rails for many years, maybe decades. The first version of Rails, I wrote everything by myself. The second version, maybe half.
27:40And by the time we got to the sixth and the seventh, barely any at all. Just direction. Where do we want to go?
27:47What's good? What's in? What's out? That is what we now have all access to.
27:55What's also true is that the innovator's dilemma is usually describing what happens to incumbent businesses when new technology emerges. First, the new technology looks like a toy. It's not a threat. It can only handle the low-end stuff. Why would we care? We have the lion share of the market and we have the big customers and they don't care about toys. Anyone who was around when Ruby
28:23first rose to prominence will remember this story. It doesn't scale. Remember that. That's what people are saying now about AI. And they are wrong in exactly the same way as they were wrong about Ruby and Rails back in the beginning because not only does the vibe coding work, does it produce great outcomes, but it is improving at an absolutely astronomical rate. So whatever currently does not scale is going to scale in five minutes from
29:02now. That much is clear. So we have to be careful not to sit as the incumbents, not to scoff at the toys.
29:14Speaking of for a hot moment, they don't do what we want. They will. I hear echoes of this in uh of contempt for AI and calling things slop and um referring to things as meat proxies and and to what extent are these and they're evocative and they're they're often true in a in in some sense and to what extent do you think they are real diagnoses and uh to
29:44what extent are they cope?
29:52I don't know. I just don't know. I just hate prediction. I'm I'm not good at future prediction.
30:01This is why we have to deal in probabilities, not predictions, not certainties, but probabilities.
30:07And the probability is that this is cope. And the sooner you get rid of those crutches, the sooner you can run.
30:15And it is true that as we figure out how to use these system to the best of our abilities and the best of their abilities, we're going to have some suboptimal ways of doing it. And the meat proxy is one of them. If you're spending time copy and pasting between agents and error messages, you should consider just letting the agent read the error messages directly.
30:37Why are you in the loop? Why are you sitting there as a meat proxy? Get out of that role. It is unfulfilling and it is ineffective. So many things are like that when you get them off the ground. They're a little riggedy. They're not completely ironed out. We don't have a perfect process. We don't have perfect tooling.
30:57And we make do for a while, but we should have the ambition that we are aiming for something higher. So the meat proxy slur is just a temporary plank to get from A to B. The slop thing though is a cope of the highest order. The idea that agents cannot write original high quality code free of bugs is just at this point delusional. Far more
31:27delusional far more AI psychosis than the optimism about what they can do because it's a head in the sand. So the slop thing I think it's soon time to retire. Even the slop grenade is not long for this world.
31:45I think slop grenade gets it something that that slop doesn't because it's it's slop plus the delivery and that's when people feel like it's slop when it's being dumped on them. And it's like it's kind of like a not shipping all the way. I've got an idea or it's like getting a PR that uh hasn't been thought through and now it's your job to use your attention to work through it and understand it and the slop grenade then being that you've got
32:15to figure out whether this is worth shipping. So it's there's what's missing there. There's more than just writing the code. I don't mind slop grenades at all. I just look at them as suggestions and I don't have to catch. And if I do like the suggestion, my agent will pick the slop apart and return with a beautiful implementation.
32:38I vastly prefer pull requests and issued issues opened by agents. They are of higher quality than any average human has ever produced PRs and issues on any repo I have ever had the privilege of managing. Doesn't mean I have to take the implementation. In fact, it is even better because if you did not write the code, you will have no sense of loss when I flush it all and rewrite it.
33:07Well, I won't rewrite it. My agent will. But you're not attached to the lines of code anymore. That's a blessing. Much of the friction in open source communities of the past were people getting attached to lines of code because they happened to have put a lot of energy into writing those lines of code and it was hard to give them up when better lines of code came along. I've never had that problem.
33:31I don't think there's that many lines of code left in the Rails codebase that I personally wrote. Wonderful improvement, progress, better. I think this idea that we're no longer writing the code by hand allows more people to experience that an egoless production of lines of code and therefore an attachment only to ideas and better ideas and improvement.
34:06Yeah, I think uh we can handle the the massive you know pills and issues from the the with the help of AI. Uh for example, yesterday uh I woke up then got showered then checked my GitHub and then we we have uh zero issues and zero pull request for
34:30spin out the uh that's nice and I then I walk up and then walk to the to the venue here and have some kind of discussion and uh at the right before his keynote I got 20 issues, one per request in only one hour.
34:55And then then I pulled up my phone and asked open the the cloud app. Then I I asked the cloud to okay address these issues and then the pull request and uh at the end of the talk at keynote the the clo automatically solve the 12 issues. That's the way we do. That's the way we way way we create the software that everything has changed and we can handle the value from AI using AI.
35:36That gets to something else I was going to ask about as we've approached on these past nine months really um as folks have come to generally accept that well these models can produce great code and keep looking for the thing that they can't do and what's the what's the little gap that keeps shrinking as the human domain where we're always going to have some kind of superiority uh and and why even why even hold on to that in the first place. But one of them
36:03is the sense of having good judgment.
36:06Now when I see Claude handle all those issues and just loop through them and make the right calls like is that a limiting factor anymore?
36:16Are humans the ones who are exerting their good judgment or how much do we seed to the agents to decide?
36:25as much as their competence warrants.
36:28And their competence is measured in your trust that the last pull request was handled correctly, just like you would any human. I look at the agents and I look for the same signs I would as a programmer working for 37 Signals. Is this person ready for more responsibility?
36:48How often do I need to check in? And the more senior the agent or the employee becomes, the less I check in, the more I trust, the more I assume that they got it right, and the more I also accept that there's a risk that they won't. If I read every line of code, I'll know what each line of code does.
37:12If I stop reading the lines of code, I have to rely on the outputs and the trust. And occasionally, the agent will make a mistake. Who amongst us have not made one? Who amongst us have not written poor code with bugs that could be faster? All of us all of the time.
37:32Why do you have this bar that the new intelligence must be perfect and fault-free from day one? That's the AI psychosis. That's the AI delusion. This intelligence is improving rapidly, but it's not perfect yet. And neither are we. So what's the problem?
37:53There isn't any asymmetry in the standard. I mean similar to self-driving vehicles where any collision is too many and yet there are tens of thousands of collisions yearly but the humans in control. So is there something like that of the human in control, human at the wheel that's more excusable to generate faults and errors and bugs and be risky? In a society ruled by
38:18lawsuits, yes. In a sane society ruled by outcomes, no.
38:26There are different societies around the world that tackle this problem very differently. There are no personal injury lawsuits in Denmark. That's just not a category of work. It's not a category of law that has any impact on how decisions are made. those societies will do better because right now we are unfortunately faced with the problem of having superior driving technology that by the metrics I've seen is about eight
38:54times less likely to have a collision than the average human and yet go ah I don't know one collision is one too many 40 45,000 people die every year in the United States from traffic collisions if we could improve that right now and pull it down to an eighth, 30,000 people would be alive at the end of the year who otherwise won't be. That's not a sane society that chooses to ignore that.
39:29Yeah. Makes me think of other applications of these same things because this is not purely a programming phenomenon and people are looking to apply these same things in healthcare and engineering as a whole. Would you would you want uh an AI team designing a new bridge? I mean real engineering.
39:48Yeah. But uh I have one concern. Even if we create the software but using agents without knowing detail but uh the solution still rely on the existing software components like Rust compiler the Ruby on Rails or Ruby interpreter uh whatever Linux or the Apostl or and
40:17then the since we rely on more agents, uh the the other components will would become more and more transparent. And um even though those components mostly open source software are very important and viable uh in the society but uh they wouldn't see them and they wouldn't care them.
40:53The that is my biggest concern. the more components become transparent less uh society care about the the components and maintain sustainability uh that's that's my concern and I have to we have to work on sustaining those components including Ruby and Rails and Linux and
41:22the databases that makes me think about David, you're talking about the downsides of abstraction. At what point do we bypass those components and everybody kind of invents their own? And I think of things like we're we're talking about single libraries like why not uh you know bypass a websockets library and just implement the websockets protocol directly and and everybody I mean it's a
41:50it's a wide ecosystem of a bunch of different implementations evolving independently and with their own fitness functions that it needs to be able to interoperate And my engineering mind immediately goes, well, there are these clear downsides of like inefficiencies of scale of if there's a bug, then you could just fix it in one place instead of 100,000 places. But what do you think?
42:18This is the next frontier. Realizing that our abstractions in our own code bases are hindrances to concurrency and parallelism and so are our frameworks and our languages to some extent. And eventually we will reach the photon level, the physics directly. and that all our efforts over the past 60 years
42:47of software development have been to cope with the limits of human cognition. And if those limits no longer apply, neither do the solutions. And therefore, I can completely imagine that the future of software looks more like the vanguard of generative gameplay we have now. There are models able to generate game playing worlds on the fly right now.
43:14The idea that we could end up in a world where operating systems, device drivers, frameworks, languages are generated on the fly. seems science fiction at this moment, but so did the idea that these agents could write all our web applications for us and relieve us of the pencil very shortly ago. So I think we actually need more science fiction,
43:43more imaginative play because that's what's going to guide our imagination going forward. So much of our imagination today is anchored in things like 2001 of space odyssey. So much of our idea of the dangers of AI come from Hall 9000, come from the Terminator, come from science fiction written
44:10anywhere from 40 to 100 years ago. We need better science fiction for the moment because all of those tales have come true already to some degree and therefore uh we need new horizons to give us new inspiration for what a new era of computing can look like.
44:28Do you think there are are speed limits that we're immediately facing here when you talk about uh I mean say I want to bypass lib and just talk you know micro code to a CPU it's like that's going to take a lot more tokens like what what is that activating within a model like there are other kinds of efficiency barriers other than runtime efficiency uh development time efficiency we've squashed development time or the feedback loop the cost is near zero so
44:57we say Well, I don't have to pay the cost of uh any other whatever language affords me the uh high expressivity.
45:07So, let's choose Rust cuz it's going to squash runtime cost. But what about the cycle cost, the tokens being spent to represent reality and operate within it?
45:17I think we're dealing with the Commodore 64 right now. We have a 1 megahertz agent and next year we'll have one running 10 times as fast and the year after that 100 times as fast and humans are simply incapable of collectively understanding exponential growth. So all our concerns right now about token efficiency and token cost are relevant for this moment and you should pay attention or your
45:47token bill will explode. But that attention is a short-term consideration. Of course, this is going to get cheaper. Again, the degrowth doomer nonsense that we're about to get rockpulled by anthropic and open AI is just economically illiterate. Open weight models are already phenomenally good. There is competition.
46:13There's never been as much competition in a new field of computing as we have right now with AI. None of the earlier paradigm shifts had anything like this in terms of competition. When mobile came around, we got two players. We got Google, we got Apple. When desktop computing was divided, we had Windows, we had Apple. Now we have a million token providers. Maybe Anthropic and AI
46:42are in the lead, but their lead is measured in months, if not weeks. There's nothing to worry about, folks. It's going to get better. It's going to get cheaper. It's going to get greater. Matt's uh Indoan had this observation about Ruby being the most token efficient language some some months ago.
47:08Yeah. Several months ago, we the colleague of mine measured uh several language including the uh Ruby, Python, JavaScript and then TypeScript and and the Rust, Cotling, uh whatever go and then the interestingly the there are three language out of I don't remember I probably 13 languages uh three language
47:38out there is quite uh token efficiency and time efficiency and and the those language are Ruby, Python and JavaScript pure part JavaScript and then interestingly the static typing does not help the talking efficiency nor time efficiency.
48:03told you now to pair with that seeing that agents have the closest I could get is saying they have a good time with these token efficient languages they can get to the outcome they're looking for quickly and if I had any closer measure of agent happiness it would be that they had hill climbed their way yeah it's too strong uh assumption but uh I believe the you know The
48:32programming language next to human designed to be for the joy of programming. It probably the language is nice to uh AIS too.
48:47Android stream in Ruby.
48:51So the interesting thing there was that Chad Fowler did a a benchmark with a a bunch of representative tasks and Ruby was chosen in zero of them. And the thing most the things most commonly reached for were Python, JavaScript, etc. depending on kind of the class of problem and uh perhaps reflects pre-training of what they saw. So what they know is what they use. Uh how do you steer a model? Well, in the sense that we're kind of going
49:20off the rails here. We're saying that we're going to allow models to do everything and yet the models already have their own sense of internal rails.
49:28It's what they've been trained on. So, how do we get models to do what we want?
49:33And I mean, maybe that's kind of u uh polluting the frame a bit because it's not necessarily do what we want, but we get what they were trained on. Is it what we want?
49:47I don't think the agents care. If you want them to speak to you in Ruby, they will speak to you in Ruby. And they're very good at it. The agent eval show exactly that. They're token efficient.
49:59They're perfectly happy to speak Ruby to you. They speak Python by default because that's what the machine learning researchers who've been working on these systems were trained on, but that has no bearing on what they speak better. They might as well speak Ruby to you. They do not care. They speak every language fluently. And also a focus on the pre-training gets very myopic very quickly. And I think we got trapped in that vision early on when we were
50:28considering how could we help the labs teach the models better Ruby because we had this idea that they needed to see a lot of Ruby to write Ruby. Well, no, they don't. The principles of great software development are universal.
50:46And whether they learn those rules in JavaScript, Python or small talk does not matter. they will translate to final form just as well. This is the second misconception of the past era of thinking that these are parrots. They're just repeating what we told them. No, they're not. They're incredibly creative thinkers. In fact, this is why they're such a challenge in security. They are
51:16so incredibly creative in stringing multiple combo attacks together. And this is why we're having a hard time dealing with it. And why we need agents of our own to defend against them. The creativity is there. In fact, if anything, they are more creative than the humans who steer them. So lean into that. Have them talk Ruby to you when that's what you prefer to see. When you want to look at the code, of course, they should be talking Ruby because Ruby
51:45is the best programming language for humans. So have them translate into you and then they can go back to speaking assembly machine code directly to the CPU. That's what spinner does.
52:11So I'd like to talk a little bit about what's past Rails. We've got Rails for web development.
52:18It's kind of a particular instantiation of what we as programmers bring to the technology world. I mean for the past 20 years and that's changing. Our our grasp is uh is stronger, is broader, we can do more. Um, and yet there's a sense of like I want to keep Rails and u it doesn't necessarily need to be the framework but what about the values of Rails and you with David with Amashi you're starting something new
52:47and um it's its values are attractive and Matt's with Mina Swan. Matt is nice so so we are nice. I that's never really sounded right to me cuz it's like you don't do something just cuz somebody else is some way but it's almost like giving permission for a way to interact with a language that it's okay to value the things that Ruby values and given that permission there's a great filter
53:15of who's attracted to that language.
53:18So you two as founders what's what's next for you?
53:22uh I don't know but uh I really respect Linux to because he created Linux that's great great accomplishment but in addition he creat you know one things is a story but uh two creating two great work is a kind of legend and then I that why I really
53:48respect the Alenas but and you He created railway on rails and now machi okay he's he's lining legend
54:04I'm creating Ruby what about another thing yeah let me think about that well I think it is very important for humans to find their tribe to find others who like the same things that they like who have the same look upon the world, not entirely but shared because we need a little friction. We need a little disagreement to be able to learn anything from each other. And I do
54:32think that the reason all the hands went up when asked about do you think of yourself as a rubist is that we have a common view on the importance of Ruby as an expression form when directing machines. That's really important. Not everyone shares that at all. There are many people who dislike Ruby greatly.
54:56There are many people who dislike Umachi or Rails or anything else that I've been involved with. That's good. It'd be all so boring if we all like the same things in exactly the same way and there was only one programming language, one framework, one operating system in this world might have been efficient. sure as hell wouldn't be fun because humans are tremendously diverse in their ways of
55:24thinking and they respond differently to different technologies, to different paradigms, to different methodologies. The longunning debate in the programming community about static typing versus dynamic typing is a perfect illustration of this. You can lob as many arguments as you want towards folks in one camp or the other. They will not change their minds because they have not reasoned themselves into these positions. So they cannot be reasoned out of them.
55:55Some of these positions are simply bedrock almost presets in their brain.
56:07Tabs versus spaces, Emacs versus Vim.
56:12These are exactly those dividing lines and we should have them and we should celebrate them and we need to find new ones. So when we go into the future and agents are writing more and more of our code, we need new ways to connect with others, create camaraderie and find a tribe. I think that this community here has a unique opportunity to do that together. You already know that you see much of the world the same way. So, as we hop into whatever is next, stick
56:42around. It'll be a good time. So, if we can't predict the future, I mean, perhaps we can position ourselves for it and uh and celebrate the present.
56:55Um, what do you feel that Ruby and Rails have have really gotten right these past decades?
57:05For me, it's a focus on agency.
57:07individual programmers being able to go much further than they would with less efficient, pleasurable, beautiful tools. Ruby to me was this magical unlock because it both gave me a practical tool to shape web applications, but then it was also an endless source of joy and motivation to engage in the effort.
57:32I think we in the Ruby and Rails communities have gotten that better than anyone else. An understanding of human psychology, what drives productivity. A huge component of that is exactly what you said. It's motivation. It's working with beautiful ergonomic tools that create something that seems on the surface maybe frivolous code that looks like poetry
58:00beyond whether it runs fast. Now this is the other thing about this present moment. I think it's important to understand there are performance critical applications that can be improved by rewriting them in something like Rust. And then there are many many many many more where none of those efficiency matters. The vast majority of Rails applications can already run on a single Raspberry Pi.
58:26Do not need further speed than that. And then when more hardware is required, you can change it. So I'm going to start all new web applications that I write in Ruby on Rails. Oh, wonderful way to start and I will take great satisfaction in having a glimpse behind the curtain and seeing this beautiful code being generated by the agents and then should the moment arise when something becomes so popular that it's economically
58:56advantageous to rewrite it in Rust or machine code we will just do that and then we can turn it back into Ruby if so we please for a moment of just sheer joy and appreciation of beautiful code poetry. This is all malible. We can go in one direction, the other direction.
59:12You do not need to log in and think, "Oh my god, now I have to be a Rust programmer." I would not condemn you to that face. Trust me.
59:26the as far as I believe the the biggest contribution of the Ruby community to the world is the the telling you the importance of the uh joy and the motivation and the community uh to in the programming scene there we humans requires motivation to do
59:52anything. So uh we need to mot be motivated to create a software or you know the creating any improve the society as well and then and then we when we feel joy we can be far more productive in product um in development that that kind of thing is not the
1:00:19common sense in 30 years ago. So that that is the greatest contribution uh from the Ruby language and then the basic principle as as long as human concerns are still the same in the future I believe. So the motivation matters, the joy matters and freedom matters. That kind of things will be stay same. But uh you know
1:00:48technology comes and goes and uh pro maybe in the future Ruby is less important would become less important but uh but anyway the joy and motivation and freedom uh still very much will be still important for all of us in the developers or makers.
1:01:15Hell yeah. Yeah. And when I think about programmer happiness, it is agency and joy together. And there's something about maybe professional programmer happiness. It's also getting paid.
1:01:26It's it's it's a recognition of what you're creating and relevance uh within the professional realm that you have a future doing this kind of work. So last thing looking back at and this is really like a 20-year partnership between Ruby and Rails of agency and Joy. What are you most thankful for?
1:01:50I'm most thankful for Matt's allowing me and others in the Rails community to finish the book he started. Put the application programmer at the same level as the language designer and make it such that we couldn't tell the difference.
1:02:08uh I appreciate the exist the real DH and Rails community to make Ruby known to the world. So before Rails the Ruby is was there but virtually no one knows and but uh yeah for the Rails sake everyone started using Rails and then many application including Shopify GitHub and early
1:02:37Twitter's uh uh built on top of the Rubian rails and everyone started using it the and in the past many many many uh startups using uh Ruby and Rails and then they made you know the they made a profit and they changed the world that this is so
1:03:02uh so much joy for me and then and gain give me some kind of the self-esteem and then and then after Rails I can work Ruby full time. So that I am more than you know I very very very much appreciate the uh existence of DHH and Rails.
1:03:34Well Matts David thank you both for everything. Thank you.
