Reaping the Benefits of Elixir: How to Get Started • Saša Jurić & Erik Schön • GOTO 2020

we've held a lot of go to conferences across the world and collaborated with some of the top creators and innovators within software in this brand new go to book club to give you key takeaways from the masters themselves in the form of interviews revolving around books they've created learn strategies empowered to become a more efficient developer as we dive into the first online series of our go to book club [Music] this episode was made possible thanks to growtopia.tech welcome this is the go to book club this book was written by sasha urich one of our top-rated speakers we invited him to a conversation about elixir in general and about his book to lead the conversation we invited eric stern managing director of earling solutions in sweden and an author himself we started by asking sasha if you could do a quick overview what is elixir so elixir is a programming language in theory you could say that it's a general purpose programming language but in my personal view it has like it's a particular sweet spot of what kind of programs can you write with with elixir and such programs are what i call software systems and by that i mean uh any kind of program that runs on the backend side of thing any kind of a server uh server-side program such as a web server but also for example say a database or a message queue uh and uh what is particular for software systems compared to other types of programs is that once you put them into production you know you start them for the very first time in production they have to be running for a long period of time constantly continuously for a long amount of time like a couple of years or maybe even a couple of decades and during this period you don't really want them to go down because that essentially means that the system is not providing any service at all another particular property of a software system is that at any point in time it is doing a bunch of different things a bunch of different activities are happening within the system like say all of us are making requests uh to a web server and each request by a different person is its own separate activity uh but beyond just uh handling requests the system has to do other things like say run background jobs or periodical jobs it might need to manage some kind of an in-memory state such as cash for example it may need to do some load control such as applying back pressure or rate limiting so a lot of stuff is happening just beyond a plane request responding and what's interesting is that these activities are uh mostly mutually either very loosely dependent or in many cases even completely independent like say your request and my request are typically you know completely unrelated and what this means is that in a software system uh the the the semantics of success are not binary you have like degrees of success which is not true for every type of program like if you take say a compiler or typically any kind of a command line tool you know these programs get some input they do some processing they produce the output and they can either succeed or fail there is nothing in between but for software systems you have this uh these degrees of uh success so like of course ideally uh we want uh the system to always work for everyone but clearly this is not possible uh because i mean ultimately we're humans and we're gonna produce some bugs and some things will go wrong and even if we are able to write perfect software this software runs on some hardware which will occasionally fail typically in many systems we depend on external stuff not developed by us like say external database or third-party services like say payment gateway for example um so these things might fall and it's completely out of or might fail right and that's completely out of our control so things will go wrong but because there is a non-binary idea of success we we can implement we can capitalize on this and implement the system in a way that it uh provides as much of the service as possible at any point in time even when something go wrong which is better than you know providing nothing and so this is a very particular challenge for any kind of a software system and this is what i what i like to call uh what for me is high availability it's not about you know chase chasing some mythical amount of nines of uptime it's about providing as much of the service as possible for our users you know and uh also of course the system should be able to automatically detect when something goes wrong and recover automatically from that failure as soon as possible given the circumstances um so those are the challenges of software system and uh again they are really applied to any kind of a software system regardless of the particular business domain or even scaling even in smaller systems and simple systems uh you still want your system to be mostly up and running and providing as much of the service now elixir uh as a language gives us tools to address those challenges uh gives us you know like basic building blocks very simple in their nature but very powerful and flexible to approach the challenge of high availability in a systematical uh fashion um now i want to say that elixir is not the only such language available uh for this job there are a couple of other languages like for example erlang or a lisp for erlang or gleam as an example of a newer and a strongly typed language and what ties all these languages together is the fact that they share the same runtime which is called beam and this is the name of the erlang virtual machine originally designed or written for uh the erlang programming language and now you know with time we have a bunch of other newer languages built on top of beam and beam is really the secret sauce here which allows this story to happen which allows us to build a highly available systems takeaway number one the key ingredient of alexia's support for high availability is beam the erlang virtual machine so sasha speaking of the beam here i mean that's that's the elixir virtual machine how do you say how would you say that compares to to other virtual machines that people may be more more familiar with like the the java virtual machine the jvm for instance yeah so uh what i personally find about beam is that it really has a strong focus on what it wants to do and this is to power the software systems highly available long-running programs which should ideally never fail never go down completely and uh beam has been built from the ground up from the day one you know even day minus one if you will before it didn't even exist there was a lot of thought put into it you know how to build such uh a runtime and so build provides uh many things at the runtime layer which uh other runtimes typically do not uh let me briefly explain how how it works on beam so it's gonna be clearer so uh essentially the way it works is like when you build your program in the beam blank which such as elixir or lung or other languages you will start your program and the single operating system process is started and this is the instance of beam where uh our program is running if i run five beam programs i'm gonna have five of those uh instances five os processes now within a single uh beam instance uh we can start many uh small lightweight independent programs which we call processors so just to clarify process is not a noise process os process is one beam instance and then within a single beam instance you can have a bunch of these small processes and when i say a bunch i really mean like a large number like hundreds of thousands millions up to i think around 100 million uh processes per single beam instance now uh these uh these processes these programs are completely isolated uh from each other uh so they share no memory at all uh they have their own separate memory space uh and they can only communicate through uh sending themselves messages which is also known as message passing concurrency and they are completely isolated from each other so like if a single process crashes if that single small program crashes all the other processes in the system are still up and running so they will not fail and this crash can be detected and these are like the basic foundational uh stuff that we get at the beam level now uh what this means is uh basically i like to sometimes say that like we have uh support for microservices at least some parts of microservices directly at the runtime layer and therefore directly at the language level we can do stuff for for which in other languages we have to fall back to the os level and run a bunch of different os processes and different components and orchestrate them through some uh service manager and whatnot you can do a lot of that stuff directly in a beam language such as elixir and so the idea of building a fault tolerant and highly available system is like in its basic form it's like very simple to me uh like let's say a system has to do this huge chunk huge amount of job you know everything the system has to do like it's like some huge big square if you take this big square and somehow strategically split it into a small number of independent or loosely dependent programs then suddenly no one is too big to fail right and so if you experience some sort of an error in a particular part of the system you know like maybe there is some division by zero square root of minus one something unexpected happens uh still most of the system is up and running and we are still providing as much of the service as possible and uh at the same time because failure and in general the process termination is not a silent event so any other process can be notified about it you can uh implement uh self-healing uh strategies so like uh one process crashes the other one gets notified about it and starts a new process in its place or maybe redirects some jobs to another process that was uh that is still available so it's like a pretty simple uh but very powerful idea um compared to other uh virtual machines well i didn't do it like a thorough comparison but in general as far as i know no other runtime layer has such support for high available systems or such focus uh in particular for example in jvm as far as i know there is no light with concurrency at the runtime level uh people do this on top of jvm so the most notable example is akka which takes a lot of ideas from uh erlang and i mean brings also a lot of other interesting ideas to the table but this is implemented at the library level so like you implement aka in a language i don't know in which language is it written probably java but what this means is that you kind of fall short uh you basically can do only what your runtime can do so uh for example in beam these processes are scheduled preemptively so to speak so like when a single process runs in an infinite cpu bound loop it's moved out and someone else gets the slot so you can terminate the process even if it gets stuck completely even if it refuses to stop as far as i know this these things are not possible in akka or anything else because you essentially don't have the support from the runtime you know the runtime doesn't know about uh these lightweight uh likely concurrency entities so in my view beam is really you know very focused and very well built it's a really stable runtime you know has been around for uh more than 20 years or so and i mean erlang itself is old i think about 30 years or maybe even more if you take the design phase into account so uh very stable proven practice in large systems and diverse systems such as whatsapp for example and of course in ericsson telecom systems so it's as far as i know the best option we have available today or the most suitable option that we have available today as a foundation for building software systems or again highly available fault tolerance and scalable programs so yeah i fully agree with you sasha and this is really captured in in the saying right once run forever right this that's sort of the essence of what you just described right take away number two beam is very stable which has been proven in practice in very large systems like whatsapp yeah and i'm thinking in the community now there's a lot of talk about golang and dark lang and that are in some aspects similar um what are your thoughts on on sort of the differences and similarities uh between these languages and and the languages on the beam elixir being one of them of course yeah so let's uh let's start with uh go so in my view go go is a really great language for uh building tools you know the complete opposite of software uh systems because a tool especially like if you want to distribute them massively to a large audience which runs in a bunch of different operating systems and whatnot so gogo really has a great deployment story which i really like you know you build this standalone binary and give it away and it works you know so this is uh super great i think as far as i know it's probably the state of the art in that particular area it's very simple language to pick up you know uh so uh those are like pretty good things but uh i personally and i know that people are building systems with go but personally i don't feel that go is as good of a fit for that job as beam languages so i mean go does have a lightweight concurrency but that's pretty much all it has so it's not just about having lightweight concurrence it has to be designed in a particular way if you want to build software systems with it in go for example all these go routines are sharing memory which can lead to all sort of uh strange problems and bugs if a goal routine crashes then the entire program crashes so you know think about like if you have a a single go program which runs i don't know maybe a million of go routines you are i don't know handling websocket connections to some real-time uh game server or something like that and see there is a single bug you know you have somewhere square root of minus one single go routine crashes all of these connections go down and this is like super disruptive uh for all the users you know this is the kind of thing that will not happen in beam when you design it properly uh you know you will just have one process crashing uh then go also basically has like still has cooperative uh scheduling uh they did a lot of improvements there but as far as i'm aware they're still not completely preemptive so you can still end up with a go routine which just you know runs in some longer cpu bound loop and uh just takes up a single scheduler and a couple of such routines basically block your entire system and uh also uh you cannot really terminate go routines this is a very interesting thing that you have on beam so in beam you know because process is a runtime entity uh you can terminate it uh by the random you can ask the runtime please stop this thing now you know and no matter what it does it's going to be stopped now because you know this is the random level service and so this is the first class cancellation at the runtime layer you know that kind of things pretty much are not possible to implement reliably or come completely reliably on uh in go or in say on top of jvm again because the runtime doesn't uh have the support for that uh just maybe as a passing mention you know i explained this in more detail through a demo driven presentation about a year ago when i was talking to go to chicago giving a talk called the soul of erlang and elixir so you know i'm giving a very high level overview here but if you want to see this in action you may want to check out that talk so yeah in general i think that go for me uh personally i would definitely use it and recommend it to build tools to build one of programs pretty works pretty great for that uh probably the best in class for many such scenarios but for software system you know again i understand that people are building large and uh interesting things with that uh but personally you know for me that would not be the choice i feel that uh beam languages are a better uh better option now when it comes to dark this is a very interesting story so i really like dark i mean what i've seen you know so i didn't really get to try it but i just saw a couple of presentations uh i think the dark really has a very important story and this is the story that uh dark starts with the premise that backhand development is very complex because you have to use a huge amount of different tooling and somehow glue it all together this is like the modern state of art you start with kubernetes and then run a bunch of different components and you split your system into a bunch of different micro services and whatnot and the the amount of technical complexity we introduce here uh is crazy this is like definitely server side back inside programming is way too complex these days um and so dark aims to solve this by being uh like a single tool you know you learn this one tool and you can do everything with dark so you know it reduces a huge amount of this technical complexity and i really like this story now what's interesting is that you can sort of get a similar story on top of beam languages uh precisely because beam already at the runtime level gives you a lot of the things that you get otherwise from the operating system uh so like indeed we sometimes say that uh erlang or elixir is like an operating system for our code and when you have operating system services in your code then you don't have to fall back to the operating system level and you can do a lot of stuff from the language and i've had a bunch of these examples in practice where i built a system using exclusively erlang or using exclusively beam with nothing else running on the side supporting it uh so like no nginx for example no external in memory kv because we have like an in-memory key value storage called or long term storage or ets so things like that you know when with other languages i would have to fall back and run a couple of different processes and a couple of different third-party components and glue them and again this is a huge amount of technical complexity uh with erlang and elixir you can frequently you know get away just fine with a single project and a single os process uh running for each machine in the cluster and i believe that uh basically with beam you can get similar uh similar uh sort of properties that dark aims to give you uh however uh beam uh and the entire ecosystem is kind of a ground up story it's more like a toolkit less than a framework so uh with beam and standard libraries overland elixir you get like a relatively low level uh low level uh abstractions and then uh libraries give you some medium level abstractions and uh what we are kind of liking and dark sort of starts from the opposite direction are like super high level abstractions so ideally i mean this is perfectly possible we have good foundations in place and again in my view you can typically implement something like on top of beam and not many other platforms but we are lacking these high level abstractions and i would like to see the ecosystem evolving to the point where like when i say i want to build a small to medium uh distributed web facing system and in 15 minutes you know i bring in a couple of libraries a single project and bam it just works this is perfectly possible and uh i would really like like to see our ecosystem getting there yeah and i think that's that's a very good comment i think the the ecosystem around elixir and the beam is fantastic and i'm sure there are brains as we speak thinking and working on exactly those things take away number three beam languages handle a lot of the complexity for you doing server-side programming you could say they're the operating system for your code so um slightly related topic i was listening to another episode on the go to book club on elm in action and um you know elm being a total different beast of course but what i found interesting there is the the approach taken to to static typing it's very very rigid what are your thoughts on on static typing for for the beam and beam languages so uh in my view uh the lack of static typing is uh the biggest deficiency on uh on beam languages and i mean i know that there are like camps uh dynamic versus static i personally you know done uh both uh for like many many years and uh for the past 15 years i've been mostly using dynamic languages and i'm now pretty much certain to say that i believe that static uh is definitely a better option you know i still love erlang and the leagues here and these are like my first languages regardless of the lack of static typing because they offer something that i cannot find anywhere else but i would love to see static typing story on uh beam languages unfortunately uh mostly it hasn't been available so what we have for erlang and elixir is uh what is called a success typing through the tool called dialyzer which i like to say is far from perfect but it's the best we got uh however uh there are very interesting initiatives uh there is one language called alpaca and another language called clean which look very very promising uh and they basically aim to bring static typing into the beam world like you know proper sound static typing and this is something i'm super excited about i still didn't have the chance to try them out but i would definitely love uh love to see how this story unfolds uh yeah i mean the one challenge you know with beam languages is because you you really have two dimensions in those languages so like there is a functional dimension so erlang is a functional language and elixir is a functional language typically all the languages are functional because somehow the the runtime itself is tuned to that and but then there is a whole other dimension which is concurrent dimension that's what i talked about you know the ability to run and manage a large number of programs within a single uh os process and this is usually lacking from other languages and like these two dimensions are completely serve completely different purposes uh and uh the challenge is uh i'm curious to see how this will be sold in uh like gleam for example is how to get uh uh type safe message passing for example uh so this is going to be very interesting to see how it unfold but in any case i'm certain that uh strong typing can be added to beam languages and i'm very very excited about uh gleam and i'm looking forward to see how it unfolds yeah i fully agree with you i think that's a very interesting story and there's even rumors that you know what's up they're being a big user of the being language called erlang they they are very much into strong typing and they even invented different new versions of languages including strong types so let's see how that plays out and i'm really excited take away number four the lack of static typing is the biggest deficiency on beam languages but it will likely be solved with the emergence of gleam and alpaca goto gives you the chance to learn from the brightest minds in software development join community meetups and highly rated conferences and take deep dives on your favorite topics with master classes so um moving a bit into to alex here um what would you say are the the key benefits from from a business perspective let's say a business user considering elixir what would be the key benefits from that angle so uh right i mean as i said uh elixir like any other bim language for me it should be strongly considered when you want to build a server-side system and i don't want to repeat all that again but definitely you know give it a try at least give it an evaluation uh but of course it begs the question you know why would we choose say elixir or erlang which is the first beam language and uh clearly like the whole runtime has been designed for erlang and i mean there are of course other languages as well so in my personal view and just to be clear you know i'm not the member of the core team or i'm not the creator of the language or anything so i'm just a user i always like to say i'm a happy user overlang and elixir and my personal impression is that uh what elixir brings to the table compared to erlang is a better approachability and maybe a better developer productivity story so i have been using erlang in production for a couple of years before you know elixir even existed and then uh through the middle of the past decade i was using both languages side by side and uh finally a couple of years ago i moved completely to elixir and i like to think that i had like a good uh good you know practice with both languages and so i could have seen like pros and cons and the thing is you know in my view erlang is a very simple language you know people get confused people uh think that elixir is simpler but that's not true erlang is a simpler language it just looks strange to most people because it has this prologue like uh syntax right but like very very simple language and that's that's really cool um very simple syntax and very regular syntax no no ambiguities at all uh but you know that's the problem with simplicity as well because uh the simpler the language also the less expressive it is so what i found in erlang is that i had to write a lot of repeating a boilerplate and what you could call a noise you know i know some people will say that it's like more explicit then but my personal sentiment is that it's more noisy and so elixir i would say which looks maybe more approachable for the syntax which is the least interesting part but you know it has like this ruby like syntax which people many people are used to but what really in my view is alexia versus erlang is it's a more complex more complicated language uh so there's more there are more things to learn but because of that uh you as a programmer can also be more expressive so you can actually reduce and uh put aside some boilerplate and so i i found that like it strikes a better uh balance for me personally but you know i wouldn't dare to say that either one of these two languages is better it's more about you know your own personal preferences of whether you like to you know write a bit more uh and then have that boilerplate but also you know the simpler language or you prefer to have like more complex uh features in the language uh but then uh you know you you also can reduce some noise so it's a matter of personal preferences to me now uh another thing that elixir brought to the table uh back when it was uh when it originally appeared so i believe that jose valim started writing in 2011. if i remember correctly i personally saw it in like early 2013 and at that time my impression my impression was that elixir had a much better tooling support so like uh basically erlang didn't have official tool at the time so you had to use some third-party tool which now has been integrated and which is now actually much better so the story in urlank has approved as well but you know with elixir you just get this thing and you start this mixed new project and you do everything with mix and it was like very easy to build an otp release even back at that time when uh that thing the doing it with erlang was a bit more uh complex and again required some different tools even the community overland didn't have this consensus about which tool you should use so there were five or more different options to do that so this is where i find you know historically elixir uh working better i believe that you know i don't really follow overland so much anymore but my impression is that erlang has improved as well in those areas and i kind of like the thing that you know having these multiple choices that these communities uh essentially move each other forward together so uh we are all like whole beam ecosystem and i mean it's always worth saying that you can use uh like in elixir you can use erlang libraries and we wouldn't even exist if we didn't use those libraries starting from the standard library and the otp framework but then also third-party libraries such as the popular cowboy web server and things like that and also then again uh owing to the work on the links here there have been some pull requests done back to the uh erlang slash otp so essentially these two languages you know kind of work together and not just these two languages but all of them languages as they should so ultimately to me you know the uh the question of say erlang versus elixir is all more about like do you prefer a simpler language with a bit more typing or do you want a more expressive language but also more complex language and again i think that uh my impression is that elixir has like a slightly better story in tooling in documentation maybe support for uh tests and so on yeah i think you're absolutely right there and that that was a bit of a weakness in the community and i think that the whole elixir team with jose and the others have have you know moved the community forwards as a whole and now the whole beam community can can benefit from it so i think that's just awesome work done there take away number five alexia is focused on being approachable and making developers productive speaking a bit about your book i i think it's really cool and i love your your t-shirt so um what kind of person did you have in mind when when writing it um yeah that's that's a very good question uh thank you for giving a chance to clarify that uh so elixir in action is i personally advertise it as it's an introductional introductory book to alex here uh but not for non-programmers so it's not introduction to programming i actually expect expect a programmer who is has some experience in other languages not related to beam at all uh you know such as ruby c sharp java javascript whatever you know python and so on um preferably on the server side of things you know for at least i would say a year or two so uh the reader should be familiar with what it feels like to write a web server a web facing system the way i like to call it um other than that of course they don't have to know anything about uh about beam or orlando or elixir at all yeah take away number six the readers should be familiar with what's happening inside a web server nowadays there there are quite a few books on on elixir out there on the market so what would you say is is unique with with alex here in action uh yeah i actually you know up until a few years ago i read all of books written on alex here uh these days you know that there are like already so many that i know i find hard to catch up uh my personal impression is uh obviously no one partial to my book but that my personal impression is that all of these books are great books and that mostly they complement each other so in particular uh for elixir in action uh i wrote it with the focus again remember i said there are like two dimensions of elixir so functional and concurrent my focus was on the concurrent aspect of elixir because this is where i find uh that any beam language really shines the most this is what's uh what they bring significance to the table compared to anything else available out there i'm not saying that functional is somehow boring or anything but this is the the stuff that i kind of treat it more as a nuisance uh so that's uh one thing about elixir reaction you know it starts very uneventfully very like the first part of the book uh those are the first of four chapters uh they basically deal with functional programming and the type system and it's more like you have this and you have that and you have that so you kind of have to survive through this first third but then the the second and the third third uh so the second part and the third part they are uh focused on concurrency how to think concurrently in beam and uh how to use it properly and how to use the higher level abstraction from the beam standpoint or from the those languages like otp uh how to use those things properly and what i really like about those chapters is that they they're sort of modeled through my own experience you know like when i was working with erlang for i started using girling in 2010 and back then there wasn't even the famous book learning summer lang and there were a couple of books i learned from joe's book for example but it wasn't completely clear to me how should i do things you know so i made many mistakes and in a sense this is replicated in a book uh so it doesn't you know just guide you in a straight line from point a to point b but it does more of like a zigzag you know i do some things wrong deliberately so like you start in a with one chapter and you're gonna start with something learn some new techniques and build some implementation and you're gonna feel good about yourself and then in the beginning of the next chapter i'm gonna explain why this implementation is wrong you know and then we're going to learn something new and then we're going to improve it and then in the next chapter you're going to learn that this is wrong too uh so but i never let you fall very far you know go straight very far but i believe that in this sense you know my goal was to not explain not only uh how you should do something but also why you should do something because this is what i found at the time liking uh in beam literature you know people will tell you like you should do it like this and no explanation at all why and so uh i made some mistakes which i've seen on i mean on forums and other exchange sites that people also tend to make when when they don't know this and this is where i personally find uh the book uh like for me at least you know uh most helpful and in essence i wrote this book uh the way i would want to have it you know if i if i didn't write it in so something that i was found find missing myself now i really love that approach i mean it's fantastic way of teaching because that's the way you learn in reality right it's it's never this straight path it's always you know one step forward a half step back and two step forward and so on and so forth so so having that approach when writing a book is is really awesome takeaway number seven the book focuses on teaching not only how but also why you should do something in concur in the lecture thinking about you know being being a writer myself um i'm curious to what kind of feedback you you got on the book and what what kind of feedback was most surprising to you because i mean you said that you wrote it like you would have liked it right so what kind of feedback and surprising feedback did you receive uh so far yeah well i mean the book so this is now the second edition uh if i remember correctly the first edition was released in 2015 so it's been like now uh five years or so yeah i got to say that i was surprised first and foremost i was surprised that they got any feedback uh so uh you know it was the first and the only book i ever wrote and i wasn't really famous or anything before that so there were more famous authors writing on elixir and i really you know didn't expect that anyone would even read the book except for myself and my uh family but yeah it was actually turned out like a pretty pretty nice surprise that people actually read it and i got a very good feedback and it feels like the book has grown sort of organically you know so i see people recommending it and sometimes i get unsolicited feedback and it's just someone you know contacts me on whatever channel and say you know hey i read your book and it's uh it's a really good book thank you for writing it and this for me is is like the best reward that you can get from a book you know when you're not fishing for a review or anything you know someone approaches you and just said you know i read your book and it's uh i really enjoyed it it really helped me subscribe to the go to youtube channel now for ad-free videos released almost daily and join the experts in person or online at any upcoming go to conference using the promo code book club visit gotopia.tech to learn [Music] more [Music] [Music] you

Channel: GOTO Conferences

Views: 156,231

Rating: 4.0778327 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, Software Engineering, GOTObookclub, GOTO Book Club, Sasa Juric, Erik Schön, Elixir, BEAM, BEAM Languages, GoLang, DarkLang, Functional Programming, Programming Languages

Id: -bCkha6U70o

Length: 37min 24sec (2244 seconds)

Published: Thu Sep 24 2020