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