Rails manifesto: Principles of a great programming language

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

`2:08:55`

You can solve the email client problem with either 28 megabytes of uncompressed JavaScript or with 40 kilobytes if you do things differently. But that comes through the same problem essentially. This is why I have fiercely fought splitting front end and back end apart. That, in my opinion, this was one of the great crimes against web development. That we are still atoning for. That we separated and divided what was and should be a unified problem solving mechanism. When you are working both on front end and back end, you understand the whole system. And you're not going to get into these camps that decompose and eventually you end up with like GraphQL. — Okay, let's fly through the rest of the doctrine. No one paradigm. — No one paradigm goes to the fact that Ruby is a fiercely object- oriented programming language at its core, but it's also a functional program language. This five times I told you about, you can essentially do these anonymous function calls