Speaker 1: So imagine trying to change the tires on a car
Speaker 1: while you're driving down the highway at like seventy miles
Speaker 1: an hour.
Speaker 2: Right, which sounds completely terrifying.
Speaker 1: Yeah, exactly, But I mean that is literally what software
Speaker 1: engineers are expected to do every single.
Speaker 2: Day, oh for sure. Because when you open an app,
Speaker 2: you know, like WhatsApp, you just expected to work instantly.
Speaker 1: Yeah, even if developers are like deploying these massive software
Speaker 1: updates to the system right there in the background.
Speaker 2: You don't even notice it.
Speaker 1: Right, So today's deep dive is exploring the hidden engine
Speaker 1: behind that modern miracle of well always on reliability. We're
Speaker 1: going to be unpacking excerpts from a really fascinating book
Speaker 1: called Elixir in Action by Sasha Jurich, published by Manning.
Speaker 2: Yeah, and before we really delve into the whole technical
Speaker 2: architecture side of things, the physical book itself has a
Speaker 2: couple of charming details I think you're worth.
Speaker 1: Noting, Oh, right, like the dedication exactly.
Speaker 2: The author dedicates the work to his wife, Arnada, which
Speaker 2: is sweet. But the publisher also chose a very specific
Speaker 2: piece of cover art.
Speaker 1: Right. It's an illustration, isn't it.
Speaker 2: Yeah, it's called a Russian Girl from Thomas Jeffrey's eighteenth
Speaker 2: Century Trust Collection and Back of the seventeen hundreds. Those
Speaker 2: illustrations highlighted the incredible diversity of global cultures. Oh wow,
Speaker 2: so here the publisher is kind of using it as
Speaker 2: a nod to the vast interconnected ecosystem of computer systems
Speaker 2: we're about to explore.
Speaker 1: I love that, and I mean to really understand that ecosystem,
Speaker 1: we kind of need to look at the author's own
Speaker 1: breaking point. Right.
Speaker 2: Yeah, let's set the scene.
Speaker 1: So the year is twenty ten. Jurich is tasked with
Speaker 1: building a near real time push server. And this isn't
Speaker 1: like a small weekend project. It needs to handle thousands
Speaker 1: of connected users simultaneously without dropping a single connection.
Speaker 2: Which is a huge technical challenge totally.
Speaker 1: His company was primarily using Rubyon Rails, which is a
Speaker 1: very popular web framework. But as he's staring down this
Speaker 1: incoming wall of concurrent traffic, his CTO suggests he look
Speaker 1: into a language called erlang.
Speaker 2: And I mean Erling wasn't exactly the first tool a
Speaker 2: web developer reached for back in twenty ten, No, not
Speaker 2: at all. But Yurch builds this prototype. He runs the
Speaker 2: load tests, and the performance in the stability were just
Speaker 2: so absolute that he ended up rebuilding the entire system in.
Speaker 1: It wow, just scrap the old one pretty much.
Speaker 2: He even started a blog called the Erlangelist just to
Speaker 2: help other object oriented programmers wrap their heads around this
Speaker 2: strange yet really powerful tool.
Speaker 1: Right, and to see why Erling was such a revelation
Speaker 1: for him, we actually have to travel way back to
Speaker 1: the mid nineteen eighties.
Speaker 2: Yeah, time travel.
Speaker 1: Erline was created by a team at Ericsson led by
Speaker 1: the legendary software engineer Joe Armstrong, and Ericson is a
Speaker 1: Swedish telecom giant. They built Erlang specifically to run their
Speaker 1: massive telephone network switches.
Speaker 2: Right, And you might be sitting there wondering, well, why
Speaker 2: should you care about a programming language built for nineteen
Speaker 2: eighties landline phones?
Speaker 1: Right, Yeah, sounds pretty obsolete.
Speaker 2: But it comes down to the fund mental requirement of telecom,
Speaker 2: which is zero downtime. Ah right, Because in the eighties
Speaker 2: and nineties, if consumer desktop software crashed, I mean it
Speaker 2: was annoying, but it only affected one person.
Speaker 1: Just reboot your computer in your front exactly.
Speaker 2: A telecom network, however, had to be highly available fault
Speaker 2: tolerant and scalable without ever turning the machine off.
Speaker 1: Because you couldn't drop thousands of active phone calls just
Speaker 1: because a hardware component failed, or like an engineer uploaded new.
Speaker 2: Code exactly and fast forward to today, Suddenly everything you
Speaker 2: use has those exact same telecom level requirements.
Speaker 1: Cloud deployment platforms, massive multiplayer online games, social networks, all
Speaker 1: of it. Yeah, these are the modern equivalent of the
Speaker 1: global telephone grid. I mean, consider that when WhatsApp was acquired,
Speaker 1: they had hundreds of millions of users, but only about
Speaker 1: fifty engineers keeping the entire system.
Speaker 2: Running, which is mind blowing, right.
Speaker 1: And they achieved that impossible leverage because their system was
Speaker 1: built on the core DNA of.
Speaker 2: Erlink and that survival mechanism. It really comes down to
Speaker 2: Erlang's completely unique take on concurrency.
Speaker 1: Basically how computer juggles multiple tasks at once.
Speaker 2: Right there, because it doesn't rely on the heavyweight spreads
Speaker 2: and processes provided by your computer's operating system like Mac
Speaker 2: or Windows or Linux. Instead, it runs inside its own
Speaker 2: isolated virtual machine called the beam.
Speaker 1: Right, the beam that stands for a Bogden or Bjorn's
Speaker 1: erlaying abstract machine named after its creators obviously naturally, and
Speaker 1: instead of relying on the operating system, the beam just
Speaker 1: reinvents concurrency using its own incredibly lightweight processes. We aren't
Speaker 1: talking about a server handling a few hundred tasks here, no,
Speaker 1: not at all. A single Beam system can comfortably run
Speaker 1: thousands or even millions of these tiny processes at the
Speaker 1: exact same time.
Speaker 2: Yeah, and the book describes this as a shared nothing
Speaker 2: architecture because in traditional operating system threads, concurrent programming is
Speaker 2: incredibly difficult since process is share the same memory space.
Speaker 1: Okay, so let's picture traditional shared state concurrency as like
Speaker 1: a chaotic group project in a single conference room.
Speaker 2: I've been in a few of those, right.
Speaker 1: Everyone is fighting over the same single whiteboard to write
Speaker 1: down their ideas. That whiteboard is the shared.
Speaker 2: Memory, right, which creates constant bottlenecks because people are awaiting their.
Speaker 1: Turn exactly, and to keep them from talking over each other,
Speaker 1: developers have to write these complex locking mechanisms into the code.
Speaker 2: Oh and if someone accidentally knocks a whiteboard over.
Speaker 1: The entire project crashes. Everyone goes down, Yeah, which is
Speaker 1: a nightmare.
Speaker 2: But the Erlang process is on the Beam. They operate
Speaker 2: in a completely different reality. Ow So instead of one
Speaker 2: chaotic conference room, imagine you have a million remote workers. Okay,
Speaker 2: every single worker is sitting in their own, locked, isolated
Speaker 2: room with their own private whiteboard. They share absolutely nothing
Speaker 2: with each other.
Speaker 1: So how do they even talk?
Speaker 2: Well, if they need to coordinate, the only way they
Speaker 2: can communicate is by sliding little notes under the door,
Speaker 2: which Erlane calls asynchronous messages.
Speaker 1: Okay, that makes sense. And because they share no memory,
Speaker 1: the first massive benefit of that is fault tolerance.
Speaker 2: Absolutely.
Speaker 1: If one worker in their isolated room rates bad code
Speaker 1: and suddenly bursts into flames, which you know is a
Speaker 1: software crash, doesn't affect anyone else, Right, The.
Speaker 2: Fire cannot spread to the shared whiteboard because there is
Speaker 2: no shared whiteboard.
Speaker 1: Yeah, the system just sweeps out the ashes, places a
Speaker 1: brand new worker in the room, and the rest of
Speaker 1: the system literally doesn't even blink.
Speaker 2: And that isolation also solves the problem of resource hawking.
Speaker 1: Oh that's a big one, right.
Speaker 2: Because you might ask, well, what happens if a worker
Speaker 2: doesn't crash but just get stuck trying to solve some
Speaker 2: massively heavy mathematical equation.
Speaker 1: Yeah, does the rest of the system freeze up waiting
Speaker 1: for them to finish. Well.
Speaker 2: In standard systems, yeah, a heavy task can easily choke
Speaker 2: the central processor, yeah, and cause the whole app to
Speaker 2: become unresponsive for everyone else.
Speaker 1: But the beam has a preemptive scheduler, right, which acts
Speaker 1: like a highly strict manager walking the halls.
Speaker 2: Yeah, and the way this manager works is actually fascinating.
Speaker 2: Doesn't track time on a clock, yeah you know, it
Speaker 2: tracks reduction reduction, right, which is essentially counting the number
Speaker 2: of function calls a worker makes. Once a worker hits
Speaker 2: a specific limit, say two thousand function calls the walk,
Speaker 2: the manager forces them to pause, saves their exact state,
Speaker 2: and moves on to the next worker.
Speaker 1: Oh wow, So by counting operations rather than milliseconds, the
Speaker 1: scheduler ensures total fairness exactly. Even if a worker is
Speaker 1: doing the heaviest database crunching imaginable, they are forcibly paused
Speaker 1: when their turn is up. The manager just keeps the
Speaker 1: line moving.
Speaker 2: Yeah, meaning your simple web request never gets stuck behind
Speaker 2: someone else's massive data download. The system just remains remarkably
Speaker 2: responsive under intense pressure.
Speaker 1: And because these isolated workers aren't sharing that central whiteboard,
Speaker 1: it solves another massive headache for developers, which is cleaning
Speaker 1: up memory.
Speaker 2: Oh yeah, garbage collection.
Speaker 1: Right. In standard systems, when the computer needs to sweep
Speaker 1: up unused data, it often has to pause the entire
Speaker 1: system to safely clear the shared.
Speaker 2: Memory, and for you, the user, that looks like a
Speaker 2: frozen screen or you know that infinite buffering wheel the worse.
Speaker 1: But in Erlang, garbage collection happens individually per process. One
Speaker 1: remote worker just takes out their own tiny trash can
Speaker 1: in their own isolated.
Speaker 2: Room, while the other nine hundred and ninety nine thousand
Speaker 2: workers just keep typing away.
Speaker 1: Right. There are never any massive system wide pauses that
Speaker 1: degrade the user experience, and.
Speaker 2: This total isolation fundamentally changes how developers build entire server architectures.
Speaker 2: How So, the book actually gives a real life comparison
Speaker 2: of two web servers to highlight this. So server A
Speaker 2: represents a standard modern setup. It's a patchwork quilt of
Speaker 2: different specialized technologies.
Speaker 1: So you might have one piece of software answering the
Speaker 1: web praffic, a completely different language processing the business logic.
Speaker 2: Right, and an external memory database holding onto users shopping carts,
Speaker 2: plus a separate scheduling tool running background jobs at midnight.
Speaker 1: Wow. Yeah, the author affectionately calls this the server side zoo.
Speaker 2: Exactly. You have all these different animals, all these independent
Speaker 2: moving parts loosely tied together with network cables to build
Speaker 2: one application.
Speaker 1: And if any one of those independent pieces fails or
Speaker 1: loses connection, the whole house of cards basically it comes down.
Speaker 2: Yeah, it's fragile, but sir B, on the other hand,
Speaker 2: handles the web traffic, the business logic, the temporary user states,
Speaker 2: and the background jobs using only early just one language. Yeah.
Speaker 2: It relies on a battle tested framework build directly into
Speaker 2: the language called OTP or Open Telecom Platform.
Speaker 1: Okay, I've heard of that.
Speaker 2: Yeah. OTP provides standardized templates like something called a gen server,
Speaker 2: which stands for Generic Server. A gen server handles all
Speaker 2: the complex logic of how processes should communicate, how they
Speaker 2: should store data safely, and exactly how they should be restarted.
Speaker 1: If they crash, and the developer doesn't have to reinvent
Speaker 1: the wheel every time.
Speaker 2: Right. It allows you to build a highly available, cohibited
Speaker 2: system entirely inside a single technology stack running on a
Speaker 2: single machine.
Speaker 1: Okay, let me push back on this monolith approach, though, sure,
Speaker 1: because as someone who builds systems, relying on a jack
Speaker 1: of all trades tool for everything usually ends in disaster.
Speaker 2: I get that.
Speaker 1: I mean a Swiss army knife is great for a
Speaker 1: camping trip, but you wouldn't use the tiny sawblade to
Speaker 1: build house, right. Shouldn't developers use specialized external tools for
Speaker 1: things like caching or background processing because those tools have
Speaker 1: spent years perfecting that one specific job.
Speaker 2: Is a very valid criticism, honestly, But the key distinction
Speaker 2: here is that erlank isn't forcing you into a closed box.
Speaker 1: Oh it's not.
Speaker 2: No, It's completely capable of talking to external databases or
Speaker 2: message cues when you need them. If you require raw
Speaker 2: speed for a highly specific task like heavy image processing,
Speaker 2: erlang allows you to run fast c code natively alongside it.
Speaker 1: Okay. Interesting.
Speaker 2: What erling provides is the option of a homogeneous system
Speaker 2: from day one.
Speaker 1: So you aren't forced to manage the whole zoo when
Speaker 1: you're just starting.
Speaker 2: Out precisely, I mean, in the early days of a
Speaker 2: startup or for small engineering teams, Deploying and maintaining five
Speaker 2: different databases and languages across multiple servers is an operational light.
Speaker 1: It just too much overhead.
Speaker 2: Exactly, Erling lets a tiny team build a massive, robust
Speaker 2: system out of the box. You only bolt on those
Speaker 2: specialized external tools when you truly hit the limits of
Speaker 2: what the bean can do, which takes a very, very
Speaker 2: long time.
Speaker 1: Well, if erlang is this indestructible supertool, it raises an
Speaker 1: obvious question. I think, why did anyone feel the need
Speaker 1: to invent alixer. I mean, why isn't every developer on
Speaker 1: Earth just writing raw arline code right now?
Speaker 2: Well, the answer comes down to the simple act of
Speaker 2: typing it out. Yeah. Erling was designed in the nineteen eighties,
Speaker 2: and its syntax really reflects that era. It is notoriously dense,
Speaker 2: highly repetitive, and frankly kind of jarring to modern programmers.
Speaker 1: Right. It's the classic critique of the language. It makes
Speaker 1: the hardest problems in computer science, like distributed concurrency fault
Speaker 1: tolerance look incredibly easy, but it makes simple things like
Speaker 1: defining a basic module or adding numbers together bizarrely hard
Speaker 1: and verbose.
Speaker 2: Yeah. But then the author discovered Elixer around its zero
Speaker 2: point eight release.
Speaker 1: Right. Elixer was created by a developer named Jose Valim.
Speaker 2: And Jurige realized immediately that Elixir was the perfect bridge,
Speaker 2: because the magic of Elixir is that it compiles down
Speaker 2: to the exact same beam bytecode as Erlang.
Speaker 1: Oh wow, so you don't lose a single drop of
Speaker 1: Erlang's performance or its twenty four to seven reliability.
Speaker 2: Nope, you are still driving the exact same, indestructible nineteen
Speaker 2: eighties telecom engine. Elixer just replaces the rusty dashboard with
Speaker 2: the sleek, modern, developer friendly interface.
Speaker 1: And it aggressively fixes Erlang's boilerplate problem. The book highlights
Speaker 1: a really specific.
Speaker 2: Example, right the addition one.
Speaker 1: Yeah, so you want to write a tiny server process
Speaker 1: in Erlang, whose only job is to add two numbers together.
Speaker 1: Doing this requires typing out a massive, noisy block of
Speaker 1: boilerplate code just to set up the process is so tedious. Yeah,
Speaker 1: The structure is so tedious that veteran programmers don't even
Speaker 1: type it out. They literally copy and paste it from
Speaker 1: older projects just to get to the one line of
Speaker 1: code that actually does the math, which.
Speaker 2: Creates totally unnecessary cognitive load for the developer. But Elixer
Speaker 2: shrinks this dramatically.
Speaker 1: Yeah. The author actually built a custom Elixer library called exactor.
Speaker 1: To prove this exact point, he took that massive, ugly
Speaker 1: block of Erling boilerplate and used Elixer to trink it
Speaker 1: down to just a couple of lines of beautiful readable code.
Speaker 2: Which is awesome. And the mechanism Elixer uses to achieve
Speaker 2: this shrinkage is its secret weapon macros.
Speaker 1: Now, when people hear the word macro, they often think
Speaker 1: of older languages like see where a macro is essentially
Speaker 1: a glorified find and replace.
Speaker 2: Right, It just looks for a string of text and
Speaker 2: swaps it out for another string of text before the
Speaker 2: program runs.
Speaker 1: But Elixer macros are far more intelligent, aren't they.
Speaker 2: Oh? Yeah, Elixir macros operate on what is called the
Speaker 2: abstracts and tax tree, or the AST.
Speaker 1: Okay, to put that in plain English, think back to
Speaker 1: grade school when you had to diagram a sentence. You
Speaker 1: didn't just read the words. You mapped out the noun,
Speaker 1: the verb, and the subject exactly.
Speaker 2: And the AST does that for code. The macro isn't
Speaker 2: just looking at the letters you typed. It understands the
Speaker 2: actual grammar and structural logic of your program at compile time.
Speaker 1: Wow. And this deep structural understanding allows developers to write
Speaker 1: code that writes other code. You can flesh out all
Speaker 1: that repetitive boilerplate before the program even runs.
Speaker 2: Yeah, it empowers developers to create tools that feel like
Speaker 2: native parts of the Elixer language itself.
Speaker 1: A great example from the book is the Ecto project,
Speaker 1: which basically helps Elixer talk to databases.
Speaker 2: Right in many languages, if you want to pull user
Speaker 2: data from a database, you have to write raw, clucky
Speaker 2: SQL database strings right in the middle of your clean
Speaker 2: application code. It's so ugly it is, but Ecto uses
Speaker 2: macros to let developers write database queries that look and
Speaker 2: behave exactly like native Elixer code. It feels completely seamless.
Speaker 1: And that seamlessness carries over into how you string ideas
Speaker 1: together too. Elixer fundamentally changes the flow of data with
Speaker 1: something called the pipeline operator yes.
Speaker 2: Which is a huge shift from Erling because in Erlang,
Speaker 2: if you want to pass a piece of data through
Speaker 2: a series of transformations, you have to use a technique
Speaker 2: called staircasing.
Speaker 1: Right, you take the raw data, pass it to the
Speaker 1: first function, and you have to invent a temporary name
Speaker 1: for the result like data one. Then you pass data
Speaker 1: one into the second function and save the result as
Speaker 1: data too.
Speaker 2: It's exhausting. It forces the developer to read the code
Speaker 2: inside out, you know, navigating a cluttered mess of temporary
Speaker 2: variables just to track how the data is changing.
Speaker 1: I like to think of arline staircasing as like a
Speaker 1: clumsy bucket brigade where people are splashing water everywhere and
Speaker 1: fumbling the hand off. That's a great visual, Whereas Elixer's
Speaker 1: pipeline operator is a perfectly calibrated factory conveyor belt.
Speaker 2: Yeah. The operator literally looks like a simple little arrow
Speaker 2: made of a vertical line and a greater than oh cool.
Speaker 2: And the pipeline operator takes the result of one function
Speaker 2: and feeds it directly into the next function. As the
Speaker 2: very first argument.
Speaker 1: So you drop the raw material at the start of
Speaker 1: the belt and it glides seamlessly through machine A straight
Speaker 1: into machine B, thraight into machine C. It removes all
Speaker 1: the temporary variables and leaves you with pure logic. You
Speaker 1: read the code exactly as a human thinks. Take this data,
Speaker 1: transform it here, filter it there, and save it.
Speaker 2: It really creates a state of flow for the developer
Speaker 2: which translates to fewer bugs and faster future development.
Speaker 1: Okay, so we have this bulletproof nineteen eighties telecom engine
Speaker 1: in the beam, ensuring the system never crashes. We have
Speaker 1: this beautiful modern dashboard and Elixir with intelligent macros and
Speaker 1: conveyor belts making the developers happy. Sounds perfect, right, almost
Speaker 1: too perfect. Every technology has trade offs. The most prominent
Speaker 1: catch here is raw speed for specific types of heavy math,
Speaker 1: isn't it.
Speaker 2: Yeah, definitely. If you put erlang or elixer in a
Speaker 2: synthetic benchmark race against a low level language like C
Speaker 2: or C plus plus to see who can crunch a
Speaker 2: massive complex mathematical algorithm, the fastest C will win easily.
Speaker 1: But the beam wasn't really built for that kind of
Speaker 1: raw speed anyway.
Speaker 2: No, the goal is predictability. I mean, if a C
Speaker 2: server gets hit with a massive, crushing wave of traffic,
Speaker 2: it might process the first few requests incredibly fast, but
Speaker 2: then it could freeze entirely or crash, leaving thousands of
Speaker 2: users completely locked out.
Speaker 1: Whereas earling is designed to degrade gracefully exactly so under
Speaker 1: heavy load, the app might take an extra second to
Speaker 1: load a message, but the message will absolutely load the
Speaker 1: system stays alive.
Speaker 2: That is the ultimate trade off. If you are building
Speaker 2: a heavy video encoding platform or a three D rendering engine,
Speaker 2: where raw mathematical speed is the only metric that matters,
Speaker 2: you shouldn't write it in an Elixir. You would write
Speaker 2: that highly specific component in a lower level language and
Speaker 2: let Elixer act as the manager, handling the network traffic
Speaker 2: and keeping the server stable.
Speaker 1: That makes total sense. Now. The second catch the author
Speaker 1: par points out is the size of the ecosystem.
Speaker 2: Yeah, that's true.
Speaker 1: Back when this book was written in twenty fifteen, if
Speaker 1: you looked on GitHub, there were over six hundred thousand
Speaker 1: code repositories for Ruby. For Erlang there were about eleven thousand,
Speaker 1: and for Elixer just two thousand.
Speaker 2: It is a much smaller pond, for sure. Yeah, and
Speaker 2: while the ecosystem has grown significantly since the book's publication,
Speaker 2: you still might not find a pre built plug and
Speaker 2: play library for every obscure third party service you want
Speaker 2: to connect to. You might have to write that integration yourself.
Speaker 1: Right, You're paving your own road sometimes a bid.
Speaker 2: Yeah. But the author makes a point to note that
Speaker 2: the Elixir community is exceptionally welcoming and supportive.
Speaker 1: Well bringing this all together for you. What we've explored
Speaker 1: today is really a brilliant marriage of two different eras
Speaker 1: of computing.
Speaker 2: Yeah, it really is.
Speaker 1: On one hand, you have Erlang and the Beam, a
Speaker 1: battle tested, fault tolerant engine designed to keep the nineteen
Speaker 1: eighties phone grid alive through anything.
Speaker 2: And on the other hand, you have alixer, a modern
Speaker 2: boilerplate free interface that makes writing code a joy.
Speaker 1: Combined, they give small engineering teams incredible leverage. They can
Speaker 1: build massive, reliable Internet services that handle millions of users, instantly,
Speaker 1: isolate errors, and deploy complex updates on a single machine
Speaker 1: without relying on a fragile zoo of different technology.
Speaker 2: To incredibly powerful.
Speaker 1: Yeah. But there's one final concept from the book that
Speaker 1: steps outside the realm of code entirely, and I think
Speaker 1: it's something really worth mulling over.
Speaker 2: Ah yah.
Speaker 1: Throughout this deep dive, we've explored Erlang's core philosophy of isolation.
Speaker 1: When a process crashes, it's trapped in its own room,
Speaker 1: the fire doesn't spread, and the rest of the system survives.
Speaker 2: Right, which is known as the let it crash philosophy.
Speaker 1: Let it crash.
Speaker 2: I love that it embraces the reality of failure rather
Speaker 2: than fighting a losing battle against it.
Speaker 1: And in most traditional software, and honestly, in most traditional
Speaker 1: human systems, we obsess over making everything fail safe.
Speaker 2: We do. We try to prevent every possible error right.
Speaker 1: We micromanage every detail operating under the asumption that if
Speaker 1: one tiny component goes wrong, the whole company or the
Speaker 1: whole project will collapse. But Erlang proves that perfect prevention
Speaker 1: is a myth.
Speaker 2: Instead, it is designed to be safe to fail exactly.
Speaker 1: It accepts that things will break, and it optimizes for
Speaker 1: rapid recovery instead of impossible perfection.
Speaker 2: Fail Safe is about preventing the crash. Safe to fail
Speaker 2: is about surviving it.
Speaker 1: So what if we implied this isolation philosophy to human systems.
Speaker 1: What if in our corporate organizations, our team management, or
Speaker 1: even how we handle our own personal missteps, we just
Speaker 1: stop trying to be flawless.
Speaker 2: It would take a lot of pressure off.
Speaker 1: It really would. What if we built boundaries that allowed
Speaker 1: us to say, let it crash, knowing that the overall
Speaker 1: system or our own resilience is strong enough to sweep
Speaker 1: up the ashes, learn from the air, and keep the
Speaker 1: line moving.
Speaker 2: That's a great perspective.
Speaker 1: Yeah, it's definitely something to think about the next time
Speaker 1: you open a massive app on your phone and miraculously
Speaker 1: it just works. Thanks for joining us on this d
Speaker 1: DVE