Rails manifesto: Principles of a great programming language

`2:03:45`

You have all these aspirations, they're gonna do some kind of custom, most beautiful Legos castle that nobody's ever built from these pieces. But in reality to be productive in most situations, you just need to build the basic thing. And then on top of that is where your creativity comes. — Absolutely, and I think this is one of those, part of the doctrine that a lot of programmers who get to use Ruby on Rails begrudgingly will acknowledge it's a nice thing, even if they don't really like it. Like it's hard to beat the sort of attraction to building with Legos from scratch out of programmers. That's just what we like. This is why we're programmers in the first place because we'd like to put these little pieces together, but we can direct that instinct towards a more productive end of the stack. — Okay, what are some of the other ones? — The menu is omakase. It actually comes out of the same principle that great defaults really matter. If you look at everything that's wrong with the JavaScript ecosystem right now, for example, it is that no one is in charge of the menu.

`2:04:49`

There are a billion different dishes and you can configure just your tailored specific configuration of it, but no one done the work to make sure it all fits together. So you have all these unique problems in the JavaScript ecosystem, for example, there's probably 25 major ways of just doing the controller layer. And then as many of how to talk to the database. So you get this permutation of n times n times n of no one is using the same thing. And if they are using the same thing, they're only using the same thing for about five minutes. So we have no retained wisdom. We build up no durable skills. Rails goes the complete opposite way of saying, do you know what? Rails is not just a white framework. It's a complete attempt at solving the web problem. It's a complete attempt at solving everything you need to build a great web application. And every piece of that puzzle should ideally be in the box pre-configured, preassembled. If you want to change some of those pieces later,

`2:05:50`

that's wonderful. But on day one you'll get a full menu designed by a chef who really cared about every piece of ingredient and you're gonna enjoy it. And that's again, one of those things where many programmers think like I know better. And they do in some hyper local sense of it. Every programmer knows better. This is what Ruby is built on. That every programmer knows better in their specific situation. Maybe they can do something dangerous. Maybe they think they know better and then they blow their foot off and then they truly will know better because they've blown their foot off once and won't do it again. But the the menu of omakase is that. — So you in general see the value in the in the monolith? — Yes, the integrated system. — Integrated. — That someone thought of the whole problem. This is one of the reasons why I've been on a crusade against microservices since the term was coined. Microservices was born out of essentially a good idea. What do you do at Netflix scale when you have thousands of engineers working

`2:06:51`

on millions of lines of code? No one can keep that entire system in their head at one time. You have to break it down. Microservices can be a reasonable way to do that. When you're at Netflix scale, when you apply that pattern to a team of 20 programmers working on a code base of half a million lines of code, you're an idiot. You just don't need to turn method invocations into network calls. It is the first rule of distributed programming. Do not distribute your programming. It is makes everything harder. All the failure conditions you have to consider as a programmer just becomes infinitely harder when there's a network cable involved. So I hate the idea of premature decomposition and microservices is exactly that. The monolith says. Let's try to focus on building a whole system that a single human can actually understand and push that paradigm as far as possible by compressing all the concepts such that more of it will fit into memory of a single operating human. And then we can have a system where I can actually understand all the Basecamp.

`2:07:53`

I can actually understand all of HEY. Both of those systems are just over a hundred thousand lines of code. I've seen people do this that maybe twice, maybe three times that scale and then it starts breaking down. Once you get north of certainly half a million lines of code, no individual human can do it and that's when you get into maybe some degree of microservices can make sense. — Basecamp and HEY are both a hundred thousand? — A hundred thousand lines of code thereabouts. — Wow, it's small. — It is. Considering the fact that Basecamp I think has something like 420 screens, different ways and configurations. — Ah, do you include the front end in that? — No, that's the Ruby code. Well, it's front end in the sense that some of that Ruby codes. It's beneficial to the front, but it's not JavaScript for example. Now the other thing we might talk about later is we write very little JavaScript actually for all of our applications. HEY, which is a Gmail competitor. Gmail ships I think 28 megabytes of uncompressed JavaScript. If you compress it, I think it's about six megabytes, 28 megabytes. Think about how many lines of code that is. When HEY launched, we shipped 40 kilobytes. It's trying to solve the same problem.