 Thank you for coming to Elixir Conf. I think it's pretty irrational for a lot of us to be here. Like, why did we take vacation, go without pay? A lot of people are here on their own dime from Europe. Why? It's not like anyone is paying us to write Elixir in the next few years. We're not very likely. But we're here anyway, because we care, because we're excited, because we've found something that might advance the state of our field and also of our own minds. And apparently, we like that. Apparently, we're bananas enough to come to this conference anyway just to talk and learn about a technology that we find exciting and important for the future of programming and software and therefore the world. It reminds me a lot of science. I majored in physics in college. And then as soon as I got my bachelor's degree, I very rationally went into programming. It was 1999, and that was the perfect year to get into programming. Everybody was hiring, went out of college. I'm like, wow, I can get a job in any city, making better money than I would as a physicist with a PhD. And also, it's like stimulating fun. And at 5.30, I can go home and have no homework. Sweet. That's worked out really well for me. Of course, now I go home and I program. But at least I get to choose what to program on. But a lot of people stay in physics, or at least some number. And they do this. They stay in the sciences, and they get their PhD, and they do postdocs, and they do research. They have a passion for expanding the scope of human knowledge. So they spend all these years expanding their own knowledge just by a tiny little bit with their research. Hopefully, expand human knowledge. There's a book about this process. It was published in 1962. It's Structure of Scientific Revolutions by Thomas Kuhn. Now, I don't recommend it as stimulating reading material. But I got really excited about it. In fact, this is my second copy. And you can see that it's fairly well-loved. But that's because, of course, I apply everything it says directly to software. I read it in 2012. I do wish I had read it back when I was in school for physics. I would have made the professor's attitude to make a lot more sense. But there's some things I learned from this book. I'll give you the summary. The thesis is, the history of science has been told like this. Kuhn was a physics PhD who then toured a veered into history of science and revolutionized that field. Because he said, this is how y'all have been telling the story. Science progresses gradually towards truth, led by great men. They're always men in these stories. One after another. And Franklin discovered electricity. And Ampere found electrodynamics. And then Maxwell unified electromagnetism in light. Isn't that amazing? And that's what you'll get out of Wikipedia. But Kuhn said, you know, if you actually go back and look at the records and the letters and the actual history of what really happened, the story is a lot more complicated. Progress really happens in fits and starts. And there'll be a new theory that's super productive. And then people will work on that for a while and get it a little better. And then, oh, something way better comes along. And it's a lot more complicated in terms of people, too. There are a lot of people involved in this step. So when Franklin was studying electricity, a lot of other electricians, as they call themselves, were doing various observations. Just sort of scattered observations of anything that might be related to electricity. And they had, you know, they noticed a leaf and a gold leaf and some feathers that would attract. And then they would repel. And Franklin noticed lightning and found that that was electricity. And there was a device called a laden jar, which is basically the first capacitor. And it was invented independently at the same time by someone in the Netherlands and someone in Germany. Franklin was lucky enough to sort of happen upon a set of observations that he was able to pull together into a kind of theory. And he came up with the one liquid, one fluid theory of electricity, which was that electricity was a fluid. And objects with not enough of this fluid and objects with a lot of this fluid would attract each other. But at the same time, in France, Duffet was studying like attraction and repulsion and came up with what now looks very similar to us, the two fluid theory of electricity. There's a positive and a negative fluid and this worked. And there's oscillations in the molecules and the ether. But this was a theory that people could sort of latch onto and come up with the next experiments to do because the driving model behind any scientific fields sort of determines what experiments people are gonna do next, what people find relevant to test. So that was interesting and worked about 1750 until 1820, Orsted in Ilsted, he was Danish, noticed that a compass needle, which was known to be a magnetic phenomenon, and those were two separate fields then, would react to an electric current. And this was an anomaly. This didn't fit with any of the theories or magnetism. And anomaly, once it's really recognized and accepted as reality, provokes a crisis. A crisis is when the dominant model isn't good enough anymore and everyone notices that and suddenly there's all these experiments going on and people are like checking out what happens with electric current all the time. The one we hear about is Ampere, he was in France and he did some really good math, but he didn't do it alone. He worked with Laplace and Savory and a whole oodle of people that didn't make it into Wikipedia. And at the same time as he was working, there was Biot and Poisson and another P-name that I don't remember and I can't pronounce, working on competing theories that were similar to Ampere's and that competition sort of drove him to do better science and drove them to do better science and all of these people together argue for a while until finally in like 1827, Ampere publishes the textbook on electrodynamics and coins the term and eventually that became the accepted text and then people work based on his theory which was still electricity was a fluid and there was oscillating molecules and Ampere was very attached to that theory. And eventually we get to Maxwell and I'm sure the same thing happened again there. But this relates to programming in a lot of ways because this book, by the way, I've been talking about models and theories. The word Coon uses is paradigm and I know we are all like, ah, buzzword, ah, ah. This book introduced that word into common usage. Okay, so when Coon uses the word paradigm over and over and over and over, he's actually being original. The word existed but it was hardly ever used and it didn't mean exactly the thing that has come to me since his book which is a model of the world that drives us to a way of living and or doing science in this case and what questions to ask and what even matters to think about. So the first thing that I've learned is that ideas are shared. The second thing is that the ideas keep coming. You may think you've stumbled upon the ultimate truth. Like Newton had a really darn good theory of motion but why didn't he consider out of space at the speed of light and super duper nanoparticles? Well, of course he didn't. So even when we think we've hit the perfect thing for the world as we know it, there's something else out there. And finally, ideas are shared. This one comes back. So first, Denise Jacobs at Oradev in 2013 talked about creativity and one of the things she said that really stuck with me was that when the world is ready for an idea, when all the foundations are laid for an idea, it doesn't come to just one person. It comes to multiple people. Two people invented the laden jar, Franklin and Dufay, Ampere and some other compatriots of his that it doesn't come to just one person. Newton and Leibniz invented the calculus at the same time because all ideas build on other ideas and once all those other ideas are there, that idea is gonna be shared by multiple people. This is really reassuring to me when I've like, I've got something that's just, it's brilliant and it's important and I just really, I've made this connection and I really need to blog it because this could affect the programming of people around the world and my kids have to go to bed and one of them has stubbed her toe and there's great doom and I'm like, somebody else will think of it. It's okay. The converse of this is that if an idea comes to us from multiple sources, if multiple people and groups are thinking about the same thing and coming up with the same thing, maybe that idea is important. The actor model, it's been in Erlang for a while but now it's more accessible in Elixir and at the same time I've worked in Aka on Scala and it also works on Chava on the JVM and Orleans is the actor model for C-Sharp and all of these are useful systems that people are attracted to and so there must be something different. Maybe there's some sort of crisis in our field that's provoking us to seek out new models. This is Camille Fournier at Strange Loop just last week in what I found to be the best talk of the conference and she expressed the theme of Strange Loop as a whole when she said distributed systems, they're ugly, they're hard and they are here to stay. This is very true and it was a great talk, I recommend it but the fact is, I mean we've been working on distributed systems forever because you've got client server. When I started programming was the architecture of every application, box, arrow, box, arrow, cylinder. I was like, oh yeah, that's every single one, you're right. But now we're trying to move behind box, arrow, box, arrow, cylinder because this doesn't scale and of course Bruce talked about this beautifully this morning and one thing that he brought out that I think is an important point to think about even if a straightforward client to server to database app is working for you and it can handle the capacity of your customers and your database is big enough and you don't have scaling problems in the Netflix sense, we all have scaling problems with our head. At some point we reach our intellectual capacity of features that our app can have because each feature makes the intellectual burden of the client and the server and the database bigger and bigger until we just can't fit it in our heads anymore. This is the scaling problem of all software everywhere even if you think you don't have scaling problems. So how do we deal with that? Well we talked earlier about the, or Bruce talked earlier about stateless services and the limitations thereof because if we wanna horizontally scale our server, that's fine and then we could start breaking it into microservices and that's now conventional. But we want a little more than that. We want those rich conversations that Bruce talked about this morning. This is Katie McCaffrey, also at Strange Loop last week and she did a whole talk about stateful services and three different architectures of stateful services and the struggles of the distributed systems and how hard that was and how they overcame them. Ending by the way with Orleans and the actor model which basically you get down to okay it's not enough to have stateless request response cycles that's not interesting enough. We need to have some state on the other end because it's faster, we don't have to make trips to the database all the time and it's richer we can do more with the client. In fact you can add like multiple clients working with the same chat server or chat room or document that you're mutually editing. You can have multiple views on the same model when the model is in the state of your application which of course elixir is very suited for and then I've totally moved the database off to a separate application where it belongs and then you can have horizontal scaling on those services. I do like that separation and then you can just have more of those and then you have microservices. So these are hard problems to solve and I would love it if we could solve these problems with functional programming because functional programming is my paradigm at the moment and it's like the new hotness not as new as elixir but it's still like awesome in everything right and it is awesome. In my opinion the essence of functional programming is the flow of data. You get some data in that might be from the real world and then you do transformations and you make decisions and then some data goes out. This is beautiful for a request response because you can take an HTTP request in do some transformations and produce an HTTP response and this is lovely because you've got immutable data you've got no side effects you can have them on the outside but not in your transformation. Whatever goes in for any given input you always get the same output back and that makes it extremely testable and predictable and wonderful. There are no circular dependencies. There's nothing jumping in from outside. Unfortunately, functional programming is not enough to solve our distributed systems problem. The lambda calculus does not support concurrency and the statefulness also does that's not functional programming strength. So what about OO? Well, object-oriented programming is definitely not enough and that's because object-oriented programming and its current state of Java and Ruby is like a snarly mess that never fits in our heads. Whenever you've got mutable state in particular you have a circular dependency that you can't see. Anything that might possibly have a pointer to the state that you also have a pointer to if that state is mutable there's a circular dependency there. And the same with accessing the world there's a whole slew of just invisible circular dependencies that you don't know where they are. Oh, you're reading from this table. What updates that table? Anything. So all these invisible dependencies and interconnections that you can't even see are pretty bad and plus like in Java and Scala there's nothing stopping me from having all my classes depend on every other class in the package. Oh, in every other package in my application it's just all right there. One thing I've started doing that I learned from Clojure and Elm is being like, okay, I'm not going to have circular dependencies. I recognize those as a weakness and I will draw my little directed acyclic graph for my package dependencies and my class dependencies. And once you do this you can kind of recognize that there's a big strength of OO and that is code organization. It's really good at namespacing. It gives us great ways to group related code together. And we can use that once we decide not to have a mutable state. So Elixir has that advantage. Elixir has another advantage. If you go back to the very beginning of OO when Alan Kay first enunciated the concept the guiding principle was nothing that we really talk about today in Java or Ruby, it's tell, don't ask. It's asynchronous messaging. I don't call getters to get the data out of you. I just tell you what needs to be done and let you do it. Which is exactly the actor model. It kind of confuses me when people talk about Elixir and Erlang as functional languages because while within an actor you've got the immutability and you can do data transformation and you can be a functional language within one message processing, the actors themselves and the interconnections are the essence of OO. They're what OO always wanted to be. So we really kind of have the strengths of both. Plus the thing that makes imperative programming and therefore our usual idea of object oriented useful is that we can access the world. We can have side effects because while data transformations are lovely I actually want my program to do something. And in the actor model we have every opportunity to do something without screwing ourselves up because we have that failure isolation. I love Bruce's quote from this morning. Concurrency without isolation is just noise. Here we have the opportunity to respond because worst case the world blows up and my actor dies and I'll just start up a new actor and it'll connect to a new world. Whatever world exists two seconds later and hopefully that world will be more friendly. So we've got that isolation and that's crucially important. Also crucially important is how Elixir and Erlang acknowledge failure as a first class citizen. It's not something we don't want to talk about. It's not something we just try to avoid making any code, catch exception, open brace, curly brace. But we can actually do something with it which is crucial. There's a paradigm that exists in our culture and it still exists in a lot of places that the way to success is to avoid failure. But from what I've been hearing in our industry in the last three or four years is much more useful. It's the way to success is through a lot of failures. Is hit a failure, recognize it, learn from it, back up. Hit another failure, recognize it, learn from it, back up. It's failed quickly and learn from it and that's the path to success. This is great because let's acknowledge how important failure is. In our code, traditionally, we love to tell the story of the happy path, how our users are supposed to navigate through our system and we've got like this pretty green path in our mind with little flowers along the edges and okay, maybe 98% of interactions in our code actually flow down that path. But the thing about code is it can run 98,000 times or it can run one time, it's the same code. So let's not count the number of interactions, let's count the number of possible paths. There are one or a few happy paths that our users hopefully go down, but there are myriad failure paths. Everything that could possibly fail is like its own case and then every combinatorial combination of all those thingers is its own case and so the failure paths are myriad and if we count the paths instead of the traversals and on the path, we realize that failure is the common case in code and that's why it's perfectly natural for most of our code to be error handling code. We're trying to make some process legible in a way that covers all cases, not just the ones that we want to think about. I love how Elixir lets us do that with the supervision trees and letting the actors fail. Also consider this in testing, failure is the common case there too because when I want to develop something, I write a failing test and it fails and then I do some work and then it fails and I do some work and it fails and then I do some work and it's green and I stop. Or maybe I refactor a little bit and I stop. So failure becomes the common case in testing as well and that's awesome because we're trying to learn from this. In the beam, in the Erlang VM, you have access to some of the best testing tools in the world, you have access to QuickCheck which is by John Hughes, the original property-based testing tool and the property-based testing can help you find the friendly failure in the forest of success. Which is really hard because it's a lot easier for us to write successful test cases than failure test cases, turns out. It's harder, it's hard for us to find the edge case that will actually fail. Property test says you don't have to write this 100 million tests, I love that part. It says you write some code that generates the input for these tests and then I pretty much automate the writing of the tests that we automate the running of. And that's fantastic because it means I can write fewer tests, honestly, that's what I care about but it's also cool that it can find the edge failure cases. I recommend you check out QuickCheckCI, I mean you probably have to write the tests in Erlang for now but maybe we can, that's something that we could look at because it would be just amazing to write property tests. A QuickCheckCI is a tool that John Hughes created that lets you run continuous integration and it runs your tests in a property test aware manner. So the thing about these generated tests is that it doesn't generate the same ones every time. Every time you run your tests you get different tests which is really cool because your test coverage is continually growing but really annoying when you get a flickering failure that doesn't happen the next time you run them. But QuickCheckCI remembers that and it says next time I run the test I'm gonna run that one first. Which is like super awesome and I desperately want that in a CI tool. So that's even more ways that we can embrace failure as a first class citizen, as our friend and we can learn from it. Here, if your objective is in science and going into science is for Wikipedia to list you as the third greatest physicist of all time, that's Maxwell, then failure is the common case here too. But if we recognize that ideas are shared and that yeah, Ampere got the credit but everybody who worked with him and against him and drove him to better work contributed to electrodynamics. And if we look at that and also everyone who wrote books and papers and notes and made electrodynamics accessible to everyone who didn't know about it yet, all of those people contributed and if you define that as success, then success can be the common case here too. But every success looks different. In Elixir, we have the best of functional programming because we have immutability and flow of data within our actors, like the whole plug architecture is a beautiful flow of data. We also have the best of OO, we have like independence of our actor processes and we can use the OO organization scheme because we have tell, don't ask, we have the best of it. We also have isolation which really neither of those paradigms have. The actor model does this for us. So wonderful, we have this great idea and now we can work within this paradigm and the sky is the limit, right? The sky is the limit and that is a problem because there's something above the sky. The ideas keep coming and what we think is the best possible solution now is only the best possible solution we've seen for the world we live in right now and we should keep asking, what comes next? So what comes after, here I'm gonna make a bunch of predictions which are entirely my opinion but it'll be entertaining. What comes after agile? The answer to this in my opinion is lean. It's not even very new but we're not doing it yet. So if you take the essence of agile, you write some code and then you show it to people and then you use the feedback from that to decide which code to write. But at the same time you're also writing some code and then you do a retrospective and you reflect on how that coding went and decide to write code a little differently. So you're writing the better, more likely to be the right code in a more likely to be the right way and you can do little experiments because it's not so threatening to say let's change something for the next two weeks and then we'll see whether it worked and we can change it back if we need to. That's awesome, these feedback loops really promote learning and take us to places that we didn't even know existed. It's hard to predict the results of these but we can say that the results will probably be better which is fantastic. This is Marty Kagan at Kraft Conference in Budapest earlier this year and he talked about how just agile development is really, I mean that's great but it's great for the developers but it's not enough to make our businesses productive because chances are very, very good we're writing the wrong code and you can write the wrong code in the perfect right way all day long and that's not getting you very far. In order to get to write the right code we need to bring this feedback loop to the entire business and Lean it's got this like build, measure, learn cycle which I like to put learn at the top because it's the most important involves like the whole team is kind of a micro business and creation of the idea, generation of the idea and then like validation of ideas as fast as possible it could be doing surveys or little paper prototypes and things like that. Can you validate or reject this idea within hours not within the months or weeks it takes to write software around it and then discard a whole bunch of them and then only the ones that look promising based on measurements get into the software production process and that agile loop at all. This is really awesome but let's go a little further and ask what comes after no estimates because we had estimates and a lot of us still do have estimates unfortunately but we all know they're bullshit. So then we have no estimate which is the movement for oh since all estimates are bullshit we should not make estimates because otherwise we're bullshitting ourselves well okay that's a step but can we swing the pendulum back a little bit because the fact is we actually need to make decisions about what to build and if we have no estimates at all that can be hard. So based on this is coming from Dan North what comes next is ranged estimates because if you say how long is this gonna take? 22 days, bullshit you don't know but what you can say you're not completely without knowledge when someone presents you with kind of a general idea you can say well it's definitely gonna take at least two weeks so it's gonna be at least half a month but I would be embarrassed if it took me more than two months. You can put that kind of range on it and that's more information than the business person had before and if your estimate comes out to be somewhere between one and 12 months and they're like what? That's when you say okay well I mean if you want me to spend some time researching this and checking on the things that I find highly uncertain and dangerous and it worry me about this then great I can do that and then I can come back after an iteration of working on not the highest value part of the software is not the quick return but the most risky and uncertain parts of the software the parts you don't wanna think about and usually push off to the end and then your last 20% becomes only the next 80% if you do those first then you can narrow your estimate and at that point there's a decision and the business can say okay based on this new information what do I want to continue or not? That's something that's missing from a lot of business processes every iteration of the software should end with a decision point is it still worth it to do more on this or is the opportunity greater somewhere else? Also they can decide okay what's the value of this information and how much do we want you to work on the riskiest part versus the make me a prototype part? A value of information and measurements of this kind of thing if that sounds useful to you I recommend this book how to measure anything and it's a little dry too but it was written in 2007 so it's also a lot more recent and it's on Audible but you won't be able to work through the Excel worksheet examples in Audible I didn't really experience that as a loss This totally talks about like embracing uncertainty and we talk about failure being a first class citizen make uncertainty a first class citizen in your estimate and then you can deal with it instead of hiding it or running away Someone pointed out to me yesterday Brian pointed out to me that this circle looks a lot like the scientific method it's like you make a hypothesis and you do an experiment you analyze the results and you come up with the next hypothesis while Coon would probably tell you it doesn't work quite that way like Ampere when he was doing his experiments with electrical currents to find electrodynamics and relate it to magnetism and try to unify those he did experiments that discovered electrical induction but electrical induction didn't help improve his theory didn't even have a name then so he just ignored it he was like that's not important I'm gonna go do something that's relevant that proves my theory a lot of science these days is based on is it publishable? In meantime, fortunately Faraday was more exploratory and also recognized electrical induction so he gets credit for that invention in Wikipedia Right, so hypothetically this should correspond to the scientific method but if nothing else messes with your head today that's scientific method it can't even if it can help in the natural sciences it doesn't help in our teens I mean maybe you can do AB tests and have control groups and have some sort of reproducible experiment with your customers but you can't do it in your team will my team work better if we adopt elixir? You can't test that because you only have one of your team with those individuals and their context and the problem that you are particularly working on we can't do controlled experiments the scientific method doesn't help us with agile learnings feedback cycles what comes after the scientific method? That's not a question we ask ourselves very often I do have one idea it's just an idea at this point Dr. Brene Brown is a social scientist and she studies whole-heartedness and shame and vulnerability she has some amazing TED talks that might change your life 20 minutes, it's really good and I've read one of her books and the most exciting chapter for me by far was the appendix because the appendix talks about the methods that she used to do her research and this is studying a system from the inside because when we're in a team we're in a human system and we can't exercise objective repeatable experiments on it that's no, we're so far from that but that doesn't mean we can't collect data it doesn't mean we can't form theories in our retrospectives and learn about how it works and the social sciences actually have techniques for this particularly Brene Brown uses grounded theory which says you start with a question what is whole-heartedness and how do I get it and then you start gathering data which winds up being listening to people mostly and then you do a whole bunch of categorization they call it coding which is totally confusing but basically it's categorization of all the stories and the statements by people in the interviews and then that feeds into a new theory maybe whole-heartedness has to do with to winds up with vulnerability but then you take that and that just like any other paradigm leads you to the next questions to ask the next data to collect and the learning cycle continues and this we can do from inside the system so I'm really fascinated by that all these circles all these circles of learning and innovation and finding out what comes next are super fascinating in people and I totally want this to happen in my team but keep them out of my code I do not want my code like going off in the wilderness in directions I never expected or could predict that's where those no-circular dependencies come in and the worst one is oh my God two-way data bindings ugh so I have to ask what comes after MVC I'm not even the first one to ask this today which makes me really happy Chris talked about it and my answer to what comes after MVC is the LM architecture pretty much and there's been a lot of talk about LM here which is awesome and I'm going to talk about it again in the LM architecture you start with an immutable model so there's some data and it's immutable and that one model feeds into all the different bits of the view so you're producing HTML producing HTML over time in fact but there's the single immutable model feeds into the view functions and out comes a type that represents HTML and then this works like React where it's got a virtual DOM and it's doing the diff to magically make the page updates fast but the view function is data in, data out it's a nice flow of data and then that goes to the user and included in that is stuff like what happens when you push the button when you submit or when you type in the input field or when you breathe on the screen and all of those things well maybe not the breathing one but seriously it's like every freaking click comes back and it needs to change the model but it does not go back through the view it does not make a tight little circle it makes exactly one circle for the entire application it goes into the update function which is a data in, data out purely functional function of code which then produces the next version of the model so this can progress over time and your HTML and therefore your browser page can change over time but all of your code is perfectly stateless and it does this through sending event into the update function one at a time that's really awesome you can also talk to the outside world in a similar manner Elm has a very clear line between JavaScript and therefore everything in the world and your Elm code but you can return from your update function in addition to the new model you can send out instructions that are data for what you would like to happen in the world and how you would like to hear about it and that comes back in as events so you have a single point of entry of things that can change your page that turns out to be really sane in the sense that you can like think about it you can read the list of what happens you can see what the model turned into at each point this like scales in your head really well it turns out my friend Richard who's got a great Elm Tucket Strange Loop reports that I was like ah it's so hard to make this modular there's so much glue to go together and I'm trying to make itty bitty little modular pieces and he's like you know I kind of just had to let go of that and his events his list of events is like this big and he's got this many views and this many in one page one single page app but he's like but it hasn't been a problem it just the number of features coming in doesn't scale the complexity nearly as badly as in other architectures I think that's really cool and I kind of wonder if we can like scale this architecture fractally with elixir on the back end but I don't have good pictures for that yet I do want to point out that this idea is coming in from many sources it's an Elm or if you want to stay in JavaScript you can use React with Redux a Redux is one implementation of Flux but it's the elmiest implementation of Flux and also these ideas come in from CQRS this is a super enterprising term that means command query responsibility segregation which translates to your reads and your writes are totally separate processes don't make two-way data bindings that's all you need to know about CQRS event sourcing on the other hand is actually fascinating and it's about picturing history as a series of events which the Elm architecture models perfectly and you just add each event one at a time and you get all of history I like to think about that on a personal level I think of it as, okay so every piece of information that comes in I make some decision and that decision has two outputs it has whatever side effects I have on the world and the next version of me it works for actor model too then we have to ask what comes after rest because like receive a message well that was the wrong botan one thing that annoys me in Elm is if I have to respond to messages from the server by sending another message to the server and it just gets irritating I have to like build up my model gradually is annoying rest is like a whole bunch of you have to say like okay I want to know about conferences okay now tell me more about elixir conf okay now tell me the attendees at elixir conf and then this other piece of the view might be like okay tell me about this I attendee tell me about this attendee oh my gosh so CQRS as Chris explained this morning takes all of those questions puts them together into a single query and I'm glad that he gave a lot more detail today because there's a ton more about graphql oh yeah I forgot to say what comes after rest graphql and that's the brings it down into one request to the server that's efficient but it's also oh my gosh so much cleaner because then you're like your one response comes back and you feed it into your one model which gets parceled out to all your views and if you have multiple views on the same piece of information like here's your messages and here's your counted messages they're always in sync because all your views are coming from one model it's pretty awesome all in the back end graphql is cool Chris talked about how to implement it in Phoenix this morning which I think will be super extra awesome but even in existing architectures if you have like microservices the graphql server can split up the query to all the different microservices and the back end doesn't even like have to know it's just an extra layer you don't have to redesign your system this fits very well on top of existing systems so that you can write better clients and then you can like I don't know if you want to you can gradually change your microservices into anything else I think we could take this farther so this is not currently in graphql but I think it would fit really well with the graphql implementation in Phoenix is what if that query okay I want to know about conferences named elixirconf and for each conference I want its dates and this list of attendees and for each attendee I want their name and their city of origin you can make that one query say this is what I care about but what if that was not just a request but a subscription and then you open a persistent connection tons of talk about persistent connections a strange loop this year totally a thing and that persistent connection gave you the information as it came back and also gave you any updates to that information that happened due to other clients activity I've seen this implemented it wasn't called graphql but Six Wonder Kinder Chad Fowler's company which makes Wonder List which is a great to-do app does this they totally do this they open a persistent connection over a web socket and the client is subscribed to updates that that client cares about and it's really cool it works really well and the app is really slick because it updates between your mobile and your desktop lickety-split so I think that could be really cool to replace rest but on the back end then we've still got a lot of microservices so we have to ask what comes after microservices because they are totally the hotness and also the headache of the software world right now and the answer is, in my opinion, better organized microservices which Elixir is totally well-suited for because you can divide your application into more applications and have them talk to each other and depend on each other and communicate super fast so the last company that I worked for was like, oh, we tried microservices and it didn't work it was too slow because I'm like, have you heard of protocols other than HTTP? It's like, people think that microservices have to be HTTP and JSON no, what they have to be is independent from each other and never touching each other's databases you should never connect to if you connect to a database directly you better be the only application that connects to that database directly and everybody else better come through you that is the crucial bit of microservices it has nothing to do with HTTP so by all means I think Elixir is really suited this is a picture of microservices in their original form as espoused by Fred George back before microservices were a thing and they had all the messages on the river and the microservices just took filtered feeds from the river but they always put their messages they just dump them back into the river for whoever wanted it to filter it out and do what they want they're super independent and there's that single source of entry again which is useful and they had total microservice chaos I mean they're in all kinds of languages and they went microservices crazy but they do have that one piece of sanity of everything comes through one entry and that makes it kind of reproducible, hypothetically it doesn't scale though if you just have one for your whole company and Kafka just isn't enough for this so we want to put this instead oh, we can't support one river so let's just have everybody send it to everybody else and this looks a lot like my Java code from back in the day I don't think we've improved anything but if I take this diagram and say, okay, wait, circular dependencies are bad can I create a directed acyclic graph this is the same diagram as I think it was kind of hard to be certain with all those lines and also I removed some pointy bits and made the arrows unidirectional but you can organize your microservices more consciously and then especially in elixir you can be like, okay, this is an application and now it's a little simpler and you've just got to create those layers I mean if we have like five to seven to nine depending on who you read slots in our working memory that's how many different things we should have in each layer and we can do that it works really well in elixir and conceptually you can do that at other levels too at Monsanto right now we have what we call ecosystems where you put a bunch of related microservices into a VPC layers of services also one thing that I love about the actor model and I experienced this when I was working in Aka was sometimes I would be like, okay, I have a task I'm gonna designate it I'm gonna make an actor to do that task and that actor would turn out to be a whole little subsystem of vectors and that was totally fine because from outside it just looks like one this green box might have a whole bunch of actors in it in this one I've got my precious state in one actor and I like to separate one actor is holding the state and if I wanna do anything that might possibly throw an exception that's going in another actor so I can separate that stuff and one can be responsible for sending responses that's kind of like the view and others can be responsible for accessing the world and you can just make these little subsystems within subsystems and one of those boxes could be a subsystem for all I care it scales, that's pretty cool all right, so we've got immutability we've got the best of FP and OO and we've got isolation and everything's wonderful and there's one thing missing from me singing the praises of Elixir and that is the people because take away number three ideas are shared one person alone no matter how good the idea is and how much work they put into it and how good that work is they can't bring the idea to the world and make it useful to everyone it takes a team, it takes a lot of teams it takes a lot of people it takes all 290 people who committed to Elixir 1.1 and this is crucial, it's crucial to science and it's crucial to us some communities have experts and if you wanna join the rank of those experts you better be prepared to climb through some hell and you know what, those experts can stand up there feeling smart but their paradigm is not going to spread to the rest of the world because it's not accessible to the rest of the world it's not near at hand it doesn't matter how useful it could be if you got there, if you don't see a path to get there so what we want is a community more like Ruby and Rails where there's people at every level who are answering questions and writing documentation and writing blog posts and making tutorials and you don't want only beginners and you don't want only experts who are willing to answer questions for near experts it takes that whole spectrum and what's more, it's more than one spectrum there's more than one approach to learning Elixir so some people come from Ruby and some people come from Erlang and others from Java and each of these is a different approach and the best thing we can do is if you hear anything confusing as soon as you learn something put it out there to make that step a little easier for other people whether it's ask a question on Stack Overflow and then answer it when you find the answer sometimes I do that just to track my work but it makes it in public or you can blog or you can tweet or you can make bug reports and investigate bug reports and Elixir has a great community of people that help so that Jose actually has a chance of getting some work done it's something Evan is struggling with on Elm right now and this is fantastic and specifically if you are not from Ruby which seems to be the most common place to come to Elixir then your contributions as blog posts or documentation clarifications are especially valuable because this afternoon Alan says to me, hey do you want a biscuit? and I was like a what? Oh a cookie British biscuit is UK for cookie and I mean that's just a simple geographical language difference but one of the things that Kuhn emphasizes in structure of scientific revolutions is that the people who are trying to bring the older scientists up to the new paradigm and often this took a generation the older people who were stubborn and just loved the ether to death well they had to die for the science to move away from the theory they were so attached to and seriously I forgot there's some quote about how science advances with the graveyard if you know that quote give it to me afterward because it's pretty good which is sad but I think with the internet I think this is changing and certainly in programming that's not the case because we have continual new people coming in and because we're here and we actually want to learn stuff and change stuff and we don't have this idea that what we grew up with is the only right way a lot of us didn't even grow up with programming right so the important thing is separate people with separate paradigms with different models of the world they can't even talk to each other right like gravity is totally different between Newtonian and Einstein and physics and masses if you use the same symbol but it's a different thing that they're talking about and functional programmers will talk about curying and monoids and other fun things that make no sense but that's not nearly as bad as when you use a word like biscuit that has meanings to both people they're just totally different meanings and they may not even realize it the word property to functional programmers that's basically an assertion it's something you can say that's always true about a piece of code and to Java programmers that means a getter and setter it means a field and when I talk about property based testing to Rubyists I call it generative testing because the word property is just confusing it's overused nevermind application and process so if you are from Erlang or Java or have never programmed before this your input is especially valuable because the people who are experts have the cursive knowledge and they don't know how much they know and that makes it hard for them to teach for us to teach I struggled with this when I tried to teach anymore because once you know enough about it the people you can teach the best are one step behind you and that means whatever step you're on you are the best person to teach the people one step behind you whether it's answering questions on Slack or showing up to the meetup and doing a talk it doesn't matter what level you are if you show up to the meetup someone is going to learn from you and someone is going to learn from you better than anyone who knows more than you that's particularly important for this whole other stare of people who've never programmed before and I know there are some people like that here and kudos to you because it takes a lot of guts this field I feel really lucky that I got into it when I did and I got into it like in Linux and C and back before version control was complicated and back before IDE's and before debuggers existed I just didn't use them and now printlin is my friend again with functional programming and I got in here when it was simple but there is so much to learn and we don't realize how much we already know I'm trying to teach my sister to program and my gosh it's just there's just so many prerequisites so anything you can help with anything you learn is a contribution and blogging is a great way to get there because Google totally helps I frequently or no a couple of times anyway I've Googled something and found my own blog post from years ago that I forgot so it's totally useful even to your future self but these people who've never programmed before are in fact the most important people because they're the ones without preconceived notions of what application looks like they aren't expecting it well why is this different from Rails they don't or they don't have the assumption that it's going to be like anything because they don't have a paradigm that's locking them in the hardest part of learning is unlearning and these people who don't have to unlearn anything can give us the best feedback and when they say why does it work like that and that's confusing that is the most valuable feedback and also these are the people who are going to have the ideas that push elixir out of the sky and into space and if we want the best ideas of the future to build on elixir we need people who don't think like us we need people who don't know how to program yet and learn from elixir and they're going to have the ideas of hey this is confusing oh I never thought about it you're right they're going to have the ideas that are going to push us to the next level and build also people from historically in science it's usually people from a different field that have the big ideas Franklin was a politician mostly he was a thousand things but he wasn't only an electrician what we should aim for I think is to take this staircase and if we provide enough information and answer enough questions and have enough meetups and are friendly and welcoming and give everyone a sense of belonging then eventually these steps stop becoming barriers and we smooth it out and suddenly getting from zero to useful in elixir is a beautiful experience it's not just the language either it's all the tools and all the scripts and everything everybody publishes on github if you have some really basic code that other people can read and learn from that's helpful there's so many things that we can do if we learn in public then we're building a ramp for everyone who comes behind us an idea doesn't belong to one person first of all it's pretty unlikely that only one person thought of it but even that it doesn't belong to the first person who published it it belongs with everyone who contributes to making that idea useful to the world everyone who writes a script that makes the build process a little easier everyone who tweets about it and attracts some attention so that people say huh maybe I could use that everyone who writes a blog poster an issue or contributes in any way is part of elixir Jose is a great leader of our community but he is not the community he is not the language or elixir the programming system we are and thousands of people who aren't here so I want to thank everyone for being irrational enough to come to this conference and I hope that the beer is a good reward in a few minutes and I particularly want to thank Jim for being even more irrational enough to throw this conference and organize it because yeah you're right yeah good good good because as a speaker I know I would never organize a conference it's way too much work a couple days ago after I got here and I was supposed to be working on my talk we had an activity instead and seven actors journeyed to Dave and Buster's where we shared the resources of four power cards between us two of our actors crashed but the remaining five achieved our eventual result alright alright he's got the banana and the many side effects of blinking lights we found a lot of tickets and Jim we would like to present you thank you delivery actor with this banana that's enough to throw this conference and everybody go forth and elixir five