hpr-knowledge-base/hpr_transcripts/hpr3369.txt

Episode: 3369
Title: HPR3369: Linux Inlaws S01E33: The Return of the Rust
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3369/hpr3369.mp3
Transcribed: 2025-10-24 22:08:02

---

This is Hacker Public Radio Episode 3369 for Thursday,
the 1st of July 2021.
Today's show is entitled,
Linux in Laws S0133,
the return of the rest and as part of the series Linux,
in laws it is hosted by Monochromic and is about 64 minutes long
and carries an explicit flag.
The summary is a show with Steve Klabnik,
uncorroded metal, hipster programming languages,
and the analog world.
This episode of HPR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the offer code
HPR15, that's HPR15.
Better web hosting that's honest and fair at AnanasThost.com.
This is Linux in Laws,
a podcast on topics around free and open source software,
any associated contraband,
communism, the revolution in general,
and whatever fence is your tickle.
Please note that this and other episodes
may contain strong language, offensive humor,
and other certainly not politically correct language
you have been warned.
Our parents insisted on this disclaimer.
Happy mom?
Thus the content is not suitable for consumption in the workplace,
especially when played back in an open plan office or similar environments,
any minors under the age of 35 or any pets,
including fluffy little killer bunnies,
you trust the guide dog unless on speed,
and QT rexes, or other associated dinosaurs.
This is a season one episode 33,
the return of the rust.
Martin, how are things?
Things are great.
One thought we have a special guest tonight.
Yes, we do indeed.
Perfect, so that's great.
Indeed, his name is Stephen Klavenik,
but without further you, Steve.
Martin, why don't you introduce yourself?
Yeah, hi, everybody.
I'm Steve.
Thanks for having me on.
I've been doing like open source software stuff
for a really long time at this point,
but my project over the last couple of years
has been the rust programming language,
and so that is, you know,
probably we're going to talk about most here today.
Before that, I worked on Ruby and Ruby on Rails,
some other shanigans.
You know, I've been around for a while,
even though I was a user for a long time,
before I did maintain myself.
Like, I had a five-digit slash.id,
maybe it was low sixes.
Wow, I was like a kid at the time,
but like, yeah, I remember like riding my bicycle
to the local library,
because they had internet
to be able to like read slash.
So, they've been around for a minute.
Inside the library,
hell, this is giving you a joy.
Yeah, the cat video network,
normally known as the internet,
has a vicious rumor on you in it.
It basically says that you started coding
at the tender age of seven.
Yeah, I mean, like, it's always hard to remember exactly.
Like, that's the closest data I can specifically remember,
but I've been programming long enough
that I don't remember what it was like
to not know how to program.
And if I like triangulate the events,
so specifically,
my uncle was like really into computers in the 80s.
He did a whole bunch of stuff.
He did the whole flip the physical bits
and hit a button to save the bite
into the machine kind of.
Like, he was looking to fall back in those days.
And so, he brought a Mac plus home to my grandparents house
to show them like,
this is what I'm doing with my life.
Here's this computer thing.
And I happened to be around,
and I was a small child.
And so, I think this was about when I was seven.
And you fell for Mac, okay?
Yeah, basically.
Well, so the thing is,
he pulled up a colossal cave adventure.
So, that had been courted.
I see.
And so, I was like, oh, man,
I just wanted to play that game forever.
So, then, a couple of months later, for Christmas,
there were all these computers you could buy
at the back of this year's catalog.
And so, I got this computer
as based on a Z80, basically,
but had a basic interpreter on it.
And so, I just learned how to write stuff
and basic on this tiny little computer.
And that was sort of the start of that.
So, yeah, I was about seven years old.
Very young.
So, there's a little bit of a journey
of writing basic,
at the 10th edition of Seven, right up to rust,
for the two people in the audience
that do not know what rust is.
Maybe you can explain what this,
what this, I mean, you see, every time I go to
one of these hipster coffee shops,
I see people with the MacBook Pro is typing away,
doing the next big thing, inventing the next big thing.
But you see, over the last five years,
more and more MacBook Pro has this sticker
that looks like a cork with an R in it on them.
So, that must be something going on.
Totally. So, yeah.
So, rust is a programming language, first and foremost.
So, you know, you use it to write software.
And you can use to write a lot of kinds of software,
but the sort of, I like to think about things in a historical way.
So, the reason that, like, rust sort of
came into existence was to do stuff in the system space,
not where it is super overloaded,
but, again, in a second,
but to make it, like, better and specifically more safer.
And so, what that means is, like, kind of complicated,
but Mozilla picked it up to help Firefox be better.
So, you can imagine, like, you're implementing a web browser.
You are doing so in C or C++,
because that's what every browser is implemented at this point.
C++, of course, there's some C and everything, basically.
And so, Mozilla was like, we want to make it better.
We think that one of the ways to make it better is to have a better language
for doing this work.
And so, they picked up sponsorship of the rest project
as sort of a long-term effort to make that happen.
One of my favorite bugs on Firefox was actually closed a couple years ago.
And it was someone who had reported a corruption in a preference option somewhere.
And that bug had been filed like 15 years ago.
And they recently rewrote that component in Rust,
and when they did so, it fixed the bug, and they closed it.
And I was laughing, I was like, thinking about, like, okay,
imagine that you could tell the future.
Like, you would go back in time to that bug.
This person files this small corruption issue.
And you're like, okay, we're going to fix this bug for you.
But first, we're going to go off and make a whole new programming language first.
And then we're going to come back and read the subsystem.
So, you'll get this bug fixed, but it's going to be like a decade.
So, anyway, yeah.
So, that's like kind of thing.
So, Rust has a lot of this sort of, like, low level kind of programming
is sort of in his blood.
However, for various reasons, it also could feel a lot higher level.
And so, there's a lot of people who it turns out
have wanted to do lower-level programming.
But it felt either intimidated or, like, unwelcome by the low-level, like, ecosystem.
And so, Rust has kind of, like, positioned itself in many ways,
is like, many programmers sort of first lower-level language.
It's more familiar and approachable to them.
And so, we have a lot of folks who are from sort of, like,
Ruby, JavaScript, Python, backgrounds,
who are now writing device drivers, because they picked up Rust
for whatever reason.
And so, that's kind of the sort of where Rust fits in the landscape.
So, it's kind of like a very low-level language,
but it feels a lot higher level a lot of the time.
So, there's a lot of CLI tools that are being written in Rust now.
And there's, like, web services even that are being written in Rust.
And so, it's kind of all over the place.
It turns out you can use languages from almost anything.
Cool. Yeah, I mean, I think all you haven't mentioned
is how you got involved in...
Yeah, because I think you mentioned you were doing Ruby before, is that right?
Yeah, I was doing Ruby and specifically Ruby on Rails.
And it was kind of a fun thing whenever you work on something for a really long time,
eventually, you know, like, I'd really liked programming in Ruby,
and I'd like to use Ruby on Rails.
So, I kind of set a personal goal for myself to, like,
I would like to get one patch into Rails someday.
And then, I got a patch in.
And I was like, cool. That was fun.
I want to do that again.
And so, then I got three or four.
And then I was like, I want to be on the team for Rails,
and maybe even the team for Ruby.
And so, I started getting more and more patches in.
Eventually, I was on the Rails team.
And then at some point, you're like, okay,
now I'm working on my framework and my language.
Like, where do I go from here?
Like, I sort of, I just burned out, it's kind of wrong.
But I felt like I accomplished all that I could accomplish.
And I was sort of like looking for whatever's next.
And I don't live where I'm from.
So, I went back home for Christmas to visit my family.
And I grew up on a farm in the middle of nowhere, sort of kind of.
And so, I didn't know a lot to do.
And so, I was reading hacker news.
And there was this Rust 0.5 has been released.
Like, item appeared.
And I was like, oh, I like programming,
like, which is I should check this out.
And I read the sort of like basic documentation
I had at the time.
And I thought, oh, this is kind of cool.
I want to give it a try.
I have nothing to do.
I'm hanging out.
So, I did.
And I tried Hello World.
And I couldn't get a sickle pile.
And I was like, oh, man, this is kind of weird.
And Rust had a reputation that was well deserved back then
for changing pretty much all of the time.
And so, I, uh, it is a drop virus,
our IRC room and ask for help.
And so, I was like, okay.
I know that, like, jumping into an IRC room
to ask for help for compiling Hello World,
like, I am probably going to, like,
your laughing, because you know,
that could over say it, right?
Like, I'm probably going to be told to, like,
the bad things are going to happen to me.
But I was bored.
And, like, I don't know if I'm in a long time.
I can handle some trolling.
So, I was like, fine.
I'll just do this, because I'm curious.
So, I did.
And instead, what I got was,
oh, a new person.
Welcome.
Uh, yeah, sorry.
It turns out, at the last minute,
we actually, like, made a small change here.
So, you need to, like,
add this change instead to get a compiling.
We're really sorry about that.
This isn't the thing we could do to help you learn more rust.
That would be great.
Feel free to hang out and ask questions.
Wow.
And I was like, holy crap.
These people are awesome.
And so, I was like, I'm going to just, like, hang out.
And it turns off that wasn't a one-off event.
It just turns out that the rest folks are really nice and really helpful.
And so, I just, like, hung out in the IRC room
and started, like, learning stuff.
And so, I kind of just grew from there.
And that was 2011 or something?
2012.
Christmas 2012.
Oh, yeah.
It's been, it's been a long time.
So, from your, I mean, when you've described your Ruby story
and onwards from that, you're not so much interested in the application
of the language or the technology anymore.
You're more of the building of the foundations.
Yeah, at that time, I was.
So, my current job actually is writing, like,
basically embedded firmware in rust.
So, I am very much like, I still do work on the language,
but, like, not as a job anymore, purely as a hobby.
And so, my job is actually writing stuff in rust.
So, now I'm more into the application things.
And I do think also, I think you can't, you can't remove these two.
So, it's like, you need to be in touch with your users
to make them work well.
So, there's always a balance there, right?
So, you want people that are working on the language full time,
but you want to make sure they're connected
to the people that are using it.
And that's actually one of the reasons why I continued to stay involved was,
so, like, not only was Missila picking up sponsoring the language,
but they were also working on this servo project,
which was, like, rewriting a new browser in rust.
So, you sort of already had one big application
that was not the compiler being written in the language.
And that did a really good job of providing early feedback
on what works and what didn't work.
And this is also why I personally spent a lot of time
hanging out in chat rooms and on message boards,
talking with people who were using the language
and finding what their pain points are.
We sort of made that a really big culture
in rust in general, like, we run a yearly survey,
where we ask users to tell us what we're doing well
and what we're not doing well.
And we try really hard to get that feedback loop
and make it as short as possible.
So, yeah, so I was interested in the early days,
especially about just the building aspect,
because I'm sort of like a programming language nerd.
Like, I like that stuff, you know, of itself.
But if you want to make a product that's useful,
you do need to make sure that you're talking
to people just using the language
and not just, like, make the language
whatever you want.
Definitely.
Yeah, this is not on all right.
Or Ada, as your colleague.
Yeah, totally.
I mean, I think that they did do a thing
that was good for their initial users.
It's problem just that their initial users
were very niche, which is like the department of defense.
Because only one department of defense.
And, you know, even if you're dominant in that niche,
which they no longer are from what I understand,
you know, you can get caught up in the Dutch Navy
use that as well.
The way it was portrayed to us,
we had this, we had this at university.
It was a language designed by committees
and it proved by committees.
And this is, that was the point in time
when I tried to run away, but I couldn't
because I had to take that quiz
because I had to form my credits.
Yeah, but more than 35 years ago or something.
Now, a quick question.
Mozilla started Rust in 2006 or 2010.
Yeah, so what's kind of interesting is is that,
so it was a personal project of a Mozilla employee.
So kind of like what happened was, at one point,
Mozilla said, we want to spin up like a research department.
So this became Mozilla research.
And so, Bren and I, who was the CTO at the time,
basically said like, I want to start this whole division
to do research.
If anyone has personal projects,
they think are suitable for Mozilla's mission
then you should tell me about them
and we'll consider turning them into Mozilla projects.
And so, Grayden Hoer, no relation to Tony Hoer,
even though they share, both are awesome.
He even resigns us in both share last name.
Grayden was an employee in Mozilla at the time
and he had been working on Rust as a personal project.
And so he kind of pitched it as,
Mozilla should be interested in this
because it would help us make Firefox better.
And so I think, if I remember the days right,
Grayden started at no six, but Mozilla adopted it in no 10
because he had been doing it on its own
and kind of it already existed as a personal project.
So yeah, so it's kind of both.
And then hit 1.0 in 2015.
So we kind of have, it's hard to determine
when things start, like yeah.
And it has been self hosting as in,
when did you start the bootstrap process,
pretty early in the process, right?
Yeah, I think it was in like 2011.
It was already bootstrap when I started using it in 2012.
So I think it was somewhere around then,
but yeah, it was written in OCAML originally
and then eventually self hosted.
But for some strange reason, Rust is not known
as the language to write compilers in.
Yeah, I mean, it's interesting
because it inherits a lot of the stuff that's good
from OCAML that makes compilers nice.
And there are a couple.
Facebook actually is porting over
one of their compilers to Rust right now.
Really?
Yeah, it's for the hack compiler.
They're hack language, I think.
It's like an open ML that compiles to JavaScript.
Or is it reason?
Facebook has like 12 languages
and I always forget which one is which.
But one of them, they're rewriting it in Rust right now.
So we'll see.
But yeah, you're right that it's not like
there's like a ton of really famous compilers
in Rust currently.
No, it's interesting.
Yeah, it's interesting because just in the side note,
you probably know a package called Pyoxidizer
that is used to package,
that is used to package by packages as it happens.
And this is mostly written Rust in Python.
Yeah, totally.
And it's kind of interesting because part of the reason
that project came into existence is because
Mercurial is written in Python,
but they're slowly writing more and more Mercurial in Rust.
And so Pyoxidizer is kind of created as a way
to make Mercurial work better.
Yeah, yeah, that's so yeah.
Mercurial is still alive.
Yes, it is.
Actually, it turns it out.
It's dead, okay?
Yeah, so well, here's an interesting thing.
Since this is a free form,
we can get an attendance podcast.
My own needs, my own needs.
Yeah, so I like many people prefer to get over Mercurial.
It's like kind of ignore Mercurial too.
But what's interesting is Mercurial kind of found
a niche in like Mono Rebo's.
Like it is kind of bad once it scales up
it's really, really large understanding.
I've never done this,
but like that's what people told me.
And so Mizzillas, all the Vizzillas actually,
their Mono Rebo is in Mercurial.
And Facebook also had their Mono Rebo in Mercurial
until really recently.
And what's kind of wild is,
this is bringing it back onto the Rust topic.
They had started writing a Mercurial server
in Rust at Facebook called Mononoke.
And now at this point, they've forked Mercurial
and they've turned it back into a centralized
version management system.
And so, yeah, so it kind of like weirdly lives on
as like literally all of Facebook source code is stored
in a Mercurial derived virtual system.
I forget what it's called these days,
but it's, yeah, it's like really interesting.
It basically says on it like,
this is an open source repo,
but we don't expect you'll be able to build it probably.
You can ask us for help and we'll try to help you,
but like right now it's just really rough.
So I haven't really investigated it super closely,
but yeah, it's kind of designed for big giant Mono Reboes.
So yeah, it's still kicking around.
It's, I mean, you hear me laughing in the background,
it's interesting the loops and bounds.
Yeah, absolutely.
Given, given Rust's heritage,
let's put this way, or legacy,
it developed, or it was spun out,
it was spun off rather as a kind of low level systems language,
but whenever basically I give presentations on Rust,
I compare it to Python,
but only in a way more compressed dense time span,
because if I take a look at the ecosystem that is out there
on something called Crates.io,
I wouldn't say it's comparable to PyPy,
but it's rapidly getting there,
and it took Rust about 10 years,
and it took Python 30 years.
Yeah, totally.
And we had the benefit of a lot of hindsight
with these things too.
And so we made that tooling happen really early,
so that way everyone used the same tools,
so that way we don't have the battle of PyP
versus virtual end, versus conda, versus poetry,
versus PyPen.
I think I got all of them there.
This is a fact, too, it's more.
It's probably one that somebody's really mad now,
because I forgot what their favorite one is.
Don't forget containers and virtual machines.
Yeah, right, exactly.
So we wanted to make sure that we had good tooling there,
but also know that network effects matter,
because these all rely on the same packaging formats,
it's actually really hard to optimize Python packaging
because of legacy issues related to Python packaging stuff,
but that's a whole another giant can of worms.
But yeah, so we're definitely,
this is what's growing,
and we sort of wanted to be that way
and kind of made that happen sort of deliberately,
so it's been nice to see it actually happening.
Yeah, I think there's like 50,000 packages in Crates.io,
let's see, yeah, 59,000 packages currently,
so it's definitely not enough.
For the view, not Rasp programmers listen to this podcast,
Crates.io would be the central package repository for us.
Yeah, just as quickly as they said,
yes, it's like my PI, exactly.
And you see what I've found most interesting is actually,
Rasp is on the constant change.
I think you put in changes every couple of months,
if I'm not completely mistaken, but at the same time,
you're driving a very strict standardization,
and Crates.io would be the primary example,
and he ended up in Chicago,
the built and packagement in the system.
Yeah, and so it's quite a fun, very interesting.
We do release changes,
but the key is, is they're all backwards compatible.
So we add things, but we don't remove things.
So we release every six weeks,
which is like very aggressive for a programming language.
I think that like one year is kind of the standard
and some take even longer than a year,
but we do one every six weeks.
And part of the reason for that is,
we actually find ironically that it lets you go slower,
because like, so if you haven't once a year release schedule,
and somebody proposes an awesome feature,
let's say you release on Christmas,
Ruby releases on Christmas, for example.
So let's say someone suggests an awesome feature
at like the end of October or early November.
So now you have these two choices.
You can either rush the feature through
to get it out for Christmas,
or it's going to take like over a year
before that feature can even land.
And so you end up creating this weird situation
where actually having slower release cadence
means that you end up rushing a lot more,
because you have this deadline
and you like kind of have to get to it.
And so we found that by releasing every six weeks,
it means that we can actually take things
and like keep them slower,
because if you miss a release,
it's only going to be six more weeks until the next one.
And so that lets us be like really slow and methodical
about adding big new features,
because we can just like wait until it's ready
and not have to feel rushed to make it out,
before there's another year is going to go by.
And we've deliberately waited on some features
like that actually the most significant recent feature
that landed is this thing called Constantinarix.
And it landed on Russ 1.51,
but it was actually technically ready at Russ 1.50,
but we said, you know, this is a big feature
and we really want to get it right.
So we're just going to like hold off one whole release,
even though we think we could release it now,
just because we want to like be extra sure.
And so that, you know,
wouldn't be possible if we released once a year,
but we only talking about six weeks,
it's like no big deal.
So yeah.
Yeah, okay, okay, enough, enough.
I mean, for the list as well,
we often have people from open source projects on
and like to sort of touch a little bit
on the the way the project is organized
in terms of structure because you mentioned the releases
and how does the project get managed or how do you
features make it in there?
How do you manage the project?
Totally.
So there's many different models, right?
Yeah, yeah.
It's actually easiest to explain it through history.
So because it kind of grows
and I didn't make sense that way.
So originally Graydon's project, he's the only person,
you know, so he makes all the decisions.
And Mozilla adopts it and they wanted to make sure,
you know, those bigger than just the creators.
So they added two other people to sort of form this
like initial kind of council.
And so that eventually became named the core team.
And I joined it in 2014.
And so at that point in time,
we were about like eight-ish people.
And so we sort of made all decisions.
People would make it get out of issue
and they'd ask about a decision and we'd say yes or no.
And that's how things would happen.
But as it came time to start getting around
to releasing 1.0 and things sort of really started
to like ramping up, it became increasingly difficult
because there was a wide range of things
that needed to be decided.
And a lot of times, you know,
not the whole core team would actually care.
So for example, I found myself,
they're focusing on documentation
and like sort of the social side of things.
And so I did less language design work.
Like I'm not a type theorist.
And there's lots of type theory stuff happening in Rust.
And so if there was a question about,
should we add this new fancy type feature?
Like I wouldn't really have an opinion,
but some of the people who really cared about type systems would.
And if there was like a new documentation situation
that needed a call, you know, I would be all over that.
But the language folks would not necessarily care as much.
And so also there became more decisions
that we had time to make.
And so we started developing this backlog of like every week
or we'd run a time meeting.
And so we decided to switch
to a kind of more federated governance model.
So what ended up happening in, I think it was like early 2015,
we switched to a system where the core team still existed.
But we've split everything up into sub teams.
And those sub teams would have full autonomy
over their part of the project.
And the core team would be more for like high level product
decisions and also cross team communication.
So we set off the language team,
had full decision making power over the language itself.
And you know, the library team had full power
over the standard library.
And so that's like a little more decentralized
than many projects, even the ones that have a core team
instead of a PDF file, usually the core team
makes all decisions.
But in Rust, the teams themselves have full power
over kind of everything.
That's still the basic way that happens today,
except for, there's a couple more details that matter.
First, all the teams operate under consensus, not voting.
So that's really matters because the team itself
needs to all agree with anything for it to go forward.
And so given that we have a bunch of small teams
that really works, there's about 200 people
involved in Rust governance now, 250, something like that.
And so if we needed all of them to agree on every decision
that wouldn't work very well.
But when it's the language team as eight members
and the library team as eight members
and the different sets of people
is much easier to operate under consensus.
And we like consensus for a number of different reasons
a little more than voting.
So we stuck with the consensus model,
but we've done this decentralized kind of team structure
to deal with the idea of that.
It's very good compromise between the dictatorship
and everybody has a vote, definitely.
And the other thing we've added now is we have working groups
who are sort of like affiliations of people,
but they don't have formal decision making power
in the project, but it gives people like a space
to find out.
So there's a game development working group, for example.
So if you're interested in making Rust better
for ready video games, they don't get to decide what goes
in the language, but it's like a forum for the people
who do that kind of work to sort of work together.
So we have that as kind of like a structure.
And then finally, the newest thing is,
we have the Rust foundation now exists.
This happened in the last couple of months.
And the foundation, unlike in many other projects
where the governance of the project
is sort of under the foundation,
the foundation's role in Rust is to support the project,
not to be in charge of it.
So the teams still have full autonomy over the project
even though the foundation exists.
And the foundation is basically at this point,
like a place to hold the IP and a place to manage donations
to be able to pay for things like CI expenses
and legal fees and like all that kind of stuff.
So they hold legal ownership of the trademark
on Rust and cargo and the logos.
And they sort of do things like pay our hosting bill.
So when you download the compiler,
you're downloading it from minus three buckets somewhere.
That bill is paid for by the family.
Right.
So that's that.
Yeah, I mean, there was obviously the announcement
of the new chair for the foundation.
Does that mean that there is a large interest?
I mean, I think you mentioned on previous sessions
that all of Amazon Namdas are touching
a bunch of Rust code when they go.
So there seems that they have a fair bit of vested interest
in the all language.
Yeah, Amazon has made a huge investment in the language.
So has a number of other companies that are like,
both on the foundation and off of the foundation, actually.
So a great example, one of my most favorite recent examples
is we now have tier one support for ARG64
because ARM themselves were like, hey, we really want
this to happen and they put in the work
to write up the design documents.
They donated us hardware.
They did a bunch of stuff.
And if that's been really super positive
to see interest from them.
And basically every large check company
that you can think of has some rust somewhere at this point.
Facebook, Amazon, Microsoft, Google, Netflix.
I think I've heard some rumors,
but I'm not a ton about them, like Apple,
all sorts of things.
That's both good and bad in many ways.
It's really nice that they're used for that way,
but also you always have to be careful.
Corporate influence on open source projects
is a really big hot topic right now.
And so we're starting to grapple with that ourselves
as more and more big companies become more and more
formally involved.
We have to make sure that we do what's right for rest
and not with the people with money you think we should do.
Which oftentimes those things are correlated,
but the trouble comes in when they're not, right?
So, yeah.
Yeah, I mean, with all open source,
there is obviously the, yeah.
People have to have a living as well, right?
Yeah, totally.
So so far it's been really fantastic
and everyone's been very supportive,
so we just gotta keep it up.
But yeah.
Okay, so should you think, I mean,
those big organizations choosing to use Rust4
fairly substantial pieces of their infrastructure.
I mean, that kind of ties into the attributes of Rustry,
which is, I think what struck me most about
one of your previous talks was again,
that you mentioned that the finding of bugs
is kind of something that doesn't happen
as much as in other languages of that level,
like C++ and whatever.
In that, once you get it to compile,
you're on a good trajectory
of actually having something that's relatively bug free.
Yeah, you can't guarantee it's bug free, of course,
but you've found a lot of bugs
that you may not find until later stages.
It's interesting because I've been thinking about this
more lately, I've heard some people talking about this
and this thing I think I agree with is,
it's not even so much that Rust prevents bugs
or that it makes your code have less bugs.
It's that it moves the bugs forward in time.
So there's like a lot of things in Rust
that it catches a compile time
that I would still have those bugs in my Ruby program.
I would just see them happen in production instead.
And so it's not really like that,
like it makes more robust software
because it forces you to confront those bugs earlier
and deal with them immediately
rather than putting them off.
And it turns out that it's actually like it tends
to be cheaper before you have the thing
that makes your service topple over
and it causes you to refund a bunch of your customers,
it'd be nice if you caught that bug ahead of time.
It's almost like doing some design as well first,
really, it's not right, it's not right.
But it's hard kind of principle, yeah.
It's often hard to get management to agree
that you should fix the bugs before release though, you know?
And so it's nice that you've got to blame it on well.
The code won't compile unless I fix these bugs.
So that's the way it is.
So it seems like so far,
Rust programs have less bugs in them
to some, you know, for various meetings of bugs
and less obviously, it's not a panacea, it's not magic.
I've written many logic bugs and less programs,
it happens.
I've never claimed that Rust makes your code bug free,
but it does help you deal with bugs earlier.
And that tends to be a better way to do it.
And that means it also can feel a little frustrating
because you have to deal with them earlier.
So sometimes people really get caught up in like,
oh my code hasn't compiled for like a whole day
and I feel like I've made no progress.
And it's like, well, no, you have made some progress.
You know, there's just a lot of bugs
and you're being forced to deal with them now.
And you've got to like iron them out before things happen.
So it's, I can, yeah, I can recall well, learning Rust.
And it was, I wouldn't say a frustrating experience,
but the learning curve was pretty steep.
Coming from, coming from languages like Python,
maybe C, maybe C++.
Yeah.
And the app is spot on.
The compiler is pretty strict in terms of the old adage
to the applies.
If you can convince the Rust compiler to generate code,
you're almost done.
Apart from these few logic errors that you're referring to,
for enough, but to master that learning curve
is not for the faint hearted, I think.
In terms of, for example, I do not necessarily
recommend for a beginner learning to program
to learn Rust right away, because the learning curve
just might be too steep.
It's interesting because I also agree with you
but for like a different reason, which is,
there's no materials aimed at helping brand new programmers.
Like a long time ago, I actually used
to teach people programming as a job.
And so I have a lot of experience teaching people
who have never coded before how to do it.
And one thing that's really counterintuitive
to a lot of professional programmers
is that beginners' minds don't work the same way
as people who have been programming.
And I don't mean that in some sort of like physical way,
but I mean, like, I've heard a lot of programmers express,
like, oh, I would make sure to teach a new programmer,
Ruby Python and JavaScript, because types are too hard
and I don't want to discourage them from learning.
But I've actually found that a lot of beginners
intuitively understand the concept of types
and they are confused that they don't exist.
Because like, when you think about how we talk about words,
like we talk about the types of things
when we use words to describe stuff
and so they want something similar in their programs.
And so it's like kind of really interesting
that like a newbie can sometimes find
different things easier or harder.
And so I have a suspicion that it might,
some people might like programming
and rest as their first language
because they've never learned the bad habits
that cause people to struggle with rust
when they're experienced programmers.
Like we found that some Ruby people learn rust faster
than some C people, even though you might think
as a low level language would be easier
for C people to learn.
And the reason why is a Ruby is just never dealt
with pointers before.
So the only thing they know is the way
that rust presents references.
And so they tend to pick it up a little easier.
And a C person is like, I know how to use pointers.
So I'm going to do the same things I used to do.
And then the rest compiler like slaps them on the knuckles
and is like, hey, don't do that.
And then they get frustrated and they leave.
And so I suspect that there might be some folks
who would be good to learn rust as a beginner,
but there's just no supporting resources for them.
And so I think they'd be mostly set up to fail at the moment.
But who knows?
We'll see if anyone ever bothers to write that book
and gives it a try.
I don't know.
So for all your budding psychiatrists out there,
there's a new business niche.
Consult a tainted my's in terms of,
in terms of hardened and advanced programmers
just to go back to the beginning.
I think about this problem all the time, though.
There's the documentation for a person.
It's sort of kind of at least partially my job
to teach people rust.
And so I need to figure out, there's
this really common thing where people will try rust,
they'll find it too hard, they'll quit.
Six months will go by, they'll come back,
they'll say, I'm going to give it a try again.
And then they find it a lot easier.
And they're like, I don't remember
why it was so hard the first time.
And I have never been able to figure out what it is
to like get people to skip that weird six month quick period.
But it would be great if I could figure out what it is.
I wouldn't commit on the six month,
but you're talking to one of them.
When I first picked up rust, the learning curve,
as I said, was pretty steep.
But then it took about two to three months
to get back into the swing of things.
By no means fully stuttered, I'm not a rust expert.
I'll just give presentations on rust
and try to convert the, convert the parish, so to speak.
But I find this really interesting, really fascinating
because once you get the hang of it,
rust code is actually easier to write
than C++, Python, and some other programming languages
that come to mind for exactly these reasons
because the compiler takes to by the end
and actually guides you there.
The way to your goal might be a little bit tricky,
but I think rust is one of the few compilers
that actually gives you HTML links
as part of the error messages.
Yeah, it's definitely put a lot of work in there.
And there's a couple of contributors over the years
that have really focused on error messages making them good.
And it definitely shows.
I'm really thankful for the work for sure.
But yeah, it's definitely kind of funny.
Yeah, the whole like learning process.
I don't know, it's a tricky problem.
I'm still trying to figure it out.
We'll see if I ever crack that nut.
Maybe it turns out you just need to practice.
But this is also why we try to be really upfront
with people that like, hey, if you're feeling frustrated,
maybe rust isn't for you.
It's totally fine.
Like we'll still be here in the future if you change your mind.
And I think that's been kind of necessary
in order to help people out because we don't want to be like,
we want to encourage people not to discourage them.
So it's interesting for sure.
Yeah, no, I mean, you've obviously seen a lot.
I think you mentioned it at the start.
You saw a lot of Ruby Python programmers converting
or adopting it.
Is that the predominant kind of uptake of the rest language
that you can use?
There's kind of three groups of constituents.
So I like to describe it.
So there's the like C C++ people.
There's the Ruby Python JavaScript people.
And then there's the like Haskell OCaml Scholar people.
And so you kind of have this like,
I sort of like call them systems people,
scripting people and functional people.
And Rust is kind of all three of those things shoved together.
And so it's really interesting because each group
will find certain things really easy about Rust
and other ones will find it really hard.
And so they almost like need different learning resources
sometimes because like, it's amazing to watch a C programmer
use cargo for the first time.
And they like find it kind of difficult
because it's not a make file.
And they know make files really well.
And so they're like, it's like a totally different paradigm.
And so they struggle with it a little bit sometimes.
And you find a Ruby person.
And they will have to learn pointers
and they'll struggle with that.
But like they'll get cargo instantly.
And you know, the C person will get references,
you know, relatively easily.
And so like, you know, the C people will reach
for a for loop more often.
And the functional people will reach for a map.
But you know, like, it's kind of like,
different people bring different perspectives
and they struggle with different things.
So in terms of the size,
one thing is kind of interesting is that
I do think the scripting people are the bigger audience now.
But that's really just due to the sheer volume
of people that exist more than like a desire
or like a, even necessarily maybe like a usefulness
to that audience.
Like there's just so many people that know
about a program in a scripting language
that, you know, if you got,
if you got half a percent of the people
who knew Ruby to try rest,
that might be bigger than if you've got like,
one percent of C programmers.
Because it's just a lot more people
that know higher level languages.
And so I think that they are a bigger constituent.
Yeah.
So just purely due to numbers,
not because it's like better for scripting or whatever.
And this has kind of been common in a lot of newer languages
that have uptake as they like realize like,
oh yeah, we're getting a lot of people
from some particular languages just because the number,
I mean, even just JavaScript alone
like is massively larger than almost every other programming
language.
And some of them you put together.
So it's, you're much more likely to run into a JavaScript dev
than you are a hardcore low-level C++ programmer.
I mean, sorry, Chris, I was just following on the learning piece.
Yeah, like most of us who've done design,
so apart from those of us who started programming
in basic when we were seven,
we obviously learned how to program
or touch upon different programming in English at our,
during our course,
is this something that you're trying to encourage
in university spheres or?
Yeah, I mean, to some degree,
like I would say that we have tended to try to be supportive
when it's already happening,
but we haven't done proactive research.
There's no, I'm not showing up at university campuses
with a rest book on my hand knocking on professor's door
being like, hello, do you have a minute to talk
about your board and savior?
There's the crap.
But we have had a couple of people do university classes
and we've tried to be supportive.
Like I have gone physically before COVID, obviously.
I have traveled to some universities
where they were running a rest class to drop in and say hi
and like whatever.
And there's been some university hackathons
every year, they have some rest people
and some stuff like that.
But the university stuff changes pretty slowly.
It takes a lot of time.
So we have seen, it's probably like 10 classes pop up
which is not zero, but not all of them.
And so yeah, totally, non zero, but not many of them.
Okay, very interesting.
Yeah, change it to tack a little bit.
Rust was originally on as a, well, no level system
programming language, but with the recent additions
to the ecosystem, I'll fully get it where Rust is going.
But at the same time, you see still this,
I'm always tempted to say rejuvenation of the language
in terms of going back to its origins.
You have the butter rocket project from AWS,
which is essentially container based operating system
or sorry, container based Linux platform
for container deployment written mostly in Rust.
Microsoft apparently is pouring big dollars
into the technology for their future programming projects.
And there is this little operating system
called Linux, I think it's called.
I think that's a short, yeah.
That is in the fashion.
Exactly, no, not at all, not at all.
And there was this conference in 2020 called
the Linux Promise Conference, where a guy called
Linux Talbot's actually said he could imagine
seeing Rust entering the kernel.
Any comment on this?
Yep, so I think it's good.
I actually was at a Linux foundation event one time
and I was in the same room as Linus
and I really wanted to go ask him about Rust and the kernel.
This was in like 2014, 2015, it was way too early.
And I was like, I don't want to be that guy,
but I was like, I really, really, really want to be that guy.
And I didn't do it because I thought it wasn't bad.
But I do think it's really interesting and exciting.
I, we always kind of like, so one of the reasons
why it's named Rust is it's supposed to evoke
the feelings of like a well-worn tool.
Like things only get Rusty after they've existed for a while.
And so Rust is kind of like, it's funny
because it feels like a cutting edge programming language,
but that's also because industry languages were all made
in like 1995, basically.
I don't know what they were like put in the drinking water
at 95, but that was an amazing year
of a programming language.
So if Java, JavaScript, Python, Ruby were similar.
Python's a little older, Ruby was 95 as well.
Python was slightly before that, but like the sort of mid 90s
was like where most of our very popular languages
sort of come from.
And so Rust is kind of like a cutting edge programming language
from like 2008.
And so it's really funny because if you talk to like programming
language theory people, they're like, oh yeah,
like Rust doesn't have any new in it.
But if you talk to industry people,
it's like, this has all this stuff I've never seen before.
And so with the part of the reason why that was chosen
is because we wanted to only include stuff
that had seen some use and we knew would be useful
for real world things.
Like Rust has always had the intention
of being a programming language that was used
to build things and impact the world
and not just be a research playground.
And so it's really exciting to see it finally kind of like
continue to grow into more and more useful big systems.
Like it used to be that I would give talks about Rust
and I'm like, yeah, I've heard some rumors
that some companies are gonna use it someday.
And then it would be like, oh, like, you know,
Dropbox was the first like big company
that I would like talk about as using Rust
because that was in 2014 they started using it.
And so it's like, yeah, Dropbox use it for real things.
And then eventually it became like, okay,
here's five of the 10 companies I know about.
And now I like run into people who are using Rust
for real production things I've never met
or heard of them before or what they're doing.
And that's like really, really awesome.
I'm really happy about it.
And so I'm excited to see both the tons
of little people using Rust and also the biggest companies
because you know, that's how like people make decisions
about their technologies based on who else is using them.
And to be able to say that these big companies using Rust
is a really strong showing of social proof
that allows a lot of smaller companies to use Rust.
So I think it's important and useful.
So given the niche character of this tiny program language,
where do you see this going?
Yeah, well, I mean, I think it really,
it really like depends.
I think that, you know, the signs all look good,
but there is a chance that, you know, for example,
so that the Rust code technically has landed
not in the Linux tree proper,
but in like the beta branch, the Linux next.
And so it's not quite in there yet,
but like maybe they do a little more work
and it turns out actually it's horrible
and they pull it out and they say no, right?
Like we're at this interesting like kind of cusp moment
with many things.
Obviously it's been in production at Amazon and Google
and Facebook and mobile.
So that's definitely there, but like, you know,
I still, because I've been around for the whole days,
it still doesn't quite feel really yet.
So I'm always like, when does this go wrong?
Like, where's the point time where they wake up
and like, oh, nevermind, actually turns out, you know, tomorrow.
So the thing about Lambda is like firecracker
is this VM technology that Amazon's been working on.
And every single Lambda execution goes to firecracker
because it's kind of the underlying virtualization
technology makes firecracker work.
So, you know, what happens when I wake up tomorrow
in terms of every single AWS Lambda
has stopped working because it was like a bug
in the rescue compiler.
And you know, now it's a big problem
and like, you know, ah, what's it happen?
Maybe I have an exciting problem for those.
But I think that I'm sure I got a good testing permit.
Yeah, hopefully that's a good testing
when it doesn't happen.
But like, yeah, so, you know, so part of me is just really
waiting until these success stories are successful for a while
and they'll kind of see where things go.
But I think that the sort of the biggest question right now,
like Russ is definitely being used in low-level stuff
very successfully, the question is how high up the stack
is it a reasonable choice for?
And that's a question that has been evolving over the years
and I don't think we have a full good answer on yet
because like, if you would ask me in 2013,
if I thought you should write a web application in Rust,
I would tell you definitely not.
And now I would say maybe, like my company
is basically writing web applications in Rust
and it works great.
And some other places are doing so and it's fine.
But it's not clear, it's always a good fit
in the same way that many other things are.
And so, you know, I don't know what place in the stack
it is unquestionably an amazing choice
like how far up the stack that goes.
Because I think the answer is definitely yes
for the lowest levels of the stack,
but it's unclear where the top work caps out, basically.
So we'll see.
It's an interesting perspective
because you just mentioned web frameworks.
I can recall, I wouldn't say a few,
but a discussion that's put it this way a few years back
with regards to something called Arctic's web.
Maybe before we go into the details
because I think that teaches a very important lesson
about community management or the rest of it,
maybe we should explain what Arctic's web was on about
and why the controversy actually sparked.
Totally.
So, Actix was a project to build an actor system in Rust.
So hence, Actix is like the name for Actix system.
And Actix Web was a web framework built on top of Rust Actors.
And so, that was going pretty well.
I think eventually Actix Web actually dropped Actix support
and kind of ended up becoming its own thing.
It didn't use Actors anymore,
but I'm not a researcher about that,
but anyway, the point is is that it became very fast
and started to appear.
There's this benchmarking suite.
It's really popular called the tech and power benchmarks.
And it benchmarks web framework tests.
And so, Actix showed up and started like
just absolutely demolishing the charts.
Like it was really, really faster
than all this other stuff that had come before.
And so it got a lot of attention very quickly.
And so that's kind of like the back story
is web framework, written Rust, extremely fast,
and very powerful.
I don't know if you want any more background
or if there's anything I didn't cover
before we talk about the conference.
I think the important lesson is actually
what happened to the community.
And why?
So the problem happened is this attention meant
that more and more people started looking at the internals.
Like how is this so much faster?
And part of that answer was unsafe code.
So Rust has this concept of unsafe
and basically like Rust has only rules
that it uses to check to see that your code is good or not.
And unfortunately, CPUs aren't built
to encode Rust's rules in them.
So there's kind of this point where
when you're doing the lowest level stuff,
like you make a system call,
system calls are inherently not built
into the Rust language.
So I can't know how they work.
So we have this concept called unsafe.
It basically lets you do whatever you want.
There's a lot of caveat there.
But you know, we can fill a whole hour
just talking about just that alone.
But the point is that there's kind of like an escape hatch
that lets you do things that are, you know,
maybe a little more dubious by Rust's normal standards.
And so what this means is...
Mark, here are, here are the dragons from now on.
That's all the thing.
Yeah, like you get access to the same pointers
you haven't seen with no checks.
You can do anything you want.
You want to cause a site fault, totally possible.
And so it's on you with the programmer
to make sure that you've done the checks appropriately.
And so naturally people looked into this
and they found that some of the reason why
tactics was so fast was made some pretty dubious usage
of unsafe internally.
And what made the situation so complicated
was that it's like...
It's stuff that wasn't necessarily strictly speaking
clearly wrong.
So it's easy to resolve the situation
if it's like definitely wrong.
And you point out it's wrong.
And the people say thank you
and they merge the port west and the bug is closed.
But when you start getting into debates about
is this even wrong in the first place
that provides a fruitful place for arguing?
And since this has gotten so much attention,
it was so popular, a lot of people saw it
as kind of like a flagship project.
And so a lot of people got kind of upset
because they felt like a flagship project
was doing shady stuff internally.
And that would look bad on Rust.
And so there started to be like a back and forth
that was not very productive
about the ways it acts as useless and unsafe.
Part of that was also people submitted patches
to remove the unsafe and the maintainer said,
no, close them.
Some people got mad that he closed them
because they thought he should accept the things
and I'm like blah blah blah.
And so eventually he burned out and he quit.
And he originally deleted the project
then he undeleded it and gave it over
to some other people instead.
And so we had to kind of have this like,
sort of like community discussion
about like is this behavior acceptable?
And you know, and by this behavior,
I mean the community hounding a maintainer
and so he quit his project.
And like, you know, was this handled the right way
and how do we want to go about this in the future?
Obviously we can't control the way
that little labor one who says they like Rust acts.
But we sort of had to decide, you know,
like was this a good outcome or not?
And if so, you know, what do we want to do differently
in the future?
And so, you know, I thought it was kind of
pretty embarrassing for the Rust community in general.
And yeah, so if you get everyone now,
like has kind of chilled out and sort of recognized
that was like not a great look for anyone.
And the project is new maintainers
and they're doing their thing
and it's still pretty performant,
web framework and all that stuff.
But you know, it matters.
The people part of this is definitely important.
And you know, it just, it's complicated.
So that's kind of the summary of what happens.
Yeah, but Steve, isn't that the best example
for something called evolution?
Yeah, maybe.
But this, this is driving,
it'd be overall fast.
I wouldn't say heritage legacy, but it's spirit.
That's what I'm looking for.
If something doesn't work,
if something doesn't work, people will change it.
And if they don't get the fork it.
The thing is, is the evolution requires a lot of death.
And it's not really comfortable.
It does, yes.
It's not really comfortable.
It's not comforting if you're the person needs to die.
So it will work, right?
Like that's not, I'm not like, oh, well, sorry,
you know, you got to die now because that's just evolution.
And you're like, yeah, but I'm still going to die.
So I'm not happy about this.
I'm like, well, you know, I mean,
and the other thing too is,
people always forget evolution is a process
where the next generation does things better, right?
And so this, you know, forking is important.
But yeah, like the thing is that there wasn't forking behavior.
And I think this is also part of it too,
is that it's not like people forked it.
And so we're going to make it a bit better
and then left the original guy alone.
Like one of the interesting changes, I think,
you know, as we're getting close to the end of the hour,
actually talking about open source stuff.
One of the things that I think has changed culturally
about open source is there's less of a,
like forking has seen more aggressively today
than it used to be.
And there's more pressure to incorporate changes
into some sort of canonical upstream.
And what that canonical upstream does
is more important to people than, you know,
it used to be in the past.
And so I think that that's also part of this story,
is that, you know, if this had happened the same way
in the 90s, some group of people that weren't happy
would have forked the project,
made their own version of actics, but safer or whatever.
And there were left the original guys alone.
Maybe there would have been some mailing list arguments
and they would yell to each other or whatever, but like,
I think there would have sort of been this like co-evolution
instead of an intense pressure on the upstream
to change their ways.
And that's tricky.
For distortion, because our legal department insists
on this normally, kids for distortion,
people didn't die when actics are, all right.
So only code basis, as part of the evolution
in the open source ecosystem, basically die
or are left to, are left to bid draws.
People do not die, just code basis on places like GitHub
or some other hosting platform.
So only digits fade away, not people,
before the natural end, of course.
Yeah.
Martin, any final questions before we wrap this up?
Yeah, it's been great so far, I was so far ahead of it.
We are the end of it.
I'll be good to keep talking, but yeah, I mean,
I think what do you see for yourself?
You mentioned your Ruby history and how you move on from that,
because you've kind of done there.
Do you see something happening there yourself
in the Rust scene as well?
Surely.
I mean, I'm sure at some point, you know,
I will reach my natural end.
And it is just describing the maturity of Rust as well.
Unless a list to look at Valley events,
some sort of immortality tech, and I magically
get to live forever for some reason.
I don't think it's going to happen, but you know,
whatever, there will be an end to some point.
But yeah, I mean, you know, it definitely like,
as projects grow and change, like,
so I am the oldest current existing core team member.
Everyone else is on the core team
before me, he was left at this point.
Wow.
And so, you know, there's sort of a certain amount
of interesting thing there.
And I also think it's important that people move on
because you need fresh new ideas too, right?
So if something is connected to any one individual,
it's not robust specifically because of these kind
of pressures over time.
And so we've added a lot of new people to the core team.
And so, you know, at some point, there is a time
where like, I should probably step back a little
to make space for new people that want to do work
and get involved in things.
I don't know when that's going to be,
but you know, I'm sure it will happen at some point.
And to some degree, you know, I guess that's already happened
in some ways because it used to be my full-time job
to work on Rust.
And now I do it, you know, nice and weekends.
So I do put less time into it than I used to
when it was my full-time day job all the time.
So it's some degree that I got a little bit.
But I still really love using Rust
and I love writing Rust and being around Rust people
and doing all those things.
So I have no immediate plans to kind of like actively move on.
But I do like, I am excited that other people are also
doing cool things and seeing how that works
and trying to, you know, make sure that if people want
to do stuff that I'm not taking up space
that someone else really wants to do.
So it's always, it's always ancient balance.
It's an interesting observation about the new people
because if I look at a project that I'm quite familiar with,
which is the core team has been there for many, many,
many, many years in the same form.
So it's kind of the contrast to what you just observed
about Rust.
Please note, Steve referred to Rust people,
not Rusty people.
This is going to be easier.
That's true.
Usually we use the term Rustations.
I'm just saying.
Right, yeah, totally.
OK, we have a very special segment of each and every show
where we have a guest on, and we do it without guests, too.
The closing segment is actually, we talk about poxies
and poxies are, of course, the picks out the week in terms
of something that comes across as being worth mentioned.
In terms of favorite book, favorite movie,
that sort of thing that you think is worth talking about
in, in, to the, about four people
that we have listening on a, on a regular basis.
So Martin, why don't you start us off with a,
with a pox of this episode?
Yeah, I'm not sure whether it's a, a pox or anti-pox,
but I found the, the announcement of open search
quite interesting as a, you know, from, from the whole open source
scenario.
And it's a licensing and there's a lot of support for it,
which is for various reasons.
But that's the one that, that struck me for, for this week as a,
maybe we should extend our open searches just for the
annumissated.
Yeah, this is basically a, a, a, a, this fork of elastic search
because of the, the nice thing restrictions that they put on it.
And, yeah, it's, it's had a lot of support from the open source
and, you see, which is how I take on this.
I, I think your description is accurate, but I found another
description, which I also think is accurate, which is elastic,
forked elastic search themselves.
And Amazon has now taken over the original.
Yeah, just like a varying, like, you know,
like it's kind of true and kind of a little weird.
Yeah.
Yeah, I mean, that's a point.
Yeah, I mean, that's just a good, so far.
My pox of the, my pox of the week would be, of course,
or the non-technical, and Martin would probably be the
benefactor here because the pubs actually opened on Monday
in Great Britain for outside business.
If a completely mistaken, due to the COVID situation, yes.
So no further explanation needed as long as you're living in the UK.
For those people, for those few people, not listen,
and not living in the UK and listen to this podcast,
pubs are places of business where you can get intoxicated
and licorice.
Just the case that that's the side, side fight,
but it's made me to get together with people.
OK, without asking it.
And the socializing factor, of course, would come at night.
But without you, Steve, what is your pox?
OK, so mine's also going to be non-technical because the thing
I've been most interested in lately is bullet journaling.
So I've been, I've been very, so one of the interesting things
about running a lot of open source projects
is that you need to be organized, and I'm terrible at being
organized.
And so I've been doing different things over the last couple
of months to try to get into it.
But a couple of my friends have started looking at this.
And it's not a new thing by any means,
but so bullets, like a bulleted list.
And basically, it's just a strategy for you
to manage stuff like to do, but also any notes you're trying to take.
And it's a fully analog system.
So I have here on my desk an actual paper together.
And it's a blue, it's called a binding.
OK, it's like an iPad.
It's like if you stack 20 iPads on top of each other?
No.
So I have a little notebook and a pen, and I've been writing down.
So I have here, you know, on my little, for today's journal,
I have, you know, go on the Linux in-laws podcast at one
and in five minutes or whatever we're done here.
I'm going to check that off.
But I've been experimenting with, instead
of having complicated software to track my to-do list,
doing it in a log style.
And it's only been three days.
So I can't tell you if it works well or not.
But I'm interested.
And my handwriting is terrible.
So we'll see if I can read my notes after today,
after I write them.
But it's been kind of cool.
And, you know, you can sort of learn
about the system for bulletjournal.com or whatever.
But yeah, it's been fun.
I mean, this is most amazing.
One of the key contributors to one
of the four-front hipster languages using analog technology.
Yeah, so this is most amazing.
So yeah, so we'll see how it goes.
But I think it's interesting, you know,
almost all my life is computers all the time.
So doing some stuff.
One of the reasons I like doing embedded work
is you get a little physical computer.
You get to see it's supposed to be desktop,
to laptop, to laptop, or whatever.
And so it's kind of another just like,
oh yeah, maybe I should interact with the physical world
every once in a while.
So writing and writing papers is kind of fun.
So Steve, let's do it.
Yeah.
So Steve, let us get you back on the show
in about two weeks to report on the program here.
Yeah, totally.
We'll see how it goes.
I see that has been more than insightful.
I thank you so much for what you're speaking.
Yeah, thank you.
And I'm looking really looking forward to have you
go back on the show in a few years' time
to see where this rust thing actually went.
Yeah, we'll see that.
And with that, I thank you for listening.
This is the Linux Enloss.
You come for the knowledge.
But stay for the madness.
Thank you for listening.
This podcast is licensed under the latest version
of the Creative Commons license.
Tap Attribution Share Like.
Credits for the entry music go to Blue Sea Roosters
for the song Salut Margot, to Twin Flames
for their piece called The Flow, used for the second intros,
and finally to the lesser ground for the song Sweetjustice
used by the dark side.
You find these and other ditties license
under Creative Commons at Germando.
The website dedicated to liberate the music industry
from choking corporate legislation and other crap concepts.
You've been listening to HECK Public Radio at HECK Public Radio.org.
We are a community podcast network that
releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HBR
listener like yourself.
If you ever thought of recording a podcast,
then click on our contributing to find out how easy it really is.
HECK Public Radio was founded by the digital dog pound
and the infonomicom computer club,
and is part of the binary revolution at binrev.com.
If you have comments on today's show,
please email the host directly, leave a comment on the website
or record a follow-up episode yourself.
Unless otherwise status, today's show is released
under Creative Commons, Attribution, ShareLite, 3.0 license.