What every Node.js developer needs to know about Elixir
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 96 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51860 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201623 / 96
2
7
8
9
12
14
19
20
26
28
31
33
38
40
43
45
48
50
51
61
63
65
76
79
80
83
87
88
90
93
94
96
00:00
Software developerMassVideo gameTwitterPerfect groupData conversionComputer architectureSoftwareLine (geometry)Physical systemFrequencyCodeState of matterMultiplication signConcurrency (computer science)Video gameImperative programmingWordProjective planeMathematicsEvent horizonQuicksortFunctional programmingProgramming languagePoint (geometry)C sharpErlang distributionDirection (geometry)Civil engineeringShared memoryWeightVertex (graph theory)Online helpOptical disc driveCartesian coordinate systemComputer animation
05:34
Software developerStack (abstract data type)Concurrency (computer science)Visual systemQuicksortGame controllerGoodness of fitDifferent (Kate Ryan album)Arc (geometry)Computer programmingArithmetic progressionConcurrency (computer science)Visualization (computer graphics)Vertex (graph theory)Stack (abstract data type)Computer animation
07:12
Infinite conjugacy class propertyMaizeArithmetic progressionQuicksortPoint (geometry)Mathematical optimizationRight angleEscape characterGroup actionScatteringErlang distributionMixed realityConnected spaceGodCodeVertex (graph theory)Computer animation
09:13
ScalabilityBlock (periodic table)ScalabilityLibrary (computing)Context awarenessMultiplication signQuicksortWordData managementVelocityRadical (chemistry)Connected spaceMereologyQueue (abstract data type)Vertex (graph theory)Computer animation
10:37
Integrated development environmentQuicksortMereologyBlogView (database)CASE <Informatik>Vertex (graph theory)
11:51
Armstrong, JoeRuby on RailsProgramming languageImage resolutionMereologyScaling (geometry)Erlang distributionNP-hardReverse engineeringRow (database)TrailGoodness of fitCore dumpFault-tolerant systemConcurrency (computer science)Distribution (mathematics)BuildingRight angle
14:14
Installation artBuildingPlot (narrative)Menu (computing)Programming languageComputing platformScalabilityLimit (category theory)Software developerDecision theorySolitary confinementModul <Datentyp>Line (geometry)Multiplication signHexagonLevel (video gaming)Goodness of fitErlang distributionQuicksortCodeData storage deviceLibrary (computing)Programming languageLink (knot theory)Physical systemCatastrophismVertex (graph theory)FeedbackProduct (business)WebsiteRight angleCuboidFunctional programmingMereologyRadical (chemistry)Data managementNegative numberGodPattern languageTerm (mathematics)Electronic program guideWeb pageBeat (acoustics)Solitary confinementDecision theorySingle-precision floating-point formatElectronic mailing listJSONXML
17:29
Erlang distributionTelephone number mappingComputer fileSource codeTask (computing)Electronic mailing listInformationLetterpress printingDefault (computer science)CompilerSoftware testingString (computer science)NumberExecution unitModule (mathematics)Parameter (computer programming)CountingOnline helpLibrary (computing)Algebraic closureRight angleReading (process)Line (geometry)Template (C++)Software testingUnit testingMixed realityPattern matchingExecution unitCodeMereologyVertex (graph theory)Projective planeSoftware bugSuite (music)Module (mathematics)Radical (chemistry)Graph coloringFunctional programmingVirtual machineInstance (computer science)Erlang distributionStructural loadTelephone number mappingGastropod shellComplete metric spaceNumberComputer fileInteractive televisionConfiguration spaceCuboidXML
21:40
Software frameworkFlow separationContent (media)Software frameworkGoodness of fitWeb 2.0Programming languageMereologyFunctional programmingoutputTable (information)Social classFlow separationFunction (mathematics)Module (mathematics)Set (mathematics)NP-hardRule of inferenceField (computer science)TrailState of matterMessage passingProcess (computing)Computer programmingCategory of beingSoftware bugJSONComputer animation
24:02
Software developerIntegerType theoryGlass floatString (computer science)TuplePattern matchingNumerical digitStreaming mediaTelephone number mappingDigital filterClient (computing)Programming languageExpressionBitNumberSeries (mathematics)Parameter (computer programming)Information managementMultilaterationComputer configurationRight angleFunctional programmingPhysical systemCodeType theoryStreaming mediaVideo gameMultiplication signErlang distributionData storage deviceFluid staticsQuicksortVirtual machineServer (computing)Finite-state machineKeyboard shortcutError messageLengthStatement (computer science)InterpolationElectronic mailing listDevice driverPlastikkarteString (computer science)Different (Kate Ryan album)Projective planeDigitizingFlow separationCASE <Informatik>NeuroinformatikPresentation of a groupLogicCommunications protocolReal numberInterface (computing)Service (economics)Online helpAlgebraic closureMappingModule (mathematics)Crash (computing)Thresholding (image processing)HexagonTelecommunicationResultantAtomic numberLevel (video gaming)Parity (mathematics)Data structureMaxima and minimaTerm (mathematics)Range (statistics)Fault-tolerant systemPerturbation theoryWordPattern matchingOperating systemMachine learningMobile appPattern languageGastropod shellSoftwareEquivalence relationTupleMessage passingPOKEKey (cryptography)Default (computer science)Sound effectPersonal identification numberNP-hardComplex (psychology)Monad (category theory)MereologyProcess (computing)Category of beingMatching (graph theory)File systemIntegerDamping3 (number)Equaliser (mathematics)2 (number)Goodness of fitBinary codeExpected valueMathematicsJSONXMLUMLComputer animation
31:30
PixelComputer fileClique-widthProgramming languagePattern matchingBinary fileBitMotion captureMedical imagingGreen's functionTouchscreenLine (geometry)Raster graphicsParsingPixelVariable (mathematics)File formatCommunications protocolCodeMatching (graph theory)Computer fileProcess (computing)Binary codeJSONComputer animation
33:43
Erlang distributionCoprocessorVertex (graph theory)Kernel (computing)State diagramLibrary (computing)Menu (computing)Drill commandsTelephone number mappingInterrupt <Informatik>Memory managementInstallable File SystemDevice driverPhysical systemOperations researchErlang distributionProcess (computing)TelecommunicationFault-tolerant systemCuboidConcurrency (computer science)Distribution (mathematics)BootingOperating system2 (number)Instance (computer science)Electronic mailing listWeb 2.0Programming languageResultantWindowMultiplication signNumberData managementMobile WebRow (database)FacebookMemory managementServer (computing)Run time (program lifecycle phase)File systemContext awarenessCodeBitPhysical systemTrailDemo (music)Semiconductor memoryOperator (mathematics)Computer fileCore dumpXMLComputer animation
36:12
BefehlsprozessorParallel computingConcurrency (computer science)Erlang distributionProcess (computing)Link (knot theory)Scheduling (computing)Core dumpPräemptives MultitaskingWeb pageComputer multitaskingOperations researchComputer programNumbering schemeSingle-precision floating-point formatLoop (music)Event horizonConvex hullTotal S.A.Distribution (mathematics)Structural loadPhysical systemErlang distributionCodeStability theoryProgramming languageOperating systemRule of inferenceMereologyVirtual machineJava appletData structureMulti-core processorThread (computing)Concurrency (computer science)Software testingParallel portCore dumpComputer multitaskingSemiconductor memoryBlogWordMultiplication signComputer fileServer (computing)Scheduling (computing)Projective planeVertex (graph theory)Boom (sailing)Message passingBlock (periodic table)Mixed reality1 (number)EmailProcess (computing)RotationRoutingoutputPattern languageCartesian coordinate systemDependent and independent variablesConnected spaceNumberRight angleDistribution (mathematics)Physical systemEntire functionStructural loadTotal S.A.SpeicherbereinigungFault-tolerant systemBitHard disk drivePlastikkarteGame theoryMagnetic-core memoryLink (knot theory)SoftwareEndliche ModelltheorieGodCompact spaceEvent horizonLocal ringLoop (music)Characteristic polynomialReal-time operating systemSingle-precision floating-point formatCuboidLevel (video gaming)Different (Kate Ryan album)QuicksortCommitment schemeReading (process)BefehlsprozessorMassSequenceFunctional programmingPoint (geometry)Memory managementSet (mathematics)Raster graphicsChemical equationPerturbation theoryCausalityOperator (mathematics)2 (number)Computer animation
45:59
Demo (music)Source codeErlang distributionChi-squared distributionInteractive televisionSynchronizationModule (mathematics)Link (knot theory)Loop (music)CurvatureElectric currentRevision controlHill differential equationMaxima and minimaModulo (jargon)MalwareExecution unitConvex hulloutputSoftware testingTelephone number mappingEqualiser (mathematics)Radio-frequency identificationCoefficient of determinationFunctional programmingRight angleParameter (computer programming)Demo (music)Message passingLoop (music)CuboidVirtual machineVertex (graph theory)Multiplication signElectronic mailing listDistribution (mathematics)ArmBlock (periodic table)Computer architectureSystem callSoftware bugFreewareComputer-assisted translationCodeServer (computing)Function (mathematics)QuicksortPoint (geometry)Process (computing)MultiplicationModule (mathematics)Polygon meshComputer hardware32-bitWindowLine (geometry)HTTP cookieExistential quantificationCompilerMixed realityRadical (chemistry)Data storage deviceLogicConnected spaceReal numberPrincipal ideal domainSource codeJSON
51:47
CodeVertex (graph theory)Extension (kinesiology)Exception handlingConcurrency (computer science)Process (computing)Data modelNetwork topologyServer (computing)Error messageCrash (computing)Loop (music)Arithmetic meanCartesian coordinate systemEndliche ModelltheorieGreatest elementFault-tolerant systemProcess (computing)Exception handlingCodeQuicksortPhysical system9 (number)TelecommunicationBitCodeConcurrency (computer science)Context awarenessExtension (kinesiology)Erlang distributionMassCharge carrierGradientEvent horizonMachine visionPeer-to-peerRight angleThresholding (image processing)Single-precision floating-point formatVertex (graph theory)Thread (computing)State of matterDifferent (Kate Ryan album)XMLUML
54:46
RepetitionCodeSoftware testingPhysical systemRadio-frequency identificationGastropod shellCodeSoftware testingBuildingMereologyLinear regressionCodeInterface (computing)QuicksortJSONXMLUML
55:40
Vertex (graph theory)Software developerWebsiteFitness functionGoodness of fitError messageVertex (graph theory)CodeProgramming languageSoftware frameworkDifferent (Kate Ryan album)BitLine (geometry)Closed setComputer animationJSON
57:28
Inclusion mapSoftware testingSample (statistics)Distribution (mathematics)TwitterConcurrency (computer science)Programming languageTrailConnected spaceWebsiteTransformation (genetics)Mobile appVertex (graph theory)Power (physics)VotingClient (computing)Erlang distributionFault-tolerant systemQuicksortElectric power transmissionArmstrong, JoeFluid staticsType theoryTerm (mathematics)Thresholding (image processing)CodeExpected valuePhysical systemSystem callData storage deviceServer (computing)Mobile WebBitMultiplication signVideo gameComputer configurationMultilaterationPerturbation theoryProcess (computing)Computer fileDevice driverSoftwareNumberVirtual machineDigitizingGoodness of fitFinite-state machineError messageMessage passingWritingMonad (category theory)Equivalence relationOperator (mathematics)Interface (computing)POKEWeb browserCrash (computing)Online helpTelecommunicationC sharpFunctional programmingMachine learningPresentation of a groupJSONXML
Transcript: English(auto-generated)
00:06
All right, perfect. So, awesome to have you here. Thank you, thank you. We're gonna talk about what every Node.js developer needs to know about Elixir today. There's me on Twitter. I respond on Twitter, so hit me there.
00:22
I love carrying this conversation on out of here, and if you have any questions, always follow up with me there. There's no expiration date on that. I wanna start off. So, this illustration appeared in The Guardian shortly after December 25th, 1914,
00:41
and this is an illustration of the Christmas truce, where the German and British soldiers that were trench warfare, with this excuse of coming out and burying their dead, they got together and they were civil to each other. In the middle of this horror that was going on, they stepped out and they acknowledged
01:02
each other's humanity. And in technology, tech, we often break off into camps, and we don't do that so well. A lot of times we don't reach out. And so, for the Node folks here, I really appreciate you all coming to a functional programming talk. And for the functional programming people, I'm really glad you're here
01:21
to think about this Node side of things. And so, at the point that we make problems visible, then you can do something about it. You can improve the situation. But until you make them visible, it doesn't really happen. And so, thanks.
01:41
So, this idea of civility, we might hate a technology, there might be problems with the technology, we might know that a technology's dangerous, but you have to understand how people got there and have empathy for them on both directions. So, my path, this sort of long road,
02:02
you can tell by my gray hair, that I began writing software professionally back in 1994, and so I was writing C and VB, so the old VB, not vb.net, but kicking it old school, and then Pascal, VBScript, JScript, JavaScript,
02:20
and then C Sharp on. And through that path, I ran into lots and lots of problems. I created lots of problems, like we all do, but I probably created more than my share of problems. And through that, I might not have been the best developer, but I was awfully good at seeing my mistakes and trying to learn from them
02:41
and seeing what the pitfalls were that led me there. And through that, I worked to try to help other people avoid pitfalls. And that empathy that I tried to use in this land of imperative code and OO code during the 90s and the aughts, interestingly, it had this reputation
03:02
for being able to see these problems and help, and that led me then to Norway, 2007. So, I was here, I was brought over for a large architectural risk assessment project. So here in Oslo, there was a company that had a huge code base. They had 20 million lines of managed C++ and C Sharp code.
03:21
They had these 12 architects, and we worked on this risk assessment of how is the software gonna destroy the company project over the six-week period. And through that, all of the problems that I imagined would be in the code base, you know, those were there. You could almost get Robert Martin's book
03:40
and just hand that book over before you even went in and looked at the code, because those problems are common across all imperative and OO systems. Those code smells are there. And so, that was expected, that side of it. Amazing team, but you expected the problems. One thing I didn't expect, though, is there was a system in that shop
04:01
that had been up and running for four years without a millisecond of downtime. So all the other applications, they were crashing maybe multiple times a day. It was embarrassing, it was causing trouble. You had dependencies within the code that made it hard to upgrade. You had the mingling of state data and behavior,
04:23
like we're told to do by Martin Fowler. We had that all through the code and that caused all these defects in the software that made, it was really hard to solve problems then. We had event storms, because you had concurrency involved in this. Concurrency's hard to do if you have mutable state. Problem, problem, problem.
04:41
But this system, four years without a millisecond of downtime, that was unusual. So I asked more and more about it. And I actually learned it was even more remarkable. There had been two years previously there had been a major code upgrade, this compiled language. They compiled and they had pushed new updates to this running cluster without a millisecond of downtime then.
05:01
So I was like, what is the spooky magic? And so I learned for the first time the word Erlang. I'd never heard of it. I was off imperative OO guy, you know? And I was happy there, sort of happy. I knew I had problems and I knew there were problems, but I was comfortable there. And so I dug in and I started learning more about Erlang and my code changed.
05:22
And I have built systems that people tell stories about now. They've seen these good things and I couldn't have done that before, before I ran into the Erlang VM. And so it changed my life and so I'd like to come back to Norway and share, return the favor. So I'm very thankful for this city
05:40
and for what it's done for me. And all the defects it's kept me out of. So here we have the hero's journey. This is sort of the arc that all novels and movies and everything follow. This arc of the hero's journey. And so that was the beginning of my hero's journey and hopefully this will be the beginning
06:00
of your hero's journey as you go through and you pick up some of this knowledge. We'll go through this ordinary world and we'll progress. So for the Node folks here, I imagine you came to Node for some of these reasons. It's really a welcoming community. You can come in without knowing much about programming at all and you're welcomed in
06:21
and that's awesome. And it's easy to get started in Node and there's no doubt about that. It's easy to get started. And you can be working in Angular, Durandal, Aurelia, one of these frameworks and if you need to have a backend, you need to send that back up in quickly, well you can do that in Node. It's very easy to kick that up.
06:40
Everyone sort of knows JavaScript. No one really knows JavaScript, everyone sort of knows it. Then people also come because they've been hurt in other stacks. There's problems with the tools being too heavy or not being able to have enough control over things. Just various problems. And there is a concurrency story on Node.
07:00
It's different than I think a lot of people think it is. But there is a story there and people know that concurrency is important. So that brings people. And then there's good support in Visual Studio and on Azure. I think of this sort of progression in Node.
07:21
And I have lots of friends that went through Node. I started working in Node when it was brand shiny new because I was interested in the story of it. I pretty quickly then dropped it because I had already learned Erlang at that point and I saw it's like this isn't really filling the bargain that I thought it should be. And so, but this is this progression. We start off with folks that are junior
07:41
and they're full of optimism. You know, they haven't even heard the horror stories yet. They haven't heard any of the bad. It's just this welcoming community. They come in and they're excited about this. And that is a beautiful thing to have. And at some point you move on and you then have your sort of engineers. And they have heard the problems.
08:02
Maybe they've seen a few problems. But the thing is they can say, I'll be a craftsman. I see these problems, they're documented. I'll know how to actually be diligent and not run into these problems myself. And that's that tier. This is the second stage of Node development. And then you move on to the seniors and the leads.
08:22
And I have friends that are in this spot right now. They bought into this, they brought their companies along and they've heard the problems, they've seen the problems and now they're like, oh my God, what have I done? You know, they've got themselves in a trap because they used it for everything. They used it for things far, far outside of its sweet spot. And they're in a terrible place
08:40
and they're having trouble shipping code. That's rough, that's a rough spot to be in. And those folks, I'm excited about where they're at. I'm excited about all of these groups coming in because it's a great feeder into Elixir, I believe. But the folks that are senior, they're looking for escape pods. And a lot of them are joining up at the Elixir user groups around the country,
09:00
so around the world. So you'll have this mix of Ruby people and you'll have this mix of Node people and then a few scattered FP people showing up at the Elixir meetups. And so I'm really tickled about this linkage and this connection. When on Node, when people talk about Node, they often use the word scalable.
09:22
And it's sort of a problem, I believe, to use the word scalable in the context of Node. Scalable's a rough word. It's sort of a buzzword marketing word. It's a word that managers like to use even though they don't know quite what it means. And I feel like you could say, okay, you've got a fast car. Describing a car's a fast car.
09:41
You've got a car that goes and flies through the guardrails and falls down the bluff at terminal velocity. And you could say that that's a fast car, but you're missing an important part of the story by calling that a fast car. There's other things going on. And so when you call Node scalable, there's an issue in that it can handle the 20,000 connections that come in.
10:00
It can handle the 20,000 users as long as you immediately pass that off for something else to do the work. Because if you do the work, you then have got this issue of where you're blocking. You're blocking your other 19,999 users. So the issue then is like, okay, we hand off the work, or who's gonna do the work then? And what do we write that in?
10:20
And there are all sorts of solutions. Every time you run into a problem, there's a lot of ingenuity in the Node community, and they have solutions. You'll have things like Q. And you'll have these ways of just passing things off, these libraries that have been written. But it's always hard manual work, and a lot of learning and discipline involved. A lot of folks, you'll see a lot of blog posts
10:41
that will say Node is not a silver bullet. And I think you could say that about most technologies. It's not the thing that solves everything. But there's another way of actually looking at the problem of silver bullet. And in this sense, I think maybe Node is a silver bullet. In that a silver bullet has a really narrow use case.
11:04
And there's a sweet spot for a silver bullet, and that is to kill werewolves. And day to day, there aren't nearly as many werewolves running around as Hollywood would make you think. And so the sweet spots that you'd fit, there aren't as many solutions where it does map up closely. And so more of an uglier view of this might be
11:22
it's maybe not the silver bullet, maybe it's more like the full moon that brings out sort of some crazy in the environment. And I'm kind of off of this part of the talk, but I've seen so many of my friends hurt by this and I believe that this is the most dangerous technology in the world.
11:40
And so, and I hope that you take this in the spirit that I'm offering it, that I'm really trying to help and I'm trying to keep problems from happening. So let's now move on to Elixir and how it came to be. So we've got this history of a character named Jose Vellin who is here at the conference this week to speak.
12:03
And so he was a core member of the Ruby on Rails team. And he was trying to solve problems on Ruby. He's a good developer, he's focused on these issues, it's hard to solve problems on Ruby. People would ask for scale.
12:21
They would ask for concurrency, they'd ask for performance, and that's a hard thing to deliver on Ruby. And so he was battling that battle and he was then reading seven languages in seven weeks. Out of curiosity, who else read this book? Awesome, awesome, yeah. And so he got to the chapter on Erlang and he was like, whoa, he's kinda like everyone does
12:40
when they first hear about what this thing does. And they're like, that's weird, why haven't I heard of this thing? And so he was reading about Erlang and he saw that it fit these problems of fault tolerance, concurrency, distribution, this scale thing that he had been asked to solve. And so he started looking into Erlang then. He's like, first, like everyone does when they first bump into Erlang,
13:01
they think, okay, can I steal parts from Erlang and bring it over into my stack? And there are reasons you can't do that that we'll talk about briefly. It's really hard, it's a hard, hard problem. And so he's a smart guy, he realized it pretty quickly, you can't do this, it's not gonna happen. So he thought, maybe I'll become an Erlang developer. Okay, Ruby is known for one thing
13:21
and that's it's about developer joy, right? It's a happy place to be a developer. They hug each other, you know, it's like a good spot. It's not necessarily known for, you know, those other things we're talking about. But it is about developer joy. Now you can say the reverse about Erlang. So it is good about solving these hard engineering problems.
13:40
You've got these crusty engineers that created the language. Two of them are here this week, so we have Joe Armstrong and Robert Verding, crusty, serious engineer guys. And so they weren't focused on the problem of dev joy at Ericsson in Sweden, in Stockholm. They weren't focused on that problem. And so Jose decided, I'm gonna take, I've got another approach. Instead of trying to rip off Erlang,
14:01
what I'm gonna do is I'm gonna write a new language that targets the Erlang VM. And that's the path he went down. He's like, I'm gonna build developer joy, good modern tooling, all this on top of this VM that has this amazing track record. And we're gonna talk now about the sweet spots. So Elixir, it's also approachable.
14:22
And it's productive not just in the short term, but in the long term. So it's approachable, productive, and you have modern tooling. So first about approachable, we can look at, you go to elixirlang.org, and it's a useful website. It's not just a thing because you gotta have a website. It's really useful of learning the language.
14:41
And so if you jump in there and you go to the getting started guide, down on the right here, you see one through 21, and you actually have a really good handle of the language just by following those pages. You can start here instead of getting a book and you'll do fine. Then as you're going through that, you can also go to this other link here
15:01
and find all the meetups around the world. And you'll see a bunch of Ruby people and a bunch of node people and functional programming people scattered in. This is the pattern I've seen city by city. You can go to GitHub, see the code, see the language, and contribute. And you'll have feedback from Jose right on the site.
15:20
So you have this, you get a pull request and he's sending hearts all over the place. And so this is a nice thing to see this Ruby love showing up inside of this language. He's a great guardian of the language, he's a great protector, and he's also very interested in bringing in ideas from all outside places. Another part of the tooling story is hex.
15:41
You have hex PM, it's a package management system. It targets, so you can use this for your Erlang code, which you don't have because there aren't any Erlang developers in the world. There's like five, 10, 15, there are a few of us. And so there aren't many. But this Elixir side, there are a lot, and that's a growing thing. And so we go off and we see some of the libraries out here.
16:03
You won't find libraries that do like three lines of code libraries. These are libraries that take on more serious things that people need all the time. But you won't have your six lines of code on a package. And also if you go to something like Ecto and look at, you'll see that the level is pretty good here.
16:24
This is the documentation off of a package that you pull down from hex. Hex is fast, all sorts of good qualities about it. Packages don't disappear on you on hex. It's this immutable store of packages. Packages disappearing on you. This of course has been in the news this year.
16:41
Poor fellow over here, Azer, God bless him. And so he took a beating, and there's a lot of beating that went on. There's a lot of negative that happened here, but I think his comment by Tracy Harms is really nice. This catastrophe isn't the fault of a single solitary developer's decisions.
17:02
And if a complete stranger can push some buttons and break your production deployment, you have some thinking to do. Especially if that was around six lines of code that was really about doing something that the language should have done anyway, out of the box. Okay, modern tooling. So we'll have this sort of retro, modern,
17:22
hipster, bicycle thing here. And so like all modern languages, we have the terminal is the way you do your good work. And so we'll return to the terminal here. IEX, the interactive Elixir shell. When we say IEX, that brings up an Erlang node. So it brings up an instance of the Erlang virtual machine
17:42
and loads up all the Elixir goodies here. We go IEX, and we are inside of IEX, and we can do something like H, enum. So help, we're gonna get help on this thing. We hit dot, we tab, and we get auto-completion of all of the functions within the enum module.
18:01
Or within the enum, yeah, within the enum module. And so we say, I'm interested in what count one does. The count that takes one argument. I'm interested in what that one does. So we get this nice color. We get examples right in the examples. And this is the way you can go through all of the libraries in Elixir, and you have this help right at your fingertips.
18:22
Mix is another tool. IEX is a tool. Mix is a tool. Mix is ripped off from closure community. There's a tool called line again there, which, you know, you can see some of the commands we can do with this. You can think of it, build code, run your tests, scaffold new projects, and it's pluggable. So additional things can come in.
18:41
So let's say mix new fizzbuzz. We're gonna scaffold out fizzbuzz, and here we go. We get a read me markdown file, which is nice and modern. We get a get ignore built in, which has our ignores that we would want to have an Elixir project. That's nice and modern. And our config, and so on.
19:00
We have our fizzbuzz module, and then we have tests. I mean, this is nice. You know, we come in here, and this is a nice place to be. So let's go into CD into fizzbuzz. We'll say mix test. We compile, and right out of the box, we get one passing test. So they already started off for us
19:20
with a template for us to have tests. So let's now go in and see what that story looks like. Okay, so I have here our scaffolded out code
19:41
off of our fizzbuzz. This is just what is, so this is our one test that was scaffolded out for us, and that's why we had our one. Now I have a fully implemented fizzbuzz over here, and we can see it's down here.
20:00
We play to a number, and it does a bunch of stuff that we don't have to worry about yet, because we're gonna see about the syntax in a minute. The thing I wanted to show here was the experience of saying mix test. Okay, so we have three tests and one failure. So we saw one test a minute ago. What's that about, and why do we have a fail test?
20:20
Let's go here and see what this fail test actually is. So it says here fizzbuzz play 10 to 16, and it expected a fizzbuzz here, but we had a fizz instead. So let's go up here and see what that's about. So what we have here is this is not a regular comment.
20:45
This is a doc test, and so right in the middle of our comments, we've included examples of usage to make it easy for people to come in, and right here, this becomes part of our test suite. So we have fizzbuzz play one to five, it should get this, and that became a unit test.
21:03
Fizzbuzz play 10 to 16, should get this, and that became a unit test that actually failed on us, because we have a bug down here. We have a pattern match that's too greedy, and so what we need to do is move this code up here, do this, and then we need to move down here, and we need to rerun our test.
21:23
Oops, I forgot to save dinner. Yeah, so our test passed now that was based off of that doc test, so I think that's pretty sweet.
21:41
Okay, so another productive, nice, sweet part of Elixir is the Phoenix framework. So this is a web framework that was built by the fellow who just walked in here, Jose Valim, created the language. And Sunny Scroggin, who is back there, and Chris McCord, and so a bunch of awesome people.
22:01
Chris was here last year, gave a talk, it's on Vimeo. And so Phoenix is amazing, but I'm not gonna talk about it because there's a lot of good content about it by people here later today. But this is what a lot of people want when they come to a web framework. So Elixir is functional.
22:21
And so we've probably heard a lot of buzz about functional over the last few years. And so a simple way of looking about functional is you have inputs that are transformed by a function and you have then outputs. A goes to B, inputs go to outputs. You don't have, I'm gonna come in, I'm gonna set the table with all my state,
22:42
I'm gonna set fields, properties, I'm gonna have a class with all this stuff and I'm gonna call then functions that are gonna mutate state and then I'm gonna lose track of what I just did a minute ago and I'm gonna have all these bugs. Instead, you can look at the class, what came in as the input, and know what should have happened inside of the function in return. This is important.
23:00
And this is a good way of getting out of a lot of those troubles that I saw when I was my first trip to Norway. Mutability is another part of functional programming and Elixir takes this very seriously. It has to take this very seriously because Erlang VM has a hard set of rules that it enforces and this is one of them. So it's not a thing you can turn off.
23:22
Separation of data and behavior. So this is the thing we were talking about earlier about classes with their fields, their properties, their data and their behavior mingled together which limits the use that you'd be able to handle and use that class in. This is, in Elixir you have modules that have functions. You don't have properties fields. So you call into a module
23:40
and you call a function within a module and it's just the inputs that come in and then the outputs that go out. So you spawn up a new process and you say, this process, I need to call into this function, passing in this input, I'm gonna take the output of that and feed that into another function and you just pipeline these things together and that's the way you build programs inside of Elixir.
24:04
So we have expressive dev joy. Let's talk a bit about the language now. So language, language, language. Okay, so we have IEX again and we're gonna look at some of the types here. So we have integer, expect it, 0x2a, that's kind of nice. You know, we get our hex right there.
24:21
You know, we don't get barked at for having seven float divided by three. It just does the thing you'd expect. The thing. You have a type called atoms that are sort of, they're the thing themselves. They're only comparable to themselves. They're just a handle or a constant that even if you have a whole cluster of different machines, this, like the atom goat is equal
24:43
to the atom goat on the server and it's not equal to anything other than the atom goat. Strings are real strings inside of Elixir. You might have heard stories, horror stories about Erlang where it's like, oh, it's bad at strings. And it turns out it was a problem with naming was the problem with Erlang and strings.
25:01
The thing they called a string is not what people expected it to be. And in Elixir, a string is what you expect it to be. You know, you get this UTF-8 binary good thing and it behaves like you would expect it to. Actually, it behaves a little bit better than you expect it to and we'll see that in a second. We have lists.
25:21
You have lots of list processing inside of functional languages and you have tuples. So this is a positional thing, so we see that. Okay, let's look at pattern matching for a second. So X equal five. So we've got our five there. And we say five equal X. Well, that's a little weird. So what we're actually doing here, this is a pattern match
25:40
and it's going to evaluate the same. It's happy to say, yep, five is equal to X. You know, this is a match. And you can pin X down and say pin X equal five. And it's happy to say that, you know, that's it. We say pin X is equal to X plus one. It's going to bomb and say, nope, no it's not. Thing's not equal to six. Left hand side's not equal to six.
26:02
We have then pattern matches that can be against more complex structures like tuples here. So we have ABC tuple that matches against apple, banana, cherry and we see that we then bound B to banana. Apple to A and cherry to C as well but that's what we showed here in the shell.
26:22
Pattern matching, we'll have a little bit bigger of an example. We have list here, one, two, three. See, it binds. Does a pattern match, sort of, is a way of looking at it. But we're actually assigning this thing. So list is now equal to one, two, three. And we say case, our list and we're going to do pattern matching here
26:41
inside of this case statement. So, and we're doing this in the shell here. You can have multi-line things. You can have complex bits inside of the shell which is pretty awesome. So we say case list, do. We say 11, 12, 13. And this is not going to match because one, two, three's not going to match that, right? Okay, is this going to match? Nope, not going to match because this is a tuple, one, two, three rather than a list, one, two, three.
27:01
It's a different type, right? Here we have one X three. And this is going to match and it's going to bind the X that came in. It's going to bind the two to the X in the middle and we can then use that later on in the same case statement to do our string interpolation and show this. We'll see that happen here. So, matches and binds two to X.
27:23
Digit separators. This is something that's coming in C sharp seven, I believe. So we've got a thousand. You also just can say a hundred, underscore. You can say da da da. So it's just pure candy. I mean, this is about the Devjoy side of the language. I mean, there's just all these things that just make life a little bit nicer, you know?
27:43
It's not important, but it's just awesome, though. It's thoughtful, you know? So here we're going to look at anooms and streams. So we're going to define an anonymous function. So a lot of times in functions, there's a convention of if it returns a true or false, you can put a question mark at the end of it.
28:00
So that's a nice convention. You see it, you know what to expect. So we're going to define this anonymous function. It's going to use the rem function. So rem returns the remainder of two numbers, you know, divided. So this is like a module. And so we say rem, the first argument. So the ampersand one is going to take that first argument that's passed in. It's going to rem that number, comma, two.
28:22
So we pass in a five. Remainder of five, comma, two would be, well, one. And so it's going to be an odd number, right? So here we have a range. We have one to a hundred thousand. And we're going to pipe this forward. So any F-sharp people in the room? All right, you'll recognize this. So we've got one to a hundred thousand piping forward into,
28:43
so that each one of those values are going to get pushed in, is the first argument to the thing on the right. So this functional pipelining. A new map, and we're going to take whatever the argument was, we're going to multiply it times three, and we're going to pipe that forward into a new filter. And we're going to filter on our odd function that we defined at the top.
29:00
And then we're going to enum sum that. And we get our answer. Let's do the same thing, but this time we're going to use stream.map. Stream.filter. And then we do enum sum. So the difference here, we get the same result. The difference is, is stream is lazy. And so on our first and our enum, each stage of that, we went through the whole computation
29:22
and we passed then that on to the next series in the pipeline. With stream, it's dragging one at a time as you're coming through, it's a pull-based thing. And these both work off the same interface. It's called a protocol that they both, both implement the enumerable protocol. This is like interfaces and C sharp,
29:42
or the protocol comes from closure, where this idea is directly borrowed. I mentioned strings earlier, this is kind of cool. You know, we can have straight up UTF awesomeness right here. So all the Norwegians with funny characters in your names, you can appreciate this, right?
30:01
Person equal. So let's look at maps. So we got our person name, Brian, Beardy Faults. I'm only Beardy in the winter, not Beardy in the summer. And so we can access it by key, like this. Person name, we can access it by dot, like this, get the same thing. We can build a new map based on an old map
30:22
and just push in the properties, or the keys that we're gonna change or we're gonna override, and so we have the same thing, Brian Hunter here. Okay, let's look at structs. Yes. Yep, yeah, I could do person and it's still there. It's just that we have a new, everything's a copy.
30:42
It's not mutating, so good question. Here, this builds up on top of that idea but gives us some extra goodies. So we're gonna define this module called person here. We're gonna put a def struct in here where we say name, and we're gonna give it a default of empty string, and we're gonna say Beardy, and it's gonna default to false. And we then have this data structure that we can start using.
31:01
So I say a person. I get my defaults. I'm gonna say Brian is equal to a person named Brian. So we see person, Beardy Faults, name Brian. I say person named Brian, Beardy Faults. Boom, there's no such thing as Beardy. So we got protected by using the wrong key there.
31:20
There's no such thing as Beardy, there's Beardy. So it blew and barked and kept us from getting into all sorts of trouble that you've probably all experienced with JSON. Alrighty, versatile. This is a really crazy thing. So the language, you expect certain things out of languages.
31:42
Here we have something you would only expect to be able to do in C. So we have the bit syntax, and we're gonna run through this really quickly. We're gonna grab OK bin data, and we're gonna read this file. So if we look back on this image, this is five pixel wide, black, red, green, blue,
32:03
white, and this is the data below. So we're gonna read this file, capture it. We captured bin data, we captured the binary data there to the bin data variable. And we're gonna set up a pattern match where we're gonna catch on the left, using this DSL called the bit syntax, we're gonna catch on the left the data
32:23
if it matches against bin data here. And so we'll see how that worked. So here's our data again. Our left two bytes has to be BM in a bitmap. So you can just go through and just think about data struct, you know, binaries out there, and you can just implement using this DSL and be able to process like whatever your protocol is
32:44
that you're trying to implement, your format. So that was a match. We're gonna throw away 64 bits. We're gonna capture a 32 bit little indian into a variable called offset to pixels. Throw away, grab five, height one.
33:01
Size, we're gonna throw 16 bits away. We're gonna make sure that the next thing is a 24 here. And then we're gonna throw the rest of it away. Now we're gonna say that offset to pixels, this told us where the actual pixel data begins. And we're going to remember that, and we're going to throw away that many pixels. And we're gonna capture the rest of it
33:20
into a variable called pixels. We do that. So we saw our values that were here. So we have this for comprehension where we're gonna capture, we're gonna shove pixels in, eight bits, eight bits, eight bits into blue, green, red. And here we go. We've got our data. So that's one line, one screen worth of code inside of the shell, and we've parsed bitmap,
33:43
which is kinda awesome. So something borrowed, a lot of things borrowed. One of the things borrowed is Erlang VM. Erlang VM grew up out of Ericsson, doing awesome, serious, hardcore telecom things. We're focused on fault tolerance.
34:02
So to have fault tolerance, you have to have concurrency. If you don't, process dies, you're fully down. You have to have distribution. If you don't, box catches on fire, you're fully down. So those things are important. And you see the track record of the fact your phone works, and that over half the world's mobile traffic is going through Erlang, which is pretty incredible,
34:23
all the data, text, voice. More recent story is WhatsApp, with their victories on the Erlang VM. So just amazing, amazing numbers here. A billion active users a month, and so on. And another number that's important to the business is 19 billion dollars that they were paid by Facebook.
34:43
There's 10 engineers building this mighty code base. We look at what the Erlang VM is in context. We have the runtime, we have OTP, we have languages of Erlang, Elixir, list-flavored Erlang. There's a talk here this week on list-flavored Erlang by Robert Verding. And so here's why people can't just grab the Erlang VM,
35:05
like Erlang bits, and pull it into their language. And it comes down to this thing is an operating system. And it took a lot of time to build it. It's a serious operating system. It's not a general purpose operating system like Linux or Windows. It's a special purpose operating system about making a safe place for code to run.
35:20
250 plus years of development went into it. You can see an example of it being an operating system on Erlang on Zyn, the Zerg demo. And this boots up what would take 300 seconds to boot up a Linux VM on EC2. Here they boot up into an instance of bare metal Erlang running on the Zyn hypervisor. It boots up in milliseconds, brings up the Erlang VM,
35:45
runs a web server, processes things, kicks out your request, and you have this result in .3 seconds. Pretty awesome. So let's look at the job of an operating system, which Erlang VM is, process management, interrupts, memory management, file system, so on, so on.
36:02
And think about what our code does. Our C sharp, our C, our JavaScript has a job. And that job is to eat as much core as it possibly can. It's trying to do, it's only worried about itself. It's not interested about the safety of the rest of everything running on the machine.
36:22
And so the operating system kind of has to hate you. It has to hate your code, it can't trust it. And this is the place where it's really different on the Erlang VM is because the Erlang code cannot do things to hurt the stability. The Erlang code itself has to play by the rules that the Erlang VM set up for it. Erlang VM doesn't have to support C and Java and Ruby
36:42
and all these languages. It supports languages that only are going to do things that the Erlang VM allows them to. So that trust is nice. When you can cooperate, you can get a lot done. When everyone's fighting against each other, you don't get a lot done. And so this is a big part of that story. So we got our Shaun of the Dead reference,
37:01
cricket bat, processes. So processes is the way we win here. So concurrency. Concurrency is not the same thing as parallelism. A lot of times those words get used interchangeably, but concurrency is about the structure, doing lots of things at once, and parallelism is about the execution of lots of things at once. This comes in on a story at Ericsson.
37:23
So when they built Erlang in 1986, they weren't targeting multi-core machines in Stockholm then. I mean, this wasn't a thing then. And so they built concurrency, and they didn't build it so they could go twice as fast. They built concurrency so that they could code
37:43
without getting twisted up into these horrible nests of callback-y weirdness and into thread weirdness, and they wanted to make the code simple to read and to write, because code that's simple to read and write is less buggy, and that helps your fault-tolerance story. So they did this massive moonshot from 86,
38:02
and then they turned on multi-core in 2006, and code had been written a decade before. It did then run twice as fast on two cores, four times as fast on four cores. And like 2010 or 11, there was a test where it had linear scaling up to 40 cores on properly written Erlang code. We get that same thing in Elixir,
38:20
because it's the same VM, all compiles down to the same beam. So let's look at Elixir and the Erlang VM and the actor model. So every actor gets some props. So our actors are processes. So every process gets these props. One is memory. So each process is one kilobyte.
38:42
On a 32-bit machine, it's two kilobytes on a 64-bit machine. Inside of this memory here, we have a heap and a stack, and it's that processes only. No one else can reach in and grab a reference to memory inside of that process. It's isolated. And it's also immutable, right? Because it's functional. And so garbage collector,
39:02
easiest job in the world to be a garbage collector on the Erlang VM, because no one's, only one person's looking at the memory. You can't change it once it's set. And so each of these processes, they get their own isolated dedicated garbage collector. So there's not gonna be a big stop the world GC that happens. Each one gets garbage collected independently, which is pretty amazing.
39:21
And that's done for low latency, and it's done for deterministic scheduling. Our mailbox. This is the only way our process talks to the world. So, last poor year. So we talk to the world through our mailbox. This is the only way a process can reach out. And so we send a message out of our mailbox.
39:42
We address it to another process. It makes it in this inbox when they go into a receive block. Links and monitors is the thing that we build up on to create some fault tolerance goodies. This is at this OS level, this Erlang VM level, where we get links and monitors. Links, basically like, I'm going to link to Jose over here.
40:01
And if Jose dies, I'm gonna die with him. Okay? Sunny back here. There's a different sort of thing. So Sunny, I'm gonna monitor to Sunny back here. So Sunny dies. Well, I don't really exactly want to die. But I'd like you to tell me about it. Tell me if Sunny dies. I actually care about him, but I don't want to die. And so it's a different level of commitment there.
40:22
And so that's these two tools you have out of the box. So process scheduling on the Erlang VM. We have a CPU core. We have a single scheduler that lives on that CPU core. Get three processes up. And each one of these processes is gonna get 2,000 swipes at the core.
40:42
2,000, 2,000, 2,000. There's nothing in the world they can do to eat more core than 2,000 swipes. They can't block and hold up the show. Everyone gets, it's preemptive scheduling here. So this is another way of visualizing it.
41:01
They each get this much and they get thrown back into the rotation. Same thing happens if there's multi-core. If there's big multi-core. All happening. So we also have the supervision bit off the links and monitors it's talking about. We have a supervisor and a worker. The worker, something happens. The network card's down.
41:21
The hard drive failed, whatever. We have some weirdness. The supervisor can then restart the worker. And this is important because what do you do? When you call tech support about something, the story is rebooted, right? That's the first thing they walk you through and it always works. And you're like, oh, good, it worked again. And so this model is built into Erlang. It worked so well for tech support
41:41
that they included it as part of the language. So process running. The process running and boom. He falls into a receive block. He's gonna sit here forever and ever and ever blocking, waiting for a message to appear in his mailbox. No one's talking to him so he's gonna sit here. Well, does that wreck the show? Have we now blocked and wrecked the show? Well, no we haven't.
42:01
Because the Erlang VM schedules him out of the mix. And then we schedule then across the other two remaining cores, back and forth. And we don't bring this guy back into the mix until the postman, the Erlang VM, the operating system, until he knows that that process actually has mail. When it does, he's brought back into the fold, part of the rotation.
42:21
This includes things like file IO. So any sort of IO that we have goes through message passing like this. So even though I write file read earlier on that bitmap file, when I said file read, I was talking to another process
42:40
and then I waited for that process to send me a message back. I didn't have to do this as a developer, it's just part of file and the read function on there. It's part of gen server. And so at the point I asked for that file, immediately when I asked for it, that process is over there doing the file reading and I'm removed from the rotation until I have a message in my inbox. So non-blocking IO that you don't have to worry about,
43:02
you can treat like sequential code. It's really done right here. Four cores, four schedulers, you got processes and we have this game of balancing compaction. So that happens. And so busy scheduler, busy scheduler, I'm not so busy. I'm gonna take some work from this guy, move it over here so that this scheduler can get sleepy
43:22
and the whole core can go to sleep. And this will happen so that you get this compaction across your cores and in a server closet you'll have half your cores being able to go to sleep on if they're running Erlang, which is pretty amazing for power savings. This core, memory locality, things are building up here.
43:41
He's getting hot, hot. This one's got some work ceiling to make it even-steven balanced. So got this game where we play and we get massive concurrency, preemptive multitasking, soft real-time, low latency. And the low latency is valued more than raw throughput,
44:01
which is an unusual characteristic for a language. Scheduling, parallelization, and fault tolerance in node. Cause you're pretty much left to your own devices here. I mean things, you're gonna build your own operating system
44:21
every project or use something out there that someone else has had to do. So on node we have cooperative multitasking and on Elixir we have preemptive multitasking. So cooperative multitasking, it sounds good, right? But what it means is you have to cooperate and if you don't you can wreck the entire scheduling system. On Elixir you cannot do that.
44:42
Single-threaded event loop. Single-threaded event loop, cooperative multitasking. It's like they read my mind. What we do when we were, we get into this trouble with callbacks and I know that this is one that you've heard a lot about and there are a thousand blog posts out there
45:00
saying there's no such thing as callback hell, it's a myth and all this. But a lot of people are talking about it. So some people experience it. But there's discipline, you can follow all these paths, you can go down this route and you can solve your callback hell problem and have flat code by hoisting things around and flattening things out and on and on and on, all these patterns if you're a diligent person.
45:25
There's a funny use of words in node but we'll talk about that in a second. So Node.js does not automatically manage the number of workers for you, however, it's your responsibility to manage the worker pool for your application needs. So node's easy, that doesn't sound easy. Distribution tends to be very unbalanced
45:41
due to operating system scheduler vagaries, loads have been observed where over 70% of all connections ended up on just two processes out of a total of eight. Well, node's supposed to be easy, that doesn't sound easy to me. Okay, here let's talk about Elixir and simplified distribution.
46:00
And I think I actually do have time for this demo which is really awesome and surprising. Okay, so here we have just a simple loop called Blabber. And I'm going to move over here and then use, I've got three consoles,
46:23
a terminal window set up. And I'm going to start up an IEX and I'm gonna pass it S name cat with a cookie of taco. Here I'm going to start up an IEX with the name of dog with a cookie of taco.
46:41
And here I'm going to do bird with a cookie of taco. So I've got these three named virtual machines, these three nodes brought up here. Okay, and if I say node list, I don't have any friends yet. So I say node connect.
47:00
And I'm the cat so I want to connect to the bird and it says true. So if I say node list again, I see this. The bird, he knows that something's happened too. And he's like uh oh, cat knows about me.
47:21
So I'm gonna say node dot connect. And I'm gonna bring the dog into the mix because the dog always saves the cat, right? Saves the bird from the cat. So here, I go back over here, do my node list. And I'm like uh oh.
47:40
So we all know about each other at this point. So we have a full mesh between these nodes. And that's all it took to do this. This can happen across multiple boxes, across heterogeneous hardware. So 64-bit Windows, 32-bit Linux, a Raspberry Pi on ARM architecture. And we can have code, this cluster formed and we can deploy code across these. So the code I'm interested in deploying here is this Blabber server.
48:01
So we're gonna spawn this process start. We're gonna call start, which is gonna spawn this process based on this server loop here. This is a really short piece of code here. We're gonna fall into a receive block. We're gonna wait for someone to send us a stop message. If we don't, after 200 milliseconds, we're gonna say nice, we've got some uptime here. And then we're gonna tail call loop into ourself passing plus one.
48:22
So that's our logic. So let me ls, make sure that that code is there. I'll say compile Blabber. Just a blabber, just to make sure that I've got a fresh good one here. And I'm gonna say, I'm gonna store off a PID,
48:41
equal Blabber start. So I've got my process ID that was returned from that and I'm here and I'm seeing nice, zero years of bug-free uptime on cat at Daedalus. I go over here and I was like, I'd kinda like to do that too.
49:07
So I say PID equal Blabber start. Gah, I don't know anything about that because I'm not over here on bird. It wouldn't exist there either. But what I can do here is I can say nl and I can say nl Blabber.
49:25
And so what happened then is I just deployed my code to all my connected nodes. So over here on dog, I can now say PID Blabber start and it works. And I can go back over here
49:44
and I can say, I wanna spawn this process on another node. I wanna say PID two is equal to node dot spawn. And I'm gonna spawn that on the bird node
50:04
and I'm gonna spawn it by passing the node name. I'm gonna pass in the module name and I'm gonna pass in the function name to call and I'm gonna pass in the arguments, which is an empty list, right? And so now this process is running over on bird.
50:24
We've got the one running on here but we're actually getting the IO piped to us. It's running over on this box. If we kill this thing, we would no longer be getting this message on the left saying six years of bug free uptime. Okay, so that's pretty cool, I think. So here, let's fix some code.
50:41
We've got a bug in here, don't we? Where's our bug here? We don't have enough gusto is our problem. Our bug here on this line is we need more gusto. We need an exclamation point here. Okay, so let's go over here. We fixed our bug. We're gonna ship this code and so we're going to first recompile it.
51:03
And so we get this. Our next tell call into this, our bug is hot code deployed on our running server and I say NL to deploy this code to my other servers and notice what's happening there. Over on our other cluster, over on another node,
51:23
we have that picked up and it deployed over here to this one as well because its output is being piped back to us. So this is pretty crazy awesome is what this is. And this is short of examples I can show about, this is a basic way of showing how the foundations and how the real stuff works.
51:41
Okay, so we've got to now hurry because I took the luxury of a sweet, sweet demo. Okay, so let's talk just briefly about OTP. So this is where the safety and fault tolerance story really comes in and it's built up on these basic things that we all get by using Erlang VM,
52:00
by using Elixir. We get applications, we get supervisors and we get gen servers. Gen servers is where we do the work and these all play with this nice system and this is proven at Ericsson over this decades on these systems that have nine nines of uptime. So we're talking about milliseconds a year. This is a common sort of thing. Everything has to be carrier grade for it to be telecom
52:22
which is five nines but you actually beat that with Erlang because of these amazing bits here. So application supervisor gen server, this is sort of looking at the tree of it. So an application spins up and brings up all of the things that need to run in the context of that application. So you'll start up, you'll have supervision
52:40
where that supervision is then over here watching our gen server, right? And if that gen server hits some weirdness and dies, it'll restart. If this gen server down here causes some trouble or any of its peers, we've got a bunch of gen servers being supervised by this supervisor. If any of those croak,
53:02
this supervisor's gonna restart them and if it happens so often, we meet some threshold, the supervisor here could actually be killed. And if that happens, this supervisor is going to bring that back up. And so you have these whole trees of these things depending on what you expect to happen in the code and how nasty you see the problems being. So in Elixir, we code the happy path.
53:23
We don't have a bunch of tri-catchy stuff worrying about like, oh, what's gonna happen because you never can really predict it. You can predict some things but you should maybe just code it differently. But what's easier is to code the happy path, things go weird, just let it crash. Let the process crash and leave that problem of handling the error to supervision.
53:44
On this side, different story. Unhandled exception means your application and by extension Node.js itself is an undefined state. Blindly resuming means anything could happen. And this is right off of nodejs.org and this terrifies me. The safe way to code for massive concurrency
54:02
is to code sequentially. The easiest code in the world is code that goes top to bottom that you can just read. Instead of, callbacks are not really easy to grok, so you actually code top to bottom in Elixir code. You have massive concurrency but you're coding top to bottom. It's not your job to think about all of the plumbing of how the concurrency works.
54:23
So think about this, you've got 100,000 connected users. They're making all these callbacks. You're running on the single-threaded event loop on this single process and you don't really have a supervision model. So one of those dies. So you've created this attractive nuisance here. Node is this attractive nuisance where people come in
54:42
and they can just break their ass. You can really get hurt on this thing. And we have all sorts of tools that we've been talking about so far in Elixir where you get out of this pit of failure and you end up in a place where it's just actually easier to build systems that work. It's easier to do your day-to-day coding.
55:00
One of those things is being able to code with a powerful REPL. The shell there. So when I'm building my Elixir code, I try it out in IEX, I can do all my things, I can see it work, and when it works, I hoist that up and put it into test to protect me against regressions. So this is like TDD, the part where you actually
55:21
change your interface by the way you call it. You're getting that constantly inside of the REPL and then you can then hoist that code out to protect you against regressions. So this idea of testing is big because it's big in the Ruby community. It's made very easy here in Elixir. Made easy by having good docs and then doc tests like we saw earlier.
55:41
Website called the Node Way talks about, this is a protecting you from trouble kind of website, it's a guidance website. Node.js has always been easy to grasp but difficult to master, common fit falls, never been well documented, it's up to you through painful trial and error, on and on and on. And it's like, oh my goodness, this is the tool that's supposed to be easy.
56:03
This is what was gonna make us be able to write code more simply and deploy more simply and it's just not what happens because we are required constant diligence there and we shouldn't do this to ourselves, we shouldn't do that, we shouldn't allow tools and frameworks and languages to put us in that spot
56:21
where we're constantly having to be on guard because we're fallible, we're human. So at this spot, we have now traveled through our hero's journey here where you've now had this introduction to this thing and it's kind of up to you to go off and pick it up and do awesome things with it and I think you're gonna be stunned about what you can pull off
56:42
and how it's not just easy at the beginning, it continues to be easy. It's easy as it can be, should be, I guess. So hats off really for Jose over here for this thing he's built, it's absolutely stunning. And so at the end of this, I love this on the hero's journey that they actually end with this line,
57:01
it's return with the elixir. So hopefully you all will go and return with the elixir. My two closing bits here are elixir, it's a pure sustainable joy, is I think what you get on elixir and you get something maybe a little bit different over here, it's popular, it's crazy and it's dangerous
57:21
and I'm going back to this country here at the end of the week and so that's the world I live in. So thank you all for being here. We have this over here so please vote and tweet and go off and install elixir and have fun with it and then also come right back in here in a minute for our next session with Yan Cui
57:41
and it's on F Sharp in the Real World. And so the FP track will be in this room all week other than the workshops which is the hour after lunch and for those, I would be in workshop, I think it's room 10 but it's workshops and it's where you can just hang out with all the speakers in the FP track and have them walk you through things. And so we'll have Jose, we'll have Joe Armstrong, we'll have Robert Verding, we'll have Matisse Brindavender
58:02
who ran the F Sharp Machine Learning Workshop with Evelina and so awesome bunch in there, hope you join us for that and other than that, actually I cannot believe it, I have a minute and a half for questions. Is anyone, yes.
58:22
I think so, I think it has that sweet spot. I mean it definitely has a sweet spot of sending up a website quickly that can handle lots and lots of things but then it's like you've got to then have someone actually do the work.
58:51
They would there, I mean that would be, it's easy to handle 100,000 users on the Erlang VM. This is a sweet spot of the language, that fault tolerance concurrency distribution,
59:01
that's what it was built for. So back in the 80s that was what it was built for. 100,000 phone connections coming in and people expect their phone, they did expect their, before mobile phones with apps, you expected your phone to work and so you had fault tolerance. So I remember as a kid when a squirrel would get into the transformer on the power lines
59:21
and go poof and in the house all the power would go out we'd pick up our phone and we'd call the power company and that just tells you about that sort of fault tolerance story and it's real there and it's real because of these tools and so again that Erlang VM is why that's happening. Like over half of the world, all of the traffic for mobile is going through this, so massive concurrency.
59:42
Easy to do, I mean it's just the sweet spot of the language. A place where I would use Node for is, I think maybe what you were getting at, a place where I would use Node is here where I am using Node. This is Atom. I think JavaScript is a great language for the client.
01:00:00
I mean, JavaScript obviously works well in a browser and it's a very good thing to have on the client. It's ubiquitous, it's out there, people know it, you know the problems with it, and you don't have 100,000 people that are going to get hurt if my atom crashes. And so that idea of atom and electron, there are talks here this week on electron
01:00:21
I believe, and so it's a good thing to have it there. It's really nice the tooling they built up. But I wouldn't want to use it on something where I had to count on fault tolerance. And I wouldn't want to have my company building up on it for business logic. And I know companies that have done that. They got lured in, their business logic, everything.
01:00:43
They ported from C Sharp because of problems that they saw there. They didn't like the experience there. They moved over to Node and now they're trapped. They feel like they're in deep. They've started bringing in microservices, which is basically the plea for help.
01:01:01
So when node shops start talking about microservices, what they mean is like, we've screwed up, we're going to have this tiniest bit of code. And it's like, maybe this will get us out of this trouble we're in. Well, you think about what functions are and processes with a message passing, that's microservices. That's how you want to handle that problem. And so, any other questions? Yes.
01:01:34
Well, this is a really interesting one. So, you'll never ever hear on the Erlang VM anyone talking about monads.
01:01:41
But you have something that... So, what is the IOMONAD for? So, we know in Haskell, if we're writing in Haskell, that we want to have all of our code be sane and we want to build a reason about the world, right? But we still have to... We have to have side effects, right? If your code doesn't have... If it can't write to the monitor, if it can't write to the hard drive, it can't write to the network card,
01:02:02
you're not actually going to get anything done. So, you wrap that then inside of the IOMONAD. Well, on Elixir and Erlang, the equivalent of that would be port drivers. So, all of my Elixir code, my Erlang code, it can only talk to other processes through message passing, right? Can't reach out to the operating system, can't poke through, do anything.
01:02:22
It's all in that safe, safe world. So, the way that the ugly, scary world is hooked in is through port drivers. Those are written in C and they meet a certain interface that makes them look to the Erlang VM as if they are Erlang or Elixir. You know, they look native on that side.
01:02:41
But you've got the scary, scary world there. And the only thing that then can touch the outside world is a port driver, which is a process which can be supervised. And you don't go off writing port drivers all the time because there's the file system, there's the network card, there are these basic number of things that you want to talk to in the outside world and the way you do that is through port drivers. But I love that question and I forgot to actually mention it earlier, so thank you.
01:03:03
Yes? So, I'm always surprised. People talk, well, Erlang's not a great language for doing machine learning, that sort of thing. Well, it turns out it actually is pretty good at machine learning.
01:03:23
And here's an example of, so you see the F-sharp digit recognizer project. So, the thing it's not good at, so I'll say that you can actually do this and I've explored this path of using it for this. The thing it's not good at is it doesn't have a static type system. So there are going to be errors that you don't catch at compile time.
01:03:42
This is a place where F-sharp absolutely just beats the hell out of us over on Elixir. Because static type system, you catch all these problems. And it depends on the kind of code you're deploying and why you're deploying it. So, if you're going to a mobile phone, for example, where you have to go through the Apple store for a week review and all this and you can't change your code and you can't get users to install the new one,
01:04:03
you want to catch every problem you can at compile time. So that's why I really am excited, you know, like Xamarin, which I have my Xamarin shirt under here. You know, they have this F-sharp support and there's also a talk on F-sharp and mobile coming up a little bit later today. But that's a place where I would use F-sharp for sure over,
01:04:20
you know, you don't even have the option of using Elixir on a mobile phone. But I would use it for those places. Now, on the server, it's actually a lot easier. You think about this, we did this hot code deployment. It's easier to deploy that new Elixir code to a server than it would be if you had a static type system with DLLs and all that. You know, that was just crazy easy. We changed the code, deployed across this cluster and everything worked.
01:04:41
And so, it comes down to what your deployment story is. So I think in the short run, like, if an app has to work really, really well immediately and it's going to be really hard to update, you know, that's a static type system problem. If it's something, you know, this other side you have to have a system that runs and runs and runs for years
01:05:02
with no downtime, the static type system protects you in that first hour. You get your maximum, it's kind of like term life insurance, that sort of thing. You know, there's different thresholds when they're the most valuable. Static type systems are helping you the most right when you deploy in that first little bit of life. Something like Elixir Erlang, they're helping you if you need that thing to be running for years with no downtime.
01:05:24
And I think I am now out of time. So Jan will be in here, so don't get too far away because Jan will talk about F-Sharp in the real world and he is awesome. He's an amazing presenter. And thank you all for being here. This is awesome.