Speaker 1: Hello everybody, and welcome to another episode of Elixir Mix,
Speaker 1: again this week without Charles so I'm such a wolf.
Speaker 1: And this week on the panel we have Adie Ainger
Speaker 1: and Alan Weymore. Hello, I hope I pronounced about the
Speaker 1: name's bob right. This week we actually gonna pick a
Speaker 1: topic from Twitter. Like, so a while ago, I asked
Speaker 1: on Twitter what's something people would be interested in and
Speaker 1: to hear about in Alix Mix, and Kevin Stingen basically
Speaker 1: asked us to talk about Elixir is a general purpose
Speaker 1: language for aka, how to convince people that alix heir
Speaker 1: is not this niche thing you only reach for when
Speaker 1: you have like these super specific concurrency issues, but that
Speaker 1: it's actually something you can use it the same way
Speaker 1: like for people reach for rails for example, and then
Speaker 1: you can go from there. And just before we started recording,
Speaker 1: we considered talking about this, and then we also thought, okay,
Speaker 1: let's look at like Phoenix for example, because Phoenix is
Speaker 1: something you can get productive with quite easily, and I'd
Speaker 1: like to hear like your thoughts on that. Adia, Like
Speaker 1: when you started with Felix, You're like, how was the
Speaker 1: story there? If you like jump into Phoenix for example,
Speaker 1: right away, And how did it feel for you?
Speaker 2: Yeah, yeah, Alexa For me, actually it's my first professional
Speaker 2: like coding job was an Elixir luckily. And yeah, I
Speaker 2: think that like kind of statement should be enough in
Speaker 2: terms of how general purpose, how easily accessible it is.
Speaker 2: I didn't hadn't really have to touch the OTP, the
Speaker 2: gen server pod or any any kind of a TV
Speaker 2: stuff for like a while. I did start with plugs
Speaker 2: at that time. Phoenix was like still I think I
Speaker 2: don't know if one point it was out at that time,
Speaker 2: but my first Elixir app was like just a plug
Speaker 2: based back end API and again just how plug looks
Speaker 2: pretty straightforward to right use. And they right away had
Speaker 2: support for Cowboy as well, so was again pretty easy
Speaker 2: to follow along with the documentation and just get us.
Speaker 2: We're up and running within a couple hours. So yeah,
Speaker 2: I had a very pleasant experience for the Elixir.
Speaker 1: And so you said that you didn't have a lot
Speaker 1: of things to do with OTP at that point in time, Like,
Speaker 1: was that like anything specific in that first app you
Speaker 1: learned Elixir with, like where you then at some point
Speaker 1: reached for OTP, And is it like a story there
Speaker 1: to be told or rather than.
Speaker 2: There is definitely a story there. The app was actually
Speaker 2: replacing a small functionality of a huge rails app, and
Speaker 2: that small functionality was something that the CTO of my
Speaker 2: company at that time envisioned to you know, kind of
Speaker 2: be more scalable, and it was an experiment for us
Speaker 2: to try writing that in Elixir, and initially we didn't
Speaker 2: do any OTP, but the first thing that we did
Speaker 2: was just adding tasks to that, and then this experiment
Speaker 2: pool boy and everything. But it matured to a point
Speaker 2: where we had investigated infrastructure. We had it in a
Speaker 2: place where you know, we didn't. They not only had
Speaker 2: a great amount of concurrency with different workers doing different things,
Speaker 2: but we had we also were spinning in temporary infrastructure
Speaker 2: like a super server in Google Cloud where I think
Speaker 2: I think it was like what one hundred and twenty
Speaker 2: eight gigs of RAM temporarily to process a huge again
Speaker 2: without giving a lot of business information, a huge chunk
Speaker 2: of data. And yeah, it became a pretty crazy app
Speaker 2: by twenty nineteen. But yeah, the first iteration of that
Speaker 2: untwenty fifteen was just a simple plug resserver lo concurrency nothing, well,
Speaker 2: each request was concurrent, but yeah, besides that there was
Speaker 2: no OTP whatsoever.
Speaker 1: Yeah, that's pretty similar to to my personal experience. Like
Speaker 1: I mean I didn't start from plug, but I jumped
Speaker 1: right into Phoenix when I when I first used flixir
Speaker 1: at my previous employer, where also like a first contact
Speaker 1: with Filixir, right, and there were also like beginning just
Speaker 1: had like this Phoenix app and if you have any
Speaker 1: point written some kind of back end code like be
Speaker 1: create rails, be it like PHP larravel. A lot of
Speaker 1: things feel very familiar. So you you all this OTP
Speaker 1: stuff at that point feel it's a lot like magic,
Speaker 1: and but you don't have to use it, like to
Speaker 1: just write an endpoint and to just get i don't know,
Speaker 1: like a response back to the user. So I feel
Speaker 1: like there's a lot of a lot to be said
Speaker 1: about the ease of onboarding there and like not having
Speaker 1: to to jump the gun on all the maybe more
Speaker 1: uncommon and maybe more weird outip things the Beam offers,
Speaker 1: which is super powerful but can be quite confusing for newcomers. Right, definitely,
Speaker 1: Like Alan, do you do you have like any any
Speaker 1: story you'd like to share about how your first contact
Speaker 1: possophilis here? And like what you did with it.
Speaker 3: That's a good question. I'm trying to think of what
Speaker 3: my first interaction was. I think I may share the
Speaker 3: same interactions most people were. You kind of keen and
Speaker 3: from the Phoenix side in that, like you didn't get
Speaker 3: too much exposure to OTP when you're using Phoenix, because
Speaker 3: a lot of stuff is kind of abstracted from you.
Speaker 3: Like even I'm thinking about like when I'm first looking
Speaker 3: at the application ex file that gets created and it's
Speaker 3: not super clear like what's going on. You just have
Speaker 3: a bunch of stuff we see that gets started up,
Speaker 3: but you don't really understand exactly what's going on. You
Speaker 3: don't really see like the endpoint all these kind of
Speaker 3: things and coming from rails, like I think most people
Speaker 3: did that. I didn't really think too much about a
Speaker 3: lot of things. I just kind of try to keep things, yeah,
Speaker 3: just just in line. I mean when I started speaking,
Speaker 3: that was way back we had like the web folder
Speaker 3: that was outside of the lib folder. If you remember that,
Speaker 3: that was a long time ago, that was I think, yeah, yeah,
Speaker 3: so I think I came in about one point two
Speaker 3: or something, and yeah, so it was a it was
Speaker 3: a different time back then.
Speaker 1: Also, you had like, what was it?
Speaker 3: It was weird, like you didn't have a schema, right,
Speaker 3: you had something else like a model models.
Speaker 2: Yeah, it was actually models. It wasn't controls and templates.
Speaker 1: I guess.
Speaker 2: Yeah. So, and I remember like a lot of one
Speaker 2: of the things that a lot of people in the
Speaker 2: Alica community who did not come from RAILS community didn't like,
Speaker 2: was said, why are we calling the schema's models? So
Speaker 2: then we then I saw Phoenix moving away from that.
Speaker 2: I think one point three that that's what introduced the
Speaker 2: bounded contexts, right, the context modules that don't know well.
Speaker 3: I mean the part is that actually made it more
Speaker 3: approachable for me at least because I did understand NBC
Speaker 3: and they were really pushing MBC at that time, I think,
Speaker 3: like with the different folders, so that that was much
Speaker 3: easier for me. And so I didn't really get too
Speaker 3: into OTP for some time. I had to spend time
Speaker 3: outside and just kind of look into it. I kept
Speaker 3: hearing about TP, and then I just had to go
Speaker 3: through like Sasha Sasha's book, a Little OTP book. These
Speaker 3: two books for sure were definitely my early intros to it,
Speaker 3: and then I could started to seeing it there's definitely
Speaker 3: some powers over here. Also, Dave Dave's book from prag
Speaker 3: Prog was also really good too, Like the fact that
Speaker 3: I could spin off a bunch of like asynchronous processes.
Speaker 3: Thought that was super powerful, like these things, so like
Speaker 3: it took some time for me to really get into,
Speaker 3: you know, what I wanted to do. And after spending
Speaker 3: quite a bit of time like getting into it, then
Speaker 3: I started actually adding it to projects for things like
Speaker 3: I had to process webbooks and you had to return
Speaker 3: a sponsor this response with a certain amount of time.
Speaker 3: So initially that was actually synchronous, and they started taking
Speaker 3: longer and longer, and then finally we said, okay, let's
Speaker 3: try to spin off this as a process and let's
Speaker 3: just return immediately. And that definitely was amazing. It was crazy,
Speaker 3: like because we went from like a couple of seconds
Speaker 3: to like now like was it like seventy two? Like
Speaker 3: that U symbol was that microseconds?
Speaker 1: So that was microseconds?
Speaker 3: Yeah, yeah, that was super powerful. And then like we
Speaker 3: had this third party, so we got a WebBook. Then
Speaker 3: we had to ask them, like what happened? So we're
Speaker 3: working with Strava. Strava would send us a webook saying, hey,
Speaker 3: this user has an activity, and then we would reply back, hey,
Speaker 3: tell me more about the activity, and Strava would actually
Speaker 3: fall apart. It would just like die whenever we asked them.
Speaker 3: And so that actually brought us into another stage of
Speaker 3: OTP where if it failed, let it, we let it crash,
Speaker 3: then we just retry it. And we actually built in
Speaker 3: like a retrit mechanism too. So it was also super
Speaker 3: helpful because they were experiencing a lot of growth issues
Speaker 3: at the time, so it's really a gradual process to
Speaker 3: me that just like adding this layer, adding that layer,
Speaker 3: So it wasn't very overwhelming, but at the same time,
Speaker 3: like because of the approachability of Phoenix, especially at that
Speaker 3: time to where I was come from, it was really straightforward,
Speaker 3: I think for the most part.
Speaker 1: Yeah, I think that's a very common story. Right. You
Speaker 1: start off with like air quote, just the web app,
Speaker 1: and then you at some point say, okay, I would
Speaker 1: like some background processing, like this thing over here it
Speaker 1: takes too long. Let's let's move into the background. And
Speaker 1: then like if you would be using raids, but you
Speaker 1: would reach for something like sidekick, but then alix here.
Speaker 1: Then then then OTP and like obstructions built on top
Speaker 1: of that just in reach right, and you can then
Speaker 1: then go very naturally transition into okay, how exactly is
Speaker 1: this supposed to work? And what can I use here?
Speaker 1: And what guarantees does this give me and explore basically
Speaker 1: what what OTP provides you very very gently from from there.
Speaker 3: I think the the funny thing now is like, okay,
Speaker 3: you would reach for sidekick. There was a sidekick implementation
Speaker 3: in a lixture and then people said, okay, you don't
Speaker 3: need that. But now it's funny like we're almost reaching
Speaker 3: for another sidekick nowadays, Like the open library not to
Speaker 3: knock an open orban is fantastic, right, but it's funny
Speaker 3: that actually now we're back to doing something similar, although
Speaker 3: now you don't have to actually add in another dependency.
Speaker 3: You don't have to add in like reddis. You just
Speaker 3: work off the same database. That's the nice part. But
Speaker 3: as it's taken like, it's kind of funny, like we're
Speaker 3: necessarily almost full circle, right, It's like, okay, you don't
Speaker 3: need sidekick, or so you don't need reddis. Okay, you
Speaker 3: don't need like a background managing tool for background processes.
Speaker 3: You could just split up a process, use a supervisor,
Speaker 3: and now it's like, okay, now let's just farm it
Speaker 3: out to open.
Speaker 1: So it's kind of like full circle again. Yeah, I
Speaker 1: think you can a bit of a bit of observe
Speaker 1: like the development in the community there, because I mean,
Speaker 1: Open is great if you have persistent jobs right degreat
Speaker 1: but which should survive a restart of your app. But
Speaker 1: sometimes that's not something you need. And the beginning, I
Speaker 1: think a lot of people were like, oh, otp and
Speaker 1: but that's cool, like what can we do with it?
Speaker 1: And I mean the other folks will probably say like
Speaker 1: it's an old app, but for the Elixi community it
Speaker 1: was like, hey, maybe we don't need all that other
Speaker 1: stuff we we used in our programming language. Let's try
Speaker 1: to do it all like in the VM itself. But
Speaker 1: now that a bit of time has passed, I guess
Speaker 1: it makes sense that that you have now a solution
Speaker 1: like Open, which has okay, like sometimes you really want
Speaker 1: this persistent qube sometimes you really want these persistent jobs.
Speaker 1: And while you might why, there might be solutions to
Speaker 1: doing that in the side of a VM, it's just
Speaker 1: quotes simpler to use a database. You're probably already using
Speaker 1: I guess it tells a story about like the Elixi
Speaker 1: community maturing and trying to do a bit of the
Speaker 1: simplest thing.
Speaker 2: Yeah, totally, yeah, I do. I really like the fact
Speaker 2: that oban has become like the standard these days. Whenever
Speaker 2: I have tried use OTP within the application, I am
Speaker 2: in distorber state of jobs. It has always it's been
Speaker 2: hard to manage that, especially with like crashes and stuff.
Speaker 2: It's a lot easier to think of your data as
Speaker 2: separate from your app. But I'm not saying it's not possible,
Speaker 2: and airline is built for that, but it's just easier
Speaker 2: to manage things, you know, and like it won't conflict
Speaker 2: with your infrastructure and how you deploy and all that stuff.
Speaker 1: Right. Yeah, it reminds me. I think it's like in
Speaker 1: the book of such a Urk there's like this this
Speaker 1: table about like what what you need for example, to
Speaker 1: one like a web server and like persistence and so
Speaker 1: on and so forth, like in like a language like
Speaker 1: Ruby or Python or whatever, and it's like, okay, you
Speaker 1: have to be ins like web server will be for example,
Speaker 1: and the will we land will be like how is
Speaker 1: it called kuma?
Speaker 2: Right?
Speaker 1: And then you have rails for the web app, and
Speaker 1: then you have read is for like the QUE, and
Speaker 1: you have postcors for persistence, and then you have engine
Speaker 1: X for like web routing and so and so, and
Speaker 1: then there's like this table on the other side. Like,
Speaker 1: while it's a bit tang in j there is some
Speaker 1: truth to that that I think it's interesting to see,
Speaker 1: like how the community pushes in that direction. And so
Speaker 1: it makes sense that in the beginning you had a
Speaker 1: bunch of job ques which we did all inside of
Speaker 1: the VM because like, hey, this is like a direction
Speaker 1: the community tends to push because it reduces complexity. Less
Speaker 1: dependencies means less complexity. But yeah, like I said before,
Speaker 1: sometimes you really want these persistent jobs, and then it's
Speaker 1: good to have an optimism in a project like Oburn,
Speaker 1: which I think has been a godsend for a lot
Speaker 1: of people.
Speaker 2: For sure. Yeah, I agree, I have Remember, I feel
Speaker 2: like I don't know if the susproduction or not. I
Speaker 2: do remember using debts for a more persistent QUE. We
Speaker 2: were already using the online term storage, and that the
Speaker 2: disc based online term storage was something I remember exploring.
Speaker 2: I'm not sure if it was in production for too long.
Speaker 2: At all because we moved to Oban very quickly after that,
Speaker 2: but which just made our life a lot simpler.
Speaker 1: So was that's something like you you home brewed in
Speaker 1: your company, Like.
Speaker 2: Yeah, yeah, we already had a job processing thing that
Speaker 2: was already half baked. We were using a gens will
Speaker 2: attract that, and then we realized, oh we and as
Speaker 2: what became more complicated, we needed like more like table
Speaker 2: like infrastructure, right, and then we switched TOTS and then
Speaker 2: we realized, oh, we need this to prosist beyond the
Speaker 2: application crashes and whatnot. So then we moved to debts
Speaker 2: and then I'm like, wait, there's a new thing, call
Speaker 2: oh man. And I want to say that we did
Speaker 2: have debts for some time in production, but very little's
Speaker 2: probably like a month or so. But it wasn't much
Speaker 2: of an effort to move from already implemented you know
Speaker 2: ETS two.
Speaker 1: Yes, like for our listeners to get like ets like
Speaker 1: this recording term storage. We mentioned it in a few
Speaker 1: past episodes, but it's basically like an in memory key
Speaker 1: value table, and debts is basically left the same thing,
Speaker 1: but that saves the contents on a file on disc.
Speaker 1: So then you actually can have resistance across restarts of app.
Speaker 1: Just in case somebody is not familiar with it. We
Speaker 1: can like blink to the dogs, I guess in the show.
Speaker 2: Great. The best part about it is that you get
Speaker 2: to use this amazing query look up language. I'm not
Speaker 2: sure if you've tried, yes, I.
Speaker 1: Have, amazing wouldn't have been the adjective I'm using there.
Speaker 2: I was definitely I was definitely been sarcastic.
Speaker 1: Yeah, I mean there are some some helpers there, right,
Speaker 1: like this fun too an ass which is like fun
Speaker 1: to matches back, so they basically pass it like a function.
Speaker 1: And then it's like somehow automatically powerises these these guards
Speaker 1: or these pattern matches to specify. Like that's a lot
Speaker 1: better already. But the match specs interesting. Let's just say
Speaker 1: that I have written some I've written some simple match
Speaker 1: specs are okay, but that's as soon as it gets
Speaker 1: like even remotely complex. It's even worse than regular expressions.
Speaker 2: Agree percent.
Speaker 1: But yeah, it just just to reiterate, I feel like
Speaker 1: there is a very natural transition to say, okay, I
Speaker 1: want to start like my web project, right, and I
Speaker 1: just use Phoenix and then I write some controllers and
Speaker 1: then I write some code here and sometimes maybe some
Speaker 1: active I have a database and I don't have to
Speaker 1: care about ODP. But as soon as you like want
Speaker 1: to step out of that that I'm not sure, like
Speaker 1: that the safe zone like this the sandbox, then then
Speaker 1: OTP is there, like it allows you to like reach
Speaker 1: for things beyond this air quotes simple and easy Phoenix stuff.
Speaker 1: And I must say, like my personally, my experience has
Speaker 1: been very very positive there, because I mean I remember
Speaker 1: trying to step out of like this safe zone in
Speaker 1: other languages, like be they back end or even like
Speaker 1: front end code, and then I feel like the experience
Speaker 1: is often that that you bump into like weird walls
Speaker 1: and weird edges like you didn't expect to bump into
Speaker 1: because like then suddenly tried to do things outside of
Speaker 1: the scope of the framework, right, and then things become
Speaker 1: very very hard all of a sudden without especially like
Speaker 1: when you try to like do this for the first
Speaker 1: time and they don't really understand why things don't work
Speaker 1: as you might expect them to. I very much remember,
Speaker 1: like my very first web app was actually PHP thing
Speaker 1: with like Laravel, and then we wanted to send like
Speaker 1: a push notification and to a bunch of users, and
Speaker 1: like I was like looking at this, and I was
Speaker 1: like thinking, okay, I'd like to do that in the background,
Speaker 1: right because it might go through like thousands and thousands
Speaker 1: of devices. And suddenly I was like, looking, Okay, then
Speaker 1: you have like they have to start this demon which
Speaker 1: like handles your bag PHP background process, And I was like,
Speaker 1: what the fuck? Why is this so hard? And yeah,
Speaker 1: I feel like at least in that in that context,
Speaker 1: Elixir gives a very more and more streamlined and a
Speaker 1: more simple solution to do these these common issues without
Speaker 1: you having to like really grog or all the things.
Speaker 1: And one interesting thing I know for myself there was
Speaker 1: as soon as like I got like a basic understanding
Speaker 1: of OTP, I could also very much appreciate about, Okay,
Speaker 1: how it does phoenix actually work? Right, Like how you
Speaker 1: have one process per request? Yeah, and like I feel
Speaker 1: like all the pieces like snack together. So that's pretty
Speaker 1: pretty interesting and like something I have not yet experienced
Speaker 1: in the same fission in a different technology stack, but
Speaker 1: maybe like my MIC, maybe something like that will pop
Speaker 1: up at some time.
Speaker 2: Yeah, totally, totally, Yeah, it's actually cowboy if I want
Speaker 2: to say, I think Cowboy itself.
Speaker 1: Every public quest is a probably.
Speaker 2: Its own process, which is I think Veena's just like
Speaker 2: piggybacks off of that, which is yeah, pretty awesome. Yeah,
Speaker 2: I mean, yeah, totally right about again the point you
Speaker 2: made about before diving into it to be And I
Speaker 2: mean there's also Alixir as a community has so many
Speaker 2: cool I mean we're not even gonna we haven't even
Speaker 2: touched nerves yet. But like something as simple as like
Speaker 2: the embedded elixa engine, right that is so powerful, like
Speaker 2: it can just power you anything you want to template.
Speaker 2: Like here's an example. Right before I did any little
Speaker 2: any I met it a very little OTP, but like
Speaker 2: before I dealt into OTP, I wrote this DevOps like app.
Speaker 2: It basically sets up a Linix ra Mac with like
Speaker 2: all the tools I want, you know, I used to
Speaker 2: him the terminal I want, zoom and whatever. It just
Speaker 2: and using Alix for stuff like that. It's little looks weird,
Speaker 2: but it was so easy to do that because of
Speaker 2: embedded Alixir. Writing shared templates is so easy to do
Speaker 2: and it looks with such an accessible language. You have
Speaker 2: to figure out how to install it first, But once
Speaker 2: you install Alexa. Once you got it running in a
Speaker 2: nice script, it's very powerful because it's interfaces like so idiomatic, right,
Speaker 2: Like it's it's so easy to use, like most of
Speaker 2: the libraries and the language.
Speaker 1: Itself, the tooling and the tooling is just superb.
Speaker 2: Right.
Speaker 1: I feel like the onboarding experience and Elix here, like
Speaker 1: even like just going through the guides on the Elixir
Speaker 1: website drops you off at a point where, at least
Speaker 1: for me I might personally where you feel relatively comfortable,
Speaker 1: like tackling your first Elixir like not not really like
Speaker 1: diving into like like I like writing like website from scratch, right,
Speaker 1: but like really okay, I feel like I know enough
Speaker 1: to be productive to actually build something, And that I
Speaker 1: think that tells a story where about where ALIXI comes from, right,
Speaker 1: I mean just look at where what Jose did before Elixir,
Speaker 1: Like he was very very active in the Ruby community,
Speaker 1: and Ruby has this mantra and like this reputation and
Speaker 1: we're very well earned reputation about being approachable and about
Speaker 1: being easy to pick up and like focusing on developer happiness.
Speaker 1: And you really see this in elix heir that they
Speaker 1: did a lot of these the same ideas have evolved
Speaker 1: to a certain degree, but also went into the design
Speaker 1: of this language and the design of the tooling and
Speaker 1: the design of your onboarding experience and while still learning
Speaker 1: for maybe is like some of of things which haven't
Speaker 1: worked out that nicely in the Ruby community, because I
Speaker 1: mean a lot of people who do Elixir come from Ruby.
Speaker 1: That's just a very natural transition, and at least in Ruby,
Speaker 1: sometimes you have a situation where if you have a
Speaker 1: very big money which evolved over time, then you have
Speaker 1: obvious like different parts which like magically touched each other,
Speaker 1: and then it becomes very hard to reason about things.
Speaker 1: And that's like something I think you can see in Elixir,
Speaker 1: where like Jose, but very very very deliberate design decisions
Speaker 1: to avoid some of these pitfalls.
Speaker 2: So yeah, totally. I think one of the things that
Speaker 2: I guess I'm again being in a more and more
Speaker 2: of a unique place where I actually did Elixir before
Speaker 2: Ruby on Rails delivered my production app and Elixir before
Speaker 2: I did Ruby on Rails stuff. I didn't even Phoenix
Speaker 2: before Rails.
Speaker 1: The same there, I also have hadn't done Ruby before awesome.
Speaker 1: I cannot tell us like you don't know shit.
Speaker 2: But what I what I really felt is, I mean, yes,
Speaker 2: Elixir and Phoenix did feel like magic still to some extent,
Speaker 2: but a lot less magic than Ruby on rails, like
Speaker 2: you have that endpoint dot ex, you still have the
Speaker 2: application dot ex, you still have the user channel dot ex.
Speaker 2: Even though you don't need to use that code, no
Speaker 2: one touches it ever, you can. You still have this
Speaker 2: more explicitness in the interface. Also, I think by design
Speaker 2: and Elixir too, like there you can do a lot
Speaker 2: of The meta program is very powerful, but it restricts
Speaker 2: you from doing things that you shouldn't do, for example,
Speaker 2: opening up a class and defining functions that are not
Speaker 2: defined in it right like rail stands and all the time.
Speaker 2: And the only the craziest thing you can do is
Speaker 2: like use the on definition hook the compile time hook
Speaker 2: and you know, do something there. But even with that,
Speaker 2: it restricts you from defining or creating a new function.
Speaker 1: Yeah, well, I just wanted to say, like on definition
Speaker 1: callback is actually very interesting because like it's deliberately like
Speaker 1: when you write it, it's deliberately a function you have
Speaker 1: to write. You can't write a macro there, so you
Speaker 1: can't inject code there you can only like I don't know,
Speaker 1: like track something like. That's a very very deliberate design
Speaker 1: decision because I think all the other complex compilation callbacks
Speaker 1: are all macros only the un definition is a function
Speaker 1: and probably just to avoid this exactly this kind of
Speaker 1: magic behavior which would otherwise be very hard to wrap
Speaker 1: your head around.
Speaker 2: Totally. Yeah, I think the before compiling after compel can
Speaker 2: be both both macros and functions, but you're right on definition,
Speaker 2: it can only be a function.
Speaker 1: So that's like a very interesting dedesign tidbit.
Speaker 2: Definitely.
Speaker 1: I feel like it's probably also something like you can
Speaker 1: see that somebody has made this decision probably because they
Speaker 1: have been burned by something working differently before.
Speaker 2: Right right, exactly, I think the whole if you look
Speaker 2: at the Elixir proposals groups, school groups, you can see
Speaker 2: how protective people are of like bad patterns in the community.
Speaker 2: Like a lot of times, if you suggest something that
Speaker 2: could be potentially off, you don't have to wait to
Speaker 2: see Jose's opinion, like so many others just bounds off
Speaker 2: and like oh what about this? What about that? And
Speaker 2: it's just it's a very very positive involved community that's
Speaker 2: you know, Jose has managed to create your Jose and
Speaker 2: everyone else like where there's so many people who are
Speaker 2: just like inherently care about the language enough to actively
Speaker 2: monitor Google groups even without being in the Lexa core team,
Speaker 2: which is quite amazing.
Speaker 1: Yeah, I agree with one. Yeah, I think it's it's
Speaker 1: like an interesting balance which has been which Alixi has
Speaker 1: been striking, like where you can get productive relatively quickly.
Speaker 1: I've seen that happen. I've seen that happen with colleagues
Speaker 1: picking up alixit very first time, and like a lot
Speaker 1: of people are like, oh, it's a functional language. I'm
Speaker 1: not sure how productive I will be. But if you
Speaker 1: drop them into like a Phoenix project and then tell them, hey,
Speaker 1: go through the who were getting started guys of elix here,
Speaker 1: and then just look at the code and you figure
Speaker 1: things out. My experience has been that people become a
Speaker 1: lot quicker productive than they might have expect expected initially
Speaker 1: just by this being a functional language. And yeah, I
Speaker 1: mean then we said that that you have this natural
Speaker 1: transition about Okay, now I want to reach for something more.
Speaker 1: I want to do background processing, and and they're the
Speaker 1: indexit community is also very helpful, like if you just
Speaker 1: ask a question, the Alixi firm people will will very
Speaker 1: quickly give you an answer and help you figure things out.
Speaker 1: So yes, it's an interesting, interesting balance which I think
Speaker 1: may the core team and the community is striking between okay,
Speaker 1: easy to onboard, but still powerful if you want it
Speaker 1: to be. One thing I wanted to say, like earlier
Speaker 1: when we talked about Phoenix, is I agree that like
Speaker 1: Phoenix can feel a lot quite some quite magic when
Speaker 1: you when you begin with it. But what I found
Speaker 1: is when you then started to pull back the curtain
Speaker 1: right the next okay, well what's actually happening beneath all
Speaker 1: that magic? It's not a lot to be honest. I mean,
Speaker 1: you have like the plug pipeline, then you have to
Speaker 1: grop okay, what's actually a plug? And like how does
Speaker 1: that work? And like how how do these like plug
Speaker 1: macro and so and so forth work? But at the
Speaker 1: end of the day, it boils down to being a
Speaker 1: list of like modules plugs and then being invoked one
Speaker 1: after the other. And even like you're router and like
Speaker 1: your controller are plugs underneath, right, So if you look
Speaker 1: at it and like find out, okay, well how does
Speaker 1: this actually work? There is not that much magic to
Speaker 1: untangle to find out, hey, okay, this is this is
Speaker 1: what happens, which I found very very surprising when when
Speaker 1: I first did that.
Speaker 2: Yeah, totally, yeah, everything is plugs, as a correct way
Speaker 2: of explaining it, like up your riter is a plug
Speaker 2: once as soon as it gets to the router, once
Speaker 2: get to the endpoint, it is a sequence of plugs.
Speaker 2: Even the rendering a view happens in a plug. If
Speaker 2: you actually inspect your connection in after like a request
Speaker 2: test and after the controller test, it will have a
Speaker 2: Phoenix uh plugs attribute on it and it will show
Speaker 2: some underscoring to score Phoenix views something like that, and
Speaker 2: that it's responsibility to render the view. It's actually pretty awesome.
Speaker 2: I'm going to use this as a shameless.
Speaker 1: Plug for my book, which pun intended.
Speaker 2: Yeah, shamous plug.
Speaker 3: You're right.
Speaker 2: Yeah, So if people think Phoenix is magic, like I
Speaker 2: did a while ago, I'm actually currently working on a
Speaker 2: book with packed publications which teaches you how to build
Speaker 2: your own web framework and Alixir. Again. I've already talked
Speaker 2: about it once before on this podcast, but just wanted
Speaker 2: to give that make that again plug again, so I'll
Speaker 2: keep you guys posted how it's coming.
Speaker 1: But yeah, no, maybe you can just drop a link
Speaker 1: into the show notes also if people want to check
Speaker 1: it out.
Speaker 2: Yeah, actually I'm not sure if there's a link. We've
Speaker 2: only worked okay, I'm just trying to I'm just trying
Speaker 2: to create a little bit of for that.
Speaker 1: Let me know if it likes, becomes available and I'll
Speaker 1: certainly take a look at it. Yeah, anything else, like
Speaker 1: we can talk about here, anything else, but like any
Speaker 1: stories left to tell.
Speaker 2: I mean we have essentially touched everything.
Speaker 1: Yeah, I mean maybe one thing left. The one thing
Speaker 1: we can talk about is that I feel like just
Speaker 1: by the nature of like runtime all in the end,
Speaker 1: and like all the good work which has been which
Speaker 1: has went into like ODP and laying and like being
Speaker 1: as performant and like as resilient as it is, and
Speaker 1: you have this relatively straightforward on boarding experience and starting
Speaker 1: to write your app. But then at some point, like
Speaker 1: if you actually, like if you build like a startup
Speaker 1: and your product becomes successful, right Alixir and the runtime
Speaker 1: especially is there to like scale with you, And I
Speaker 1: feel like, while of course you can also scare of
Speaker 1: different technologies. I mean just look at GitHub for example,
Speaker 1: which is still using rails to this day and very
Speaker 1: successfully so, but at least from what I've seen, is
Speaker 1: that elixir can push you a lot further with less
Speaker 1: effort when compared to maybe like some more traditional technologies,
Speaker 1: and like that's that's a very powerful combination, right, I
Speaker 1: can start off relatively easy, of course, not as easily
Speaker 1: as rails, and like the thora of like gems in there,
Speaker 1: so that's certainly not not a position ex years in yet.
Speaker 1: But if you stick to the well worn in the
Speaker 1: well known path, then you can go very far, very quickly.
Speaker 1: And when you come into position where you actually have
Speaker 1: to to scale and they actually have to handle different
Speaker 1: load scenarios than the beam, and all the tools there
Speaker 1: are in your reach, and can I can help to
Speaker 1: achieve these goals without maybe some of the growing pains
Speaker 1: which which usually come in such a scenario.
Speaker 2: That's very well said. Yeah, Elixir with less effort will
Speaker 2: help you get a lot further than something like ribons. Yeah.
Speaker 1: Yes, So this was like a little fun story like
Speaker 1: tangantially related to that, as like a former colleague of
Speaker 1: mine had this like little small elixir app running in
Speaker 1: production for a while for personal project, right, and then
Speaker 1: at some point he just found out that sometimes there
Speaker 1: was some some load spikes which like crashed a few things,
Speaker 1: but like they only found out like months later when
Speaker 1: he looked at the logs because then OTP just restarted everything.
Speaker 1: So that was like a nice little experience for him,
Speaker 1: like seeing, okay, like in a different scenario, will probably
Speaker 1: have to handle you have to jump the gun. They
Speaker 1: have to I don't know, astations to the server and
Speaker 1: like restart things yourself and like maybe set us on
Speaker 1: monitoring and like make sure that things get restarted effet
Speaker 1: crash and like OTP just did that all of that
Speaker 1: for him, and he didn't even notice until he looked
Speaker 1: at the laws. So just to give like a one
Speaker 1: little story where the runtime really delivered on some of
Speaker 1: its promises. And so yeah, if some of our listeners,
Speaker 1: like I have not did used elixir or like feel
Speaker 1: like I don't know, like I don't want to lose elixir.
Speaker 1: Elixir is like an overkill for this ad, just give
Speaker 1: it a try. And there's also like a actually I'm
Speaker 1: going to share that on the in the in the
Speaker 1: show notes, theres like a super interesting article from engineer
Speaker 1: at Spotify where they like wrote an Elixir service like
Speaker 1: as a prototype thing for for some of some internal
Speaker 1: metrics application which like gathered data and gathered metrics from
Speaker 1: a lot of other services inside of their their infrastructure,
Speaker 1: and like he tells this interesting story also about how
Speaker 1: he used some performance tooling by the Beam because he
Speaker 1: found out that the Elixir prototype had like a bottleneck.
Speaker 1: And he found that out very very quickly actually by
Speaker 1: by the tooling given for prove Beam, and then at
Speaker 1: some point he like put that into production and then
Speaker 1: like I don't know, devor redirected like some percentage of
Speaker 1: a traffic to this prototype. Like the thing didn't even
Speaker 1: break as wet, so he just spent like full full
Speaker 1: on crazy mode and just like redirected all traffic to
Speaker 1: this to this prototype, and that part just happily chucked along,
Speaker 1: like it just did it strong and the like the
Speaker 1: former thing they had running there was like a super
Speaker 1: high performance to Java thing, which like really like a
Speaker 1: lot of very smart people spend time on like making
Speaker 1: it as performed as possible, and then just the sky
Speaker 1: comes along it like writes this ELIXI prototype like the
Speaker 1: first time writing Elixir and then fixes with one performance
Speaker 1: bottleneck and boom. That just works. So I feel like
Speaker 1: that tells that tells you a lot about how far
Speaker 1: the run time can push you, even if you don't
Speaker 1: feel comfortable with a lot of the intiquity details of ODP.
Speaker 1: So I'm going to link that in the show notes
Speaker 1: because I feel like that that might help a lot
Speaker 1: of people like maybe jump jump the gun and like
Speaker 1: to try it out.
Speaker 2: Yeah, that's a very very good story, Sasha reading that article. Yeah,
Speaker 2: one thing I do think, just as a negative one thing,
Speaker 2: I mean, I think we've talked about quite a bit,
Speaker 2: just that would really make it look so amazing would
Speaker 2: be obviously the a good type system.
Speaker 1: Oh boy.
Speaker 2: Yeah, and that's also a very good segue to the
Speaker 2: shout out for our next podcast. It's going to be
Speaker 2: I think it's the next one we're gonna have Louis Pilford,
Speaker 2: I think next the next podcast, the creator of Glean.
Speaker 1: Yeah, and he's trying to bring an aesthetic type system
Speaker 1: to the Beam and I'm very very curious to hear
Speaker 1: his thoughts on that.
Speaker 2: Yeah too.
Speaker 1: Okay, I guess we can wrap it up here, or
Speaker 1: is there anything else you'd like to talk about, Addie?
Speaker 1: All right, then, let's go to picks. So, Addie, is
Speaker 1: there anything you'd like to pick for us this week?
Speaker 2: Yeah, I have a very It's a relatively simple blog post,
Speaker 2: but it's very effective. It's written by one of my
Speaker 2: co workers, Hassan is his name, and it's a very
Speaker 2: cool blog post. Ratio is how you can split Phoenix
Speaker 2: router into multiple modules in a more manageable way. It's
Speaker 2: important to I think at least read that because I
Speaker 2: think I know with the rails background, Phoenix rounders can
Speaker 2: tend to get huge and less manageable. So I would
Speaker 2: encourage people to give that a read that The link
Speaker 2: will be in the description.
Speaker 1: Ye. Nice, I don't have any specific picks this week.
Speaker 1: I've been very busy, like the past week with a
Speaker 1: lot of things which have been going only in Germany
Speaker 1: because in my part of Germany, nor from Australia, there
Speaker 1: have been floods last week, like insane floods, like floods
Speaker 1: of a level which has not been seen before. In
Speaker 1: a lot of houses in my neighborhood went underwater and
Speaker 1: which we were so I spent a lot of time
Speaker 1: like helping neighbors, like just throwing away stuff from their
Speaker 1: cellar which work completely underwater, and I just like to
Speaker 1: use this opportunity to say, hey, the climate change is
Speaker 1: something which like affects all of us, and they're a
Speaker 1: lot of good work happening like in various organizations like
Speaker 1: Greenpeace or so on and so forth, and I just
Speaker 1: like as to ask every listener to like maybe have
Speaker 1: a chat with with parents, with folks they like to
Speaker 1: consider client change when the next time they go to
Speaker 1: the voting booth, because like very in September, there's like
Speaker 1: voting happening in Germany as an election, the general election,
Speaker 1: and if we have any listeners from Germany, I'd like
Speaker 1: to like say, okay, just remember that things like this
Speaker 1: flood is it's just going to become more common the
Speaker 1: further we go on the climate chain scale. So I'd
Speaker 1: like to consider this the next time. I'd like to
Speaker 1: like to ask you to consider this next time you
Speaker 1: cast a vote. That's That's all I'd like to say.
Speaker 2: Probably speak okay, Actually I'm sorry about that. I got
Speaker 2: one more pick.
Speaker 1: Yes.
Speaker 2: So keeping on the EU theme, there's a look I
Speaker 2: can't be you happening soon, and I know they're looking
Speaker 2: for volunteers and if anyone watching this want and delves
Speaker 2: the conference. I want to see how it feels like
Speaker 2: you can do it for free if you volunteer. I'm
Speaker 2: gonna paste the link to the volunteering form in the
Speaker 2: description as well. But yeah, I'm giving a talk there.
Speaker 2: By the way, I'm still volunteering. It's I think it's
Speaker 2: a great way to contribute to the community, to help
Speaker 2: organizers all these conferences in any way possible, because they
Speaker 2: work very hard to make sure these conferences go well.
Speaker 1: Yeah. Nice, that's a good pick.
Speaker 2: Nice.
Speaker 1: Okay, So, folks, I hope you enjoyed the episode and
Speaker 1: tune in next time when we come together a flinx