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