Rails manifesto: Principles of a great programming language

`2:02:43`

We just need to pick one, and then that's fine. And if we pick one and we can depend on it, it becomes a convention. And if it's a convention, we don't have to configure it. And if we don't have to configure it, you can get started with you actually care about much quicker. So convention over configuration is essentially to take that idea that the system should come preassembled. I'm not just handing you a box of fucking Legos and asking you to build the Millennium Falcon. I'm giving you a finished toy. You can edit, you can change it, it's still build out a Legos. You can still take some pieces off and put in some other pieces, but I'm giving you the final product. And this cuts against the grain of what most programmers love. They love a box of Legos. They love to put everything together from scratch. They love to make all these detailed little decisions that just don't matter at all. And I want to elevate that up so that hey, I'm not trying to take the decisions away from you. I just want you to focus on decisions that actually matter that you truly care about. No one cares about whether it's post_id or post ID or PID. — Yeah, great defaults. — Yes. — It's just a wonderful thing.

`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.