October 23, 2024 • 48 mins
We discuss how to learn and love Elixir and other functional languages, the importance of people and community in learning, the perfect autumnal cocktail and so much more with Randall Thomas—drinker, hacker and bon vivant! Panel
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Links
- Let Over Lambda—50 Years of Lisp
- Haskell Programming from First Principles
- WHAT I WISH I KNEW WHEN LEARNING HASKELL
- Programming Elixir
Picks
- Bruce - https://grox.io
- Alex - Erlang in Anger
- Alex - https://github.com/happi/theBeamBook
- Steven - 49 inch ultra wide monitor
- Randall - https://haskellbook.com/, https://keminglabs.com/finda
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, and welcome to this week's episode of Alexa Mix.
We are joined by, as ever, our fabulous panel of posts.
We have Alex Kotman, Hey Alex. We've got Bruce t Hi. Everybody,
Hello Bruce. We've got Steven Nunyez.
Speaker 2 (00:19):
Hello.
Speaker 1 (00:19):
I am SOPHIEA Benedetto and we are joined today by
Randall Thomas, who has many potential introductions that I may
choose from. So I'm going to go with my favorite two,
which is the first. One's a little more informative CTO
at a tech incubator called Geometer, as well as a
thanks for Hacker and vonn Dufon, and I'm sure we'll
be excited to dig into any of those topics. Welcome Randall, Oh,
(00:40):
thank you so much for having me. Yeah, we're so
thrilled you could be here. We've got so many great
things to dig into today. But one of the things
that we often ask us when they first come on
is tell us a little bit about how you got
into the Elixir community in the first place.
Speaker 2 (00:52):
Strangely enough, the short version is I've been around the
Rube community for a long time and one day looked
around in all the people that I knew from the
old Rubey community, you weren't there anymore, and I figured
out where they went, and it turns out that they
all showed up inn Elixir. In fact, it was kind
of accidental. I went to I think the first Elixir
CONFI I had gone to, I think was in twenty
eighteen or twenty seventeen, and I showed up there and
(01:14):
I literally just walked around. I'm like, wait, so that's
why you weren't at Ruby KMF. Oh wait, so you're here.
What are you doing here? So I thought I would
know no one, and it turned out that I knew everybody.
So all the smart people that I sort of cocktailed
on and Ruby ended up in Elixir. So I figured
they're way smarter than me. I should go follow them
see what they're doing. So it's kind of it.
Speaker 1 (01:34):
That's really as good a reason as any, and kind
of similar to how I started learning Alixir. It's like,
I don't know, maybe four or five years ago, one day,
maybe five five thirty, and Steven says, hey, you want
to see something cool, And that was kind of like
theentre into the wide world of alexir. So following the
smart people is the way to go.
Speaker 2 (01:51):
There was a funny thing. I'm pretty sure this is
actually true, right, but like all apocryphal stories, because it
happened in Barcelona. There was Baruko, Barcelon and Ruby KMF
and at the time we were giving this talk on
Ruby motion. If you remember, there was this big kerfuffle
about hey man, you're gonna be able to write iOS
apps in Ruby. And it was actually a really really
great idea, I kind of think a little ahead of
(02:12):
its time. And I think actually at that conference somebody
was talking about, oh, yeah, you heard that somebody's trying
to build a Ruby for Elixir or for Erlang, and
I'm just like, yeah, good luck with that. I literally
thought it was like because I was thinking about, like
I tried learning Arlang once when the prag Prague released
that first book from Joe on Arlang, and I remember
(02:34):
getting into it and I remember thinking I'm like, okay,
I'll put this somewhere right above pearl. I recant that
statement now, but at the time I was thinking to myself, like,
there's no way you're ever going to get Rubis to
learn the syntax, because you know, the obsession with beauty
and elegance and expressiveness and everything else.
Speaker 3 (02:49):
Yeah, and it's really funny that Jose kind of put
it onto the Ruby syntax, not as this great statement
of let's bring all the Ruby community over right. It
was more like, okay, one last thing, right, no way yet,
and then then he kind of layers on these these
beautiful abstractions. But yeah, it seems like we were kind
of circling to each other for a long time randal
(03:10):
before for the elexur community that you know, the idea
that that you were EngineYard and you know, us to
point some stuff there, and you were kind of kind
of involved from from the very beginning, and kind of
we were. We were just just outside of each other's
or bit and didn't really meet until the Garroxio course.
Speaker 2 (03:28):
Yeah, which is that's actually what I like to say is,
you know, I do a lot to to Bruce for
for really getting involved in the electric community. I don't
actually did you just advertise that course online? Was that
what it was? Yeah?
Speaker 3 (03:41):
I mean we literally just threw a couple of tweets
up just to see if there was a test market,
to test the market, and we said we would need
more people to start the class, and then you were
two signed up. But one was you right, and the
other one was Patrick Thompson, who's already writing you know,
articles and pull requests for or Phoenix or Phoenix Lide you.
(04:02):
But that was kind of a cool moment because we
had to decide whether to do the class or not,
and at that point we decided to go against the
grain of traditional courses to it's kind a you know,
like a smaller Midge school right where everybody could and
then that's that's where we kind of decided to flip
the keyboard, and you know, the rest is history.
Speaker 2 (04:22):
Yeah, I was a pretty New York or program before
I got to spend a week in pairing with Bruce,
at least for a elixir, which is I think that's
something that we take for granted. You know, if you
come from procedural languages, it's really easy. If you know C,
you can kind of learn C plus plus even though
it might not be the right idioms, but it's the bridges.
If you know job, you can kind of get into
go and like. But learning how to actually think in
(04:43):
elixir and break down the problem differently or thing functionally
is actually one of the big barrier sentry I think
people have and seeing it and doing it with other
people and going through that evolution was really helped me
but actually really leveled up my elixir.
Speaker 3 (04:55):
Yeah, so I don't I don't take any credit at
all for any you're doing an elixir uh by the way,
but I do think that there's a moment where your
revolution is like a lot of a lot of other
people's like mine as well. Right, it's why are the
cool kids leaving the room? What do they see and
how do I how do I make the mini that
(05:16):
mental shift to do the things that that good programmers do.
And you know that's what we were all able to go
through together in that class, you and Patrick and I.
Speaker 2 (05:26):
Yeah, well I I still think it's one of the
greatest things that where I recommend it. In fact, actually,
if you remember, one of the first things I did
at CTO was I got a subscription. I think I
need you write a feature so I could get my
team on Groxia. So shameless plug for Bruce's like learning
platform Groxio. It's great to learn alixer in a browser.
And I've actually used it for other people and they're like, well,
what do you think about Elixer. I'm like, I don't know.
(05:47):
Go try it out in a browser, like most people
are just blown away that'll run in a browser anyway.
So it really doesn't not in a browser, it doesn't.
But like those types of abstractions, it's not important. It's
like it's like everybody else. You know, first one's free, Amen,
first one's free.
Speaker 3 (06:02):
Yeah. But so as your Elixir Generney journey has kind
of started off, you didn't kind of peck around the
edges like most people did.
Speaker 1 (06:12):
Right.
Speaker 3 (06:12):
It's you know, you went from kind of zero to sixty, right,
so you went from Okay, now I'm in the community
technic class to now I've got this incubator. Can you
tell us a little bit about what you're doing at Geometer?
Speaker 2 (06:25):
Yeah, So some people I used to work with they
started a tech incubator, like all good things, and then
COVID hit. The most interesting part of actually what we
were doing was we ended up pivoting towards doing COVID
response work, and a lot of the work we ended
up deploying for several states was actually built on Elixer interntline.
So we actually have data transformation platforms and pipelines. A fact,
(06:46):
we used Broadway for one of them. Two that are
currently supporting contact tracing in two states on the East coast,
so we learned a lot about both the scalability and functionality.
So just to give you an idea, they were caught
in batch world. Their best turnaround time started off at
twenty four hours, and then when they were really trying
to get up to speed, they could do it maybe
in six but there were a lot of errors and bugs.
(07:09):
We were actually able to in a week spike and
prototype something and then in about another week actually get
into deployment a solution that using Broadway and the inherent
sort of scalability of OTP, that turned the Literally we
were able to process the data faster than they could
get it to us. So we went from processing and
turning around all the COVID cases in about every couple
(07:30):
hours to one minute and thirty seconds was our first test,
and we got it down to sub one minute, and
they were doing it incrementally. We were actually able to
reprocess every single test, every single run, every single time,
which allowed us to do a different type of quality control,
which really matters for deduplication because a lot of the
issues that you run into with COVID testing are that
the lag between when people get tests and the test
(07:51):
results are reported. I mean that duplicates and false positives
are a real problem. So that was all done on
Elixir and earline, right, And that was one of those things.
By the way, we also wrote a telyphony shim that
actually did calliphony control, that did call control for connecting
calls to contact tracers, also done in arline, and both
of them, if I remember correctly, I might be making
(08:13):
this up a little bit, but both of them required
so few resources that they ran in like a container
inside of like an easy two medium, right. It was
just so ridiculously efficient that it was kind of kind
of sad, and we replaced a bunch of custom made
over this Lambda functions that were doing this that had
to do with somewhere aer prone. I think the Lamba
function loads were a couple hours, like fourteen or fifteen
(08:35):
hours to reload the entire universe of data just because
of some architectural decisions. But the short version is Alexra
was a big win because three people were able to
rebuild that system in like a week. So long week,
mind you, but it was really kind of impressive. That
was one of those really aha moments. When you can
think about Elixir and Arline and Beam are very different
and they provide almost like what people or devs think
(08:56):
of as superpowers.
Speaker 4 (08:57):
So I feel like I've lived the same exact story
of Lamb does being painful and terribly slow, and then
replacing it with an Elixir app and then it was,
you know, like a whole different world entirely.
Speaker 5 (09:09):
Yeah.
Speaker 2 (09:10):
Actually, have you ever see that T shirt that says
go away, I'll replace you with a small shell script. Like,
you know, there's like this comic. I think it was
floating around for a while, but it's I almost feel
like the exact same thing. It's like almost any use
case where you're using a Lamb to function, you can
use Elixir and it just kind of works. It's kind
of funny.
Speaker 4 (09:27):
I mean, a Lamb is effected with like one gen
server and we can spawn like you know, thousands of
thousands of them, no problem.
Speaker 5 (09:33):
So are you guys saying this? And the question I
have is why isn't everyone doing this? Why is Elix
or not like the language that everyone builds all the things.
I mean, yeah, obviously it's the right soul for every
job there. That's a great question. It has nothing to
do with technology.
Speaker 2 (09:50):
I'd love to hear what you guys think, and then
I'll opine with my own slightly derisive, sarcastic view.
Speaker 3 (09:55):
On this and and the darkness behind them, right, one
language to rule them all, right, So it's it's interesting
I'm starting to play with with a lot of different
languages that that have different takes in the world. And
so the one that really opened my eyes was Pony
because it does so there are a lot of things
(10:15):
that Elixer does really well that that Pony just really
really sucks at, right, But one of the things that
Pony does well is it enforces compiler constraints that enforce
concurrency constraints, right, so incorrect programs won't compile. And so
you know that that pointed me to to the to
(10:37):
the idea that if you have to move a lot
of data around, you know, if you have a lot
of commutability, then then Elixor isn't it. And so I've
been spending a little bit of time in Julia this
year just kind of to flux the old math muscles.
Speaker 1 (10:52):
Right.
Speaker 3 (10:54):
So I was a math major in college or computer
science and math, and so one of the things that
that we were focused on was linear algebra I'm sorry,
like matrix matrix algebra. And that's kind of what machine
learning and machine modeling have have turned into, right. It's
it's you have these these massive systems of equations and
(11:16):
and algorithms to kind of slowly crank and provide more
and more precision. And we're starting to get into the
places where where you could take these these massive tables
and apply these differential equations to them. And Elixir is
just not good at that, and it is never going
to be good at that. It's good at kind of
(11:37):
the control. But yet, Yeah, I mean I think that
that there are a lot of good things that Elixer
is great at. It's funny, Randall, it's Elixer is great
at almost all the things that we were doing.
Speaker 6 (11:49):
Where you're at these early Ruby communities, right, the deployment,
the you know, the the babysit big fat relational database
with a web UI, you know, on and on.
Speaker 2 (12:00):
Yeah. No, so I don't know, what do you get?
Why do you guys think it's not winning? I mean,
I guess the other question is what's the definition of winning.
I don't think universal adoption of everything is the definition
of winning. I don't think it's for everyone. Not all
languages are for everyone.
Speaker 3 (12:15):
I have a question, how do we know it's not winning?
Speaker 2 (12:17):
Right?
Speaker 3 (12:18):
The language popularity? And so they make mistakes, right, Oh yeah,
didn't they?
Speaker 2 (12:22):
Actually what was it? There's something that they included, like crystal,
that's what it was, right, And they ended up playing
like new.
Speaker 3 (12:29):
Age chygramming crystals, which is either a programming model or
a great way to have your New Age crystals learn
as you get more enlightened every day, I.
Speaker 2 (12:42):
Have to look into that. So no, So I think
there are lots of things. It's really funny. So one
of the things I learned from being a rubyist early on,
and at the time I got into Ruby, I was
actually an independent consultant and I was all in dot net,
like I had actually started a long time ago. System
five released three, that's how old I am. But I
had gotten into that net because that's where all the
(13:03):
consulting money was. So that was C plus plus microsup
foundation classes all that crap, and the learning Aha moment
for me is I had to take some visual basic
programmers and try and teach them C sharp and they
failed miserably, Like there was no way to teach them
the basics of classes, and they just hadn't learned any
of that stuff, and we had to deliver an ETL system.
And Blake Miserini at the time he's like, hey, man,
(13:24):
I know you like Pearl, but I've got something way
better than Pearl. And I apologize for all the Pearl
I ever wrote. I think we all need to do that.
But he said, I got something way better than Pearl.
It's this Ruby thing and like whatever. So I played
around with it for a week and I'm like, huh,
this is pretty neat, and I'm pretty sure at the
time I actually had to go to like a bookstore
and find the Ruby book, like an actual print version
(13:45):
of the book. This was, you know, so like he
had to like run around to borders and whatever and
try and find a copy of Dave Thomas's book. And
I did over the weekend, and then I tried it
with these guys on one day and then I had
them doing advanced string processing and classes. They just got
it and rocked it. And that was the moment I
knew that, like, oh yeah, that's where we need to go,
(14:09):
and so I literally just stopped doing Dottin had stuff
and started doing all in on Ruby and Erlin and Elixir.
And I actually, when I say that earling Elixir Beam,
I actually really like to separate those things because I
think it's important that you don't mix them or blend them,
like there are different things and that you're getting a
lot there. I think it has that same feeling as
early adoption for Ruby. Like literally when we started doing
(14:32):
Ruby work, we had this other company called Quality Humans
where we were all doing rails apps and everybody thought
that we were crazy. You're like, I don't know this
rails thing. I don't know. It seems pretty risky, Like
only do guys in Chicago are doing it?
Speaker 1 (14:45):
Yeah.
Speaker 3 (14:45):
I mean I think that very often we as a
programming community have to take a step back to take
a step forward, right, And I think that that's one
of the things that would be provided, right. So it
was a huge step forward in a lot of ways, right,
first in the idea that programming language should be intuitive
and fun. Second in that that you didn't have to specify,
(15:07):
it wasn't kind of this this really tedious artificial typing model.
And third, we didn't have these really tedious and artificial
configurations that were you know, XML that was explicit for everything,
with no defaults. All those things were really important for Ruby,
and it seems like by taking that step back to
(15:30):
reset the kind of the bar on for application developers
on the productivity of application developers. You know, we got
a lot of the you know, the deployments, you know, immutability,
a lot of a lot of things wrong, but there
was a whole lot that was right about Ruby that
liks Or learned from.
Speaker 2 (15:50):
Yeah. Good.
Speaker 1 (15:52):
I like that you mentioned productivity, Bruce, because there's something
that I absolutely feel is true of Alexa and Phoenix.
And then kind of back to what you were saying, Randall,
when you were trying to, you know, move some folks
into kind of this realm of like object oriented and
when you found Ruby and kind of brought that to them,
that people were able to grack it and learn it
and be productive in it relatively quickly. And that's absolutely
true of Alixir. It's absolutely true of Phoenix, and not
(16:14):
just because of you know, Alixir's language features, in the
fact that, similarly to Ruby, no, it is eloquent and
easy to reason about. But I think there's so many
sort of eco Elixir ecosystem features that allow developers and
whole teams to be really highly productive. And I think
that's why I'm not at all surprised to hear how
Alexir and erlang has allowed you guys to solve these
really big scale problems for like COVID contact tracing. It
(16:37):
reminds me a bit of a talk that was one
of the keynotes at Alexa kronk EEO this year, which
will hopefully be out soon, about some folks in Kenya
who are using Elixir to develop a new like nine
to one one emergency contact system around the country. And
it's just it's kind of the perfect combination of like
scale and concurrency and fault tolerance, but also productivity for
actual humans. And so I'd definitely be curious to hear,
(16:59):
you know, from you and with your experiences lately with
some of these COVID projects, like sounds of you guys
spum this up really fast, like a week later you
had these working prototypes. So like, what is it about
alixer specifically or this ecosystem specifically that let you guys
do that so quickly?
Speaker 2 (17:14):
So I'm going to give you the first one in
no particular order, but the first one that pops to
mind is people. So it's a really bizarre thing that
I found is that people who are looking for those
exact things that you mentioned, like people for whom tools matter,
like productivity matters. Like this is not to poopoo or
denegrate people who don't choose that, but there are some
people who are like approach things that it's kind of
like a craftsman, and some people who approach it it's
(17:35):
just like this is my job. But there are literally
people who go out and try and learn more because
they want better tools, they want a better experience, like
all those things holistically matter to them. And I find
people who gravitate to the elixir ecosystem generally speaking, care
about those things and as a result it ironically it
makes them much better problem solvers, Like they literally care
about the solution and the elegance solution on I think
(17:57):
Buckminster Fuller had that statement. I might be misattributing the quote,
but it's like, first I start with a solution, but
if at the end it is an elegant, I know
that I haven't solved it in the best way. It's
kind of that's kind of the gist of it. So
we actually because we had people who had experienced in elixir,
they were really good at solving problems. Then the other
thing that really works out is that beam Erling and
(18:17):
Elixer provide great abstractions, Like I really love the fact
that you get to pick to the right level of
abstraction for your problem, and if you need to go
more granular, you can't. If you don't have to go
more granular, no need. Like I wrote C plus plus
for a long time, probably professionally for the better part
of almost eight or nine years. And one of the
(18:38):
problems I always I didn't realize at the time because
like I started off an assembler and then everything looked
better than assembler was that C plus plus forces you
to solve every abstraction from the ground up, like almost
invariably you're just starting it's like, oh yeah, so let's
talk about how you're going to pay out the memory
for your class, write another class. Guess what, now you're
going to do the exact same thing. Let's talk about
the copy se antics for your class. Let's top about
(19:01):
like all of these things which really have nothing to
do with solving the problem, are the majority of the
lift that you actually have to do. And the funny
thing is we didn't really think about parallelization. We didn't
think about memory usage, we didn't think about cputtilization. We
just really thought about, well, we have to do the
same thing over and over and over again. Well, how
(19:21):
do we solve it in the small we do this?
Oh well, what do we need to do to paralyze it?
What's this broadway thing? Okay, hey, look this gives us
some like composible data pipelines. Well that works really well? Great, Okay,
I guess it all works. How fast is it? I
don't know. Let's look at it. Oh crap, did it break?
Oh no, it finished? Weird? Okay, I guess we solved
the problem. But it felt like a happy accident. And
(19:43):
that's one of the things I really love about it. Like,
so like a perfect example, the first time you run
live you, it feels like a happy accident.
Speaker 1 (19:48):
You're like totally You're like, oh, okay, I guess that's it.
It just works. And I feel like I've had that
experience so much, not just a Live you, but definitely
very notably with Live you, but so often you're like, huh, okay,
I have to do this thing. I wonder if I
just try you know, X, Y, and Z, and then
you know you're kind of off to the races. Yeah.
Speaker 2 (20:03):
Oh, Also, speaking of productivity, I actually really like the
fact that, specifically when you start talking about abstractions, I
like the fact that one of the principal ideas behind
both Elixir Earling Phoenix novel libraries is that we don't
hide them, we just express them, if that makes sense. Like,
there's no super uber magic. The magic is there for
you to understand and see, and it basically you can
(20:25):
deal with it and you can use it or you cannot.
But it's not trying to make something really magical happen.
Like I know it's fun to pick on JavaScript, but
like promises and JavaScript seem like a really good idea,
But I think we've all written some JavaScript where the
chain of promises goes down and on and on and on.
Speaker 1 (20:41):
I has no idea what you're talking about does. It's
not making at all. I'm curious how you feel that
compares to you know, people throw the phrase like rails
magic around a lot, and that's something that I know,
like Stephen and I encountered and teaching rails is when
you take students from the way that we had taught
the course back at Flatter and usually went from you know,
you're building like a web app with rep, then you Sinatra,
than you're using rails, and like the class would always
(21:03):
split almost fifty fifty. Like half the people would be
so thrilled to get to rails. Stuff would just click
for them. They would be so productive, and then the
other people would be frankly kind of pissed because they
wanted to know what the heck was going on under
the hood and weren't comfortable or happy with all of
these abstractions.
Speaker 2 (21:17):
So, you know, the funny thing about that is one
of the best I think what saved me from that
specific thing was one I was lucky enough to take
the advanced Ruby class that they taught, where I think
it was it was the pragsy I think Dave might
have actually taught it, and he specifically talked about eidenclasses
and unpacking. So and I think the first version of
(21:38):
rails I use was point nine or point eight. It was.
It was not long after his brand news, so you
had to understand how it worked because the stuff broke
all the time, right like, it had some really weird
behaviors and we actually used to have this. What we
would say is we want Ruby programmers, not rails programmers.
And the difference was whether or not you understood the abstractions.
And I think that's actually a different approach that people
(22:00):
take to learning things, And to me, that's the difference
between maybe being a craftsman just being a utilitarian, like
you need to understand those abstractions. And in fact, I
think somebody was mentioning something about, like, what would you
say about learning Elixir? What I wish I had done differently?
I think was one of the things we were talking about.
One of the things I always tell people is learn Elixir,
not Phoenix, right, because a lot of people get into
(22:22):
Ruby through rails, and so what they learn is rails,
and that's as deep as they go. And the problem
then becomes if you ever give them a ruby esque
or Ruby centric problem, they always see it through a
rail's lens, right, same thing with Elixir. I think it's
actually way it's far better to learn Elixir first, then
learn Phoenix, then learn Phoenix, and then try and figure
(22:43):
out what's going on, because if you learn elixer, you
see Phoenix and you're like, well, that makes perfect sense right, pipes,
got it, composable, got it? It makes there's nothing there's
nothing magical here. The abstractions are all just layered into
this particular problem. It's great, but if you only see Phoenix,
like I've done this with people. They want build a
web app, they go for Phoenix, they get everything working,
They're like, I have no idea what's going on here?
(23:04):
Like why do you keep returning this? Okay? Thing? Like?
Speaker 1 (23:06):
Or I think what you'll do then, too, is you'll
draw a lot of false equivalencies between Phoenix and rails.
And I think that that's something that I did a lot,
and you know, a lot of the ELIXA that I
wrote probably for like you know whatever. The first year
of my life is an electric developer was just a
mess because I was just trying to write Ruby and Elixir.
I think that's probably not uncommon.
Speaker 2 (23:25):
I really agree with you on that one. Like I
remember I said the same thing because when I moved
to C plus plus from C, I always said that
C programmers make the worst C plus plus programmers because
you're writing C and C plus plus. And the strange
thing is Elixir has both the blessing and the curse.
Of looking like Ruby. I have seen it. Like I
see people who are literally they're great rubyists. They get
(23:45):
into Elixir and like you look at the code and
you're like, you know that at variable doesn't do what
you think it does, Like that is not what you
think it is, right, But you can see them using
it like it's a Ruby, like you know, a class
little variable, and they're like, well, it's just class a variable, right,
Like no, no, no, no.
Speaker 3 (24:03):
It's really funny. I agree with both of you so much.
And what's funny is Sophie that that when I want
to learn to code things like an Elixer developer, would
I look for your articles? But anyway, neither here Northern
so render. One of the things that's that's cool about
the pivot that we made when you impactorate to that
(24:24):
first class of ours was that our OTP and Phoenix
courses have become a looser courses with a little OTP
and Phoenix mixed in.
Speaker 2 (24:34):
Right.
Speaker 3 (24:35):
It's that you know, we we we teach this model
of you know, constructor reducer transformer that I think that
we started to talk about in your class, but since
essence has become stronger, and we also teach this concept
of pipelind and with land and how to get between them.
But we also try to teach the concepts of how
(24:56):
do you learn, where do you find things like how
do you find the callbacks? Or behavior? What is a behavior?
All those kinds of things really really matter when when
you're taking the next step.
Speaker 2 (25:08):
She didn't even think about that. That's the other thing
that was really great about Elixir is the documentation is amazing, yeah, right.
Speaker 3 (25:13):
And that the documentation actually bleeds through all the way
from the documents on X to the documents on the
individual page for the project to get up to the
documentation and I e X, and all you have to
do is using to bring it all in and make
it all available.
Speaker 7 (25:31):
Yeah.
Speaker 2 (25:31):
In fact, actually I think in one of your other podcasts,
you guys mentioned something like the we're talking about Don't
Fear er Lang? Whose podcast was that.
Speaker 1 (25:39):
We've definitely had that conversation here. Yeah, it's Toime.
Speaker 2 (25:43):
Yeah.
Speaker 5 (25:43):
Yeah.
Speaker 2 (25:43):
So by the way, I totally met him for the
first time at a lone Star.
Speaker 1 (25:48):
Yeah.
Speaker 2 (25:49):
Yeah, actually, we totally We've got a chance to hang out.
I had no idea of like and like we just
met it. We just started talking mostly about food.
Speaker 3 (25:55):
Actually, he has the biggest surfer vibe of anybody I've
ever met.
Speaker 2 (25:59):
You know, No, he's a great guy. But I actually
I had heard his podcast on your podcast, his talking
on your podcast, and it was really funny because I
think we had some of the same stuff, like Sasag
Jerrek's talk on the soul of the Elixir ecosystem. I
actually just sent that to somebody. People were like, well,
why would you care? Like, why should I care about this?
I'm like, go, go watch this. If it resonates, come
If it doesn't, well, by all means, keep keep doing
(26:21):
what you're doing.
Speaker 4 (26:21):
Yeah, that's definitely the best introductory video if anybody wants
to know what the beam is and the value proposition
set on that video, and if they're not convinced in
an hour of listening to Sasha, then it's not for them.
Speaker 2 (26:32):
Yeah. Well, you know. One of the other funny things
is so I had this conversation with somebody else the
other day because we were talking about JavaScript's easy to
pick on listen, like all tools have their both pluses
and minuses. But what I was saying is they argument.
He's like, listen, javascripts got ubiquity, all these other things,
and I said, listen, you don't write JavaScript. He's like, well,
what do you mean. I'm like, okay, I'm going to
go in and I take your babble canfig and I'm just
(26:53):
going to start deleting some stuff. Tell me whether or
not this is going to work right. And I think
one of the things that nobody realizes is that none
of us actually write the languages we think we write.
We're writing like Elixir runs on the beam, right, it
uses Erling libraries, it uses a whole bunch of other things.
Java Closure, they run on JVM. Well, which JVM the
hot spot? Like the abstractions between us and the hardware
(27:17):
and what we're really doing in the libraries we're all calling.
It's actually one of the things which which drives me
nuts is that nobody really tries to understand how many
abstractions they're getting in between them and their solution. Same
thing with JavaScript. You don't actually write jobscript. You write
yes six, or you write yes six with reducers, or
you write I don't know. I'm a terrible jobscript programmer,
but I've tried. I've struggled for hours with my babble
(27:38):
jskinfigs and all the other stuff you're try and get
something to compile right because I had the wrong type
of aerofunction selected right. And it's one of the things
I really like about the entire Arling, Elixir and Beam
ecosystem is that it makes very transparent at what level
you're operating, whereas almost everybody else they tries to obfuscate it.
Well even see nobody uses CCE anymore, use clangor LVM right,
(28:00):
like think your sea code really doesn't actually the most
instances compile straight down anymore, not in the way you
think it does.
Speaker 4 (28:06):
Yeah, I've definitely seen that issue of JavaScript. I was
helping somebody during a consultancy and then we're using a
Sinkle eight in some AWS lambda, and somewhere deep in
the AWS doctor it's like, you can't use a Sinkle weight.
It may work, but you know the the LABDA may
terminate because the event loop doesn't know that it's still
busy or something like that. So you so then we
went through and switched everything over to promises and then
all of a sudden the thing just worked. So yeah,
(28:26):
JavaScript does not equal equal JavaScript at the time.
Speaker 3 (28:30):
Yeah, I've got Joe Armstrong's voice in my head saying
run to completion semantics.
Speaker 2 (28:36):
That's madness, yeah, right, like, well, so you know what,
it's the other thing that's really interesting, just language wise.
My big kick these days is is Haskell, and I
blame Actually, I bring Bruce because he introduced me to
Brooklyn Sealinka, and I now know that she's actually ord
of magnitude smarter than i'll ever be. And so if
she's doing Haskell, then it's it's upon me to incumbent
(28:58):
upon me to learn how of what she knows about
Askell and the Hascle people are right. Being a terrible
Hascal programmer has made me a much better everything else programmer. Right, So,
and what's interesting to me is that you want to
talk about some people who embrace commutability in terms of
what your language is going to do, like your prelude,
like the idea. It's like no, no, no, no, sorry,
(29:19):
let's start. It's not a pre compiler. You tell me
what this language should be doing, right now, go ahead,
Like it's it's kind of crazy how flexible Ascal is.
Speaker 3 (29:26):
Yeah, I have another thing in common with you, Randall,
that I am a terrible Haskell programmer.
Speaker 2 (29:32):
Well, I highly recommend everybody shouldtruggle with some Askell though,
because you want to talk about some magic and some
just understanding of what raw computation looks like.
Speaker 3 (29:42):
Yeah, I mean it's the foundation for everything that's important
to the list our community, right. So even some of
the things that we're doing with types, some of the
things that we're doing that we've always done with strains,
they're all kind of based on the irrity models. Some
of the things that we want to get into with
property based testing, some of the things that we do with,
for example, the formatter. Jose did this this talk I
(30:06):
think three or four years ago called John Hughes Driven Development,
which was cool because at that time we had John
Hughes at gig City Electure, and you know, it was
just a whole lot of fun talking to him about
how his inventions in the language, and he'd never cod
it before at the time, are making such a such
a hard impact on it. I mean, it was just
(30:27):
beaming the whole time.
Speaker 4 (30:28):
So, while this is an Alixra podcast, what Haskell learning
resources would you recommend?
Speaker 2 (30:32):
So? I like the Haskell book, like Haskell from first Principles.
I think it's called it's the Purple Book. Whatever, that's
out there. That's a really good one. There is another thing,
gosh what it was called Things I wish I had
known when I was learning Haskell. I can't remember who
wrote it. I've got it. I'm sure I have a
link to it because I have a running list of
an ord file of just Haskell resources. But what it
(30:54):
talks about is it you mean, Haskell is kind of
like what Elixir could have been had there not been
a good munity. And it's not a dang against the
Haschalo community. It's just that the Hascal community, like, depending
on how you get into it, it might kick you
immediately out of it. Like there are plenty of posts
where it's like, oh well, let's start with some category theory, right,
which is it's just kind of like imagine if if
(31:15):
you came into Erlang, or you came into the luxury
ecosystem and somebody said, oh, yeah, that's really great, so
let's talk about applicative functors and basic functional like do
you know do you know what a calculus is? Do
you know what a lamb of calculus is? No, Okay,
we're going to start with some proofs, right. That's probably
not why they came there. It might be what they
need to know, but that's not necessarily what you want
(31:35):
to hit them over the head with initially, but that
one broke down like all this sort of history that
you need to know to sort of get through, like
why is their stack? Why is there cabal? Like what's
the split between the two? Why are there two configurations?
Like what's this next thing everybody's talking about? Like there's
a lot of history there also some stuff what you
need to worry about, what you don't need to worry about.
We're going to remember that Stephen Dall maybe was the
(31:56):
guy who wrote it. Maybe that I'll do a burrito blog. Yeah, yeah,
that's it. Yeah, that's I think that's that's it. So
those are kind of my two. The other one is
like the look up the LSP, like figure out how
to support Haskel inside wherever your favorite editor is emacs.
I mean, but aside from that, you know, figure out
(32:16):
some good language support for and then just start typing it.
And also there's the gosh and I'd actually have to
go actually like dig up my actual list of Pascal
resources and tell you what it was. But those were
the actually I started with A Haskell book is what
I did because actually that's what Brooklyn told me to do, right, gotcha.
Speaker 4 (32:33):
So, after embarking on this Haskell journey, what your kind
of learnings that you bring back to your Eleixtra code
and how did your your style and way of approaching
problems and elixtur change, if at all?
Speaker 2 (32:44):
Actually, so a couple of things. One, I stopped getting fancy,
and I simplified a lot of things too. What it
made me appreciate was how a looker is the same,
but how it's different. I'm actually much happier doing recursive
and recursion now, Like I'm much more likely to reach
for a recursive style or a rehearsal style of a solution,
and also a mentatic composition and state passing composition, Like
(33:05):
there are a couple of patterns that I steal all
the time now, like pass state along with that. Before
I didn't realize that's exactly what you were doing in Eluxur.
But now to me it's explicit as opposed to being implicit. Yeah.
So mostly I think Haskell is the definition of just
because you can doesn't mean you should. Right, you can
by all means it won't stop you, but be careful.
You might be just taking him at your big toe
(33:26):
with a very very very large shotmun So. Yeah. So mostly,
like I said, I think what it made me understand
is which abstractions I'm using and be much more I guess,
for I'm much more explicit about the abstractions that I'm
choosing at each level now than whereas before I'm like, oh, yeah,
we do this because that's what Alexa code is supposed
to look like. Versus now I'm thinking, oh, this is
(33:48):
what it's supposed to do. It's still a terrible Hascal
programmer though, like terrible.
Speaker 4 (33:53):
Yeah, it's a programming language of course in graduate school
and we did a Hagh school lisp in prologue and that,
and it's like, I'm never doing functional programming ever again.
I don't see the utility at all. And like five
years later I went all in on the Leikster. So
I my foot in my mouth five years ago. But yeah,
it was it was definitely interesting. I'm sure if I
picked it up again today, I'd be just as terrible
at Haskell as I was, you know, ten years ago.
Speaker 2 (34:15):
So to be full credit to the Haskell community, they're
doing a much better job about being more welcoming. Oh
also exorcism. Exorcism has a great Haskell like exercises that
you can go look at and they actually have people
who give you feedback on your Haskell and it's cool
to see this other solutions from different styles, from people
who are kind of new to Haskell, like your solutions,
and people who have been working with Haskel for a
(34:36):
little bit, and then some other person who's like, yes,
I did this in exactly three characters, right, like there
is you can see sort of see the expressiveness of
the language. And that's actually I don't know, I'm kind
of a language nerd, so I like, like we were
early on diclosure at Thunderbolt Labs, we were early adopters
of closure. We went to the first college, and I
think closure had some similar problems with that. It's incredibly powerful,
(35:00):
but in the hands of people who know how to
use it, and there's not a lot of stuff to
get you from here's a lisp to here's being really
good with a lisp. Speaking of random weird language things,
let over lambda. If you ever just want to see
I know a lot of people don't write lisp, but
if you ever just want to see a book to
see where a lisp can take you. There is this
book called let over Lambda. I think you can only
get as like an epub or like a PDF download.
(35:22):
Maybe there's a print version two. I think actually, as
a functional programmer, it's just great to read what other
people who hit the advanced end of a language can do,
And specifically let over lambda is working on. He does
a lot of macros and list style macros. One of
the things I think that's underappreciated. I would like to
learn more about it, and I never really use it
(35:43):
is the macro facilities inside of a lukxir. Right, I'm
always looking for something to really do with it. But
macros are incredibly powerful, and a let over lambda was
one of those things where I saw it and I'm
just like, I got about fifty percent of what you're
writing here, But man, that looks just ridiculously overpowered to
be like, how do you manage to do this cool stuff?
Speaker 1 (36:04):
Oh?
Speaker 2 (36:05):
Also, I had learned racket last year too, which was
kind of cool, like looking at schemes, but that's pretty cool.
Speaker 4 (36:10):
Yeah, I'm on my second take of Christmas Chord's book
Metaprogramming and Elixir. I'll figure out one of these days
and I'll build right macros correctly.
Speaker 2 (36:19):
Yeah, it's a different level of reasoning.
Speaker 3 (36:21):
They're right string interpolation for code.
Speaker 4 (36:24):
So if you can go back in time and give
yourself some advice as you embark on the selector journey,
would what would some of those tidbits be aside from
this isn't Ruby, don't treat it like this Ruby.
Speaker 2 (36:34):
That would be one of the first ones actually find people, Right,
It's really weird. One of the things I think about.
One of the things I think worked for Ruby and
specifically where else they're different things, but I mean is
that they had a community of people who are always
willing to help. I think the community aspect of a
language is really underrated. So find other people who are
in a Elixir, who are kind of in that same boat,
and collectively start learning with them. That would be one
(36:55):
to learn Elixir before learning other things first. Right, Oh,
I think somewhere on the Elixir I f a Q
or someplace maybe on the Elixir lang website it says,
don't ask how do I What was it said? Don't
ask how do you do X? An elixir ask how
would I solve why? In Alixir like the idea of
don't just translate the idioms from whatever languages you already
(37:18):
know into alexir, actually go back and learn from first
principles what's going on. That's actually one of the things
I really like about the Dave Thomas book is that
it kind of abandons some of the oh look, look,
here's hello world, Look here's a for loop. Like if
you think about it, I don't know about you, but
for the past twenty years whatever, like our programming books
have pretty much been exactly the same, right because we
(37:39):
all have some sort of c art style functional like
programming background, so they'll pretty much look the same. They
teach you the same construct so you're really trying to
do if you're trying to figure out, like, oh, what's
the equivalent of a four loop and go got it? Like,
what's the equivalent of a if then else in c
sharp got it right? So I would say, actually learned
(38:00):
it from first principles. So strangely enough, you know, shameless plug.
I did give a talk on how to learn Elixir
at ALEXAKOMF and code Beam, And the other one is
I think take time because you're building up new cognitive structures.
I think people a lot of time do not realize
how much work it takes to get your brain to
start thinking functionally. Right, there is a lot there that
(38:21):
you have to unlearn.
Speaker 3 (38:23):
Syntax, concurrency, distribution, macros. Yeah, so that's a lot, right,
it's interesting. I'm going to give another shameless plug for Bruce.
I generally speaking, I recommend that they read the Elixir book,
and then, strangely, before they read the Phoenix book, I
recommend that they read Designing p Systems and Elixir from
(38:44):
Bruce's book because it teaches you the part of the
problem is if you're functioning like no pun intended, a
function sort of professional programmer, you normally have something you
got to do for your day job. Like it's not
most of us don't just have the luxury of learning
a language for no applicative also up unintended reason, So
you need to know how you build up an electric
(39:04):
system and the functional core stuff. What does it do
fun things with? What's the rest of the acronym, Well.
Speaker 1 (39:10):
There's.
Speaker 5 (39:12):
Work work we gotta yeah, yeah, yeah, do fun things.
Speaker 7 (39:17):
A big loud yeah, big workers that's right. Yeah, and
a beer yes, Stephen, thank you? Because I I personally
I think the Wilder Beast has a nice lowing sound.
Speaker 3 (39:30):
You know, yeah it does. But O'Riley had the cover.
Speaker 1 (39:35):
On the cover, so yeah.
Speaker 2 (39:37):
Oh interesting is that really? What happened is like O'Reilly
had like a Wilder Beast on something and they're like, no,
you may not put the wild of Beasts.
Speaker 3 (39:44):
Yeah. Yeah, So James had just come back from an
Africa trip, right, and so he loved the Wilder Beast
and and I mean, I've done all this marketing, but
now I mean it makes sense. Right. Beehives layers, different
cells ODP just really good time.
Speaker 2 (40:01):
It's true, and be a beehives are built in hexagons, right,
so that you have hecks already built.
Speaker 3 (40:06):
In ooh oh, well done there.
Speaker 2 (40:10):
Well they just dropped the mike.
Speaker 3 (40:11):
We got to be done.
Speaker 2 (40:14):
So yeah, so I recommend that they read that book
because it's important to understand how you build an layer
of system together, because it's very different than a elixir.
The functional core aspect is what most people miss. In fact,
we just had a team try to learn an elixir
that had been Rubius and jobs for people, and that's
exactly what they missed. And it was the first thing
they missed. They didn't have a functional core, and it
(40:34):
made everything else almost impossible.
Speaker 3 (40:36):
It's funny. In San Francisco, Brooklyn came up to me,
and I mean she's one of the people that I
practically idolized. I mean the Witchcraft Library, the strong resonance
with Haskell, with the things that she can make Macro's do.
She's just smarter than Oliver be. But she came up
to me and said, hey about your talk, and I'm saying, oh, crap,
(40:57):
here it comes. It was basically an outline of a
worker b books. She says, I agree with all of it.
And by the way, here's where this paper says the
same thing, except between this layer and this layer you
have an interface. And so it was really it was
like a high moment in my career. You know. It's
kind of said, yeah, you get this, and I said,
(41:17):
I didn't need to get it that way, but I'll
take it right.
Speaker 2 (41:20):
So, actually, if I remember hardly, so he didn't she
say that you didn't you had like a liberal arts background,
right that.
Speaker 1 (41:26):
Yeah, yeah, liberal arts background, history degree and then ended
up at the Flattery School, which was a software engineering
boot camp, and that kind of the rest was history
just fell in love with it.
Speaker 2 (41:39):
Yeah, so when you were thinking about learning things, didn't
you wish somebody had told you?
Speaker 1 (41:43):
That's a good question. I mean, that's one of the
things that I loved about learning Ruvie is that it
tells a story and you really have the emphasis on
the problem that you're trying to solve and how to
express it with code as opposed to needing to understand
kind of some of the low level principles. I feel
like that came later for me, and then I think
the thing that really hooked me and kind of got
(42:06):
me frankly obsessed with programming was and I really think
this is a feature of something that the Flattering School
really engenders and their teachers and offers to their students
is just just an absolute love of what you're doing,
just an excitement, a curiosity, like this total space of support.
That's something that I very much felt from my teachers
there and then learned, i think, in part, how to
give to my students subsequently, because then I went on
(42:29):
to teach there from Steven. I think Stephen just brings
this like absolute joy to whatever he's doing, and he
is as excited to show you something that he showed
you know, a thousand people for five years as he
is to show you something that he just figured out
for the first time ever. And it's really infectious. And
I think that, to me is really like the secret
ingredient to learning a new language and learning a new skill.
Speaker 3 (42:50):
Joy that's actually a stone cold ninja as a teacher.
I mean, so he started coming teaching to our childhood
licture group, and you know, just kind of I just
dropped them into our most advanced class and and disappeared
on them really and and they came back right And
now I'm saying, when you coming back, you don't have
to come back. You really don't have to come back.
(43:11):
Even has this it was really really cool. I paid them.
Speaker 2 (43:15):
I paid them all to say that you Musty's. That's
a great thing to do. It's like, especially nowadays with
gift cards, it's a really easy way to get a
great review. But actually, that's really funny. I think it's interesting.
One of the common threads I see about people is people.
I think what brings us to different languages and different
tools are the people. Which is a really weird thing
to say. Protect people, right like, but a lot of
(43:35):
why we choose the tools we have is if you
get a good person who introduces you to the right
sort of like to the joy of better tools and
better approaches and better thinking, you have this great experience
and that carries forward and they're I've you know, I've
met my more than my fair share of like abused programmers,
right Like, Hey, what happened? I got dumped into this project?
Nobody told me what to do. There was no cic D,
(43:57):
nobody told me about testing. Like, we don't have somebody
to tell you how fun and how joyant and joyful
programming can be. It can be a real be a
real slug. So could useeeven if you can actually like
convey that sort of excitement to people, that's super important
for the next generation of programmers.
Speaker 1 (44:13):
Yeah, well, I think we're all very grateful to have
benefited from that. Since we are coming to the end
of our time. There's one last question that I really
wanted to get to for Randall, since you are a
bona fide bond vibon, I need like a Halloween themed
cocktail that isn't like too much. I don't like things
that are super sweet. I want to be easy because
I'm not great at this. Do you have anything for me?
Speaker 2 (44:33):
Okay, off the topllowen autumnal. Yeah, so an autumnal cocktail.
I would go with a spiced cider with a rye
whiskey on the side, or a ryebourbon whiskey kicker. So
an the things you can do is you can actually
take apple cider, need the unfiltered type sider, not juice.
So you take apple cider when you can actually reduce
it in a pan, and it makes for a very
strong apples almost like an apple syrup. Interesting, and you
(44:56):
can infuse that with things like cinnamon, So you could
put like cardamous cinnamon, any of the things in it
in a pan, reduce it more by half or a
little more, and you end up with an apple syrup.
And so from there you can basically select your level
of booziness, your level of appleness, and your level of cocktail.
You make an effort vestment by either fixing it or
top of champagne.
Speaker 1 (45:15):
I love that, I'm definitely doing.
Speaker 2 (45:17):
So it works in the situation. Yeah, yeah, champagne cocktails
are underrated. Good cure, I agree.
Speaker 1 (45:23):
Also makes me feel like I'm in the nineteen twenties.
I'm not really sure why I have the association.
Speaker 2 (45:27):
Maybe a slipper glass. Yeah, yeah, so that's because in
what I like about that is with one prep you
can make the base and then people can have either
a non alcoholic if you have people who aren't drinking,
or a completely boozy, wipe you out cocktail by just
dumping a bunch of Rye whiskey and putting a splash
of apple over the top of it.
Speaker 1 (45:43):
Also, I like a cocktail that you don't have to
mix individually. Even if you have like just a couple
of people around, it's still sort of a pain. So
I love this. Thank you. I cannot wait to try
this out. That's is perfect. So yeah great, And I
think that'll bring us to our picks. We have a
lot of great recommendations. We've been collecting some of the
links and things that have been mentioned in this convo,
but we will go around the room, so to speak,
(46:05):
and if anyone has specific recommendation. Since Bruce had to
drop off, I'll start with his. Graxio starts their Nerves
course on November first. Definitely don't miss it out and
check out grox dot Io Groxio, and I will pass
it over to Alex.
Speaker 4 (46:22):
So my picksar two learning resources. They're both kind of
open books. One is the beam book and there'll be
a link in the show notes, and the other one
is Earling and Anger. I've definitely used Earling and Anger
several times when there's been a memory leak in production
and you're like, whoa, this is a lickxir. Memory leaks
are not possible. Well, they are possible, and there's a
couple of scenarios into which they're possible. So that is
a good reference to hit up. And you don't know
(46:45):
why memory is spiking and Grafana is going off the charts,
so definitely check those out.
Speaker 1 (46:50):
Awesome, Thanks Alex Steven.
Speaker 5 (46:52):
So mine is going to be for I have ultra
wide monitors here, but I actually mean super ultra wide monitors.
So first of all, this is a thing. You can
get a monitor that's forty nine inches and super ultra wide. Yeah,
you don't know you need this, but you need this
in your life. You need to be surrounded by zoom
like people on your left, people on your right. It
(47:12):
really makes you feel like you're back in the office,
but kind of surrounded in a weird way.
Speaker 2 (47:16):
So check that out.
Speaker 1 (47:17):
Thank you for that. I can't wait to squint even
harder at the teeny tiny resolution of whatever is on
your great chair. I don't have any picks this week,
although I have a feeling I'll be recommending a cocktail
as soon as I try it out. Randal. Like I said,
I collected some of the links that you had mentioned,
but if you have anything else you'd like to share,
it currently doesn't have to be alexor or even programming related.
Speaker 2 (47:38):
So one is definitely seeing deals. The Haskell link what
I wish I had known that was actually really good.
I just like that as a comprehensive sort of resource.
Another one is Kenning Labs has this thing called Finda.
I don't know if you guys have ever used finda.
It is literally a search everything. It's like it's one
of the greatest things ever. It just pops up all
(48:00):
these this this huge overlay that you can search all
the things, and I do mean all the things as
and you can like integrate it with your VIM, you
can integrate with your emacs. I'm pretty sure it integrates
with them. I know it works with vis code, but
it'll search open tabs. So if you're liking me and
you're one of those people who never close the tabs.
You can search all your tabs, you can search all
your links, and it's super fast, and it's a it's
(48:23):
a great way to actually kind of be lazy about
managing Windows until you should.
Speaker 1 (48:27):
Really dangerous for me because I absolutely have a million
tabs and can never find anything, and I'm going to try.
Speaker 2 (48:35):
This, so check it out. Actually, like I said, I'm
a huge fan of that, just because I started using
it yesterday and I was just like, where have you been?
So cool? Thank you, thank you guys, actually appreciate you. Guys.
Give me a chance to just prat al on for
a while.
Speaker 1 (48:49):
Yeah, this is great. We were thrilled to have you
and hopefully we'll get the talk again too.
Speaker 2 (48:53):
All right, sounds great. Curious
Hello, and welcome to this week's episode of Alexa Mix.
We are joined by, as ever, our fabulous panel of posts.
We have Alex Kotman, Hey Alex. We've got Bruce t Hi. Everybody,
Hello Bruce. We've got Steven Nunyez.
Speaker 2 (00:19):
Hello.
Speaker 1 (00:19):
I am SOPHIEA Benedetto and we are joined today by
Randall Thomas, who has many potential introductions that I may
choose from. So I'm going to go with my favorite two,
which is the first. One's a little more informative CTO
at a tech incubator called Geometer, as well as a
thanks for Hacker and vonn Dufon, and I'm sure we'll
be excited to dig into any of those topics. Welcome Randall, Oh,
(00:40):
thank you so much for having me. Yeah, we're so
thrilled you could be here. We've got so many great
things to dig into today. But one of the things
that we often ask us when they first come on
is tell us a little bit about how you got
into the Elixir community in the first place.
Speaker 2 (00:52):
Strangely enough, the short version is I've been around the
Rube community for a long time and one day looked
around in all the people that I knew from the
old Rubey community, you weren't there anymore, and I figured
out where they went, and it turns out that they
all showed up inn Elixir. In fact, it was kind
of accidental. I went to I think the first Elixir
CONFI I had gone to, I think was in twenty
eighteen or twenty seventeen, and I showed up there and
(01:14):
I literally just walked around. I'm like, wait, so that's
why you weren't at Ruby KMF. Oh wait, so you're here.
What are you doing here? So I thought I would
know no one, and it turned out that I knew everybody.
So all the smart people that I sort of cocktailed
on and Ruby ended up in Elixir. So I figured
they're way smarter than me. I should go follow them
see what they're doing. So it's kind of it.
Speaker 1 (01:34):
That's really as good a reason as any, and kind
of similar to how I started learning Alixir. It's like,
I don't know, maybe four or five years ago, one day,
maybe five five thirty, and Steven says, hey, you want
to see something cool, And that was kind of like
theentre into the wide world of alexir. So following the
smart people is the way to go.
Speaker 2 (01:51):
There was a funny thing. I'm pretty sure this is
actually true, right, but like all apocryphal stories, because it
happened in Barcelona. There was Baruko, Barcelon and Ruby KMF
and at the time we were giving this talk on
Ruby motion. If you remember, there was this big kerfuffle
about hey man, you're gonna be able to write iOS
apps in Ruby. And it was actually a really really
great idea, I kind of think a little ahead of
(02:12):
its time. And I think actually at that conference somebody
was talking about, oh, yeah, you heard that somebody's trying
to build a Ruby for Elixir or for Erlang, and
I'm just like, yeah, good luck with that. I literally
thought it was like because I was thinking about, like
I tried learning Arlang once when the prag Prague released
that first book from Joe on Arlang, and I remember
(02:34):
getting into it and I remember thinking I'm like, okay,
I'll put this somewhere right above pearl. I recant that
statement now, but at the time I was thinking to myself, like,
there's no way you're ever going to get Rubis to
learn the syntax, because you know, the obsession with beauty
and elegance and expressiveness and everything else.
Speaker 3 (02:49):
Yeah, and it's really funny that Jose kind of put
it onto the Ruby syntax, not as this great statement
of let's bring all the Ruby community over right. It
was more like, okay, one last thing, right, no way yet,
and then then he kind of layers on these these
beautiful abstractions. But yeah, it seems like we were kind
of circling to each other for a long time randal
(03:10):
before for the elexur community that you know, the idea
that that you were EngineYard and you know, us to
point some stuff there, and you were kind of kind
of involved from from the very beginning, and kind of
we were. We were just just outside of each other's
or bit and didn't really meet until the Garroxio course.
Speaker 2 (03:28):
Yeah, which is that's actually what I like to say is,
you know, I do a lot to to Bruce for
for really getting involved in the electric community. I don't
actually did you just advertise that course online? Was that
what it was? Yeah?
Speaker 3 (03:41):
I mean we literally just threw a couple of tweets
up just to see if there was a test market,
to test the market, and we said we would need
more people to start the class, and then you were
two signed up. But one was you right, and the
other one was Patrick Thompson, who's already writing you know,
articles and pull requests for or Phoenix or Phoenix Lide you.
(04:02):
But that was kind of a cool moment because we
had to decide whether to do the class or not,
and at that point we decided to go against the
grain of traditional courses to it's kind a you know,
like a smaller Midge school right where everybody could and
then that's that's where we kind of decided to flip
the keyboard, and you know, the rest is history.
Speaker 2 (04:22):
Yeah, I was a pretty New York or program before
I got to spend a week in pairing with Bruce,
at least for a elixir, which is I think that's
something that we take for granted. You know, if you
come from procedural languages, it's really easy. If you know C,
you can kind of learn C plus plus even though
it might not be the right idioms, but it's the bridges.
If you know job, you can kind of get into
go and like. But learning how to actually think in
(04:43):
elixir and break down the problem differently or thing functionally
is actually one of the big barrier sentry I think
people have and seeing it and doing it with other
people and going through that evolution was really helped me
but actually really leveled up my elixir.
Speaker 3 (04:55):
Yeah, so I don't I don't take any credit at
all for any you're doing an elixir uh by the way,
but I do think that there's a moment where your
revolution is like a lot of a lot of other
people's like mine as well. Right, it's why are the
cool kids leaving the room? What do they see and
how do I how do I make the mini that
(05:16):
mental shift to do the things that that good programmers do.
And you know that's what we were all able to go
through together in that class, you and Patrick and I.
Speaker 2 (05:26):
Yeah, well I I still think it's one of the
greatest things that where I recommend it. In fact, actually,
if you remember, one of the first things I did
at CTO was I got a subscription. I think I
need you write a feature so I could get my
team on Groxia. So shameless plug for Bruce's like learning
platform Groxio. It's great to learn alixer in a browser.
And I've actually used it for other people and they're like, well,
what do you think about Elixer. I'm like, I don't know.
(05:47):
Go try it out in a browser, like most people
are just blown away that'll run in a browser anyway.
So it really doesn't not in a browser, it doesn't.
But like those types of abstractions, it's not important. It's
like it's like everybody else. You know, first one's free, Amen,
first one's free.
Speaker 3 (06:02):
Yeah. But so as your Elixir Generney journey has kind
of started off, you didn't kind of peck around the
edges like most people did.
Speaker 1 (06:12):
Right.
Speaker 3 (06:12):
It's you know, you went from kind of zero to sixty, right,
so you went from Okay, now I'm in the community
technic class to now I've got this incubator. Can you
tell us a little bit about what you're doing at Geometer?
Speaker 2 (06:25):
Yeah, So some people I used to work with they
started a tech incubator, like all good things, and then
COVID hit. The most interesting part of actually what we
were doing was we ended up pivoting towards doing COVID
response work, and a lot of the work we ended
up deploying for several states was actually built on Elixer interntline.
So we actually have data transformation platforms and pipelines. A fact,
(06:46):
we used Broadway for one of them. Two that are
currently supporting contact tracing in two states on the East coast,
so we learned a lot about both the scalability and functionality.
So just to give you an idea, they were caught
in batch world. Their best turnaround time started off at
twenty four hours, and then when they were really trying
to get up to speed, they could do it maybe
in six but there were a lot of errors and bugs.
(07:09):
We were actually able to in a week spike and
prototype something and then in about another week actually get
into deployment a solution that using Broadway and the inherent
sort of scalability of OTP, that turned the Literally we
were able to process the data faster than they could
get it to us. So we went from processing and
turning around all the COVID cases in about every couple
(07:30):
hours to one minute and thirty seconds was our first test,
and we got it down to sub one minute, and
they were doing it incrementally. We were actually able to
reprocess every single test, every single run, every single time,
which allowed us to do a different type of quality control,
which really matters for deduplication because a lot of the
issues that you run into with COVID testing are that
the lag between when people get tests and the test
(07:51):
results are reported. I mean that duplicates and false positives
are a real problem. So that was all done on
Elixir and earline, right, And that was one of those things.
By the way, we also wrote a telyphony shim that
actually did calliphony control, that did call control for connecting
calls to contact tracers, also done in arline, and both
of them, if I remember correctly, I might be making
(08:13):
this up a little bit, but both of them required
so few resources that they ran in like a container
inside of like an easy two medium, right. It was
just so ridiculously efficient that it was kind of kind
of sad, and we replaced a bunch of custom made
over this Lambda functions that were doing this that had
to do with somewhere aer prone. I think the Lamba
function loads were a couple hours, like fourteen or fifteen
(08:35):
hours to reload the entire universe of data just because
of some architectural decisions. But the short version is Alexra
was a big win because three people were able to
rebuild that system in like a week. So long week,
mind you, but it was really kind of impressive. That
was one of those really aha moments. When you can
think about Elixir and Arline and Beam are very different
and they provide almost like what people or devs think
(08:56):
of as superpowers.
Speaker 4 (08:57):
So I feel like I've lived the same exact story
of Lamb does being painful and terribly slow, and then
replacing it with an Elixir app and then it was,
you know, like a whole different world entirely.
Speaker 5 (09:09):
Yeah.
Speaker 2 (09:10):
Actually, have you ever see that T shirt that says
go away, I'll replace you with a small shell script. Like,
you know, there's like this comic. I think it was
floating around for a while, but it's I almost feel
like the exact same thing. It's like almost any use
case where you're using a Lamb to function, you can
use Elixir and it just kind of works. It's kind
of funny.
Speaker 4 (09:27):
I mean, a Lamb is effected with like one gen
server and we can spawn like you know, thousands of
thousands of them, no problem.
Speaker 5 (09:33):
So are you guys saying this? And the question I
have is why isn't everyone doing this? Why is Elix
or not like the language that everyone builds all the things.
I mean, yeah, obviously it's the right soul for every
job there. That's a great question. It has nothing to
do with technology.
Speaker 2 (09:50):
I'd love to hear what you guys think, and then
I'll opine with my own slightly derisive, sarcastic view.
Speaker 3 (09:55):
On this and and the darkness behind them, right, one
language to rule them all, right, So it's it's interesting
I'm starting to play with with a lot of different
languages that that have different takes in the world. And
so the one that really opened my eyes was Pony
because it does so there are a lot of things
(10:15):
that Elixer does really well that that Pony just really
really sucks at, right, But one of the things that
Pony does well is it enforces compiler constraints that enforce
concurrency constraints, right, so incorrect programs won't compile. And so
you know that that pointed me to to the to
(10:37):
the idea that if you have to move a lot
of data around, you know, if you have a lot
of commutability, then then Elixor isn't it. And so I've
been spending a little bit of time in Julia this
year just kind of to flux the old math muscles.
Speaker 1 (10:52):
Right.
Speaker 3 (10:54):
So I was a math major in college or computer
science and math, and so one of the things that
that we were focused on was linear algebra I'm sorry,
like matrix matrix algebra. And that's kind of what machine
learning and machine modeling have have turned into, right. It's
it's you have these these massive systems of equations and
(11:16):
and algorithms to kind of slowly crank and provide more
and more precision. And we're starting to get into the
places where where you could take these these massive tables
and apply these differential equations to them. And Elixir is
just not good at that, and it is never going
to be good at that. It's good at kind of
(11:37):
the control. But yet, Yeah, I mean I think that
that there are a lot of good things that Elixer
is great at. It's funny, Randall, it's Elixer is great
at almost all the things that we were doing.
Speaker 6 (11:49):
Where you're at these early Ruby communities, right, the deployment,
the you know, the the babysit big fat relational database
with a web UI, you know, on and on.
Speaker 2 (12:00):
Yeah. No, so I don't know, what do you get?
Why do you guys think it's not winning? I mean,
I guess the other question is what's the definition of winning.
I don't think universal adoption of everything is the definition
of winning. I don't think it's for everyone. Not all
languages are for everyone.
Speaker 3 (12:15):
I have a question, how do we know it's not winning?
Speaker 2 (12:17):
Right?
Speaker 3 (12:18):
The language popularity? And so they make mistakes, right, Oh yeah,
didn't they?
Speaker 2 (12:22):
Actually what was it? There's something that they included, like crystal,
that's what it was, right, And they ended up playing
like new.
Speaker 3 (12:29):
Age chygramming crystals, which is either a programming model or
a great way to have your New Age crystals learn
as you get more enlightened every day, I.
Speaker 2 (12:42):
Have to look into that. So no, So I think
there are lots of things. It's really funny. So one
of the things I learned from being a rubyist early on,
and at the time I got into Ruby, I was
actually an independent consultant and I was all in dot net,
like I had actually started a long time ago. System
five released three, that's how old I am. But I
had gotten into that net because that's where all the
(13:03):
consulting money was. So that was C plus plus microsup
foundation classes all that crap, and the learning Aha moment
for me is I had to take some visual basic
programmers and try and teach them C sharp and they
failed miserably, Like there was no way to teach them
the basics of classes, and they just hadn't learned any
of that stuff, and we had to deliver an ETL system.
And Blake Miserini at the time he's like, hey, man,
(13:24):
I know you like Pearl, but I've got something way
better than Pearl. And I apologize for all the Pearl
I ever wrote. I think we all need to do that.
But he said, I got something way better than Pearl.
It's this Ruby thing and like whatever. So I played
around with it for a week and I'm like, huh,
this is pretty neat, and I'm pretty sure at the
time I actually had to go to like a bookstore
and find the Ruby book, like an actual print version
(13:45):
of the book. This was, you know, so like he
had to like run around to borders and whatever and
try and find a copy of Dave Thomas's book. And
I did over the weekend, and then I tried it
with these guys on one day and then I had
them doing advanced string processing and classes. They just got
it and rocked it. And that was the moment I
knew that, like, oh yeah, that's where we need to go,
(14:09):
and so I literally just stopped doing Dottin had stuff
and started doing all in on Ruby and Erlin and Elixir.
And I actually, when I say that earling Elixir Beam,
I actually really like to separate those things because I
think it's important that you don't mix them or blend them,
like there are different things and that you're getting a
lot there. I think it has that same feeling as
early adoption for Ruby. Like literally when we started doing
(14:32):
Ruby work, we had this other company called Quality Humans
where we were all doing rails apps and everybody thought
that we were crazy. You're like, I don't know this
rails thing. I don't know. It seems pretty risky, Like
only do guys in Chicago are doing it?
Speaker 1 (14:45):
Yeah.
Speaker 3 (14:45):
I mean I think that very often we as a
programming community have to take a step back to take
a step forward, right, And I think that that's one
of the things that would be provided, right. So it
was a huge step forward in a lot of ways, right,
first in the idea that programming language should be intuitive
and fun. Second in that that you didn't have to specify,
(15:07):
it wasn't kind of this this really tedious artificial typing model.
And third, we didn't have these really tedious and artificial
configurations that were you know, XML that was explicit for everything,
with no defaults. All those things were really important for Ruby,
and it seems like by taking that step back to
(15:30):
reset the kind of the bar on for application developers
on the productivity of application developers. You know, we got
a lot of the you know, the deployments, you know, immutability,
a lot of a lot of things wrong, but there
was a whole lot that was right about Ruby that
liks Or learned from.
Speaker 2 (15:50):
Yeah. Good.
Speaker 1 (15:52):
I like that you mentioned productivity, Bruce, because there's something
that I absolutely feel is true of Alexa and Phoenix.
And then kind of back to what you were saying, Randall,
when you were trying to, you know, move some folks
into kind of this realm of like object oriented and
when you found Ruby and kind of brought that to them,
that people were able to grack it and learn it
and be productive in it relatively quickly. And that's absolutely
true of Alixir. It's absolutely true of Phoenix, and not
(16:14):
just because of you know, Alixir's language features, in the
fact that, similarly to Ruby, no, it is eloquent and
easy to reason about. But I think there's so many
sort of eco Elixir ecosystem features that allow developers and
whole teams to be really highly productive. And I think
that's why I'm not at all surprised to hear how
Alexir and erlang has allowed you guys to solve these
really big scale problems for like COVID contact tracing. It
(16:37):
reminds me a bit of a talk that was one
of the keynotes at Alexa kronk EEO this year, which
will hopefully be out soon, about some folks in Kenya
who are using Elixir to develop a new like nine
to one one emergency contact system around the country. And
it's just it's kind of the perfect combination of like
scale and concurrency and fault tolerance, but also productivity for
actual humans. And so I'd definitely be curious to hear,
(16:59):
you know, from you and with your experiences lately with
some of these COVID projects, like sounds of you guys
spum this up really fast, like a week later you
had these working prototypes. So like, what is it about
alixer specifically or this ecosystem specifically that let you guys
do that so quickly?
Speaker 2 (17:14):
So I'm going to give you the first one in
no particular order, but the first one that pops to
mind is people. So it's a really bizarre thing that
I found is that people who are looking for those
exact things that you mentioned, like people for whom tools matter,
like productivity matters. Like this is not to poopoo or
denegrate people who don't choose that, but there are some
people who are like approach things that it's kind of
like a craftsman, and some people who approach it it's
(17:35):
just like this is my job. But there are literally
people who go out and try and learn more because
they want better tools, they want a better experience, like
all those things holistically matter to them. And I find
people who gravitate to the elixir ecosystem generally speaking, care
about those things and as a result it ironically it
makes them much better problem solvers, Like they literally care
about the solution and the elegance solution on I think
(17:57):
Buckminster Fuller had that statement. I might be misattributing the quote,
but it's like, first I start with a solution, but
if at the end it is an elegant, I know
that I haven't solved it in the best way. It's
kind of that's kind of the gist of it. So
we actually because we had people who had experienced in elixir,
they were really good at solving problems. Then the other
thing that really works out is that beam Erling and
(18:17):
Elixer provide great abstractions, Like I really love the fact
that you get to pick to the right level of
abstraction for your problem, and if you need to go
more granular, you can't. If you don't have to go
more granular, no need. Like I wrote C plus plus
for a long time, probably professionally for the better part
of almost eight or nine years. And one of the
(18:38):
problems I always I didn't realize at the time because
like I started off an assembler and then everything looked
better than assembler was that C plus plus forces you
to solve every abstraction from the ground up, like almost
invariably you're just starting it's like, oh yeah, so let's
talk about how you're going to pay out the memory
for your class, write another class. Guess what, now you're
going to do the exact same thing. Let's talk about
the copy se antics for your class. Let's top about
(19:01):
like all of these things which really have nothing to
do with solving the problem, are the majority of the
lift that you actually have to do. And the funny
thing is we didn't really think about parallelization. We didn't
think about memory usage, we didn't think about cputtilization. We
just really thought about, well, we have to do the
same thing over and over and over again. Well, how
(19:21):
do we solve it in the small we do this?
Oh well, what do we need to do to paralyze it?
What's this broadway thing? Okay, hey, look this gives us
some like composible data pipelines. Well that works really well? Great, Okay,
I guess it all works. How fast is it? I
don't know. Let's look at it. Oh crap, did it break?
Oh no, it finished? Weird? Okay, I guess we solved
the problem. But it felt like a happy accident. And
(19:43):
that's one of the things I really love about it. Like,
so like a perfect example, the first time you run
live you, it feels like a happy accident.
Speaker 1 (19:48):
You're like totally You're like, oh, okay, I guess that's it.
It just works. And I feel like I've had that
experience so much, not just a Live you, but definitely
very notably with Live you, but so often you're like, huh, okay,
I have to do this thing. I wonder if I
just try you know, X, Y, and Z, and then
you know you're kind of off to the races. Yeah.
Speaker 2 (20:03):
Oh, Also, speaking of productivity, I actually really like the
fact that, specifically when you start talking about abstractions, I
like the fact that one of the principal ideas behind
both Elixir Earling Phoenix novel libraries is that we don't
hide them, we just express them, if that makes sense. Like,
there's no super uber magic. The magic is there for
you to understand and see, and it basically you can
(20:25):
deal with it and you can use it or you cannot.
But it's not trying to make something really magical happen.
Like I know it's fun to pick on JavaScript, but
like promises and JavaScript seem like a really good idea,
But I think we've all written some JavaScript where the
chain of promises goes down and on and on and on.
Speaker 1 (20:41):
I has no idea what you're talking about does. It's
not making at all. I'm curious how you feel that
compares to you know, people throw the phrase like rails
magic around a lot, and that's something that I know,
like Stephen and I encountered and teaching rails is when
you take students from the way that we had taught
the course back at Flatter and usually went from you know,
you're building like a web app with rep, then you Sinatra,
than you're using rails, and like the class would always
(21:03):
split almost fifty fifty. Like half the people would be
so thrilled to get to rails. Stuff would just click
for them. They would be so productive, and then the
other people would be frankly kind of pissed because they
wanted to know what the heck was going on under
the hood and weren't comfortable or happy with all of
these abstractions.
Speaker 2 (21:17):
So, you know, the funny thing about that is one
of the best I think what saved me from that
specific thing was one I was lucky enough to take
the advanced Ruby class that they taught, where I think
it was it was the pragsy I think Dave might
have actually taught it, and he specifically talked about eidenclasses
and unpacking. So and I think the first version of
(21:38):
rails I use was point nine or point eight. It was.
It was not long after his brand news, so you
had to understand how it worked because the stuff broke
all the time, right like, it had some really weird
behaviors and we actually used to have this. What we
would say is we want Ruby programmers, not rails programmers.
And the difference was whether or not you understood the abstractions.
And I think that's actually a different approach that people
(22:00):
take to learning things, And to me, that's the difference
between maybe being a craftsman just being a utilitarian, like
you need to understand those abstractions. And in fact, I
think somebody was mentioning something about, like, what would you
say about learning Elixir? What I wish I had done differently?
I think was one of the things we were talking about.
One of the things I always tell people is learn Elixir,
not Phoenix, right, because a lot of people get into
(22:22):
Ruby through rails, and so what they learn is rails,
and that's as deep as they go. And the problem
then becomes if you ever give them a ruby esque
or Ruby centric problem, they always see it through a
rail's lens, right, same thing with Elixir. I think it's
actually way it's far better to learn Elixir first, then
learn Phoenix, then learn Phoenix, and then try and figure
(22:43):
out what's going on, because if you learn elixer, you
see Phoenix and you're like, well, that makes perfect sense right, pipes,
got it, composable, got it? It makes there's nothing there's
nothing magical here. The abstractions are all just layered into
this particular problem. It's great, but if you only see Phoenix,
like I've done this with people. They want build a
web app, they go for Phoenix, they get everything working,
They're like, I have no idea what's going on here?
(23:04):
Like why do you keep returning this? Okay? Thing? Like?
Speaker 1 (23:06):
Or I think what you'll do then, too, is you'll
draw a lot of false equivalencies between Phoenix and rails.
And I think that that's something that I did a lot,
and you know, a lot of the ELIXA that I
wrote probably for like you know whatever. The first year
of my life is an electric developer was just a
mess because I was just trying to write Ruby and Elixir.
I think that's probably not uncommon.
Speaker 2 (23:25):
I really agree with you on that one. Like I
remember I said the same thing because when I moved
to C plus plus from C, I always said that
C programmers make the worst C plus plus programmers because
you're writing C and C plus plus. And the strange
thing is Elixir has both the blessing and the curse.
Of looking like Ruby. I have seen it. Like I
see people who are literally they're great rubyists. They get
(23:45):
into Elixir and like you look at the code and
you're like, you know that at variable doesn't do what
you think it does, Like that is not what you
think it is, right, But you can see them using
it like it's a Ruby, like you know, a class
little variable, and they're like, well, it's just class a variable, right,
Like no, no, no, no.
Speaker 3 (24:03):
It's really funny. I agree with both of you so much.
And what's funny is Sophie that that when I want
to learn to code things like an Elixer developer, would
I look for your articles? But anyway, neither here Northern
so render. One of the things that's that's cool about
the pivot that we made when you impactorate to that
(24:24):
first class of ours was that our OTP and Phoenix
courses have become a looser courses with a little OTP
and Phoenix mixed in.
Speaker 2 (24:34):
Right.
Speaker 3 (24:35):
It's that you know, we we we teach this model
of you know, constructor reducer transformer that I think that
we started to talk about in your class, but since
essence has become stronger, and we also teach this concept
of pipelind and with land and how to get between them.
But we also try to teach the concepts of how
(24:56):
do you learn, where do you find things like how
do you find the callbacks? Or behavior? What is a behavior?
All those kinds of things really really matter when when
you're taking the next step.
Speaker 2 (25:08):
She didn't even think about that. That's the other thing
that was really great about Elixir is the documentation is amazing, yeah, right.
Speaker 3 (25:13):
And that the documentation actually bleeds through all the way
from the documents on X to the documents on the
individual page for the project to get up to the
documentation and I e X, and all you have to
do is using to bring it all in and make
it all available.
Speaker 7 (25:31):
Yeah.
Speaker 2 (25:31):
In fact, actually I think in one of your other podcasts,
you guys mentioned something like the we're talking about Don't
Fear er Lang? Whose podcast was that.
Speaker 1 (25:39):
We've definitely had that conversation here. Yeah, it's Toime.
Speaker 2 (25:43):
Yeah.
Speaker 5 (25:43):
Yeah.
Speaker 2 (25:43):
So by the way, I totally met him for the
first time at a lone Star.
Speaker 1 (25:48):
Yeah.
Speaker 2 (25:49):
Yeah, actually, we totally We've got a chance to hang out.
I had no idea of like and like we just
met it. We just started talking mostly about food.
Speaker 3 (25:55):
Actually, he has the biggest surfer vibe of anybody I've
ever met.
Speaker 2 (25:59):
You know, No, he's a great guy. But I actually
I had heard his podcast on your podcast, his talking
on your podcast, and it was really funny because I
think we had some of the same stuff, like Sasag
Jerrek's talk on the soul of the Elixir ecosystem. I
actually just sent that to somebody. People were like, well,
why would you care? Like, why should I care about this?
I'm like, go, go watch this. If it resonates, come
If it doesn't, well, by all means, keep keep doing
(26:21):
what you're doing.
Speaker 4 (26:21):
Yeah, that's definitely the best introductory video if anybody wants
to know what the beam is and the value proposition
set on that video, and if they're not convinced in
an hour of listening to Sasha, then it's not for them.
Speaker 2 (26:32):
Yeah. Well, you know. One of the other funny things
is so I had this conversation with somebody else the
other day because we were talking about JavaScript's easy to
pick on listen, like all tools have their both pluses
and minuses. But what I was saying is they argument.
He's like, listen, javascripts got ubiquity, all these other things,
and I said, listen, you don't write JavaScript. He's like, well,
what do you mean. I'm like, okay, I'm going to
go in and I take your babble canfig and I'm just
(26:53):
going to start deleting some stuff. Tell me whether or
not this is going to work right. And I think
one of the things that nobody realizes is that none
of us actually write the languages we think we write.
We're writing like Elixir runs on the beam, right, it
uses Erling libraries, it uses a whole bunch of other things.
Java Closure, they run on JVM. Well, which JVM the
hot spot? Like the abstractions between us and the hardware
(27:17):
and what we're really doing in the libraries we're all calling.
It's actually one of the things which which drives me
nuts is that nobody really tries to understand how many
abstractions they're getting in between them and their solution. Same
thing with JavaScript. You don't actually write jobscript. You write
yes six, or you write yes six with reducers, or
you write I don't know. I'm a terrible jobscript programmer,
but I've tried. I've struggled for hours with my babble
(27:38):
jskinfigs and all the other stuff you're try and get
something to compile right because I had the wrong type
of aerofunction selected right. And it's one of the things
I really like about the entire Arling, Elixir and Beam
ecosystem is that it makes very transparent at what level
you're operating, whereas almost everybody else they tries to obfuscate it.
Well even see nobody uses CCE anymore, use clangor LVM right,
(28:00):
like think your sea code really doesn't actually the most
instances compile straight down anymore, not in the way you
think it does.
Speaker 4 (28:06):
Yeah, I've definitely seen that issue of JavaScript. I was
helping somebody during a consultancy and then we're using a
Sinkle eight in some AWS lambda, and somewhere deep in
the AWS doctor it's like, you can't use a Sinkle weight.
It may work, but you know the the LABDA may
terminate because the event loop doesn't know that it's still
busy or something like that. So you so then we
went through and switched everything over to promises and then
all of a sudden the thing just worked. So yeah,
(28:26):
JavaScript does not equal equal JavaScript at the time.
Speaker 3 (28:30):
Yeah, I've got Joe Armstrong's voice in my head saying
run to completion semantics.
Speaker 2 (28:36):
That's madness, yeah, right, like, well, so you know what,
it's the other thing that's really interesting, just language wise.
My big kick these days is is Haskell, and I
blame Actually, I bring Bruce because he introduced me to
Brooklyn Sealinka, and I now know that she's actually ord
of magnitude smarter than i'll ever be. And so if
she's doing Haskell, then it's it's upon me to incumbent
(28:58):
upon me to learn how of what she knows about
Askell and the Hascle people are right. Being a terrible
Hascal programmer has made me a much better everything else programmer. Right, So,
and what's interesting to me is that you want to
talk about some people who embrace commutability in terms of
what your language is going to do, like your prelude,
like the idea. It's like no, no, no, no, sorry,
(29:19):
let's start. It's not a pre compiler. You tell me
what this language should be doing, right now, go ahead,
Like it's it's kind of crazy how flexible Ascal is.
Speaker 3 (29:26):
Yeah, I have another thing in common with you, Randall,
that I am a terrible Haskell programmer.
Speaker 2 (29:32):
Well, I highly recommend everybody shouldtruggle with some Askell though,
because you want to talk about some magic and some
just understanding of what raw computation looks like.
Speaker 3 (29:42):
Yeah, I mean it's the foundation for everything that's important
to the list our community, right. So even some of
the things that we're doing with types, some of the
things that we're doing that we've always done with strains,
they're all kind of based on the irrity models. Some
of the things that we want to get into with
property based testing, some of the things that we do with,
for example, the formatter. Jose did this this talk I
(30:06):
think three or four years ago called John Hughes Driven Development,
which was cool because at that time we had John
Hughes at gig City Electure, and you know, it was
just a whole lot of fun talking to him about
how his inventions in the language, and he'd never cod
it before at the time, are making such a such
a hard impact on it. I mean, it was just
(30:27):
beaming the whole time.
Speaker 4 (30:28):
So, while this is an Alixra podcast, what Haskell learning
resources would you recommend?
Speaker 2 (30:32):
So? I like the Haskell book, like Haskell from first Principles.
I think it's called it's the Purple Book. Whatever, that's
out there. That's a really good one. There is another thing,
gosh what it was called Things I wish I had
known when I was learning Haskell. I can't remember who
wrote it. I've got it. I'm sure I have a
link to it because I have a running list of
an ord file of just Haskell resources. But what it
(30:54):
talks about is it you mean, Haskell is kind of
like what Elixir could have been had there not been
a good munity. And it's not a dang against the
Haschalo community. It's just that the Hascal community, like, depending
on how you get into it, it might kick you
immediately out of it. Like there are plenty of posts
where it's like, oh well, let's start with some category theory, right,
which is it's just kind of like imagine if if
(31:15):
you came into Erlang, or you came into the luxury
ecosystem and somebody said, oh, yeah, that's really great, so
let's talk about applicative functors and basic functional like do
you know do you know what a calculus is? Do
you know what a lamb of calculus is? No, Okay,
we're going to start with some proofs, right. That's probably
not why they came there. It might be what they
need to know, but that's not necessarily what you want
(31:35):
to hit them over the head with initially, but that
one broke down like all this sort of history that
you need to know to sort of get through, like
why is their stack? Why is there cabal? Like what's
the split between the two? Why are there two configurations?
Like what's this next thing everybody's talking about? Like there's
a lot of history there also some stuff what you
need to worry about, what you don't need to worry about.
We're going to remember that Stephen Dall maybe was the
(31:56):
guy who wrote it. Maybe that I'll do a burrito blog. Yeah, yeah,
that's it. Yeah, that's I think that's that's it. So
those are kind of my two. The other one is
like the look up the LSP, like figure out how
to support Haskel inside wherever your favorite editor is emacs.
I mean, but aside from that, you know, figure out
(32:16):
some good language support for and then just start typing it.
And also there's the gosh and I'd actually have to
go actually like dig up my actual list of Pascal
resources and tell you what it was. But those were
the actually I started with A Haskell book is what
I did because actually that's what Brooklyn told me to do, right, gotcha.
Speaker 4 (32:33):
So, after embarking on this Haskell journey, what your kind
of learnings that you bring back to your Eleixtra code
and how did your your style and way of approaching
problems and elixtur change, if at all?
Speaker 2 (32:44):
Actually, so a couple of things. One, I stopped getting fancy,
and I simplified a lot of things too. What it
made me appreciate was how a looker is the same,
but how it's different. I'm actually much happier doing recursive
and recursion now, Like I'm much more likely to reach
for a recursive style or a rehearsal style of a solution,
and also a mentatic composition and state passing composition, Like
(33:05):
there are a couple of patterns that I steal all
the time now, like pass state along with that. Before
I didn't realize that's exactly what you were doing in Eluxur.
But now to me it's explicit as opposed to being implicit. Yeah.
So mostly I think Haskell is the definition of just
because you can doesn't mean you should. Right, you can
by all means it won't stop you, but be careful.
You might be just taking him at your big toe
(33:26):
with a very very very large shotmun So. Yeah. So mostly,
like I said, I think what it made me understand
is which abstractions I'm using and be much more I guess,
for I'm much more explicit about the abstractions that I'm
choosing at each level now than whereas before I'm like, oh, yeah,
we do this because that's what Alexa code is supposed
to look like. Versus now I'm thinking, oh, this is
(33:48):
what it's supposed to do. It's still a terrible Hascal
programmer though, like terrible.
Speaker 4 (33:53):
Yeah, it's a programming language of course in graduate school
and we did a Hagh school lisp in prologue and that,
and it's like, I'm never doing functional programming ever again.
I don't see the utility at all. And like five
years later I went all in on the Leikster. So
I my foot in my mouth five years ago. But yeah,
it was it was definitely interesting. I'm sure if I
picked it up again today, I'd be just as terrible
at Haskell as I was, you know, ten years ago.
Speaker 2 (34:15):
So to be full credit to the Haskell community, they're
doing a much better job about being more welcoming. Oh
also exorcism. Exorcism has a great Haskell like exercises that
you can go look at and they actually have people
who give you feedback on your Haskell and it's cool
to see this other solutions from different styles, from people
who are kind of new to Haskell, like your solutions,
and people who have been working with Haskel for a
(34:36):
little bit, and then some other person who's like, yes,
I did this in exactly three characters, right, like there
is you can see sort of see the expressiveness of
the language. And that's actually I don't know, I'm kind
of a language nerd, so I like, like we were
early on diclosure at Thunderbolt Labs, we were early adopters
of closure. We went to the first college, and I
think closure had some similar problems with that. It's incredibly powerful,
(35:00):
but in the hands of people who know how to
use it, and there's not a lot of stuff to
get you from here's a lisp to here's being really
good with a lisp. Speaking of random weird language things,
let over lambda. If you ever just want to see
I know a lot of people don't write lisp, but
if you ever just want to see a book to
see where a lisp can take you. There is this
book called let over Lambda. I think you can only
get as like an epub or like a PDF download.
(35:22):
Maybe there's a print version two. I think actually, as
a functional programmer, it's just great to read what other
people who hit the advanced end of a language can do,
And specifically let over lambda is working on. He does
a lot of macros and list style macros. One of
the things I think that's underappreciated. I would like to
learn more about it, and I never really use it
(35:43):
is the macro facilities inside of a lukxir. Right, I'm
always looking for something to really do with it. But
macros are incredibly powerful, and a let over lambda was
one of those things where I saw it and I'm
just like, I got about fifty percent of what you're
writing here, But man, that looks just ridiculously overpowered to
be like, how do you manage to do this cool stuff?
Speaker 1 (36:04):
Oh?
Speaker 2 (36:05):
Also, I had learned racket last year too, which was
kind of cool, like looking at schemes, but that's pretty cool.
Speaker 4 (36:10):
Yeah, I'm on my second take of Christmas Chord's book
Metaprogramming and Elixir. I'll figure out one of these days
and I'll build right macros correctly.
Speaker 2 (36:19):
Yeah, it's a different level of reasoning.
Speaker 3 (36:21):
They're right string interpolation for code.
Speaker 4 (36:24):
So if you can go back in time and give
yourself some advice as you embark on the selector journey,
would what would some of those tidbits be aside from
this isn't Ruby, don't treat it like this Ruby.
Speaker 2 (36:34):
That would be one of the first ones actually find people, Right,
It's really weird. One of the things I think about.
One of the things I think worked for Ruby and
specifically where else they're different things, but I mean is
that they had a community of people who are always
willing to help. I think the community aspect of a
language is really underrated. So find other people who are
in a Elixir, who are kind of in that same boat,
and collectively start learning with them. That would be one
(36:55):
to learn Elixir before learning other things first. Right, Oh,
I think somewhere on the Elixir I f a Q
or someplace maybe on the Elixir lang website it says,
don't ask how do I What was it said? Don't
ask how do you do X? An elixir ask how
would I solve why? In Alixir like the idea of
don't just translate the idioms from whatever languages you already
(37:18):
know into alexir, actually go back and learn from first
principles what's going on. That's actually one of the things
I really like about the Dave Thomas book is that
it kind of abandons some of the oh look, look,
here's hello world, Look here's a for loop. Like if
you think about it, I don't know about you, but
for the past twenty years whatever, like our programming books
have pretty much been exactly the same, right because we
(37:39):
all have some sort of c art style functional like
programming background, so they'll pretty much look the same. They
teach you the same construct so you're really trying to
do if you're trying to figure out, like, oh, what's
the equivalent of a four loop and go got it? Like,
what's the equivalent of a if then else in c
sharp got it right? So I would say, actually learned
(38:00):
it from first principles. So strangely enough, you know, shameless plug.
I did give a talk on how to learn Elixir
at ALEXAKOMF and code Beam, And the other one is
I think take time because you're building up new cognitive structures.
I think people a lot of time do not realize
how much work it takes to get your brain to
start thinking functionally. Right, there is a lot there that
(38:21):
you have to unlearn.
Speaker 3 (38:23):
Syntax, concurrency, distribution, macros. Yeah, so that's a lot, right,
it's interesting. I'm going to give another shameless plug for Bruce.
I generally speaking, I recommend that they read the Elixir book,
and then, strangely, before they read the Phoenix book, I
recommend that they read Designing p Systems and Elixir from
(38:44):
Bruce's book because it teaches you the part of the
problem is if you're functioning like no pun intended, a
function sort of professional programmer, you normally have something you
got to do for your day job. Like it's not
most of us don't just have the luxury of learning
a language for no applicative also up unintended reason, So
you need to know how you build up an electric
(39:04):
system and the functional core stuff. What does it do
fun things with? What's the rest of the acronym, Well.
Speaker 1 (39:10):
There's.
Speaker 5 (39:12):
Work work we gotta yeah, yeah, yeah, do fun things.
Speaker 7 (39:17):
A big loud yeah, big workers that's right. Yeah, and
a beer yes, Stephen, thank you? Because I I personally
I think the Wilder Beast has a nice lowing sound.
Speaker 3 (39:30):
You know, yeah it does. But O'Riley had the cover.
Speaker 1 (39:35):
On the cover, so yeah.
Speaker 2 (39:37):
Oh interesting is that really? What happened is like O'Reilly
had like a Wilder Beast on something and they're like, no,
you may not put the wild of Beasts.
Speaker 3 (39:44):
Yeah. Yeah, So James had just come back from an
Africa trip, right, and so he loved the Wilder Beast
and and I mean, I've done all this marketing, but
now I mean it makes sense. Right. Beehives layers, different
cells ODP just really good time.
Speaker 2 (40:01):
It's true, and be a beehives are built in hexagons, right,
so that you have hecks already built.
Speaker 3 (40:06):
In ooh oh, well done there.
Speaker 2 (40:10):
Well they just dropped the mike.
Speaker 3 (40:11):
We got to be done.
Speaker 2 (40:14):
So yeah, so I recommend that they read that book
because it's important to understand how you build an layer
of system together, because it's very different than a elixir.
The functional core aspect is what most people miss. In fact,
we just had a team try to learn an elixir
that had been Rubius and jobs for people, and that's
exactly what they missed. And it was the first thing
they missed. They didn't have a functional core, and it
(40:34):
made everything else almost impossible.
Speaker 3 (40:36):
It's funny. In San Francisco, Brooklyn came up to me,
and I mean she's one of the people that I
practically idolized. I mean the Witchcraft Library, the strong resonance
with Haskell, with the things that she can make Macro's do.
She's just smarter than Oliver be. But she came up
to me and said, hey about your talk, and I'm saying, oh, crap,
(40:57):
here it comes. It was basically an outline of a
worker b books. She says, I agree with all of it.
And by the way, here's where this paper says the
same thing, except between this layer and this layer you
have an interface. And so it was really it was
like a high moment in my career. You know. It's
kind of said, yeah, you get this, and I said,
(41:17):
I didn't need to get it that way, but I'll
take it right.
Speaker 2 (41:20):
So, actually, if I remember hardly, so he didn't she
say that you didn't you had like a liberal arts background,
right that.
Speaker 1 (41:26):
Yeah, yeah, liberal arts background, history degree and then ended
up at the Flattery School, which was a software engineering
boot camp, and that kind of the rest was history
just fell in love with it.
Speaker 2 (41:39):
Yeah, so when you were thinking about learning things, didn't
you wish somebody had told you?
Speaker 1 (41:43):
That's a good question. I mean, that's one of the
things that I loved about learning Ruvie is that it
tells a story and you really have the emphasis on
the problem that you're trying to solve and how to
express it with code as opposed to needing to understand
kind of some of the low level principles. I feel
like that came later for me, and then I think
the thing that really hooked me and kind of got
(42:06):
me frankly obsessed with programming was and I really think
this is a feature of something that the Flattering School
really engenders and their teachers and offers to their students
is just just an absolute love of what you're doing,
just an excitement, a curiosity, like this total space of support.
That's something that I very much felt from my teachers
there and then learned, i think, in part, how to
give to my students subsequently, because then I went on
(42:29):
to teach there from Steven. I think Stephen just brings
this like absolute joy to whatever he's doing, and he
is as excited to show you something that he showed
you know, a thousand people for five years as he
is to show you something that he just figured out
for the first time ever. And it's really infectious. And
I think that, to me is really like the secret
ingredient to learning a new language and learning a new skill.
Speaker 3 (42:50):
Joy that's actually a stone cold ninja as a teacher.
I mean, so he started coming teaching to our childhood
licture group, and you know, just kind of I just
dropped them into our most advanced class and and disappeared
on them really and and they came back right And
now I'm saying, when you coming back, you don't have
to come back. You really don't have to come back.
(43:11):
Even has this it was really really cool. I paid them.
Speaker 2 (43:15):
I paid them all to say that you Musty's. That's
a great thing to do. It's like, especially nowadays with
gift cards, it's a really easy way to get a
great review. But actually, that's really funny. I think it's interesting.
One of the common threads I see about people is people.
I think what brings us to different languages and different
tools are the people. Which is a really weird thing
to say. Protect people, right like, but a lot of
(43:35):
why we choose the tools we have is if you
get a good person who introduces you to the right
sort of like to the joy of better tools and
better approaches and better thinking, you have this great experience
and that carries forward and they're I've you know, I've
met my more than my fair share of like abused programmers,
right Like, Hey, what happened? I got dumped into this project?
Nobody told me what to do. There was no cic D,
(43:57):
nobody told me about testing. Like, we don't have somebody
to tell you how fun and how joyant and joyful
programming can be. It can be a real be a
real slug. So could useeeven if you can actually like
convey that sort of excitement to people, that's super important
for the next generation of programmers.
Speaker 1 (44:13):
Yeah, well, I think we're all very grateful to have
benefited from that. Since we are coming to the end
of our time. There's one last question that I really
wanted to get to for Randall, since you are a
bona fide bond vibon, I need like a Halloween themed
cocktail that isn't like too much. I don't like things
that are super sweet. I want to be easy because
I'm not great at this. Do you have anything for me?
Speaker 2 (44:33):
Okay, off the topllowen autumnal. Yeah, so an autumnal cocktail.
I would go with a spiced cider with a rye
whiskey on the side, or a ryebourbon whiskey kicker. So
an the things you can do is you can actually
take apple cider, need the unfiltered type sider, not juice.
So you take apple cider when you can actually reduce
it in a pan, and it makes for a very
strong apples almost like an apple syrup. Interesting, and you
(44:56):
can infuse that with things like cinnamon, So you could
put like cardamous cinnamon, any of the things in it
in a pan, reduce it more by half or a
little more, and you end up with an apple syrup.
And so from there you can basically select your level
of booziness, your level of appleness, and your level of cocktail.
You make an effort vestment by either fixing it or
top of champagne.
Speaker 1 (45:15):
I love that, I'm definitely doing.
Speaker 2 (45:17):
So it works in the situation. Yeah, yeah, champagne cocktails
are underrated. Good cure, I agree.
Speaker 1 (45:23):
Also makes me feel like I'm in the nineteen twenties.
I'm not really sure why I have the association.
Speaker 2 (45:27):
Maybe a slipper glass. Yeah, yeah, so that's because in
what I like about that is with one prep you
can make the base and then people can have either
a non alcoholic if you have people who aren't drinking,
or a completely boozy, wipe you out cocktail by just
dumping a bunch of Rye whiskey and putting a splash
of apple over the top of it.
Speaker 1 (45:43):
Also, I like a cocktail that you don't have to
mix individually. Even if you have like just a couple
of people around, it's still sort of a pain. So
I love this. Thank you. I cannot wait to try
this out. That's is perfect. So yeah great, And I
think that'll bring us to our picks. We have a
lot of great recommendations. We've been collecting some of the
links and things that have been mentioned in this convo,
but we will go around the room, so to speak,
(46:05):
and if anyone has specific recommendation. Since Bruce had to
drop off, I'll start with his. Graxio starts their Nerves
course on November first. Definitely don't miss it out and
check out grox dot Io Groxio, and I will pass
it over to Alex.
Speaker 4 (46:22):
So my picksar two learning resources. They're both kind of
open books. One is the beam book and there'll be
a link in the show notes, and the other one
is Earling and Anger. I've definitely used Earling and Anger
several times when there's been a memory leak in production
and you're like, whoa, this is a lickxir. Memory leaks
are not possible. Well, they are possible, and there's a
couple of scenarios into which they're possible. So that is
a good reference to hit up. And you don't know
(46:45):
why memory is spiking and Grafana is going off the charts,
so definitely check those out.
Speaker 1 (46:50):
Awesome, Thanks Alex Steven.
Speaker 5 (46:52):
So mine is going to be for I have ultra
wide monitors here, but I actually mean super ultra wide monitors.
So first of all, this is a thing. You can
get a monitor that's forty nine inches and super ultra wide. Yeah,
you don't know you need this, but you need this
in your life. You need to be surrounded by zoom
like people on your left, people on your right. It
(47:12):
really makes you feel like you're back in the office,
but kind of surrounded in a weird way.
Speaker 2 (47:16):
So check that out.
Speaker 1 (47:17):
Thank you for that. I can't wait to squint even
harder at the teeny tiny resolution of whatever is on
your great chair. I don't have any picks this week,
although I have a feeling I'll be recommending a cocktail
as soon as I try it out. Randal. Like I said,
I collected some of the links that you had mentioned,
but if you have anything else you'd like to share,
it currently doesn't have to be alexor or even programming related.
Speaker 2 (47:38):
So one is definitely seeing deals. The Haskell link what
I wish I had known that was actually really good.
I just like that as a comprehensive sort of resource.
Another one is Kenning Labs has this thing called Finda.
I don't know if you guys have ever used finda.
It is literally a search everything. It's like it's one
of the greatest things ever. It just pops up all
(48:00):
these this this huge overlay that you can search all
the things, and I do mean all the things as
and you can like integrate it with your VIM, you
can integrate with your emacs. I'm pretty sure it integrates
with them. I know it works with vis code, but
it'll search open tabs. So if you're liking me and
you're one of those people who never close the tabs.
You can search all your tabs, you can search all
your links, and it's super fast, and it's a it's
(48:23):
a great way to actually kind of be lazy about
managing Windows until you should.
Speaker 1 (48:27):
Really dangerous for me because I absolutely have a million
tabs and can never find anything, and I'm going to try.
Speaker 2 (48:35):
This, so check it out. Actually, like I said, I'm
a huge fan of that, just because I started using
it yesterday and I was just like, where have you been?
So cool? Thank you, thank you guys, actually appreciate you. Guys.
Give me a chance to just prat al on for
a while.
Speaker 1 (48:49):
Yeah, this is great. We were thrilled to have you
and hopefully we'll get the talk again too.
Speaker 2 (48:53):
All right, sounds great. Curious
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.