WEBVTT 1 00:00:00.160 --> 00:00:03.640 So imagine trying to change the tires on a car 2 00:00:03.759 --> 00:00:07.120 while you're driving down the highway at like seventy miles 3 00:00:07.120 --> 00:00:07.679 an hour. 4 00:00:07.679 --> 00:00:09.919 Right, which sounds completely terrifying. 5 00:00:09.599 --> 00:00:13.359 Yeah, exactly, But I mean that is literally what software 6 00:00:13.359 --> 00:00:15.439 engineers are expected to do every single. 7 00:00:15.240 --> 00:00:17.679 Day, oh for sure. Because when you open an app, 8 00:00:18.280 --> 00:00:20.879 you know, like WhatsApp, you just expected to work instantly. 9 00:00:21.000 --> 00:00:25.239 Yeah, even if developers are like deploying these massive software 10 00:00:25.320 --> 00:00:28.280 updates to the system right there in the background. 11 00:00:27.960 --> 00:00:28.920 You don't even notice it. 12 00:00:29.120 --> 00:00:32.759 Right, So today's deep dive is exploring the hidden engine 13 00:00:32.799 --> 00:00:37.079 behind that modern miracle of well always on reliability. We're 14 00:00:37.079 --> 00:00:40.399 going to be unpacking excerpts from a really fascinating book 15 00:00:40.719 --> 00:00:44.240 called Elixir in Action by Sasha Jurich, published by Manning. 16 00:00:44.399 --> 00:00:46.640 Yeah, and before we really delve into the whole technical 17 00:00:46.719 --> 00:00:50.200 architecture side of things, the physical book itself has a 18 00:00:50.240 --> 00:00:53.719 couple of charming details I think you're worth. 19 00:00:53.520 --> 00:00:56.159 Noting, Oh, right, like the dedication exactly. 20 00:00:56.200 --> 00:00:59.000 The author dedicates the work to his wife, Arnada, which 21 00:00:59.039 --> 00:01:02.159 is sweet. But the publisher also chose a very specific 22 00:01:02.240 --> 00:01:03.079 piece of cover art. 23 00:01:03.200 --> 00:01:04.599 Right. It's an illustration, isn't it. 24 00:01:04.719 --> 00:01:07.840 Yeah, it's called a Russian Girl from Thomas Jeffrey's eighteenth 25 00:01:07.840 --> 00:01:11.480 Century Trust Collection and Back of the seventeen hundreds. Those 26 00:01:11.519 --> 00:01:15.879 illustrations highlighted the incredible diversity of global cultures. Oh wow, 27 00:01:16.079 --> 00:01:18.040 so here the publisher is kind of using it as 28 00:01:18.040 --> 00:01:23.200 a nod to the vast interconnected ecosystem of computer systems 29 00:01:23.239 --> 00:01:24.200 we're about to explore. 30 00:01:24.519 --> 00:01:27.799 I love that, and I mean to really understand that ecosystem, 31 00:01:27.920 --> 00:01:29.599 we kind of need to look at the author's own 32 00:01:29.640 --> 00:01:30.480 breaking point. Right. 33 00:01:30.599 --> 00:01:31.799 Yeah, let's set the scene. 34 00:01:32.000 --> 00:01:34.920 So the year is twenty ten. Jurich is tasked with 35 00:01:35.000 --> 00:01:38.000 building a near real time push server. And this isn't 36 00:01:38.040 --> 00:01:41.120 like a small weekend project. It needs to handle thousands 37 00:01:41.159 --> 00:01:45.680 of connected users simultaneously without dropping a single connection. 38 00:01:45.400 --> 00:01:47.319 Which is a huge technical challenge totally. 39 00:01:47.439 --> 00:01:50.640 His company was primarily using Rubyon Rails, which is a 40 00:01:50.799 --> 00:01:54.760 very popular web framework. But as he's staring down this 41 00:01:54.959 --> 00:01:58.599 incoming wall of concurrent traffic, his CTO suggests he look 42 00:01:58.640 --> 00:01:59.959 into a language called erlang. 43 00:02:00.400 --> 00:02:03.640 And I mean Erling wasn't exactly the first tool a 44 00:02:03.680 --> 00:02:06.000 web developer reached for back in twenty ten, No, not 45 00:02:06.079 --> 00:02:08.719 at all. But Yurch builds this prototype. He runs the 46 00:02:08.719 --> 00:02:11.680 load tests, and the performance in the stability were just 47 00:02:11.759 --> 00:02:16.120 so absolute that he ended up rebuilding the entire system in. 48 00:02:16.080 --> 00:02:18.560 It wow, just scrap the old one pretty much. 49 00:02:18.840 --> 00:02:22.360 He even started a blog called the Erlangelist just to 50 00:02:22.400 --> 00:02:25.759 help other object oriented programmers wrap their heads around this 51 00:02:26.280 --> 00:02:28.560 strange yet really powerful tool. 52 00:02:28.840 --> 00:02:31.240 Right, and to see why Erling was such a revelation 53 00:02:31.360 --> 00:02:33.319 for him, we actually have to travel way back to 54 00:02:33.400 --> 00:02:34.680 the mid nineteen eighties. 55 00:02:34.840 --> 00:02:36.120 Yeah, time travel. 56 00:02:36.159 --> 00:02:38.919 Erline was created by a team at Ericsson led by 57 00:02:38.960 --> 00:02:43.520 the legendary software engineer Joe Armstrong, and Ericson is a 58 00:02:43.680 --> 00:02:47.919 Swedish telecom giant. They built Erlang specifically to run their 59 00:02:48.120 --> 00:02:50.159 massive telephone network switches. 60 00:02:50.360 --> 00:02:52.319 Right, And you might be sitting there wondering, well, why 61 00:02:52.360 --> 00:02:55.080 should you care about a programming language built for nineteen 62 00:02:55.080 --> 00:02:56.400 eighties landline phones? 63 00:02:56.479 --> 00:02:59.319 Right, Yeah, sounds pretty obsolete. 64 00:02:58.840 --> 00:03:01.400 But it comes down to the fund mental requirement of telecom, 65 00:03:01.599 --> 00:03:05.159 which is zero downtime. Ah right, Because in the eighties 66 00:03:05.159 --> 00:03:08.479 and nineties, if consumer desktop software crashed, I mean it 67 00:03:08.560 --> 00:03:10.639 was annoying, but it only affected one person. 68 00:03:10.840 --> 00:03:13.199 Just reboot your computer in your front exactly. 69 00:03:13.520 --> 00:03:17.080 A telecom network, however, had to be highly available fault 70 00:03:17.120 --> 00:03:20.520 tolerant and scalable without ever turning the machine off. 71 00:03:20.400 --> 00:03:23.400 Because you couldn't drop thousands of active phone calls just 72 00:03:23.439 --> 00:03:27.400 because a hardware component failed, or like an engineer uploaded new. 73 00:03:27.280 --> 00:03:31.159 Code exactly and fast forward to today, Suddenly everything you 74 00:03:31.319 --> 00:03:35.840 use has those exact same telecom level requirements. 75 00:03:35.319 --> 00:03:41.080 Cloud deployment platforms, massive multiplayer online games, social networks, all 76 00:03:41.120 --> 00:03:43.000 of it. Yeah, these are the modern equivalent of the 77 00:03:43.000 --> 00:03:47.680 global telephone grid. I mean, consider that when WhatsApp was acquired, 78 00:03:48.240 --> 00:03:51.000 they had hundreds of millions of users, but only about 79 00:03:51.080 --> 00:03:53.439 fifty engineers keeping the entire system. 80 00:03:53.159 --> 00:03:55.080 Running, which is mind blowing, right. 81 00:03:55.000 --> 00:03:57.879 And they achieved that impossible leverage because their system was 82 00:03:57.919 --> 00:03:59.360 built on the core DNA of. 83 00:03:59.479 --> 00:04:02.719 Erlink and that survival mechanism. It really comes down to 84 00:04:02.840 --> 00:04:05.639 Erlang's completely unique take on concurrency. 85 00:04:06.039 --> 00:04:09.120 Basically how computer juggles multiple tasks at once. 86 00:04:09.120 --> 00:04:11.400 Right there, because it doesn't rely on the heavyweight spreads 87 00:04:11.439 --> 00:04:15.000 and processes provided by your computer's operating system like Mac 88 00:04:15.319 --> 00:04:18.759 or Windows or Linux. Instead, it runs inside its own 89 00:04:18.800 --> 00:04:21.000 isolated virtual machine called the beam. 90 00:04:21.519 --> 00:04:25.720 Right, the beam that stands for a Bogden or Bjorn's 91 00:04:25.839 --> 00:04:29.800 erlaying abstract machine named after its creators obviously naturally, and 92 00:04:29.920 --> 00:04:32.639 instead of relying on the operating system, the beam just 93 00:04:32.839 --> 00:04:38.439 reinvents concurrency using its own incredibly lightweight processes. We aren't 94 00:04:38.439 --> 00:04:41.360 talking about a server handling a few hundred tasks here, no, 95 00:04:41.560 --> 00:04:44.759 not at all. A single Beam system can comfortably run 96 00:04:45.199 --> 00:04:48.480 thousands or even millions of these tiny processes at the 97 00:04:48.560 --> 00:04:49.680 exact same time. 98 00:04:49.839 --> 00:04:52.920 Yeah, and the book describes this as a shared nothing 99 00:04:53.079 --> 00:04:58.079 architecture because in traditional operating system threads, concurrent programming is 100 00:04:58.120 --> 00:05:01.480 incredibly difficult since process is share the same memory space. 101 00:05:01.759 --> 00:05:05.759 Okay, so let's picture traditional shared state concurrency as like 102 00:05:05.839 --> 00:05:09.000 a chaotic group project in a single conference room. 103 00:05:09.120 --> 00:05:10.439 I've been in a few of those, right. 104 00:05:10.959 --> 00:05:13.319 Everyone is fighting over the same single whiteboard to write 105 00:05:13.360 --> 00:05:15.560 down their ideas. That whiteboard is the shared. 106 00:05:15.240 --> 00:05:18.800 Memory, right, which creates constant bottlenecks because people are awaiting their. 107 00:05:18.639 --> 00:05:22.160 Turn exactly, and to keep them from talking over each other, 108 00:05:22.240 --> 00:05:26.040 developers have to write these complex locking mechanisms into the code. 109 00:05:26.199 --> 00:05:28.680 Oh and if someone accidentally knocks a whiteboard over. 110 00:05:28.560 --> 00:05:31.519 The entire project crashes. Everyone goes down, Yeah, which is 111 00:05:31.519 --> 00:05:32.120 a nightmare. 112 00:05:32.639 --> 00:05:35.399 But the Erlang process is on the Beam. They operate 113 00:05:35.439 --> 00:05:38.560 in a completely different reality. Ow So instead of one 114 00:05:38.639 --> 00:05:43.199 chaotic conference room, imagine you have a million remote workers. Okay, 115 00:05:43.680 --> 00:05:47.680 every single worker is sitting in their own, locked, isolated 116 00:05:47.759 --> 00:05:52.240 room with their own private whiteboard. They share absolutely nothing 117 00:05:52.279 --> 00:05:53.000 with each other. 118 00:05:52.959 --> 00:05:54.000 So how do they even talk? 119 00:05:54.959 --> 00:05:57.519 Well, if they need to coordinate, the only way they 120 00:05:57.519 --> 00:06:00.360 can communicate is by sliding little notes under the door, 121 00:06:01.040 --> 00:06:03.279 which Erlane calls asynchronous messages. 122 00:06:03.680 --> 00:06:06.319 Okay, that makes sense. And because they share no memory, 123 00:06:06.439 --> 00:06:09.079 the first massive benefit of that is fault tolerance. 124 00:06:09.199 --> 00:06:09.839 Absolutely. 125 00:06:10.040 --> 00:06:12.879 If one worker in their isolated room rates bad code 126 00:06:12.920 --> 00:06:15.959 and suddenly bursts into flames, which you know is a 127 00:06:16.000 --> 00:06:18.199 software crash, doesn't affect anyone else, Right, The. 128 00:06:18.199 --> 00:06:20.600 Fire cannot spread to the shared whiteboard because there is 129 00:06:20.639 --> 00:06:21.560 no shared whiteboard. 130 00:06:21.759 --> 00:06:24.399 Yeah, the system just sweeps out the ashes, places a 131 00:06:24.439 --> 00:06:26.439 brand new worker in the room, and the rest of 132 00:06:26.480 --> 00:06:28.519 the system literally doesn't even blink. 133 00:06:28.800 --> 00:06:32.120 And that isolation also solves the problem of resource hawking. 134 00:06:32.279 --> 00:06:33.759 Oh that's a big one, right. 135 00:06:33.639 --> 00:06:35.759 Because you might ask, well, what happens if a worker 136 00:06:35.759 --> 00:06:39.439 doesn't crash but just get stuck trying to solve some 137 00:06:39.759 --> 00:06:41.600 massively heavy mathematical equation. 138 00:06:41.800 --> 00:06:43.800 Yeah, does the rest of the system freeze up waiting 139 00:06:43.800 --> 00:06:45.079 for them to finish. Well. 140 00:06:45.079 --> 00:06:49.000 In standard systems, yeah, a heavy task can easily choke 141 00:06:49.040 --> 00:06:52.040 the central processor, yeah, and cause the whole app to 142 00:06:52.040 --> 00:06:53.800 become unresponsive for everyone else. 143 00:06:53.879 --> 00:06:58.040 But the beam has a preemptive scheduler, right, which acts 144 00:06:58.120 --> 00:07:02.160 like a highly strict manager walking the halls. 145 00:07:02.319 --> 00:07:04.759 Yeah, and the way this manager works is actually fascinating. 146 00:07:04.959 --> 00:07:07.879 Doesn't track time on a clock, yeah you know, it 147 00:07:08.000 --> 00:07:11.160 tracks reduction reduction, right, which is essentially counting the number 148 00:07:11.199 --> 00:07:13.600 of function calls a worker makes. Once a worker hits 149 00:07:13.639 --> 00:07:17.000 a specific limit, say two thousand function calls the walk, 150 00:07:17.439 --> 00:07:21.120 the manager forces them to pause, saves their exact state, 151 00:07:21.439 --> 00:07:22.800 and moves on to the next worker. 152 00:07:23.000 --> 00:07:26.680 Oh wow, So by counting operations rather than milliseconds, the 153 00:07:26.720 --> 00:07:30.879 scheduler ensures total fairness exactly. Even if a worker is 154 00:07:30.920 --> 00:07:35.399 doing the heaviest database crunching imaginable, they are forcibly paused 155 00:07:35.399 --> 00:07:37.439 when their turn is up. The manager just keeps the 156 00:07:37.480 --> 00:07:38.000 line moving. 157 00:07:38.120 --> 00:07:41.199 Yeah, meaning your simple web request never gets stuck behind 158 00:07:41.199 --> 00:07:45.040 someone else's massive data download. The system just remains remarkably 159 00:07:45.040 --> 00:07:46.959 responsive under intense pressure. 160 00:07:47.120 --> 00:07:50.519 And because these isolated workers aren't sharing that central whiteboard, 161 00:07:50.920 --> 00:07:54.279 it solves another massive headache for developers, which is cleaning 162 00:07:54.360 --> 00:07:55.000 up memory. 163 00:07:55.160 --> 00:07:56.560 Oh yeah, garbage collection. 164 00:07:56.759 --> 00:07:59.399 Right. In standard systems, when the computer needs to sweep 165 00:07:59.480 --> 00:08:01.920 up unused data, it often has to pause the entire 166 00:08:02.000 --> 00:08:04.040 system to safely clear the shared. 167 00:08:03.759 --> 00:08:06.040 Memory, and for you, the user, that looks like a 168 00:08:06.040 --> 00:08:09.439 frozen screen or you know that infinite buffering wheel the worse. 169 00:08:10.160 --> 00:08:14.360 But in Erlang, garbage collection happens individually per process. One 170 00:08:14.399 --> 00:08:16.879 remote worker just takes out their own tiny trash can 171 00:08:16.920 --> 00:08:18.560 in their own isolated. 172 00:08:18.079 --> 00:08:20.480 Room, while the other nine hundred and ninety nine thousand 173 00:08:20.480 --> 00:08:22.000 workers just keep typing away. 174 00:08:22.319 --> 00:08:26.480 Right. There are never any massive system wide pauses that 175 00:08:26.600 --> 00:08:28.759 degrade the user experience, and. 176 00:08:28.720 --> 00:08:35.120 This total isolation fundamentally changes how developers build entire server architectures. 177 00:08:35.200 --> 00:08:38.720 How So, the book actually gives a real life comparison 178 00:08:38.840 --> 00:08:42.279 of two web servers to highlight this. So server A 179 00:08:43.000 --> 00:08:46.639 represents a standard modern setup. It's a patchwork quilt of 180 00:08:46.679 --> 00:08:48.240 different specialized technologies. 181 00:08:48.360 --> 00:08:51.559 So you might have one piece of software answering the 182 00:08:51.559 --> 00:08:55.559 web praffic, a completely different language processing the business logic. 183 00:08:55.360 --> 00:08:59.000 Right, and an external memory database holding onto users shopping carts, 184 00:08:59.279 --> 00:09:02.600 plus a separate scheduling tool running background jobs at midnight. 185 00:09:02.720 --> 00:09:06.679 Wow. Yeah, the author affectionately calls this the server side zoo. 186 00:09:06.840 --> 00:09:09.559 Exactly. You have all these different animals, all these independent 187 00:09:09.559 --> 00:09:12.799 moving parts loosely tied together with network cables to build 188 00:09:12.840 --> 00:09:14.120 one application. 189 00:09:13.799 --> 00:09:16.519 And if any one of those independent pieces fails or 190 00:09:16.559 --> 00:09:19.919 loses connection, the whole house of cards basically it comes down. 191 00:09:20.039 --> 00:09:22.519 Yeah, it's fragile, but sir B, on the other hand, 192 00:09:22.559 --> 00:09:26.559 handles the web traffic, the business logic, the temporary user states, 193 00:09:26.840 --> 00:09:31.000 and the background jobs using only early just one language. Yeah. 194 00:09:31.240 --> 00:09:34.440 It relies on a battle tested framework build directly into 195 00:09:34.519 --> 00:09:37.919 the language called OTP or Open Telecom Platform. 196 00:09:38.000 --> 00:09:38.759 Okay, I've heard of that. 197 00:09:39.039 --> 00:09:43.080 Yeah. OTP provides standardized templates like something called a gen server, 198 00:09:43.240 --> 00:09:46.679 which stands for Generic Server. A gen server handles all 199 00:09:46.679 --> 00:09:49.919 the complex logic of how processes should communicate, how they 200 00:09:49.960 --> 00:09:54.080 should store data safely, and exactly how they should be restarted. 201 00:09:53.600 --> 00:09:56.279 If they crash, and the developer doesn't have to reinvent 202 00:09:56.279 --> 00:09:57.159 the wheel every time. 203 00:09:57.320 --> 00:10:00.360 Right. It allows you to build a highly available, cohibited 204 00:10:00.399 --> 00:10:04.320 system entirely inside a single technology stack running on a 205 00:10:04.320 --> 00:10:05.039 single machine. 206 00:10:05.080 --> 00:10:07.679 Okay, let me push back on this monolith approach, though, sure, 207 00:10:07.720 --> 00:10:10.720 because as someone who builds systems, relying on a jack 208 00:10:10.759 --> 00:10:13.679 of all trades tool for everything usually ends in disaster. 209 00:10:13.919 --> 00:10:14.360 I get that. 210 00:10:14.600 --> 00:10:16.320 I mean a Swiss army knife is great for a 211 00:10:16.360 --> 00:10:19.600 camping trip, but you wouldn't use the tiny sawblade to 212 00:10:19.600 --> 00:10:23.679 build house, right. Shouldn't developers use specialized external tools for 213 00:10:23.759 --> 00:10:26.799 things like caching or background processing because those tools have 214 00:10:26.840 --> 00:10:29.919 spent years perfecting that one specific job. 215 00:10:30.320 --> 00:10:33.799 Is a very valid criticism, honestly, But the key distinction 216 00:10:33.919 --> 00:10:37.039 here is that erlank isn't forcing you into a closed box. 217 00:10:37.240 --> 00:10:37.759 Oh it's not. 218 00:10:38.120 --> 00:10:41.639 No, It's completely capable of talking to external databases or 219 00:10:41.639 --> 00:10:45.000 message cues when you need them. If you require raw 220 00:10:45.080 --> 00:10:48.759 speed for a highly specific task like heavy image processing, 221 00:10:49.480 --> 00:10:53.039 erlang allows you to run fast c code natively alongside it. 222 00:10:53.120 --> 00:10:53.960 Okay. Interesting. 223 00:10:54.039 --> 00:10:56.879 What erling provides is the option of a homogeneous system 224 00:10:56.919 --> 00:10:57.720 from day one. 225 00:10:57.840 --> 00:11:00.159 So you aren't forced to manage the whole zoo when 226 00:11:00.200 --> 00:11:01.279 you're just starting. 227 00:11:00.919 --> 00:11:03.440 Out precisely, I mean, in the early days of a 228 00:11:03.480 --> 00:11:07.799 startup or for small engineering teams, Deploying and maintaining five 229 00:11:07.840 --> 00:11:12.039 different databases and languages across multiple servers is an operational light. 230 00:11:12.240 --> 00:11:13.200 It just too much overhead. 231 00:11:13.600 --> 00:11:17.879 Exactly, Erling lets a tiny team build a massive, robust 232 00:11:17.879 --> 00:11:20.799 system out of the box. You only bolt on those 233 00:11:20.799 --> 00:11:23.759 specialized external tools when you truly hit the limits of 234 00:11:23.799 --> 00:11:26.440 what the bean can do, which takes a very, very 235 00:11:26.480 --> 00:11:26.960 long time. 236 00:11:27.080 --> 00:11:30.360 Well, if erlang is this indestructible supertool, it raises an 237 00:11:30.399 --> 00:11:33.440 obvious question. I think, why did anyone feel the need 238 00:11:33.480 --> 00:11:36.639 to invent alixer. I mean, why isn't every developer on 239 00:11:36.679 --> 00:11:39.360 Earth just writing raw arline code right now? 240 00:11:39.919 --> 00:11:41.679 Well, the answer comes down to the simple act of 241 00:11:41.720 --> 00:11:44.960 typing it out. Yeah. Erling was designed in the nineteen eighties, 242 00:11:45.000 --> 00:11:49.039 and its syntax really reflects that era. It is notoriously dense, 243 00:11:49.519 --> 00:11:53.360 highly repetitive, and frankly kind of jarring to modern programmers. 244 00:11:53.600 --> 00:11:56.399 Right. It's the classic critique of the language. It makes 245 00:11:56.440 --> 00:12:00.360 the hardest problems in computer science, like distributed concurrency fault 246 00:12:00.360 --> 00:12:04.360 tolerance look incredibly easy, but it makes simple things like 247 00:12:04.440 --> 00:12:08.799 defining a basic module or adding numbers together bizarrely hard 248 00:12:08.879 --> 00:12:09.559 and verbose. 249 00:12:09.759 --> 00:12:13.240 Yeah. But then the author discovered Elixer around its zero 250 00:12:13.279 --> 00:12:14.159 point eight release. 251 00:12:14.399 --> 00:12:17.879 Right. Elixer was created by a developer named Jose Valim. 252 00:12:17.679 --> 00:12:21.039 And Jurige realized immediately that Elixir was the perfect bridge, 253 00:12:21.399 --> 00:12:23.759 because the magic of Elixir is that it compiles down 254 00:12:23.759 --> 00:12:26.360 to the exact same beam bytecode as Erlang. 255 00:12:26.639 --> 00:12:28.960 Oh wow, so you don't lose a single drop of 256 00:12:29.080 --> 00:12:31.840 Erlang's performance or its twenty four to seven reliability. 257 00:12:32.080 --> 00:12:36.840 Nope, you are still driving the exact same, indestructible nineteen 258 00:12:36.879 --> 00:12:41.879 eighties telecom engine. Elixer just replaces the rusty dashboard with 259 00:12:42.000 --> 00:12:45.480 the sleek, modern, developer friendly interface. 260 00:12:45.320 --> 00:12:50.000 And it aggressively fixes Erlang's boilerplate problem. The book highlights 261 00:12:50.039 --> 00:12:51.480 a really specific. 262 00:12:51.039 --> 00:12:52.519 Example, right the addition one. 263 00:12:52.600 --> 00:12:55.000 Yeah, so you want to write a tiny server process 264 00:12:55.000 --> 00:12:57.960 in Erlang, whose only job is to add two numbers together. 265 00:12:58.639 --> 00:13:01.679 Doing this requires typing out a massive, noisy block of 266 00:13:01.720 --> 00:13:05.600 boilerplate code just to set up the process is so tedious. Yeah, 267 00:13:05.600 --> 00:13:08.240 The structure is so tedious that veteran programmers don't even 268 00:13:08.240 --> 00:13:10.720 type it out. They literally copy and paste it from 269 00:13:10.720 --> 00:13:12.919 older projects just to get to the one line of 270 00:13:12.960 --> 00:13:14.799 code that actually does the math, which. 271 00:13:14.600 --> 00:13:19.120 Creates totally unnecessary cognitive load for the developer. But Elixer 272 00:13:19.159 --> 00:13:20.360 shrinks this dramatically. 273 00:13:20.480 --> 00:13:24.080 Yeah. The author actually built a custom Elixer library called exactor. 274 00:13:24.399 --> 00:13:27.600 To prove this exact point, he took that massive, ugly 275 00:13:27.720 --> 00:13:30.840 block of Erling boilerplate and used Elixer to trink it 276 00:13:30.879 --> 00:13:33.720 down to just a couple of lines of beautiful readable code. 277 00:13:33.399 --> 00:13:36.440 Which is awesome. And the mechanism Elixer uses to achieve 278 00:13:36.440 --> 00:13:39.360 this shrinkage is its secret weapon macros. 279 00:13:39.600 --> 00:13:42.679 Now, when people hear the word macro, they often think 280 00:13:42.720 --> 00:13:45.799 of older languages like see where a macro is essentially 281 00:13:45.840 --> 00:13:48.279 a glorified find and replace. 282 00:13:48.519 --> 00:13:50.840 Right, It just looks for a string of text and 283 00:13:50.879 --> 00:13:53.039 swaps it out for another string of text before the 284 00:13:53.080 --> 00:13:53.840 program runs. 285 00:13:53.919 --> 00:13:56.679 But Elixer macros are far more intelligent, aren't they. 286 00:13:56.759 --> 00:13:59.360 Oh? Yeah, Elixir macros operate on what is called the 287 00:13:59.399 --> 00:14:01.919 abstracts and tax tree, or the AST. 288 00:14:02.399 --> 00:14:05.000 Okay, to put that in plain English, think back to 289 00:14:05.039 --> 00:14:07.480 grade school when you had to diagram a sentence. You 290 00:14:07.559 --> 00:14:09.840 didn't just read the words. You mapped out the noun, 291 00:14:09.960 --> 00:14:11.960 the verb, and the subject exactly. 292 00:14:12.120 --> 00:14:15.159 And the AST does that for code. The macro isn't 293 00:14:15.200 --> 00:14:17.639 just looking at the letters you typed. It understands the 294 00:14:17.679 --> 00:14:21.639 actual grammar and structural logic of your program at compile time. 295 00:14:21.799 --> 00:14:25.240 Wow. And this deep structural understanding allows developers to write 296 00:14:25.240 --> 00:14:28.120 code that writes other code. You can flesh out all 297 00:14:28.159 --> 00:14:30.720 that repetitive boilerplate before the program even runs. 298 00:14:30.960 --> 00:14:33.759 Yeah, it empowers developers to create tools that feel like 299 00:14:33.879 --> 00:14:35.879 native parts of the Elixer language itself. 300 00:14:36.039 --> 00:14:38.240 A great example from the book is the Ecto project, 301 00:14:38.240 --> 00:14:40.639 which basically helps Elixer talk to databases. 302 00:14:41.000 --> 00:14:43.720 Right in many languages, if you want to pull user 303 00:14:43.799 --> 00:14:46.759 data from a database, you have to write raw, clucky 304 00:14:46.840 --> 00:14:49.679 SQL database strings right in the middle of your clean 305 00:14:49.720 --> 00:14:53.480 application code. It's so ugly it is, but Ecto uses 306 00:14:53.559 --> 00:14:57.759 macros to let developers write database queries that look and 307 00:14:57.759 --> 00:15:02.720 behave exactly like native Elixer code. It feels completely seamless. 308 00:15:02.240 --> 00:15:05.360 And that seamlessness carries over into how you string ideas 309 00:15:05.399 --> 00:15:09.080 together too. Elixer fundamentally changes the flow of data with 310 00:15:09.159 --> 00:15:11.360 something called the pipeline operator yes. 311 00:15:11.240 --> 00:15:14.360 Which is a huge shift from Erling because in Erlang, 312 00:15:14.360 --> 00:15:16.240 if you want to pass a piece of data through 313 00:15:16.240 --> 00:15:18.919 a series of transformations, you have to use a technique 314 00:15:18.919 --> 00:15:19.879 called staircasing. 315 00:15:20.039 --> 00:15:22.000 Right, you take the raw data, pass it to the 316 00:15:22.000 --> 00:15:24.360 first function, and you have to invent a temporary name 317 00:15:24.399 --> 00:15:26.720 for the result like data one. Then you pass data 318 00:15:26.759 --> 00:15:30.080 one into the second function and save the result as 319 00:15:30.159 --> 00:15:30.679 data too. 320 00:15:30.799 --> 00:15:34.039 It's exhausting. It forces the developer to read the code 321 00:15:34.039 --> 00:15:37.720 inside out, you know, navigating a cluttered mess of temporary 322 00:15:37.799 --> 00:15:39.960 variables just to track how the data is changing. 323 00:15:40.200 --> 00:15:43.840 I like to think of arline staircasing as like a 324 00:15:43.960 --> 00:15:47.960 clumsy bucket brigade where people are splashing water everywhere and 325 00:15:48.080 --> 00:15:51.360 fumbling the hand off. That's a great visual, Whereas Elixer's 326 00:15:51.399 --> 00:15:54.960 pipeline operator is a perfectly calibrated factory conveyor belt. 327 00:15:55.039 --> 00:15:57.679 Yeah. The operator literally looks like a simple little arrow 328 00:15:58.039 --> 00:16:01.000 made of a vertical line and a greater than oh cool. 329 00:16:01.240 --> 00:16:03.879 And the pipeline operator takes the result of one function 330 00:16:04.360 --> 00:16:06.960 and feeds it directly into the next function. As the 331 00:16:07.080 --> 00:16:08.320 very first argument. 332 00:16:08.200 --> 00:16:10.240 So you drop the raw material at the start of 333 00:16:10.240 --> 00:16:13.399 the belt and it glides seamlessly through machine A straight 334 00:16:13.440 --> 00:16:16.720 into machine B, thraight into machine C. It removes all 335 00:16:16.720 --> 00:16:19.759 the temporary variables and leaves you with pure logic. You 336 00:16:19.799 --> 00:16:23.519 read the code exactly as a human thinks. Take this data, 337 00:16:23.720 --> 00:16:26.240 transform it here, filter it there, and save it. 338 00:16:26.240 --> 00:16:28.279 It really creates a state of flow for the developer 339 00:16:28.320 --> 00:16:31.919 which translates to fewer bugs and faster future development. 340 00:16:32.000 --> 00:16:35.039 Okay, so we have this bulletproof nineteen eighties telecom engine 341 00:16:35.159 --> 00:16:38.519 in the beam, ensuring the system never crashes. We have 342 00:16:38.559 --> 00:16:43.159 this beautiful modern dashboard and Elixir with intelligent macros and 343 00:16:43.200 --> 00:16:46.879 conveyor belts making the developers happy. Sounds perfect, right, almost 344 00:16:46.879 --> 00:16:50.440 too perfect. Every technology has trade offs. The most prominent 345 00:16:50.519 --> 00:16:53.519 catch here is raw speed for specific types of heavy math, 346 00:16:53.600 --> 00:16:54.000 isn't it. 347 00:16:54.320 --> 00:16:58.440 Yeah, definitely. If you put erlang or elixer in a 348 00:16:58.519 --> 00:17:01.679 synthetic benchmark race against a low level language like C 349 00:17:02.000 --> 00:17:04.240 or C plus plus to see who can crunch a 350 00:17:04.279 --> 00:17:08.319 massive complex mathematical algorithm, the fastest C will win easily. 351 00:17:08.759 --> 00:17:10.880 But the beam wasn't really built for that kind of 352 00:17:10.960 --> 00:17:11.920 raw speed anyway. 353 00:17:12.079 --> 00:17:14.440 No, the goal is predictability. I mean, if a C 354 00:17:14.599 --> 00:17:17.720 server gets hit with a massive, crushing wave of traffic, 355 00:17:18.359 --> 00:17:22.079 it might process the first few requests incredibly fast, but 356 00:17:22.119 --> 00:17:25.039 then it could freeze entirely or crash, leaving thousands of 357 00:17:25.119 --> 00:17:26.480 users completely locked out. 358 00:17:26.559 --> 00:17:29.960 Whereas earling is designed to degrade gracefully exactly so under 359 00:17:30.000 --> 00:17:32.119 heavy load, the app might take an extra second to 360 00:17:32.119 --> 00:17:34.960 load a message, but the message will absolutely load the 361 00:17:35.000 --> 00:17:36.079 system stays alive. 362 00:17:36.319 --> 00:17:38.720 That is the ultimate trade off. If you are building 363 00:17:38.720 --> 00:17:41.920 a heavy video encoding platform or a three D rendering engine, 364 00:17:41.920 --> 00:17:44.759 where raw mathematical speed is the only metric that matters, 365 00:17:45.079 --> 00:17:47.160 you shouldn't write it in an Elixir. You would write 366 00:17:47.279 --> 00:17:51.440 that highly specific component in a lower level language and 367 00:17:51.559 --> 00:17:55.440 let Elixer act as the manager, handling the network traffic 368 00:17:55.519 --> 00:17:56.960 and keeping the server stable. 369 00:17:57.119 --> 00:17:59.799 That makes total sense. Now. The second catch the author 370 00:17:59.799 --> 00:18:02.119 par points out is the size of the ecosystem. 371 00:18:02.200 --> 00:18:03.160 Yeah, that's true. 372 00:18:03.359 --> 00:18:05.279 Back when this book was written in twenty fifteen, if 373 00:18:05.319 --> 00:18:08.160 you looked on GitHub, there were over six hundred thousand 374 00:18:08.240 --> 00:18:12.799 code repositories for Ruby. For Erlang there were about eleven thousand, 375 00:18:13.240 --> 00:18:15.240 and for Elixer just two thousand. 376 00:18:15.480 --> 00:18:18.039 It is a much smaller pond, for sure. Yeah, and 377 00:18:18.240 --> 00:18:21.599 while the ecosystem has grown significantly since the book's publication, 378 00:18:22.519 --> 00:18:25.119 you still might not find a pre built plug and 379 00:18:25.160 --> 00:18:28.200 play library for every obscure third party service you want 380 00:18:28.240 --> 00:18:31.400 to connect to. You might have to write that integration yourself. 381 00:18:31.160 --> 00:18:33.079 Right, You're paving your own road sometimes a bid. 382 00:18:33.160 --> 00:18:34.920 Yeah. But the author makes a point to note that 383 00:18:34.960 --> 00:18:38.000 the Elixir community is exceptionally welcoming and supportive. 384 00:18:38.240 --> 00:18:40.480 Well bringing this all together for you. What we've explored 385 00:18:40.519 --> 00:18:43.480 today is really a brilliant marriage of two different eras 386 00:18:43.480 --> 00:18:44.079 of computing. 387 00:18:44.200 --> 00:18:45.039 Yeah, it really is. 388 00:18:45.319 --> 00:18:48.359 On one hand, you have Erlang and the Beam, a 389 00:18:48.680 --> 00:18:52.079 battle tested, fault tolerant engine designed to keep the nineteen 390 00:18:52.119 --> 00:18:54.400 eighties phone grid alive through anything. 391 00:18:54.440 --> 00:18:57.559 And on the other hand, you have alixer, a modern 392 00:18:57.960 --> 00:19:01.920 boilerplate free interface that makes writing code a joy. 393 00:19:02.799 --> 00:19:06.759 Combined, they give small engineering teams incredible leverage. They can 394 00:19:06.799 --> 00:19:12.000 build massive, reliable Internet services that handle millions of users, instantly, 395 00:19:12.039 --> 00:19:16.119 isolate errors, and deploy complex updates on a single machine 396 00:19:16.119 --> 00:19:19.079 without relying on a fragile zoo of different technology. 397 00:19:18.599 --> 00:19:19.559 To incredibly powerful. 398 00:19:19.720 --> 00:19:22.519 Yeah. But there's one final concept from the book that 399 00:19:22.519 --> 00:19:24.880 steps outside the realm of code entirely, and I think 400 00:19:24.920 --> 00:19:26.440 it's something really worth mulling over. 401 00:19:26.559 --> 00:19:27.000