 So, I think it's very important to be able to communicate this excitement that's in this room to our bosses so that we can do the work on the language that we want to work on, right? And to do that, we need to understand what's happening, what's happened before, and how that impacts what's happening now. So we could tell our bosses why the cool kids are leaving the room for other platforms, why we're seeing the performance numbers that we're seeing for the Elixir language, and basically why this way of building software is fundamentally better for the problems that we're trying to solve, right? So the roots of this talk actually started, the roots started, has, have, had, so the roots of this talk came from back, I guess, maybe 2004, when I was sitting down with Dave Thomas, and we were looking at some, some talk about COBOL, we were saying, hey, that looks a lot like the web today. And I started thinking then that we were starting to see recurring patterns that weren't exactly the same, but they were similar enough to, to bear some thinking about. I didn't really have, never really congealed until this year, and when, when Jose and I were talking over the programming Phoenix book, and we were talking about a modified NBC. And I said, wait a minute, we've seen this before. So anyway, this talk is about a pendulum, and there's a literal definition and a figurative definition, and this is the literal definition, basically a weight that's swinging back and forth in a fixed period of time, but there's also a figurative definition, and this is the one that we're going to use today, and especially the tendency to oscillate back and forth. If this one isn't going to be every couple of seconds, this one is going to be every 10 or 15 years or so. This is the pendulum that swings between request, response, style, where each request is an isolated thing that's basically stateless to a much more interactive style user interface where everything is more staple. We call these terms batch and interactive, and some of you may be too young to know what batch means, but basically, in batch processing, before there were really terminals, so I would say we, but I've never used a punch card. I had some friends two years before I went to college that had to submit punch cards, but basically you'd use punch cards or tape, and you would submit a batch program, and then they would all run, and you would get an output, and that's how we would do most of our work, and eventually somebody got the idea to put a terminal on the computer and take that form, and then you would fill out the form, and that would submit, and you would run a batch program. So now we're loading the pendulum for the first time, right? So that you have this form and you tie it to a batch script, which most of them turned out to be COBOL programs, and probably the first application that I remember working on that had been built in this way, I didn't work on this version of it, but it was called the Saber System, and if you were replacing an airline reservation any time in the 60s or probably most of the 70s, you were using some form of Saber. This is what it looked like, you know, that's a mainframe, those are terminals, they're not smart terminals, they're dumb terminals, and they're basically hardwired together, and you would have many, many agents sitting behind desks making reservations. Maybe they're sitting on the other side of a phone, or maybe they're sitting in an airport, and I was kind of flipping through looking for pictures of these agents, and I found an actual Saber output screen, I thought that was pretty cool. And this is some of the language that IBM used to brag about the Saber reservation system, because they were a partner in all of this, you know, I like that. So let me read you the full quote. The Saber reservation system for airline passengers was the first large, high-speed commercial, computer communications network that operated in real time, handling transactions at the time they occurred, okay? So now we have the loaded pendulum, right? We have a batch, we have a request response. That sounds a little familiar to anyone yet? So basically, these were templates, right, and they kind of mirror the request response that we used in the Internet until probably about ten years ago. And it had a pretty significant impact on the cobalt language, right? Not just the language itself, the structure, and, you know, the key words and things, but the actual language that they chose to represent their data types. Take a look at that. Why would we use the word picture? Well, because it's describing the data type on the form, right? So that literally shaped the way that the cobalt language was designed and built. So this is where we lived for a long time until the pendulum started to swing the other way, and I think the thing that started to make it swing was the invention of the computer. This was my first computer, well, one like that. It was a RadioShack Color Computer. I remember it had 4K of memory, and that's for programs and everything, 4K, right? And when we wanted more memory, we needed to learn how to solder. I didn't know how to solder, but I had a friend whose dad knew how to solder. And so we would take a 16K chip, right? We'd pull the 14K chip out, and we'd have to, you know, uns solder all these pins, and then we got another 16K chip because he knew more about computer architecture than I did, and he basically broke off one of the pins and soldered all the other pins together, piggybacking them together. So now I had a 32K system, right? And then right after this thing came out, we had the IBM PC, I bought a clone. I brought a plain vanilla clone, and so I was writing games to make my spending money in high school, but they were in basic and they moved kind of like this, but there was a cool application that came out on the Apple computer at around the same time that started to change the way that we thought about user interfaces. It was really the first business application for a personal computer, and that was called Visacalc, right? Visacalc is really a functional program in a functional programming language. But what was cool was that since it was running locally, the request response feedback loop was immediate. You change the number in here and the whole sheet would recalculate at once, right? And around the same time, so this would have been the early 80s, probably just prior to that, we started to see work come out of a group called Parklase, right? And so when I was googling around for period-specific design patterns, I found this one and this is the model view controller work that came out of Xerox and later into Parklase. And this is a recurring pattern that we're going to see that kind of moves with the pendulum, and so keep that in the back of your mind, right? But they started talking about, you know, it's not enough just to have this request response architecture because really there's no intermediate design, right? There, the design of the user interface becomes the design of your system, and we needed to break that apart so that the software would be more adaptable. And so another thing that started to happen as we were building, as the personal computers grew up, we started to have graphical user interfaces. This happened primarily on Windows and, you know, there was an X-Windows system. IBM was working on this thing called presentation manager that eventually rolled into this thing called OS2. And my first job out of college was with IBM. And the first real commercial application that I was exposed to was one that was supposed to take a Wall Street developer. And they were still working on these request response type systems. There was a giant stock feed on the wall that everyone used, but what they wanted was their little personalized feeds. And they wanted to be able to see, you know, beautiful graphs that were kind of updated in real time as things were happening so that they could make more informed buying decisions. And this didn't fit at all this request response type of application, right? But if you think about it, a lot of work had to happen to move us from that hard wired mainframe where IBM was making most of their money. And to bring that down to a server sized unit and then to communicate down to the client. And if you looked at what we were really after, we wanted a user interface that we could put on these ticker tapes, right? So this is actually what we were building toward. If you look at those user interfaces and this is kind of a Wall Street war room. And this was the first part of IBM solution. This is actually, I saw this screen for the first six months of my IBM career, right? So when you were installing OS2, there was a version called OS2's Extended Services. And it had four main parts. It had the operating system. It had the database manager and I was kind of part of the database manager team. That was my focus in college. It had a land manager for the local area networking. And it had a communications manager. And the job of the communications manager was to take those green screen applications and literally scrape off the data. So we would send commands to change to basically process input and send the data back up to the main frame so that the main frame software didn't have to change. Zoom in on there, you can see each of the little pieces that we had. So you can see exactly where IBM was going, right? The thing was, the languages of the time didn't support this vision. So IBM had to make a big bet. It's a pretty radical bet to have end users developing applications in C. This is a systems language. And there were a lot of embedded bets with the C bet. The first one is that we had to be multiprocessed, right? So this is a language that doesn't really support concurrency that well, except to say, you can fork, you can return. There's no real guarantees or protection that we're used to on the elixir side. The other thing that had to happen was we could not stop the world for garbage collection. So we had to make another bet with NC that we would manage our own memory. There's some good things with a solution like this. That's, we can control when the garbage collection happens. There's some trade-offs too, oops, did you guys catch that? So what does this program do if I get it wrong in that way? We don't know, it goes stomping through the memory, right? And so remember, these are not programmers, right? These are not systems programmers by trade. These are application programmers and expert and customer applications, right? So this is kind of what we were building architecturally. You had your clients and servers and so we started to call those client server tier applications. And somebody at IBM said, no wait, there's a big dollar sign missing from this vision and that's the main frame. We have to get that, you can no longer say client server. You need to say end tier, right? And we started so we changed all the marketing collateral from client server to end tier and we're okay with that now. But that meant that this setup was extraordinarily difficult to implement. So let's zoom in on one of those servers. So you have these tiny little applications. That's runs in a process. You have a land manager and that connection runs in another process. You have a database manager that ran in its own process at the time. You had that communications manager where we were kind of screen scraping. And so you had four processes each and that eventually collapsed under its own weight. And it wasn't just the weight of the processes, right? It was also the weight of the mental model of managing all your own memory, of managing all of your own concurrency, of trying to deploy all this stuff. So this stuff, so our bet on C in some ways backfired pretty tremendously. So you started to see IBM make another bet. We bought this company called OTI, Object Technology International. And with it, does anybody know what this icon is? Visual age, who said that? That is awesome. So visual age for small talk, which turned into a visual age for Java, which turned into Eclipse, right? So you have this, okay, you gotta put your conspiracy glasses on. Has everybody got them on? So that blue and white striped thing is in front of the sun. Right, sun, Java, the blue and white striped thing, the IBM logo. This is an open thing, right? So anyway, we're getting ahead of ourselves. So, anyway, Microsoft also knew that we had a problem, right? They attacked the enterprise in a very different way, right? So you had this beautiful system called Windows, and it was released right before IBM released their presentation manager and they know us too, right? And it was released to the mass consumer. And when this happened, there was a application that was released that had a tremendous impact on productivity of business people everywhere. And you guys know what that is, right? Just kidding. So it was office. And basically, the line of business people were actually looking at the people that ran the development organizations. And those guys were working on beautiful client server applications that were supposed to be fast and seamless, and they were all way, way behind, right? And Microsoft came in and said, okay, we'll let you run office and we'll let you script it with Visual Basic, right? And when you run it with Visual Basic, you'll be able to deliver your own applications, right? And so these are not professional developers either. These are line of business people, right? And they're writing programs and every Microsoft Visual Basic program had this magic okay push button, right? And then you would run this prototype and you would attach a script to do something, you'd say, hey, it works. And then you would cram a little bit more code in there, right? And you would say, hey, it really works until you had 10K of code hanging off of that okay push button, right? And we have the same problem again, right? Where the design of the application, the design of the user interface is the design of the application, which is precisely the wrong design if you're trying to build something long term, right? And so it turned out that this happened, right? You had 10K of code hanging off, 10,000, 10Ks of code hanging off of push buttons everywhere across the enterprise. And they said to the IT department, help and the IT department said we can, right? Things were cratering, we couldn't deploy this stuff, we couldn't manage this stuff. And all the tears couldn't fit together, right? Think about it, which version of Visual Basic are you running? Which version of Windows is that running on? Which version of the database manager is that running on? Which version of the land manager is that running on? Oh, I've got a break, okay, I'll fix the land manager. Which version of Windows is that? And that kind of had a circular dependency problem that there was no way to change, right? And the marketing folks at IBM called that DLL hell because that was really starting to resonate with our customers. So this exploded for a very different reason, right? It was crusty and slow but it exploded because it was too difficult to manage this intellectually. So we're here with a pendulum all the way on the interactive side. And nobody's happy because we can't make this stuff work and we can't make this stuff scale. So we started to work on small solutions that would make incremental pieces of this scale. For example, the database, everybody knows the answer to this problem that's worked on databases before. How do you solve this problem with millions of users connecting to the same database? Connection pool, right? That's what you do. You basically say, you basically build an API between the application and the connection pool and from the physical connected, you leave the bottom ones connected. And basically there's a round robin service to the applications on the other side of the pool, right? So really, instead of doing something like this, we did something like this, right? And we did the same thing. We were looking for the same type of thing to manage applications, right? How do you handle this round trip communication to scale for a better application model? And IBM was taking many, many different cracks at this problem and so was the rest of the industry. I know it from an IBM perspective because that's where I was for 15 years or so. Well, first we had this thing called distributed computing environment. And then after C and C++ were released, we had objects, but not everyone wanted to bet on C++. So we wanted to build this layer around objects so that you could plug any arbitrary language into an object model, called the system object model. And the language would own everything except how the objects interacted with each other, right? Terrible idea, but we double down on it, right? We said, okay, what we really need to make this work is to make it distributed, right? And then it wasn't really successful. So we said the reason it's not successful is that it can't talk to the other object brokers in the industry. Right? And we failed. So the pendulum starts swinging to the other side and now we start to see the proliferation of the internet. This is, which one is that? That's CompuServe. Does this look familiar? That's the same old green screen stuff and the customer said I don't really want that. But this stuff scaled, right? It is the old stuff. It's the same model except we're running over a modem instead of that hard, that hard wire. So the pendulum keeps drifting slowly to the other side because your request response is easy to manage until somebody built a beautiful windowed browser that wrapped around that request response metaphor. Right? It's really the same old stuff. But it has this thing called HTML and that markup. And that markup could give you a more beautiful page, right? So then we started wondering how do I make this scale to thousands of people with a business application? So this was a cool insight. This is kind of the crux of the talk. So that looks familiar, right? That stuff is all the state. Okay, I'm gonna get cheesy for a second. What's that movie? 50 First Dates. Yeah, so she can remember short things just fine. She forgets everything at the end of the day, right? And basically the day is a web request, right? And the whole movie is about all the work that they have to do to learn how to have a meaningful long-term conversation. And all the things that she does to help herself remember what's happened. They make videos and she does a diary. So yeah, this is effectively what we did to make the web work, right? We gave our applications a lobotomy, right? We made them forget, right? So we broke that, we cut that cord right there. We shoved the state way off in a corner, somewhere else. We built a connection pool for the web. That's what a request response web server is. It's a connection pool for the web, right? We don't know how to mass produce these whole applications with these tiny conversation elements. We know how to mass produce these, right? And you've seen these things named different things. While I was at IBM, we started calling it the session facade. Remember Enterprise Java Beans? And we said, no, no, no, you can do that with a plain ordinary Java bean. We had an acronym for it called a POJO. And then we said, okay, we'll call it a command pattern. And then we renamed that, we said, hey, wait a minute. This is Model View Controller, except not really. It's Model View Controller, we called it Model 2, right? A request response version of Model View Controller. This is the second time you're gonna see this chart, okay? And while you're thinking about this and wondering, why didn't I think of that great idea? Well, you've got the benefit of history. So you know that there's a hole here, right? What happens between those requests, right? What happens here? Who has the job of managing the state? I do, you do, right? Okay, so I want you to hear this. I want you to hear this. There's some good things about this responsibility. Statelessness is important sometimes, right? The approach is standardized, much greater scale, much simpler code. There are also some downsides. See that bug on the bottom? Yeah, so I don't know if this is the root of all good or the root of all evil, you know, probably both. So anyway, we started building applications this way. And this is what they look like. So you had a browser and you had this thing called CGI. And CGI stands for? Right, so we were doing this again. We're on the other side again. So we had this thing called Java, talking to this thing called Netscape. And that's the mainframe and the dumb terminal all over again, right? The pendulum is swamp. And it's a big deal because now we can scale this. This really isn't the same old pendulum swing. It's not the same thing, right? Because this is a scalable version of the thing that we had before. Remember the connection pool? That was enabled by giving our applications lobotomies, right? We made them stateless. So, you know, this took a couple of forms before we finally settled on the right amount model. Do you guys remember, remember applets? So at IBM, so I think this was great strategy. We had customers that we had said, hey, OS2, OS2, OS2, man, you gotta buy this OS2 thing, right? In the meantime, they're spending most of their money on mainframes and they're perfectly happy, right? We kept saying OS2 and then we realized that Microsoft was going to win. Then we had to say, remember all those OS2 things you built and then the customers would stack all of their mainframes at the top of the 30th floor, they have them next to the window, they'd be ready to push and they'd say, what were you gonna tell me about OS2? We'd say, oh nothing, we kinda walk away. So we had this problem and what we decided to do was actually invest in Joppa. We'd say, okay, you need to build your applications on a browser and then we could snap out the operating system and snap in Windows, problem solved, right? That's basically what we did. This was our strategy but this is the form that it took. Of course, applets never really took off but servlets did, right? So you had this company that was watching this base very carefully and they said, okay, you can tie your HTML, we'll serve the Java side of this application, right? This was called, the server was called WebLogic and it handled the dynamic content, much the way that you have rail servers or your Elixir servers today. But Java was right in the middle of all this and I'm not gonna sit here and bash Java today. You can Google me, there's a lot of other talks that do that but Java made this all possible, right? The stability, security and organization was by far better than where we were coming from which was C, right? So if you think about it, we had the sandbox which provided the portability and the security and the stability to make all this happen, right? And this also allowed IBM in some way to in run Microsoft which was very important to IBM's really survival. Okay, and so the pendulum has swung all the way to the other side and a lot of internet applications that we're very familiar with were born at this time and I wanted to kinda look at some of the early versions of these applications so you can kinda see what the mindset was when we were thinking request response and the batch mode. It's kinda cool, right? It's not what you'd imagine and somehow that wasn't enough, right? So the pendulum swings until we started to need to do more, we started to really wanna push the envelope. Somebody said, hey, wouldn't it be great if applications were more interactive, right? We started building that on the same old architectures for the same old models for the same results, okay? There were some people that had more success with a lot more resources, but the pendulum is swinging, right? We're seeing the availability of just in time kinda push the pendulum to the other side again, okay? So here we are. So the pendulum is not quite all the way across. This is what you need to tell your boss. This is why this conference is such a big deal. This is where we are. We've given our applications a lobotomy and we've gotta fix it. Maybe, right? Because some of that statelessness is good, right? So we need to maintain that model, but for the richer request response, the richer request response stuff that has to happen to build the Twitters and the Google Maps with somebody that has less resources than Google, we need major changes, right? We need to take this frantic juggling and knock it out and stitch these requests back together so that we're dealing with full conversations again, right? This is more than an application, this is the conversation. This is why I had the metaphor of the 51st states in there, right? A rich conversation requires state and you can't be thinking about juggling the state in every step of the conversation. It's too much work to manage from a performance standpoint and from a mental ball, right? What we're really saying is Donald, you're fired, right? Always wanted to say that. We're going right back to here in a way that scales neatly and what do we need to make that happen? This, my friends, is what the conference this weekend is about. It's about the abstractions, the concurrency and isolation that makes these types of applications possible. Remember these? Way in the past, right? So what we need are pure functions. This is where the reactive model stuff comes in. Some, this isn't specifically being addressed by this conference, but the server side consumption of this is where it's at. It's a conversation. It's not a request response anymore for the richest things that we need to be able to do. Not bad for a request response. Not enough for where we are. A newly imagined model view controller separates the pure from the impure. Thanks to Jose for this, which you took from, where was this? Where was the paper? So I'm going to tweet out a link. I'm going to tweet out a link to the original NBC paper. But this separates the controller is responsible for the impure interactions. The models and the views are pure functions. Easier to test, easier to scale. This is the other reason that we're here. This isn't enough anymore, right? We need to do this. Have you guys been watching the measurements? Okay, let's start from the beginning. So Chris, when were your original Rails measurements? Roughly? Just before Elixir Compass, okay. So about a year ago, Chris ran a test. It was really exciting for you guys, I know. We were 10 times faster than Rails. Woo, everybody, right clap. Go crazy. Yeah, that's more like a woo, yeah. Okay, next. But then, the story changes as you start to look at some of the other competition. So Matthew Rothenberg ran some tests. Matthew, are you here? Okay, so Matthew ran some tests on four cores. And gosh, Phoenix is right up there with right near the top of the best frameworks in the industry, right? That's exciting. Here's what's really exciting. As you start to crank up the number of cores, Phoenix and Plug start to pull away. Does anybody expect this chart to change? That's really cool, right? That's really cool. That means that not only are we on a beautiful abstraction, which is part of why that Phoenix was built in the first place, it's a fast abstraction and it's the right abstraction. Does anybody believe that we have the resources to throw at performance that Google does? Probably not, but we have the right abstraction that's gonna win. And then the last idea is that it's not enough to be just good enough on the isolation side. Concurrency without isolation is just noise. We need things to be fast, repeatable, and reliable, supervised and consistent. And that's what it's gonna take to finish the pendulum swing to the other side. Questions, over here. So that's a great question. When does it swing back? This is not done, right? So we're just talking about one kind of move, one kind of use or input here. We're not really talking about mobile. And in fact, how many of you are using more and more voice on your phone? So maybe a third of you? I'm always on Siri. And that's a request response type metaphor, right? And pretty much has to be right now with the way the systems are designed. What else can push it the other way? Well, there's another kind of input. Smart cars have got to use video input, right? That has to be, that's gonna swing the pendulum back to the other side. Jose and I were having a conversation on the way over here. And you guys remember the lobotomy where I kind of put the lobotomy back and you put the frontal lobe back on the brain and there's a question mark. Say maybe, well, there's still many reasons that stateful or stateless is a good idea, right? None of our web applications are gonna be pure, pure stateful and pure Twitter and feeds. That's why half or more than half of our Phoenix book talks about the way to do those stateless applications. That's not dead. And yes, the pendulum will swing back to the other side. But this talk is about the drive, the ability to handle that stateful side of the equation with richer interaction with greater scale. And that's what our customers are demanding. That's what's gonna push the whole market in this direction. More questions. Did I answer your question? More questions. You guys are way too quiet. Okay, thank you. All right, thanks.