November 20, 2024 • 40 mins
AJ Foster is a developer at Pluralsight. He talks about the course he made for Pluralsight about Elixir and then talks about how Elixir was brought into Pluralsight, both into their catalog of courses as well as into the tech stack for the company.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Links
- Elixir: The Big Picture
- Keith Elder - Building A Highly Scalable Service that Survived A Super Bowl | Code BEAM SF 19
- Elixir Diff
- Erlang - heart
- PRINCIPLES OF CHAOS ENGINEERING
- GitHub: AJ Foster ( aj-foster )
- Twitter: AJ Foster ( @Austin_J_Foster )
Picks
- AJ- GitHub | aj-foster/absinthe-socket-transport
- AJ- FIRST
- Allen- Keith Elder - Building A Highly Scalable Service that Survived A Super Bowl | Code BEAM SF 19
- Allen- Zero To Production In Rust
- Eric- Hardcore Zen
- Sascha- Erlang in Anger
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. This week Ellen asked me to do the
angry German introduction, so I'll do that, and everybody, Welcome
to another episode of Elixir Mix. And this week on
our opendent we have Eric Bodikowski.
Speaker 2 (00:18):
Hey, did you be back from holiday?
Speaker 1 (00:20):
Alan Wima? This don't hurt me. My name is Sasha
a Wolf we say it in Germany. And this week
our guest is A J. Foster. Aj. Why don't we
tell us why you're on the show and why everyody
likes you? Hello?
Speaker 3 (00:35):
There, I don't know that everyone likes me, but I'm
on the show today because I'm a software developer at
ploro Site, and I recently authored a plorosite course called
Elixir the Big Picture, trying to bridge the gap between
folks who are evaluating Elixir and why they might want
to choose it for their next business match.
Speaker 1 (00:53):
That sounds nice. How did it actually come to be?
I mean you work at Plorosite, right, so how did
how did you end up making a course for for lexia? Yeah?
Speaker 3 (01:02):
You may or may not know that most authors at
plural site are external folks. There are not employees, but
there are a few employees who are interested in teaching
and education, and they end up authoring content on the
platform as well. Over time, as I got more into Elixer,
I wanted to see Elixer content on the platform, so
I gradually worked my way in and tried to convince
(01:23):
them that that would be a good idea.
Speaker 2 (01:25):
I was actually trying to do the same thing. We
were talking before the show, and we know some people
at plural Site and I was having a discussion with
one of the guys and I said, I think you
guys should put it on there, And I don't know,
there was a big reaction of like no, no, no no,
or that's not mainstream enough, or never heard of it,
or I forgot what the reaction was just a few
years ago. Actually, So I'm glad that it's finally on there.
Speaker 3 (01:46):
Yeah, it's definitely been a journey to get that type
of content on the platform, whether it's Elixer or in
the future, Er Length still working on that because plural
sites customers are very different from what you might get
if you're just creating content freely on the web. These
are corporate clients. They have very different needs, very different interests,
(02:06):
and they're trying to upscale people in very specific technologies.
Speaker 2 (02:10):
Actually, I'm kind of curious why did Maybe this is
my own kind of curiousity, is why did plural side
switch away from like B two C? It was like
B two C, and it was like B two C
plus B to B and then now it seems like
they went totally over to B to B. I was
kind of curious, like what happened? I mean, obviously that
changes a lot of things, right, Hence it probably put
more blockers into your path of getting that going.
Speaker 3 (02:29):
Sure, I wasn't there for most of the decisions around
that big transition to B to B customers business to
business customers. It was sort of happening as I joined
the company, so I'm not really sure the reasoning behind it,
but I can tell that it has done great things
for the company, So I can't fault them for making
that choice.
Speaker 1 (02:47):
And are you using alix also pluralsite? So is it
something like you actually basically eating your own dug food? Right?
Speaker 3 (02:55):
Happily we are. So we have one team at the
company right now that is using or the team that
I'm on. We focus on creating the authoring tools and
the learning experience for our hands on cloud labs. So
more of an interactive content type. You can imagine with
Alixer it's more focused on interactive things. And so we
(03:15):
do have a small group of people who are using
Elixir Plural site today.
Speaker 2 (03:19):
I think I'm more interested to hear about, like what
was the how do you start from coming in convincing
people that this could be something useful making the content
and like you said, this be to be now right
enterprise customers and saying that we should put this into
the stack. Can you actually talk about that, And I
mean feel free to be as details you want, because
(03:40):
I'm sure some listeners out there are in a corporate
environment and they do have these kind of struggles. And
I'm also curious about how long was the process. Was
it two years? Was it six months? I mean, I
can imagine it being less than a year.
Speaker 3 (03:51):
And so there are some nice parallels between the way
that we introduced the Elixer at Plural site for us
to work with and how we got Elixer content on
the platform as well. And I think this story has
played out quite a few times across different companies. You
have maybe a group of people who are working on
some sort of prototype or they're moving a little bit
(04:12):
faster working on something slightly different than the rest of
the organization. That's a great candidate group of people to
introduce Elixer too. And that's really the value that I
sold in this course to folks listening and to plural
site as well for putting this content on the platform
was Elixir is a great language for getting something off
(04:33):
the ground quickly. It removes so many barriers for things
that aren't the business value, aren't the stuff that you
should be spending time on, So you can get up
off the ground and get something out to customers and
you see the value, see if it's going to work
quickly before you invest the kind of investment that you
might put in with another language.
Speaker 2 (04:51):
OK, maybe I'll ask another question, So when you like,
what do you think was actually the easiest part of
the process of trying to convince people that you know,
Alexu is definitely something that you guys should use and
also that you should teach to other corporate clients. And actually,
I mean, do you actually have a path for that too,
because I know you guys have passed right, And what
(05:12):
was like the most easiest part of it, what was
actually the most difficult part? And was it expected for
each of those.
Speaker 3 (05:17):
It is difficult to get a new path for a
new technology on any learning platform, I think because you
have to convince them not only that you're going to
spend your time on it, which you can choose to
spend your time on whatever you want. That's not really
a cost to them, but all of the other folks
that are involved, the production editors, everything like that, the
(05:40):
folks who have to spend hours of their day supporting
this content and making sure that it gets onto the
platform correctly. It's, you know, not insignificant amount of time
that the company has to spend on any new technology
if you want to introduce it to a learning platform.
Convincing them to do it it took some time at
and I think that's true for any new technology. But
(06:01):
it really centered around this is something that's growing. It
has the opportunity to be something that changes the course
of a company's direction. It's something that people are actively
using and hiring for. It may not be the hiring
market that something like JavaScript has, but it's out there
and if you look at the index of Technologies, you
(06:23):
know the Tiobi index, Elixer is starting to make more
appearances on there, it's starting to show up higher in
like stack overflow surveys, and in those results. All of
these things sort of add up to show that this
is a technology that is growing, People may be interested
in it, and we would like to be on the
front edge of having content for it, rather than trying
(06:44):
to catch up with it later on.
Speaker 4 (06:45):
If you had to sell Elixir comparatively speaking, say, compared
to JavaScript or other major languages, what would be your
key arguments.
Speaker 3 (06:56):
This was something I had to really think about sitting
down to make this plural site course, because this first
big picture course was going to be you know, possibly
for a software developer, but also possibly for a leader
trying to evaluate whether Elixer is a good choice for
your next project. And the normal arguments just don't work.
(07:17):
The reasons I love Elixer about the things that have
to do with you know, developer happiness and my productivity.
They don't necessarily sell it, and maybe they should, maybe
they shouldn't, but they don't to a lot of leaders
in technology organizations. So I had to really think about it,
sit down and think, Okay, what matters to the business.
If you're doing a prototype, you want to get the
(07:39):
prototype out quickly. Elixer enables that if you are making
a product that's going to stick around long term, you
want that product to be reliable, easily maintainable. Elixer has
some really great strengths there as well, and so kind
of focusing in on those things and the fact that
you are enabling your developers to focus on what matters
(08:01):
rather than the minutia of, you know, just getting the
app running in the first place. That's what really sells
it to Fox, and especially to Fox like the kind
of people who pay for Plorosite for their corporate employees.
Speaker 1 (08:14):
It's interesting that you say that because recently we had
an episode where we talked about the Leik Sir as
a general purpose language and why people might want to
pick it and it's not only this niche thing, and
that was like a lot of the talking points we
ended up with, like the kid's easy to get started with,
it's easy to hit the ground running, but it also
doesn't have these foot guns other languages might have, way
(08:36):
where you end up in a situation where you have
this big ball of mud and it's unmintainable and then
buggy like. Of course, it can also happen in Elixir
but my impression is that there are certain design decisions
specifically made to avoid some of these issues with like
fast growing code bases.
Speaker 3 (08:54):
So that's right, and you know, to kind of put
even more emphasis on one particular piece of it, I
really wanted to spend some time in the course talking
about the difference between trying to avoid errors altogether and
recovering from them when they eventually happen, because the bottom
line is, if you have alix air hosted on no
(09:15):
matter where it's hosted, something's going to go down sometime.
There's nothing you can do in your code to avoid
the node going down and your app being offline. And
if you have your app as part of this distributed
system that's relying on one another, Elixer can handle that
a lot better than other languages can. And bottom line
is you're going to have less downtime because of that.
(09:37):
And just that focus of not trying to try catch
every little thing that could possibly go wrong and instead
dealing with the consequences and restarting processes when they do
eventually happen. That's really powerful.
Speaker 1 (09:49):
Yeah, basically accepting ruinity of like things are going to
break at one point or another. Nothing is perfect. I'm curious,
do you also talk in your course about like Elixir
and Berlin, because I mean a lot of these ideas
we just talked about come originally from Berlin. So how
does that stick up in the course.
Speaker 3 (10:07):
Yes, definitely. So the first module the course is all
about what elixir inherits from Arline, because a lot of
folks will look at elixer you know, this language that
first commits in twenty eleven, first releases in twenty twelve.
They think this is a shiny new technology. It's probably
just going to be a blip on the radar for
a little bit and then disappear like many technologies do.
(10:29):
But what you realize those roots in Erline, and if
you really understand what it's coming from, then you start
to realize that that's not the full story. This is
actually a technology that has really strong foundations that are
well tested and proven in production, and that can really
flip a switch when you're, you know, an engineering leader
that is trying to decide whether this is a good
technology to invest in.
Speaker 1 (10:51):
Did you already have some kind of feedback from especially
like technology leaders and like more from your B t
B set with people, said O kivis course like us
choose Elixir, So any success stories, basically.
Speaker 3 (11:03):
I wish nothing yet. I haven't received much feedback on
the course overall yet, but hopefully someday that story will
play out, you know, whether because of this course or
because of any of the other great content out there.
I would love to hear that story of You know,
we were skeptical at first, but because of the great
community and the content that was available all over the Internet,
we made a decision and we don't regret it.
Speaker 1 (11:25):
So you've heard your folks like recommend this course to
your manager and maybe things are going to pan out.
Speaker 5 (11:31):
I can dream, well if things actually do pan out,
do you have anything next plant?
Speaker 1 (11:36):
Yeah?
Speaker 3 (11:36):
So I would love to see more content about Elixir
and Erling honestly on the plural site platform because it
is in some situations it provides a sort of legitimacy
to the type of types of companies that buy plural
Site and use it to skill up their employees. If
they don't see a language represented or represented, well, then
(11:59):
they're going to consider it to be a niche language,
just bottom line. So I would love to see more
Elixer content sometime this week. There will be a new
course on a elixer called Architecting Elixir Applications with OTP.
That's sort of like that next level up. We have
some great getting started content as well, introducing you to
the syntax and everything like that. I would love to
(12:20):
see more, and hopefully we can also get some content
on Erling as well, because I know plenty of companies
already have erlang in production and they may struggle to
get folks trained in it and up and ready to
add new features to it in the long run.
Speaker 2 (12:37):
Yeah, it's true. I do remember like some interesting companies.
I think there was some insurance company or something that
put things into arlaying and yeah, they did it like
on Super Bowl Day for have you heard the story?
You're laughing, so I'm curious. Maybe you heard about it.
I forgot what the company was, but it was really
crazy and probably wasn't that they did do this was
because they knew you could handle the traffic. And I
(12:59):
think it's launch day was a supable day, you know,
because when you do your super commercial, that's when you
get your traffic right. And so I have to see
if I can find the story. But it's pretty good,
but it's a Java shop and then they knew it
couldn't scale for this kind of stuff, so they did
earling and it just worked out like too.
Speaker 3 (13:15):
Well, that is a fantastic story and exactly the kind
of story I want to tell more of too, because
if this is a technology that you can turn to
and trust for those days, that's a great choice for
any day.
Speaker 1 (13:28):
So was there anything you like learned about Elixir or
early and you didn't know before while making the course?
So in any cool little discoveries which might or might
not have made it into the course.
Speaker 3 (13:39):
It was great to really think about again why why
I like the language and really consider that that's not
the reasons that folks choose a language for a business.
You know, it's not about a friendly syntax, it's not
about how nice the mixed tool is. Really those are
great things and that I would never discount them, but
(14:01):
the real decision for an engineering leader is something much
deeper than that, and speaking to that is difficult for
any technology. I think we as an industry have fallen
into certain ruts where we see other companies that are
using a technology, so we just assume that it's a
good choice for our business. And now that I've evaluated
(14:22):
that mindset and really thought through what if I were
a leader making the same choice. Looking at those same things,
it brought me, honestly, a lot of respect for why
companies use the languages they do, because it's tough to
make that decision, it really is. It's tough to go
out and put your reputation as a leader as a
(14:43):
company on the line and say we're going to back
this language. That's a tough decision to make as well.
Just looking at alixer overall and digging more into the
history of Erlang, it was really fun to see the
situations that Erlang originally were developed in. I had the
ten thousand foot view of this is why we created
the language, and these were the problems it was there
(15:04):
to tackle. But actually digging into sort of the early
iterations of Erlang and the runtime system and it, you know,
the phase in which it went through various different run
times and was developed from there, that was really interesting
and I highly recommend folks dig into that more because
if you understand not just what erlang is and what
it brings to Alixir, but where Erlang itself came from,
(15:26):
you can get a really nice view of the full
evolution of this technology that you're using every day, and
that can be really beneficial just to understand not only
where it came from, but probably where it's going.
Speaker 2 (15:37):
It's the most interesting part is like telephone swhich is
basically mirror services, which is what we expect, high availability
and lots of traffic spiking, all these kind of things.
Like when Twitter goes down, everybody flips because they have
nowhere to complain that something's down, right, this visious cycle, yeah,
or Facebook or whatever. But the funny thing is, of course,
(15:58):
let's not say that it's Earlan and Elixir are not
invulnerable to problems, right, So WhatsApp is probably one of
the most famous cases of highly scalable or laying services.
And it does go down because I remember because like
everything stops because I'm in Hong Kong and we always
use WhatsApp to always chat, and the other guys are
here in Europe, so I'm sure it's the same thing.
(16:19):
WhatsApp is like really integra to your life, and yeah,
it does go down like a couple times a year,
but in reality, like, yeah, it's if you think about
other websites and things that you maybe used, it's probably
a fraction of that. I don't know about you guys.
Think I also enjoy the hot code upgrades that we
have that ability, because so many times to go to
check my bank account and it says, oh, yeah, you know,
(16:40):
we're upgrading between now and five hours later, so please
check another time, So it's also super annoying.
Speaker 3 (16:47):
I think one of the big powers of this run
time is it does try to be resilient. As we
all know. It has this idea of restarting processes, but
I think when folks hear that, if they're coming from
another language, they may think, oh, the app restarts itself
if there's a problem, and that's not the full picture here.
(17:08):
The portion of the application that is restarted, if you've
structured your supervision tree correctly, is the smallest portion that
needs to be restarted. So if you're having an outage
in one area, in one node, in one portion of
your service, it may just be that part. And if
you can maintain uptime for everything else that's happening in
(17:30):
the runtime at the same time, that's really powerful, and
it's really difficult to sell that and to get that
to be understood. The folks who are evaluating the language
at times because you just hear, oh, it's good at
restarting processes. You're thinking, okay, it can restart its own
OS process when it crashes, and we call that resilience.
(17:51):
Communs can do that too, right, exactly exactly. Yeah.
Speaker 1 (17:56):
I think the interesting you're there is like, at least
my experience is that a lot of engineers and developers
who have a few years of experience know that things
can fail and are aware of that, and so we consider, okay,
now maybe this API request I have to retry that. Okay,
what if the database connection goes missing? And so there
(18:17):
are mechanisms and other languages also like to to to
patterns rather to do this where you say, okay, let's
do reach try based approach here. I think the interesting
thing about the beam specifically is that it has these
primitives like built in it is still design of like okay,
what does it mean to have something which needs to run,
which which can crash, which needs to restart? And from
(18:39):
that we have gen servers and supervision trees And yeah,
I guess it makes a lot of sense what you
said earlier, that it's really digging into where we're lying
at the bigs here. And the beam come from gives
you a new appreciation of like, Okay, what does it
actually mean to have a resilient system in place? And
I wonder, like what what did you use to learn that?
Is there any resources you reckoon, for example, like vivi
(19:01):
thesis written by Armstrong or what did you look into
to like get this this level of understanding you just mentioned.
Speaker 3 (19:09):
Joe Armstrong's thesis was definitely the place I went first,
because people recommend it and it is a great read.
There was also a later paper, I believe, just detailing
more of the history of earling in a more general sense,
and that was very helpful too, because it just gives
you that that view of you know, we see the
finished product and we know a bit where it came
(19:30):
from conceptually, but you know, it wasn't always this way.
It didn't always look like it does today, and seeing
that evolution over time was very helpful.
Speaker 2 (19:38):
I also want to say, I don't know if you
guys knew there on pastonal link to here, but you
mentioned about like, okay, you're just restarting a piece, but
there's also this thing. I think heart is the one.
I know I've heard of something, but I think hard
is the one where it keeps setting a heartbeat to
your app, and if your app actually did crash at
the top level, it'll actually restart your Earlin Release application,
(19:58):
which is so there there is a supervisor for it,
I believe, which is what this thing is. So if
you turn this on you can have that ability.
Speaker 1 (20:06):
That's interesting. I didn't know this existed.
Speaker 2 (20:09):
I read it somewhere and actually also, Aja, you also
remind me of another story that I talked about on
the show a while back. Sometimes restarting your application is
a problem. So I don't know if you heard this story,
but I know I think I'm nine percent sure. I
heard it from Francisco where he's had a client and
they had this system running for like twenty plus years
and they had to restart it because it was at
(20:31):
a point where you couldn't hot code upgrade anymore. They
had to upgrade the ERTs or something. It was just
like way too far out of date. And what actually
happened is that when they went to up when they
went to shut it down and turn it back on,
it wouldn't turn back on because there was a speck
of dust between the hardware readhead and the disk, and
(20:51):
it just couldn't read the disc because it never had
a readisk before because everything was in round, and so
restarting the system and rebooting it actually caused a bigger
part problem. And yeah, the CEO was also involved because
he was like, would you guys do it? You know,
we can't do anything, you know, and if you think
about it, this kind of issue would never come to
my mind, right, like whenever something doesn't worked, just we
(21:13):
started in this situation, even though it's an early application,
we're starting, it actually made things much worse because it
was outside of control. But still it's kind of a
little bit of what do you call the oxymoron or
something ironic? Right, it's ironic.
Speaker 1 (21:26):
Yeah, it's true.
Speaker 3 (21:28):
We are so used to whenever we have a problem
that old phrase, you know, have you tried turning it
off and on again? And if anything goes wrong with
this computer I'm on right now, it's a reboot to
start just the first thing you try. But that doesn't
work for many systems. And as we go into this
cloud native sort of way of doing things too, we
(21:49):
treat servers as cattle instead of pets, where we're just like, okay,
the server's acting up, then get rid of it, add
a new VM instead, and that's great for DevOps and
it allows folks to move quickly. It allows us to
not spend a lot of time diagnosing a certain class
of issues. But there are systems that need to stay
up and having a load balance or just sending traffic
(22:12):
between different servers that doesn't always work. And in those situations,
I love that erline can stay running for years at
a time without having to worry about these kinds of issues.
Speaker 1 (22:22):
To say, like, I hope I never have to deal
with like a system running for twenty years and then
they'll rebooting because of spec of dust on the reading head,
Like that's not a thing I want to deal with. Whoever, whoever,
I had to do that, like my deepest respect. Seriously,
it reminds me of another story.
Speaker 2 (22:38):
It's not really related to this, but there was a
guy I think this is Michael mend Maynard An he
say his name. He came to Hong Kong and he
was and he was there to talk about I forgot
what now. All I can remember is the story about
how every day at like two am or four am,
the networking would just stop right So it was like
a bunch of it was a big it's a very
(22:59):
large We talk about this before because you're shaking your
head like, yes, maybe I know that story, but continue, Okay,
did you listen to this story before or did I
tell this story before?
Speaker 1 (23:08):
And I think I put it to somewhere else.
Speaker 2 (23:09):
But so every day that the networking would stop at
four am, right, and they spent like weeks, I think,
trying to dep up what's going on like around four am.
That Well, what turns out, for some reason is that
when you got so it's a cashier, it's a big,
super big chain. I think I kind of know which
one it is, but I don't want to say because
he's not allowed to say. And he told us all this. Yeah, anyways,
(23:30):
and so obviously in the daytime, you're scanning customers and
the cashiers and everything are working, right, networkings go on,
this traffic going on, but at night there's no traffic, right,
there's very little of anything. And so what happens that
they have this networking configuration where when there's no traffic
and then all of a sudden there's traffic. It's like
a way to block maybe malicious stuff. And so the
(23:52):
firewall would just come up and it would just block everything.
And so every day at four am, because what happens
is that every day at six am or five am,
they'd be getting a phone call, get over here. We
can't do anything.
Speaker 1 (24:02):
We kept me up.
Speaker 2 (24:02):
Customers, people want to buy stuff, and that's you know,
it's a huge chain and these things are all network
so like could you imagine like trying to figure out
like what's going on? And you have to like because
when it's a firewall, right, you send a package and
it just gets strucked. Nothing comes back. So that's what
was happening, is that they couldn't even diagnose it because
you wouldn't eve get a pain or anything. So why
don't we talk about this?
Speaker 1 (24:22):
I don't know.
Speaker 2 (24:22):
But anyway, crazy to bug issues, right, I think is
where it came from.
Speaker 1 (24:26):
I actually like I was thinking we were going to
a different story of it, because there's a similar story
of like a person like this one server going down
like every time around like six pm ish, and they
like also to spend weeks on trying to track it down.
And at some point this guy set taped down in
this sort of a room like a beer and like
I Ca'm going to see what happens at six pm.
At six pm, like the cleaning person, person that comes
(24:48):
in and pulls out the socket, like black from the
socket plucks in like the vacuum cleaner. That's where the
downtime came from. Yeah, I'm not sure how we got here,
but like sometimes you have really these issues and where
things goes down, Things go down even in scenarios where
(25:09):
you really would never have imagined before that this might
be an tissue down the road. So, yeah, failure is
built into our systems. It's just the way it is.
So having a run time which really accepts that and
embraces that can make a lot of things easier.
Speaker 2 (25:23):
It's pretty There's quite a few companies are actually just
gonna say, it's quite a few companies that actually do
that part of their processes. They literally go to the
service right yank and stuff out as a development process
just for Alextra Earling. Sorry, Eric, that just popped in
the mind. I want to say before I forgot you. Sorry,
go back to what you're saying. The key would be
careless engineering. If anybody would want to want to look
(25:44):
it up them and may post the link of the show.
Speaker 5 (25:47):
I was curious if you know what the trouble trioting
process for the speck of Dust story was. Like, I
wonder how they got to that root cause analysis something
that must be fascinating how to do, but to that
spickuplust imagine I had to like crack open the hard
drive at some point.
Speaker 3 (26:04):
I love imagining the person standing in front of this
machine that's twenty years old, thinking, yeah, we can keep going.
It served us for twenty years. Let's just reboot it.
It'll it'll continue. That's a pretty significant amount of trust
in a system.
Speaker 2 (26:19):
Well, there's so many. Like I remember working in a
software vendor a couple of years ago, and I don't
remember exactly the story, but I think there was like
a VPN or something running off the Selearis system and
it was just a machine that just was sitting in
the corner for decades and they just just ran and
they never restarted it. And then it was kind of like,
what is this thing doing? And I kind of reminds
(26:40):
me that it's like sometimes you just run these systems
and they just run and you just don't touch them.
One of the first services I did for that company actually,
like everything it wasn't Erlang or Elixir. It was just Python,
but we used rabbit m Q to communicate everything, and
the ops team basically started basically chaos engineering for us.
They started just shutting down processes and seeing if things
(27:01):
are happening, and the queue flooded up, and then they'd
call me and they come fix it because they were like, well,
it never aired up before, so we don't know. We
didn't know it's still actually running. We thought it wasn't
actually running at all. So that's kind of like sometimes
things run too well and then you don't get the
recognition I find that. You know, maybe it's good to
actually kind of throw a couple of bugs in there
because people like it when you save the day. They
(27:22):
think you're an awesome engineer. When your stuff works and
nothing breaks, then they don't even know you exist.
Speaker 1 (27:27):
It's like, nothing is working, why are we paying you?
Everything is working? Why are we paying you? Basically that right, Yeah,
no matter what you do, you're in trouble. Okay, maybe
back back, I'm wondering, like, based on what you left
learned and then I'm sure there are things you discovered
alongside the way of doing this course. Is there anything
(27:49):
you'd like to change or is there like where you say, okay,
I can imagine like a follow up course building or
on top of what we have here. So it's a
well does the.
Speaker 3 (27:58):
Road lead working through Elixir? The big picture again focused
on both software folks and leaders as well. It was
obvious to me that the Elixir, elixir itself and the
Earling run time have a lot of value. It may
not be immediately obvious how to capture that value, and
so I really wanted to follow up with some sort
(28:18):
of architecture related course to help you actually access all
of the great things about the runtime, actually use OTP
to its full potential to give you the great things
that we promise that you can get out of it.
And so I worked on a course called Architecting Elixir
Applications with OTP that seemed like a really important follow
up from that, I realized that if you really want
(28:42):
to get all the value from that architecture course, you
need to understand testing a lot better than even I
do today. And so I'm hoping that we can get
a little more content on testing. There's a great new
book out testing Elixir. The ideas of property based testing
as well really important. I think if we can get
more broad based understanding of not just what they are
(29:03):
and how to do them, but why they make a
difference in the long run to your business. I think
that's really important because if we can tie all of
that knowledge and all of those capabilities back to business value,
that's how we get Elixir to be adopted by more companies.
Speaker 1 (29:19):
It's kind of said that Adi isn't here, right because
if I'm remember correctly, some of his colleagues have written
testing Elixir, so he probably would have something to say, yeah, well,
here we are. Okay. I think things I can see.
I can already see how how that might be useful
to folks out there. I think one maybe a difficult
question for you, why should I, for example, choose ALIXI
(29:39):
to a big picture compared to maybe some other courses
out there. I think there's even as a course from
Bruce Tait. Also, I didn't quite find it while I
was googling, but there are already like interactive courses to
learn Elixir. So I mean, I see the appeal of
having this leadership based thing, but as if I'm just
a quotes a developer, why would I choose a a
(30:00):
big picture of it? Maybe some other courses out there,
or why should I maybe then go to other courses
if it's a better choice.
Speaker 3 (30:06):
Yeah, so I'm going to be a little do the
opposite of what I probably should do here. You know,
if you have a great course that you have access
to take it and share it, that's the main thing.
If you don't have access to plural Site, your company
hasn't paid for it, you don't have an account, then
obviously Elixir the big picture isn't going to do much
for you. What I really wanted to do by even
(30:28):
creating this course in the first place was not necessarily
create the best piece of content ever, because there's great
content out there and I could never hold a candle
to Bruce Tape or anything that he's created. But the
folks who already have access to plural Site, the folks
who use plural Site as a way to decide whether
a technology is something that they can train their people on,
(30:51):
that's who I was really targeting. And I think there's
other things we can do as a community to help
those folks out, because whether we realize it or not, folks,
these are very differ heuristic to determine the legitimacy of
a language than what we use as technologists. We try
a language, we build a project in it, we see
how it feels, we see how productive we are, and
(31:12):
those are great ways to determine if it's something we
want to build our next project with. But many companies
don't necessarily care about those things. They're wondering how quickly
is this product going to get off the ground, how
quickly are we going to get the return on our investment,
how likely are we going to be able to hire
for it, things like that, and they use things like
(31:33):
the presence of learning content on their platform of choice
as part of that heuristic. They use things like a
language's popularity on a language index, or how many hits
they get when they search for it on LinkedIn as
heuristics for whether this is a good choice for them.
Whether we agree with that or not, it does happen,
(31:53):
and so there are things we can do. Putting content
in new places always helps. Going on LinkedIn and doing
things like endorsing one another for elixir as a skill.
It seems like such a small thing, and I know
many technologists, including myself, really don't spend much time on LinkedIn,
but that data is used in places people do look
(32:15):
at it to think about whether this is a good
technology choice. So I think we can do more as
a community there to help these companies see that it's
a good choice for their next project.
Speaker 1 (32:27):
They basically reach outside of our bubble, right because I mean,
of course, as technologists we live inside of our bubble,
and maybe LinkedIn is not that big of a part
of that. So yeah, I can I can see where
you're coming from, and I can see like how you
identify this niche of like having the leaders and maybe
producing content for these people and explaining to them might
(32:49):
be great. So yeah, like that's some interesting thoughts there
for sure. I mean, maybe I'll just go on linked
the next and endorse some of my colleagues for elix knowledge.
Speaker 3 (32:58):
I recommend it, I really do. And other things that
you can do too, upvoting things on stack overflow if
there's a stack overflow question related to Alixer that helped
you upvote the question and the answer. To make sure
that those any questions that you ask are properly tagged
so we can track these things. These are little bits
of digital exhaust that companies collect in order to determine
(33:21):
how popular a language really is, and unfortunately I don't
think Elixer is well represented in those things. I think
our community is a lot bigger than our data makes
us look. So if you have an opportunity, go for it,
like go upvote things, go indoorse things like that can
really help.
Speaker 1 (33:38):
Yeah. I remember having discussions around this, so people said, Okay,
elix is not that popular onsa overflow if you look,
because a lot of what's happening in the community, and
especially questions and discussion have mo one elixa forum and
like that forum is like super active. I mean I
look into it basically daily, but there's always something happening
over there. So like these traditional platform form like stack overflow,
(34:01):
is actually maybe not as much activity on there as
you might guess in terms of how many people are
actually using elixidy today. What I really like to see
wasn't the last stack overflow survey that Alixo was the
third highest paying language. I think, so it was really
our fifth highest paying language. So that was nice to
see the finally some recognition of our of our language
(34:24):
and our platform of choice in these more traditional air
quotes sources of information.
Speaker 3 (34:30):
Yeah, if you see a developer survey like the stack
Overflow Developer survey. Please take it because people will use
that data for expanding the community.
Speaker 1 (34:39):
Okay, Ellen, Eric, do you have any more questions for
AJ otherwise that yeah, okay, otherwise I'll probably go to
picks now. And so Alan, do you want to start
off with picks this week?
Speaker 2 (34:52):
Yeah, so I can share. I definitely pick the YouTube
video I sent earlier about the so how erlang saved
this company during the Super Bowl. That's a pretty good one.
Also the other one too. So I recently started picking
up this book called Zero to prod. It is a
Rust book, of course, you guys know I'm pretty much
trying to get more and more to Rust.
Speaker 3 (35:14):
Well.
Speaker 2 (35:14):
Actually, what I like about this book is it really
takes you from beginning to like production with Rust. And
the other thing too is they do things that I
think most books don't teach you, which is actually how
to build something really from scratch and not just like
creating the services and everything, but also how to add
in things like testing. Not a lot of books add
in testing. But there's also a telemetry part too, which
(35:38):
is I never hear about telemetry any other language except
for Alixer. So when I heard that I'm like, Wow,
this is really interesting because not a lot of books,
you know, not a lot of people teach telemetry and
programming languages. So I think this book is something that
is pretty cool, and I finally started reading it today.
I'm pretty happy with this so far because I've really
taking it from the beginning and kind of saying, Okay,
(35:58):
we want to build this thing. We know that need
to have like a linter, what's a linter? And does
this we need to have like a CI server. Here's
some how you set the c I server. Really like
from beginning to end, and really like the professional route
right linters and having a CI and like I said,
telemetry eventually, those things I think are just not talked
about in most books when they're teaching you, like a language.
(36:19):
So that's why I think this is a pretty interesting
book for people who want to pick up rest and
like get the whole entire production experience.
Speaker 1 (36:25):
Nice Eric, What would be your picks? One pick?
Speaker 5 (36:28):
Which is the holiday book that I've been reading the
last two weeks. It's completely off topic. It's called a
hardcore zn punk Rock, Monster Movies and the Truth About Reality,
and it's a hilarious read about a guy who so
love as a punk rocker. Then how is it now
made it to Japan working for a company that is
making monster movies where you have he as Cyru's Rex
(36:51):
that is tearing down Tokyo and stuff like this, and
he ends up becoming a Buddhist monk, getting to the
Zemen Buddhism and meditation and a lot of the elements
of Buddhism. And it's been the various read with all
of the anecdotes that he shares, there's been made me
left out loud several times, but most crucially it's been
give you some insights into Buddhism, which has been like
(37:12):
a bit of a dish interest of mine for a
long time. I had this book on my bookshelf for
several years now and so finally time.
Speaker 1 (37:19):
To read it.
Speaker 5 (37:20):
And it's been really an enjoyable experience. So I hope
someone else finds that book useful.
Speaker 1 (37:26):
Sounds interesting. Now I have two more books to it
to my never ending to read list. Thanks. Okay a J.
Do you have any picks for us? Can be anything
like as you see, we have all kinds of picks.
Speaker 2 (37:39):
This week, there's no more books, right, no more books please?
Speaker 3 (37:42):
Right, can't add any to the list this week, so
sure I have two picks for you. First is more abstract.
I guess one of the places where you can run
into trouble with Elixer and where it can be frustrating
as a community, is where Elixir combines with other languages.
You know, the interrupt between things. So if you're one
of those rare people who knows Elixir and Swift, for example,
(38:07):
I'll drop a link to a project that I've been
working on to help make it easier to have an
iOS app, for example, work directly with absinth. That's just
one example of we need more projects that allow Elixer
to interrupt with other languages other things around technology. And second,
i'll just throw out that I believe it's September eighteenth.
(38:28):
We start a new season of the First Tech Challenge.
This is a program for middle and high school students
in robotics. They get a new challenge every year. They
build robots to meet that challenge. They compete against one another.
It's a really cool thing. So if you, as a technologist,
are in a place where this challenge takes place, there
are teams nearby you. I highly recommend go out volunteer
(38:52):
mentor teams help them learn how to program. This is
something you can really do to help inspire the next
generation of folks who are entering programming and engineering.
Speaker 1 (39:02):
Then they show him more awesome elixir can be, right,
so we create our next generation of Alixity developers. That's right. Okay,
I will make it short and sweet. I will pick
a book. Sorry, Ellen, but it's a very short read,
and I wouldn't be surprised if you already read it.
It's Earlying and Anger. It's actually a free ebook, and
it's I think it's below one hundred pages, and it
(39:25):
talks about like what can really go wrong when running
software on the Beam and like what people experience when
running Earling in Anger, so when things break, and how
to how to basically deal with beam instance running which
might not behave as you expected, and what the Beam
then gives you for tooling to deal with this kind
(39:45):
of situation. So it's very interesting read if you're like
interested in like operations and really want to to see, Okay,
how how can the beam be pushed to its limits
and what can go wrong? And it said it's a
fairly short read, so not another three hundred side book
to add to your never ending reading this. Okay, folks,
then unless you have anything else to add. No, everybody
(40:08):
is shaking their head. So I wish you a great
week and tune in next time when we have an
episode of Felix Index
Hello everybody. This week Ellen asked me to do the
angry German introduction, so I'll do that, and everybody, Welcome
to another episode of Elixir Mix. And this week on
our opendent we have Eric Bodikowski.
Speaker 2 (00:18):
Hey, did you be back from holiday?
Speaker 1 (00:20):
Alan Wima? This don't hurt me. My name is Sasha
a Wolf we say it in Germany. And this week
our guest is A J. Foster. Aj. Why don't we
tell us why you're on the show and why everyody
likes you? Hello?
Speaker 3 (00:35):
There, I don't know that everyone likes me, but I'm
on the show today because I'm a software developer at
ploro Site, and I recently authored a plorosite course called
Elixir the Big Picture, trying to bridge the gap between
folks who are evaluating Elixir and why they might want
to choose it for their next business match.
Speaker 1 (00:53):
That sounds nice. How did it actually come to be?
I mean you work at Plorosite, right, so how did
how did you end up making a course for for lexia? Yeah?
Speaker 3 (01:02):
You may or may not know that most authors at
plural site are external folks. There are not employees, but
there are a few employees who are interested in teaching
and education, and they end up authoring content on the
platform as well. Over time, as I got more into Elixer,
I wanted to see Elixer content on the platform, so
I gradually worked my way in and tried to convince
(01:23):
them that that would be a good idea.
Speaker 2 (01:25):
I was actually trying to do the same thing. We
were talking before the show, and we know some people
at plural Site and I was having a discussion with
one of the guys and I said, I think you
guys should put it on there, And I don't know,
there was a big reaction of like no, no, no no,
or that's not mainstream enough, or never heard of it,
or I forgot what the reaction was just a few
years ago. Actually, So I'm glad that it's finally on there.
Speaker 3 (01:46):
Yeah, it's definitely been a journey to get that type
of content on the platform, whether it's Elixer or in
the future, Er Length still working on that because plural
sites customers are very different from what you might get
if you're just creating content freely on the web. These
are corporate clients. They have very different needs, very different interests,
(02:06):
and they're trying to upscale people in very specific technologies.
Speaker 2 (02:10):
Actually, I'm kind of curious why did Maybe this is
my own kind of curiousity, is why did plural side
switch away from like B two C? It was like
B two C, and it was like B two C
plus B to B and then now it seems like
they went totally over to B to B. I was
kind of curious, like what happened? I mean, obviously that
changes a lot of things, right, Hence it probably put
more blockers into your path of getting that going.
Speaker 3 (02:29):
Sure, I wasn't there for most of the decisions around
that big transition to B to B customers business to
business customers. It was sort of happening as I joined
the company, so I'm not really sure the reasoning behind it,
but I can tell that it has done great things
for the company, So I can't fault them for making
that choice.
Speaker 1 (02:47):
And are you using alix also pluralsite? So is it
something like you actually basically eating your own dug food? Right?
Speaker 3 (02:55):
Happily we are. So we have one team at the
company right now that is using or the team that
I'm on. We focus on creating the authoring tools and
the learning experience for our hands on cloud labs. So
more of an interactive content type. You can imagine with
Alixer it's more focused on interactive things. And so we
(03:15):
do have a small group of people who are using
Elixir Plural site today.
Speaker 2 (03:19):
I think I'm more interested to hear about, like what
was the how do you start from coming in convincing
people that this could be something useful making the content
and like you said, this be to be now right
enterprise customers and saying that we should put this into
the stack. Can you actually talk about that, And I
mean feel free to be as details you want, because
(03:40):
I'm sure some listeners out there are in a corporate
environment and they do have these kind of struggles. And
I'm also curious about how long was the process. Was
it two years? Was it six months? I mean, I
can imagine it being less than a year.
Speaker 3 (03:51):
And so there are some nice parallels between the way
that we introduced the Elixer at Plural site for us
to work with and how we got Elixer content on
the platform as well. And I think this story has
played out quite a few times across different companies. You
have maybe a group of people who are working on
some sort of prototype or they're moving a little bit
(04:12):
faster working on something slightly different than the rest of
the organization. That's a great candidate group of people to
introduce Elixer too. And that's really the value that I
sold in this course to folks listening and to plural
site as well for putting this content on the platform
was Elixir is a great language for getting something off
(04:33):
the ground quickly. It removes so many barriers for things
that aren't the business value, aren't the stuff that you
should be spending time on, So you can get up
off the ground and get something out to customers and
you see the value, see if it's going to work
quickly before you invest the kind of investment that you
might put in with another language.
Speaker 2 (04:51):
OK, maybe I'll ask another question, So when you like,
what do you think was actually the easiest part of
the process of trying to convince people that you know,
Alexu is definitely something that you guys should use and
also that you should teach to other corporate clients. And actually,
I mean, do you actually have a path for that too,
because I know you guys have passed right, And what
(05:12):
was like the most easiest part of it, what was
actually the most difficult part? And was it expected for
each of those.
Speaker 3 (05:17):
It is difficult to get a new path for a
new technology on any learning platform, I think because you
have to convince them not only that you're going to
spend your time on it, which you can choose to
spend your time on whatever you want. That's not really
a cost to them, but all of the other folks
that are involved, the production editors, everything like that, the
(05:40):
folks who have to spend hours of their day supporting
this content and making sure that it gets onto the
platform correctly. It's, you know, not insignificant amount of time
that the company has to spend on any new technology
if you want to introduce it to a learning platform.
Convincing them to do it it took some time at
and I think that's true for any new technology. But
(06:01):
it really centered around this is something that's growing. It
has the opportunity to be something that changes the course
of a company's direction. It's something that people are actively
using and hiring for. It may not be the hiring
market that something like JavaScript has, but it's out there
and if you look at the index of Technologies, you
(06:23):
know the Tiobi index, Elixer is starting to make more
appearances on there, it's starting to show up higher in
like stack overflow surveys, and in those results. All of
these things sort of add up to show that this
is a technology that is growing, People may be interested
in it, and we would like to be on the
front edge of having content for it, rather than trying
(06:44):
to catch up with it later on.
Speaker 4 (06:45):
If you had to sell Elixir comparatively speaking, say, compared
to JavaScript or other major languages, what would be your
key arguments.
Speaker 3 (06:56):
This was something I had to really think about sitting
down to make this plural site course, because this first
big picture course was going to be you know, possibly
for a software developer, but also possibly for a leader
trying to evaluate whether Elixer is a good choice for
your next project. And the normal arguments just don't work.
(07:17):
The reasons I love Elixer about the things that have
to do with you know, developer happiness and my productivity.
They don't necessarily sell it, and maybe they should, maybe
they shouldn't, but they don't to a lot of leaders
in technology organizations. So I had to really think about it,
sit down and think, Okay, what matters to the business.
If you're doing a prototype, you want to get the
(07:39):
prototype out quickly. Elixer enables that if you are making
a product that's going to stick around long term, you
want that product to be reliable, easily maintainable. Elixer has
some really great strengths there as well, and so kind
of focusing in on those things and the fact that
you are enabling your developers to focus on what matters
(08:01):
rather than the minutia of, you know, just getting the
app running in the first place. That's what really sells
it to Fox, and especially to Fox like the kind
of people who pay for Plorosite for their corporate employees.
Speaker 1 (08:14):
It's interesting that you say that because recently we had
an episode where we talked about the Leik Sir as
a general purpose language and why people might want to
pick it and it's not only this niche thing, and
that was like a lot of the talking points we
ended up with, like the kid's easy to get started with,
it's easy to hit the ground running, but it also
doesn't have these foot guns other languages might have, way
(08:36):
where you end up in a situation where you have
this big ball of mud and it's unmintainable and then
buggy like. Of course, it can also happen in Elixir
but my impression is that there are certain design decisions
specifically made to avoid some of these issues with like
fast growing code bases.
Speaker 3 (08:54):
So that's right, and you know, to kind of put
even more emphasis on one particular piece of it, I
really wanted to spend some time in the course talking
about the difference between trying to avoid errors altogether and
recovering from them when they eventually happen, because the bottom
line is, if you have alix air hosted on no
(09:15):
matter where it's hosted, something's going to go down sometime.
There's nothing you can do in your code to avoid
the node going down and your app being offline. And
if you have your app as part of this distributed
system that's relying on one another, Elixer can handle that
a lot better than other languages can. And bottom line
is you're going to have less downtime because of that.
(09:37):
And just that focus of not trying to try catch
every little thing that could possibly go wrong and instead
dealing with the consequences and restarting processes when they do
eventually happen. That's really powerful.
Speaker 1 (09:49):
Yeah, basically accepting ruinity of like things are going to
break at one point or another. Nothing is perfect. I'm curious,
do you also talk in your course about like Elixir
and Berlin, because I mean a lot of these ideas
we just talked about come originally from Berlin. So how
does that stick up in the course.
Speaker 3 (10:07):
Yes, definitely. So the first module the course is all
about what elixir inherits from Arline, because a lot of
folks will look at elixer you know, this language that
first commits in twenty eleven, first releases in twenty twelve.
They think this is a shiny new technology. It's probably
just going to be a blip on the radar for
a little bit and then disappear like many technologies do.
(10:29):
But what you realize those roots in Erline, and if
you really understand what it's coming from, then you start
to realize that that's not the full story. This is
actually a technology that has really strong foundations that are
well tested and proven in production, and that can really
flip a switch when you're, you know, an engineering leader
that is trying to decide whether this is a good
technology to invest in.
Speaker 1 (10:51):
Did you already have some kind of feedback from especially
like technology leaders and like more from your B t
B set with people, said O kivis course like us
choose Elixir, So any success stories, basically.
Speaker 3 (11:03):
I wish nothing yet. I haven't received much feedback on
the course overall yet, but hopefully someday that story will
play out, you know, whether because of this course or
because of any of the other great content out there.
I would love to hear that story of You know,
we were skeptical at first, but because of the great
community and the content that was available all over the Internet,
we made a decision and we don't regret it.
Speaker 1 (11:25):
So you've heard your folks like recommend this course to
your manager and maybe things are going to pan out.
Speaker 5 (11:31):
I can dream, well if things actually do pan out,
do you have anything next plant?
Speaker 1 (11:36):
Yeah?
Speaker 3 (11:36):
So I would love to see more content about Elixir
and Erling honestly on the plural site platform because it
is in some situations it provides a sort of legitimacy
to the type of types of companies that buy plural
Site and use it to skill up their employees. If
they don't see a language represented or represented, well, then
(11:59):
they're going to consider it to be a niche language,
just bottom line. So I would love to see more
Elixer content sometime this week. There will be a new
course on a elixer called Architecting Elixir Applications with OTP.
That's sort of like that next level up. We have
some great getting started content as well, introducing you to
the syntax and everything like that. I would love to
(12:20):
see more, and hopefully we can also get some content
on Erling as well, because I know plenty of companies
already have erlang in production and they may struggle to
get folks trained in it and up and ready to
add new features to it in the long run.
Speaker 2 (12:37):
Yeah, it's true. I do remember like some interesting companies.
I think there was some insurance company or something that
put things into arlaying and yeah, they did it like
on Super Bowl Day for have you heard the story?
You're laughing, so I'm curious. Maybe you heard about it.
I forgot what the company was, but it was really
crazy and probably wasn't that they did do this was
because they knew you could handle the traffic. And I
(12:59):
think it's launch day was a supable day, you know,
because when you do your super commercial, that's when you
get your traffic right. And so I have to see
if I can find the story. But it's pretty good,
but it's a Java shop and then they knew it
couldn't scale for this kind of stuff, so they did
earling and it just worked out like too.
Speaker 3 (13:15):
Well, that is a fantastic story and exactly the kind
of story I want to tell more of too, because
if this is a technology that you can turn to
and trust for those days, that's a great choice for
any day.
Speaker 1 (13:28):
So was there anything you like learned about Elixir or
early and you didn't know before while making the course?
So in any cool little discoveries which might or might
not have made it into the course.
Speaker 3 (13:39):
It was great to really think about again why why
I like the language and really consider that that's not
the reasons that folks choose a language for a business.
You know, it's not about a friendly syntax, it's not
about how nice the mixed tool is. Really those are
great things and that I would never discount them, but
(14:01):
the real decision for an engineering leader is something much
deeper than that, and speaking to that is difficult for
any technology. I think we as an industry have fallen
into certain ruts where we see other companies that are
using a technology, so we just assume that it's a
good choice for our business. And now that I've evaluated
(14:22):
that mindset and really thought through what if I were
a leader making the same choice. Looking at those same things,
it brought me, honestly, a lot of respect for why
companies use the languages they do, because it's tough to
make that decision, it really is. It's tough to go
out and put your reputation as a leader as a
(14:43):
company on the line and say we're going to back
this language. That's a tough decision to make as well.
Just looking at alixer overall and digging more into the
history of Erlang, it was really fun to see the
situations that Erlang originally were developed in. I had the
ten thousand foot view of this is why we created
the language, and these were the problems it was there
(15:04):
to tackle. But actually digging into sort of the early
iterations of Erlang and the runtime system and it, you know,
the phase in which it went through various different run
times and was developed from there, that was really interesting
and I highly recommend folks dig into that more because
if you understand not just what erlang is and what
it brings to Alixir, but where Erlang itself came from,
(15:26):
you can get a really nice view of the full
evolution of this technology that you're using every day, and
that can be really beneficial just to understand not only
where it came from, but probably where it's going.
Speaker 2 (15:37):
It's the most interesting part is like telephone swhich is
basically mirror services, which is what we expect, high availability
and lots of traffic spiking, all these kind of things.
Like when Twitter goes down, everybody flips because they have
nowhere to complain that something's down, right, this visious cycle, yeah,
or Facebook or whatever. But the funny thing is, of course,
(15:58):
let's not say that it's Earlan and Elixir are not
invulnerable to problems, right, So WhatsApp is probably one of
the most famous cases of highly scalable or laying services.
And it does go down because I remember because like
everything stops because I'm in Hong Kong and we always
use WhatsApp to always chat, and the other guys are
here in Europe, so I'm sure it's the same thing.
(16:19):
WhatsApp is like really integra to your life, and yeah,
it does go down like a couple times a year,
but in reality, like, yeah, it's if you think about
other websites and things that you maybe used, it's probably
a fraction of that. I don't know about you guys.
Think I also enjoy the hot code upgrades that we
have that ability, because so many times to go to
check my bank account and it says, oh, yeah, you know,
(16:40):
we're upgrading between now and five hours later, so please
check another time, So it's also super annoying.
Speaker 3 (16:47):
I think one of the big powers of this run
time is it does try to be resilient. As we
all know. It has this idea of restarting processes, but
I think when folks hear that, if they're coming from
another language, they may think, oh, the app restarts itself
if there's a problem, and that's not the full picture here.
(17:08):
The portion of the application that is restarted, if you've
structured your supervision tree correctly, is the smallest portion that
needs to be restarted. So if you're having an outage
in one area, in one node, in one portion of
your service, it may just be that part. And if
you can maintain uptime for everything else that's happening in
(17:30):
the runtime at the same time, that's really powerful, and
it's really difficult to sell that and to get that
to be understood. The folks who are evaluating the language
at times because you just hear, oh, it's good at
restarting processes. You're thinking, okay, it can restart its own
OS process when it crashes, and we call that resilience.
(17:51):
Communs can do that too, right, exactly exactly. Yeah.
Speaker 1 (17:56):
I think the interesting you're there is like, at least
my experience is that a lot of engineers and developers
who have a few years of experience know that things
can fail and are aware of that, and so we consider, okay,
now maybe this API request I have to retry that. Okay,
what if the database connection goes missing? And so there
(18:17):
are mechanisms and other languages also like to to to
patterns rather to do this where you say, okay, let's
do reach try based approach here. I think the interesting
thing about the beam specifically is that it has these
primitives like built in it is still design of like okay,
what does it mean to have something which needs to run,
which which can crash, which needs to restart? And from
(18:39):
that we have gen servers and supervision trees And yeah,
I guess it makes a lot of sense what you
said earlier, that it's really digging into where we're lying
at the bigs here. And the beam come from gives
you a new appreciation of like, Okay, what does it
actually mean to have a resilient system in place? And
I wonder, like what what did you use to learn that?
Is there any resources you reckoon, for example, like vivi
(19:01):
thesis written by Armstrong or what did you look into
to like get this this level of understanding you just mentioned.
Speaker 3 (19:09):
Joe Armstrong's thesis was definitely the place I went first,
because people recommend it and it is a great read.
There was also a later paper, I believe, just detailing
more of the history of earling in a more general sense,
and that was very helpful too, because it just gives
you that that view of you know, we see the
finished product and we know a bit where it came
(19:30):
from conceptually, but you know, it wasn't always this way.
It didn't always look like it does today, and seeing
that evolution over time was very helpful.
Speaker 2 (19:38):
I also want to say, I don't know if you
guys knew there on pastonal link to here, but you
mentioned about like, okay, you're just restarting a piece, but
there's also this thing. I think heart is the one.
I know I've heard of something, but I think hard
is the one where it keeps setting a heartbeat to
your app, and if your app actually did crash at
the top level, it'll actually restart your Earlin Release application,
(19:58):
which is so there there is a supervisor for it,
I believe, which is what this thing is. So if
you turn this on you can have that ability.
Speaker 1 (20:06):
That's interesting. I didn't know this existed.
Speaker 2 (20:09):
I read it somewhere and actually also, Aja, you also
remind me of another story that I talked about on
the show a while back. Sometimes restarting your application is
a problem. So I don't know if you heard this story,
but I know I think I'm nine percent sure. I
heard it from Francisco where he's had a client and
they had this system running for like twenty plus years
and they had to restart it because it was at
(20:31):
a point where you couldn't hot code upgrade anymore. They
had to upgrade the ERTs or something. It was just
like way too far out of date. And what actually
happened is that when they went to up when they
went to shut it down and turn it back on,
it wouldn't turn back on because there was a speck
of dust between the hardware readhead and the disk, and
(20:51):
it just couldn't read the disc because it never had
a readisk before because everything was in round, and so
restarting the system and rebooting it actually caused a bigger
part problem. And yeah, the CEO was also involved because
he was like, would you guys do it? You know,
we can't do anything, you know, and if you think
about it, this kind of issue would never come to
my mind, right, like whenever something doesn't worked, just we
(21:13):
started in this situation, even though it's an early application,
we're starting, it actually made things much worse because it
was outside of control. But still it's kind of a
little bit of what do you call the oxymoron or
something ironic? Right, it's ironic.
Speaker 1 (21:26):
Yeah, it's true.
Speaker 3 (21:28):
We are so used to whenever we have a problem
that old phrase, you know, have you tried turning it
off and on again? And if anything goes wrong with
this computer I'm on right now, it's a reboot to
start just the first thing you try. But that doesn't
work for many systems. And as we go into this
cloud native sort of way of doing things too, we
(21:49):
treat servers as cattle instead of pets, where we're just like, okay,
the server's acting up, then get rid of it, add
a new VM instead, and that's great for DevOps and
it allows folks to move quickly. It allows us to
not spend a lot of time diagnosing a certain class
of issues. But there are systems that need to stay
up and having a load balance or just sending traffic
(22:12):
between different servers that doesn't always work. And in those situations,
I love that erline can stay running for years at
a time without having to worry about these kinds of issues.
Speaker 1 (22:22):
To say, like, I hope I never have to deal
with like a system running for twenty years and then
they'll rebooting because of spec of dust on the reading head,
Like that's not a thing I want to deal with. Whoever, whoever,
I had to do that, like my deepest respect. Seriously,
it reminds me of another story.
Speaker 2 (22:38):
It's not really related to this, but there was a
guy I think this is Michael mend Maynard An he
say his name. He came to Hong Kong and he
was and he was there to talk about I forgot
what now. All I can remember is the story about
how every day at like two am or four am,
the networking would just stop right So it was like
a bunch of it was a big it's a very
(22:59):
large We talk about this before because you're shaking your
head like, yes, maybe I know that story, but continue, Okay,
did you listen to this story before or did I
tell this story before?
Speaker 1 (23:08):
And I think I put it to somewhere else.
Speaker 2 (23:09):
But so every day that the networking would stop at
four am, right, and they spent like weeks, I think,
trying to dep up what's going on like around four am.
That Well, what turns out, for some reason is that
when you got so it's a cashier, it's a big,
super big chain. I think I kind of know which
one it is, but I don't want to say because
he's not allowed to say. And he told us all this. Yeah, anyways,
(23:30):
and so obviously in the daytime, you're scanning customers and
the cashiers and everything are working, right, networkings go on,
this traffic going on, but at night there's no traffic, right,
there's very little of anything. And so what happens that
they have this networking configuration where when there's no traffic
and then all of a sudden there's traffic. It's like
a way to block maybe malicious stuff. And so the
(23:52):
firewall would just come up and it would just block everything.
And so every day at four am, because what happens
is that every day at six am or five am,
they'd be getting a phone call, get over here. We
can't do anything.
Speaker 1 (24:02):
We kept me up.
Speaker 2 (24:02):
Customers, people want to buy stuff, and that's you know,
it's a huge chain and these things are all network
so like could you imagine like trying to figure out
like what's going on? And you have to like because
when it's a firewall, right, you send a package and
it just gets strucked. Nothing comes back. So that's what
was happening, is that they couldn't even diagnose it because
you wouldn't eve get a pain or anything. So why
don't we talk about this?
Speaker 1 (24:22):
I don't know.
Speaker 2 (24:22):
But anyway, crazy to bug issues, right, I think is
where it came from.
Speaker 1 (24:26):
I actually like I was thinking we were going to
a different story of it, because there's a similar story
of like a person like this one server going down
like every time around like six pm ish, and they
like also to spend weeks on trying to track it down.
And at some point this guy set taped down in
this sort of a room like a beer and like
I Ca'm going to see what happens at six pm.
At six pm, like the cleaning person, person that comes
(24:48):
in and pulls out the socket, like black from the
socket plucks in like the vacuum cleaner. That's where the
downtime came from. Yeah, I'm not sure how we got here,
but like sometimes you have really these issues and where
things goes down, Things go down even in scenarios where
(25:09):
you really would never have imagined before that this might
be an tissue down the road. So, yeah, failure is
built into our systems. It's just the way it is.
So having a run time which really accepts that and
embraces that can make a lot of things easier.
Speaker 2 (25:23):
It's pretty There's quite a few companies are actually just
gonna say, it's quite a few companies that actually do
that part of their processes. They literally go to the
service right yank and stuff out as a development process
just for Alextra Earling. Sorry, Eric, that just popped in
the mind. I want to say before I forgot you. Sorry,
go back to what you're saying. The key would be
careless engineering. If anybody would want to want to look
(25:44):
it up them and may post the link of the show.
Speaker 5 (25:47):
I was curious if you know what the trouble trioting
process for the speck of Dust story was. Like, I
wonder how they got to that root cause analysis something
that must be fascinating how to do, but to that
spickuplust imagine I had to like crack open the hard
drive at some point.
Speaker 3 (26:04):
I love imagining the person standing in front of this
machine that's twenty years old, thinking, yeah, we can keep going.
It served us for twenty years. Let's just reboot it.
It'll it'll continue. That's a pretty significant amount of trust
in a system.
Speaker 2 (26:19):
Well, there's so many. Like I remember working in a
software vendor a couple of years ago, and I don't
remember exactly the story, but I think there was like
a VPN or something running off the Selearis system and
it was just a machine that just was sitting in
the corner for decades and they just just ran and
they never restarted it. And then it was kind of like,
what is this thing doing? And I kind of reminds
(26:40):
me that it's like sometimes you just run these systems
and they just run and you just don't touch them.
One of the first services I did for that company actually,
like everything it wasn't Erlang or Elixir. It was just Python,
but we used rabbit m Q to communicate everything, and
the ops team basically started basically chaos engineering for us.
They started just shutting down processes and seeing if things
(27:01):
are happening, and the queue flooded up, and then they'd
call me and they come fix it because they were like, well,
it never aired up before, so we don't know. We
didn't know it's still actually running. We thought it wasn't
actually running at all. So that's kind of like sometimes
things run too well and then you don't get the
recognition I find that. You know, maybe it's good to
actually kind of throw a couple of bugs in there
because people like it when you save the day. They
(27:22):
think you're an awesome engineer. When your stuff works and
nothing breaks, then they don't even know you exist.
Speaker 1 (27:27):
It's like, nothing is working, why are we paying you?
Everything is working? Why are we paying you? Basically that right, Yeah,
no matter what you do, you're in trouble. Okay, maybe
back back, I'm wondering, like, based on what you left
learned and then I'm sure there are things you discovered
alongside the way of doing this course. Is there anything
(27:49):
you'd like to change or is there like where you say, okay,
I can imagine like a follow up course building or
on top of what we have here. So it's a
well does the.
Speaker 3 (27:58):
Road lead working through Elixir? The big picture again focused
on both software folks and leaders as well. It was
obvious to me that the Elixir, elixir itself and the
Earling run time have a lot of value. It may
not be immediately obvious how to capture that value, and
so I really wanted to follow up with some sort
(28:18):
of architecture related course to help you actually access all
of the great things about the runtime, actually use OTP
to its full potential to give you the great things
that we promise that you can get out of it.
And so I worked on a course called Architecting Elixir
Applications with OTP that seemed like a really important follow
up from that, I realized that if you really want
(28:42):
to get all the value from that architecture course, you
need to understand testing a lot better than even I
do today. And so I'm hoping that we can get
a little more content on testing. There's a great new
book out testing Elixir. The ideas of property based testing
as well really important. I think if we can get
more broad based understanding of not just what they are
(29:03):
and how to do them, but why they make a
difference in the long run to your business. I think
that's really important because if we can tie all of
that knowledge and all of those capabilities back to business value,
that's how we get Elixir to be adopted by more companies.
Speaker 1 (29:19):
It's kind of said that Adi isn't here, right because
if I'm remember correctly, some of his colleagues have written
testing Elixir, so he probably would have something to say, yeah, well,
here we are. Okay. I think things I can see.
I can already see how how that might be useful
to folks out there. I think one maybe a difficult
question for you, why should I, for example, choose ALIXI
(29:39):
to a big picture compared to maybe some other courses
out there. I think there's even as a course from
Bruce Tait. Also, I didn't quite find it while I
was googling, but there are already like interactive courses to
learn Elixir. So I mean, I see the appeal of
having this leadership based thing, but as if I'm just
a quotes a developer, why would I choose a a
(30:00):
big picture of it? Maybe some other courses out there,
or why should I maybe then go to other courses
if it's a better choice.
Speaker 3 (30:06):
Yeah, so I'm going to be a little do the
opposite of what I probably should do here. You know,
if you have a great course that you have access
to take it and share it, that's the main thing.
If you don't have access to plural Site, your company
hasn't paid for it, you don't have an account, then
obviously Elixir the big picture isn't going to do much
for you. What I really wanted to do by even
(30:28):
creating this course in the first place was not necessarily
create the best piece of content ever, because there's great
content out there and I could never hold a candle
to Bruce Tape or anything that he's created. But the
folks who already have access to plural Site, the folks
who use plural Site as a way to decide whether
a technology is something that they can train their people on,
(30:51):
that's who I was really targeting. And I think there's
other things we can do as a community to help
those folks out, because whether we realize it or not, folks,
these are very differ heuristic to determine the legitimacy of
a language than what we use as technologists. We try
a language, we build a project in it, we see
how it feels, we see how productive we are, and
(31:12):
those are great ways to determine if it's something we
want to build our next project with. But many companies
don't necessarily care about those things. They're wondering how quickly
is this product going to get off the ground, how
quickly are we going to get the return on our investment,
how likely are we going to be able to hire
for it, things like that, and they use things like
(31:33):
the presence of learning content on their platform of choice
as part of that heuristic. They use things like a
language's popularity on a language index, or how many hits
they get when they search for it on LinkedIn as
heuristics for whether this is a good choice for them.
Whether we agree with that or not, it does happen,
(31:53):
and so there are things we can do. Putting content
in new places always helps. Going on LinkedIn and doing
things like endorsing one another for elixir as a skill.
It seems like such a small thing, and I know
many technologists, including myself, really don't spend much time on LinkedIn,
but that data is used in places people do look
(32:15):
at it to think about whether this is a good
technology choice. So I think we can do more as
a community there to help these companies see that it's
a good choice for their next project.
Speaker 1 (32:27):
They basically reach outside of our bubble, right because I mean,
of course, as technologists we live inside of our bubble,
and maybe LinkedIn is not that big of a part
of that. So yeah, I can I can see where
you're coming from, and I can see like how you
identify this niche of like having the leaders and maybe
producing content for these people and explaining to them might
(32:49):
be great. So yeah, like that's some interesting thoughts there
for sure. I mean, maybe I'll just go on linked
the next and endorse some of my colleagues for elix knowledge.
Speaker 3 (32:58):
I recommend it, I really do. And other things that
you can do too, upvoting things on stack overflow if
there's a stack overflow question related to Alixer that helped
you upvote the question and the answer. To make sure
that those any questions that you ask are properly tagged
so we can track these things. These are little bits
of digital exhaust that companies collect in order to determine
(33:21):
how popular a language really is, and unfortunately I don't
think Elixer is well represented in those things. I think
our community is a lot bigger than our data makes
us look. So if you have an opportunity, go for it,
like go upvote things, go indoorse things like that can
really help.
Speaker 1 (33:38):
Yeah. I remember having discussions around this, so people said, Okay,
elix is not that popular onsa overflow if you look,
because a lot of what's happening in the community, and
especially questions and discussion have mo one elixa forum and
like that forum is like super active. I mean I
look into it basically daily, but there's always something happening
over there. So like these traditional platform form like stack overflow,
(34:01):
is actually maybe not as much activity on there as
you might guess in terms of how many people are
actually using elixidy today. What I really like to see
wasn't the last stack overflow survey that Alixo was the
third highest paying language. I think, so it was really
our fifth highest paying language. So that was nice to
see the finally some recognition of our of our language
(34:24):
and our platform of choice in these more traditional air
quotes sources of information.
Speaker 3 (34:30):
Yeah, if you see a developer survey like the stack
Overflow Developer survey. Please take it because people will use
that data for expanding the community.
Speaker 1 (34:39):
Okay, Ellen, Eric, do you have any more questions for
AJ otherwise that yeah, okay, otherwise I'll probably go to
picks now. And so Alan, do you want to start
off with picks this week?
Speaker 2 (34:52):
Yeah, so I can share. I definitely pick the YouTube
video I sent earlier about the so how erlang saved
this company during the Super Bowl. That's a pretty good one.
Also the other one too. So I recently started picking
up this book called Zero to prod. It is a
Rust book, of course, you guys know I'm pretty much
trying to get more and more to Rust.
Speaker 3 (35:14):
Well.
Speaker 2 (35:14):
Actually, what I like about this book is it really
takes you from beginning to like production with Rust. And
the other thing too is they do things that I
think most books don't teach you, which is actually how
to build something really from scratch and not just like
creating the services and everything, but also how to add
in things like testing. Not a lot of books add
in testing. But there's also a telemetry part too, which
(35:38):
is I never hear about telemetry any other language except
for Alixer. So when I heard that I'm like, Wow,
this is really interesting because not a lot of books,
you know, not a lot of people teach telemetry and
programming languages. So I think this book is something that
is pretty cool, and I finally started reading it today.
I'm pretty happy with this so far because I've really
taking it from the beginning and kind of saying, Okay,
(35:58):
we want to build this thing. We know that need
to have like a linter, what's a linter? And does
this we need to have like a CI server. Here's
some how you set the c I server. Really like
from beginning to end, and really like the professional route
right linters and having a CI and like I said,
telemetry eventually, those things I think are just not talked
about in most books when they're teaching you, like a language.
(36:19):
So that's why I think this is a pretty interesting
book for people who want to pick up rest and
like get the whole entire production experience.
Speaker 1 (36:25):
Nice Eric, What would be your picks? One pick?
Speaker 5 (36:28):
Which is the holiday book that I've been reading the
last two weeks. It's completely off topic. It's called a
hardcore zn punk Rock, Monster Movies and the Truth About Reality,
and it's a hilarious read about a guy who so
love as a punk rocker. Then how is it now
made it to Japan working for a company that is
making monster movies where you have he as Cyru's Rex
(36:51):
that is tearing down Tokyo and stuff like this, and
he ends up becoming a Buddhist monk, getting to the
Zemen Buddhism and meditation and a lot of the elements
of Buddhism. And it's been the various read with all
of the anecdotes that he shares, there's been made me
left out loud several times, but most crucially it's been
give you some insights into Buddhism, which has been like
(37:12):
a bit of a dish interest of mine for a
long time. I had this book on my bookshelf for
several years now and so finally time.
Speaker 1 (37:19):
To read it.
Speaker 5 (37:20):
And it's been really an enjoyable experience. So I hope
someone else finds that book useful.
Speaker 1 (37:26):
Sounds interesting. Now I have two more books to it
to my never ending to read list. Thanks. Okay a J.
Do you have any picks for us? Can be anything
like as you see, we have all kinds of picks.
Speaker 2 (37:39):
This week, there's no more books, right, no more books please?
Speaker 3 (37:42):
Right, can't add any to the list this week, so
sure I have two picks for you. First is more abstract.
I guess one of the places where you can run
into trouble with Elixer and where it can be frustrating
as a community, is where Elixir combines with other languages.
You know, the interrupt between things. So if you're one
of those rare people who knows Elixir and Swift, for example,
(38:07):
I'll drop a link to a project that I've been
working on to help make it easier to have an
iOS app, for example, work directly with absinth. That's just
one example of we need more projects that allow Elixer
to interrupt with other languages other things around technology. And second,
i'll just throw out that I believe it's September eighteenth.
(38:28):
We start a new season of the First Tech Challenge.
This is a program for middle and high school students
in robotics. They get a new challenge every year. They
build robots to meet that challenge. They compete against one another.
It's a really cool thing. So if you, as a technologist,
are in a place where this challenge takes place, there
are teams nearby you. I highly recommend go out volunteer
(38:52):
mentor teams help them learn how to program. This is
something you can really do to help inspire the next
generation of folks who are entering programming and engineering.
Speaker 1 (39:02):
Then they show him more awesome elixir can be, right,
so we create our next generation of Alixity developers. That's right. Okay,
I will make it short and sweet. I will pick
a book. Sorry, Ellen, but it's a very short read,
and I wouldn't be surprised if you already read it.
It's Earlying and Anger. It's actually a free ebook, and
it's I think it's below one hundred pages, and it
(39:25):
talks about like what can really go wrong when running
software on the Beam and like what people experience when
running Earling in Anger, so when things break, and how
to how to basically deal with beam instance running which
might not behave as you expected, and what the Beam
then gives you for tooling to deal with this kind
(39:45):
of situation. So it's very interesting read if you're like
interested in like operations and really want to to see, Okay,
how how can the beam be pushed to its limits
and what can go wrong? And it said it's a
fairly short read, so not another three hundred side book
to add to your never ending reading this. Okay, folks,
then unless you have anything else to add. No, everybody
(40:08):
is shaking their head. So I wish you a great
week and tune in next time when we have an
episode of Felix Index
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.