Scaling

`1:21:59`

One is runtime performance, latency. How fast can you execute a single request? Can it happen fast enough that the user will not notice? If your Rails request takes a second and a half to execute, the user's gonna notice. Your app is gonna feel slow and sluggish. You have to get that response time down below, let's say at least 300 milliseconds. I like to target a hundred milliseconds as my latency. That's kind of performance. How much performance of that kind of latency can you squeeze out of a single CPU core, that tells you something about what the price of a single request will be. But then whether you can deal with 1 million requests a second like Shopify is doing right now. If you have one box that can do a thousand requests a second, you just need X boxes to get up to a million. And what you'll actually find is that when it comes to programming languages, they're all the same in this way. They all scale largely beautifully horizontally. You just add more boxes.

`1:23:01`

The hard parts of scaling a Shopify is typically the program language. It's the database. And that's actually one of the challenges that Shopify has now is how do you deal with MySQL at the scale that they're operating at? When do you need to move to other databases to get worldwide performance? All of these things. The questions about scaling Ruby are economic questions. If we are spending so and so much on application servers, if we can get just 5% more performance out of Ruby, well we could save 5% of those servers and that could filter down into the budget. Now that analysis concludes into basically one thing. Ruby is a luxury language. It's a luxury, the highest luxury in my opinion. It is the Coco Chanel of programming languages. Something that not everyone can afford. And I mean this in the best possible way. There are some applications on the internet

`1:24:01`

where each request has so little value, you can't afford to use a luxurious language like Ruby to program in it. You simply have to slum it with a C or a Go or some other low level language or Rust, talk about line noise there for... — It's like the thrift store of languages. — Exactly, where you need kind of just... you need a very low level to do it. You can't afford to use a luxury language to use to build it with. That's not true of Shopify. It wasn't true of Basecamp even back in 2004. It's not been true of 99% of all web applications ever created because the main cost component of 99% of web applications, it's not CPU course. It's wet course. It's human course. It's human capacity to understand and involve systems. It's their personal productivity. I did a calculation once when someone had for the 400th time said that, "Oh, if you switch from Ruby to some faster language,

`1:25:02`

you could save a bunch of money." And I calculated it out that at the time, and I think the last time I did this calculation was almost a decade ago. We were spending about 15% of our operating budget on Ruby application service. So for me to improve my cost profile of the business by seven percentage points, I'd have to pick something twice as fast. That's quite hard. Versus if Ruby and Ruby on Rails was even 10% more productive than something else, I would move the needle far more because making individual programmers more productive actually matters a lot more. This is why people are so excited about AI. This is why they're freaking out over the fact that a single programmer in Silicon Valley who makes $300,000 a year can now do the work of three or five, at least in theory. I haven't actually seen that fully in practice, but let's just assume the theory is correct if not now, then in six months. That's a huge deal. That matters so much more

`1:26:02`

than whether you can squeeze a few more cycles out of the CPU, when it comes to these kinds of business applications. If you're making unreal engine rendering stuff like Tim Sweeney you had on. Yeah, he needs to really sweat all those details. The Nanite engine can't run on Ruby. It's never going to. It would not meant for that, fine. These kinds of business applications absolutely can and everything that people are excited about AI for right now, that extra capacity to just do more. That was why we were excited about Ruby back in the early 2000s. That was be because I saw that if we could even squeeze out a 10% improvement of the human programmer, we'd be able to do so much more for so much less. — Probably argue about this, but I really like working together with AI, collaborating with AI. And I would argue that the kind of code you want AI to generate is human readable, human interpretable. If it's generating Perl golf code,