Oxide and Friends

Bryan and Adam talk with Steve Klabnik and Luqman Aden about their deep, abiding love for Rust... despite a rocky start.

Show Notes

Oxide and Friends Twitter Space: July 18th, 2022

Across the Chasm with Rust
We've been holding a Twitter Space weekly on Mondays at 5p for about an hour. Even though it's not (yet?) a feature of Twitter Spaces, we have been recording them all; here is the recording for our Twitter Space for July 18th, 2022.

In addition to Bryan Cantrill and Adam Leventhal, our special guests were Steve Klabnik and Luqman Aden. Other speakers included Dan Cross, Tim McNamara, and others. (Did we miss your name and/or get it wrong? Drop a PR!)

Some of the topics we hit on, in the order that we hit them:

Creators & Guests

Host
Adam Leventhal
Host
Bryan Cantrill

What is Oxide and Friends?

Oxide hosts a weekly Discord show where we discuss a wide range of topics: computer history, startups, Oxide hardware bringup, and other topics du jour. These are the recordings in podcast form.
Join us live (usually Mondays at 5pm PT) https://discord.gg/gcQxNHAKCB
Subscribe to our calendar: https://sesh.fyi/api/calendar/v2/iMdFbuFRupMwuTiwvXswNU.ics

Speaker 1:

Alright. With that, I think we're good to go. So, and maybe not even with the with our traditional complaint about Twitter spaces, although I it it doesn't feel right to not complain about it. So I don't know.

Speaker 2:

Work work pretty good last week. Let's, hope for the best. Or

Speaker 1:

Of course. Because I'm saying that. It's gonna really be a disastrous week. So, Adam, you're describing how we got here? Because you had a tweet over the weekend that I think got us here.

Speaker 2:

Yeah. So, let's see. So, you know, there's the every so often, Steve, you can tell me how often because I don't keep track, there's a new Rust release. And then on Twitter, because I've been following more and more of the right folks, folks get excited about little here and there details. And one of the things in the most recent Rust release is let chains.

Speaker 2:

So in Rust, you can say, if let and then a pattern equals some variable and, it was sort of annoying in the past where if you wanted to do many of these things, you had to sort of nest them deep, which was annoying, or you had to put a match, which was kind of ugly. And now you knew Rust Chain. So, a let chain. So that was an example of just, like, some nice thing that came along without, you know, just I mean, from my perspective as a dumb user of Rust, it just kinda fell from space onto my lap and now I get to use it. And I feel like that happens a bunch, and it's one of the things I enjoy about Rust.

Speaker 1:

Yeah. Amen. And I think so well, we we talked about this specific feature. Because, Steve, this has been in the works for a long time.

Speaker 3:

Correct. Can you hear me? I don't know if my microphone is on my phone or if it's on my headphones. Yeah. We gotcha.

Speaker 1:

Okay. Cool. Where were you

Speaker 3:

yeah. Just like, yeah. This feature, I don't remember exactly how long, but it definitely was talked about for a while, and that was, like, for in the first place. My understanding is that Swift has had a similar feature for kind of a long time, so there was some amount of precedent. But, my recollection was there was a lot of talk about the exact syntax that should be used, and that kinda, like, held it down for a little while because this is not, like, a particularly complicated feature semantically, but, you know, making sure that you got all the your ducks in a row could take some time.

Speaker 3:

So, yeah. Totally. It, like, took a little while, but it's here and that's cool.

Speaker 2:

And I would say one one of the, kind of one of the things that is a huge time waster for me, say like late Friday evenings or whatever, is getting deep into some of these Rust features that feel like I really want them, like let let chains or like, having traits, have async, within them. Yeah. There's stuff like that that, some of them just feel like, oh, like, this is a kind of simple feature where we're dealing with with some of the esoteric details. And then some of them are just huge deep rabbit holes, where people have literally been talking about them for 6 years and the level of complexity associated with them just boggles the mind.

Speaker 3:

Definitely.

Speaker 1:

Well, and and I feel that, I mean, if lat is one of those. Like, it is not simple to if the the let change is definitely not simple. There's a lot of edge conditions that and it was interesting to because, Adam, did you go back to the history of this thing at all? I mean, it's been around for 4 plus years.

Speaker 2:

No. You know, I I had been through the history of it. You know, one of the, like, 10000 times I needed it, but I I've not, like, refreshed my memory on that.

Speaker 1:

It was interesting in terms of, like, the Odyssey that that the a feature like this goes on. And I, for 1, actually I know that Odyssey is extraordinarily frustrating, probably for all involved. But, for us, those who actually are the, like, Rust users, it's I really appreciate the Odysee because they they really make sure that they're not breaking things. I mean, I think, Steve, correct me if I'm wrong, but the the it just seems that breakage of existing crates has taken really build the various. People do not wanna break existing crates.

Speaker 3:

Definitely. I mean, that's the whole point, like, we run this test suite of the entire of all of crates as part of the release process. Like, it's important.

Speaker 1:

Which is I I I have to tell you is great. I mean, they just like the the level because I I feel like this is not always the case with just software in general. I think the often there's not a great deal of empathy with the users, frankly. And it feels like if someone wants to do something and they're kind of, you know, loud enough, they can make it happen in a lot of communities. And that doesn't really seem to be true at Rust.

Speaker 1:

It seems to be that there's, like, a lot of really thoughtful discourse on these things. And I said, I'm sure it is, like, frustrating for most people most of the time, but the the artifact, the result of that is really, really, really good, I feel.

Speaker 3:

Yeah. There's definitely a super huge balance. There's a number of people who have, like, burned out and quit over the years because of this being so onerous, and, like, it is definitely true. I think something that we see a lot more it's kinda happening a little bit lately in some cases, but what I see in other places I mean, like, literally, like, Guido stepped down from being the BDFL of Python because he added a feature that he really wanted and everybody hated him about it and he was just sick of taking shit from people. So, like, this is definitely a thing that happens, in programming language communities in general.

Speaker 3:

And actually, ironically, the, like, stability thing, one one place that takes that, like, stronger than you may normally assume is, like, Ruby is, like, actually very weirdly stable in a lot of ways.

Speaker 1:

Oh, that is that is surprising. I don't mean to sound pejorative.

Speaker 3:

Yeah. Totally. Surprising. There is a there's a feature in Ruby called flip flops. I don't know if you've ever heard of this feature or not.

Speaker 3:

It it you basically, like, you have a range and you use a triple dot, and what happens is is iteration happens, it goes from, like, returning false to then when it gets within the range, it starts returning true and then outside it starts returning false again. This is a pearlism that, like, got put in Ruby that, like, never got taken out. And so when it was time to talk about, like, Ruby 2.0, somebody filed a bug that was like, hey, we should finally remove flip flops. And there the people were like, well, does anyone know if this feature is being used by anyone? And, Yatsuke Endo, if I remember correctly, was like, I'm actually one of the users of flip flops.

Speaker 3:

For example, this. And he posted a Quine, written in the movie that relied on flip flops.

Speaker 1:

This is a load bearing quine quine quine

Speaker 4:

quine quine.

Speaker 3:

Yes. And so Matt went, cool. Seems like people are using this. Never mind.

Speaker 4:

We're not gonna remove it and close

Speaker 1:

the button. Okay. So, like, Steve, you should explain what I mean, I I you should explain what Acquiant is.

Speaker 5:

I I bet

Speaker 1:

if folks don't know what Acquiant is

Speaker 3:

So Acquiant is a program that prints its own source code, basically. And you can also have variants like, this well, the reason I remember that it's, Yatsuke Endo is because he is, like, kinda semi notorious for making a lot of these coins. And, one of the ones that he did previously was a, like, I think it's called a 7 quine. It's how you determine, like, the number of iterations. So step 1 prints step 2 prints step 3, and then print 7, print step 1 again.

Speaker 3:

So it's kinda like that kind of coin. He did one where, it looks like a globe that rotates through those 7 steps, so when it gets back to the start again, like, that's what it's like. Wait. Wait. Wait.

Speaker 1:

Wait. Is he the one who did the the the 100 Yes. Language query? Correct. Yes.

Speaker 1:

So, Adam, do you know anything about this? The the 100 language query?

Speaker 2:

You know, you told me about this, like, maybe, like, 8 years ago, something like that.

Speaker 1:

Yes. Good memory because we used it to test, LX. So we done a Linux personality for smart OS, and it was delightful to discover this now a 128 language coin relay. So coin relay is and just as Steve is describing is a program that generates another program as output. That program generates another program and and so on and so forth.

Speaker 1:

And then it the the 128th program generates the first program as output, which is extraordinary. And it actually causes to debug some really gnarly bugs in some very strange languages called I wanna say it's is it g Portugal, r Portugal? It's there's a language that's in Portuguese Portuguese, everything about it is in Portuguese, and it was we had a super esoteric linger issue again. But then, Steve, this thing was amazing. This coin relay was amazing.

Speaker 3:

Yeah. I'm gonna triple check those things. I'm, like, 99% sure that it was. Well,

Speaker 1:

I did. The person who did this was definitely.

Speaker 3:

It was. Yeah.

Speaker 1:

Okay. Yeah. Yeah. Because there are a bunch of like, because I'm like, how do you do this? And there is an issue where someone's like, hey.

Speaker 1:

Look. Like, I'm a researcher and how you kind of, like, address like an open research question, and I'm I'm very curious how you did this. Can you describe your, like, your methodology here? And then he, like, closes the issue out with, like, the cherry blossoms are out in Tokyo. Closed.

Speaker 1:

Yep. And he's like, okay. Is this is this potentially, like, an alien life form? Is this from this I mean, it's it's amazing. It's otherworldly.

Speaker 1:

So the fact that this person needs an operator does not mean that everyone needs it. I think it's the moral of the story. I think that's true. Yeah. And the flip flop is, did you ever use it in actual code, Steve?

Speaker 1:

I'm still trying to understand, like, when I would actually want that behavior.

Speaker 3:

Yeah. It's it's I forget why, like, it was originally put in Perl or whatever, but it's it's something about just, like, when you need to do certain kinds of range operations, then it's useful for I I don't know. I've never used it for anything important.

Speaker 1:

But the fact that it's got Pearl origin is definitely interesting. So I would contrast kind of Pearl something back in the day, where it just felt like it would add abstraction really quickly without necessarily thinking about the longer term consequences. And then it became a language that had so much abstraction that it became unreadable at level because someone goes to different abstraction to do the same thing.

Speaker 6:

I'm gonna use it as a girl.

Speaker 1:

This was

Speaker 6:

this was not super uncommon to use this in Pearl. And it it like, the the utilities, you can say things like, does this number match in within this range? Like, does this IP address match within this range of permitted IP addresses for something?

Speaker 4:

That that

Speaker 6:

was a really, like, Perl esque use for

Speaker 1:

this. Interesting. So the but that that's, interesting that they so in terms of the way, I guess so, Steve, the moral of the story was not the coin relay. It was Yeah.

Speaker 6:

That

Speaker 1:

the just the way that Ruby dealt with a feature being used versus the way that Rust thinks about it. I mean, were you contrasting that to the Rust community?

Speaker 3:

No. I was saying that I think that it's like different languages have different attitudes towards stability and Rusts tend to be extremely on that way. And I think some languages, even if they have the perception for being the other way, at times will be conservative. Like, you can't always, like, you can't always say that a language, like, is super stable or is not in all circumstances because, like, it just really kinda, like, depends. And so Right.

Speaker 3:

You know, like, Rust tends to take stable features really seriously, but unstable features change all the time. And, like, yeah, unstable features aren't in the language proper yet, but, like, the point is there's a mechanism for language developers to, like, care and not care and they it's clearly divided in Rust by the tooling, but other languages also do this kind of thing, they just don't necessarily have that distinction and so it can feel like they break a lot of things when sometimes maybe they, like, don't break something you don't notice as opposed to they do break something you do notice or whatever.

Speaker 1:

Yeah. That's interesting. In terms of, like, the because Rust definitely does have first class support for experimental features.

Speaker 3:

This statically and also, like, cleanly to know what things you're using and not using.

Speaker 2:

Yeah. It's it's such a lovely mechanism to to both have that extremely strict, like well thought out process for evolving the language, but then also have the the, like, nightly YOLO, do whatever you want. Like, I'm sure there's more strictures than that. But to have those opportunities, I I I think, like, you can't have one without the other. Like, to to have that strict process almost, you know, in order to to build that language and and and do it accretively, like, requires that avenue for exploration.

Speaker 1:

Yeah. When then you also allow you can get some real experience using some of these features, and that experience can also be I mean, I were do you remember the our our misadventures with the exclusive range operator in in match patterns, Adam? No. So there is a still, I believe, experimental feature for, so Rust has the exclusive versus inclusive range pattern, but the matched and tax forces you to use the inclusive range pattern if you're gonna use a range pattern in the in a match arm. Steve, please correct me if I get any of this stuff wrong.

Speaker 3:

I believe that's true. This is like, I actually don't use exclusive ranges very often or, or inclusive ranges very often, so I'm not as familiar with the specific details of some of this deck. But, yeah, you're totally right. There's something there. Yeah.

Speaker 1:

Right. And so you actually but in a match pattern, you need it well, in a I I feel like in a match pattern, I don't very often use ranges, just full stop. But the in a match pattern, you have to have inclusive ranges. There is no support for exclusive ranges. And we had I don't know if you remember this, Adam, but we had a bug in talk super early on in oxide that was due it is because the problem is if you support both inclusive and exclusive range patterns in a match arm, it's really easy to screw that up.

Speaker 1:

And Talk had screwed this up in one place and then cut and pasted it everywhere. And it's, like, kind of hard to read and re it's hard to to, like you have to be just very, I think, not just rust literate, but you have to know that, like, the double dots is always the exclusive range pattern, and this should be double dots equals to match the intent of the programmer. Does that make sense?

Speaker 2:

Yeah. Yeah. Yeah. Now now I do remember this. Yeah.

Speaker 2:

And and and they had enabled some nightly feature.

Speaker 1:

They had enabled and I'm like, I don't understand how this this code is broken. And then I'm like, oh, they've enabled this nightly feature. They've misused it everywhere. And it's it's interesting because, like, this is the old this is one of the very few, like, language issues that I've kind of been involved in, but only as, like, hey. I wanna give this, this kind of report from the field that a project turned it on and misused it everywhere.

Speaker 1:

And people should probably think carefully before enabling it. And that comment was, like, hugely down voted.

Speaker 4:

People were just like, burn him. Burn him. He's a witch.

Speaker 1:

He's a witch. And the and but what's interesting is that the I'm like, look. I just think you wanna be very careful because there's no way that Lindt is not gonna find us because these are 2 separate program where it's at. And I'm just like, I think it's but what's interesting is, like, the then to watch that discussion kinda happen over the years. And because the the other thing that I love is that Rust, the the Rust compiler will vector you to an open issue on something that is like Germane.

Speaker 1:

And the Rust compiler, if you try to use an exclusive range pattern, the Rust compiler would be like, oh, no. You can't use an exclusive range pattern in a match arm, and here's the issue that's open for it. And over the years and I this this just happened, like, this afternoon, but every, like, once in a while, someone weighs in on that issue being, like, the fact that this is not like a power just saved my butt because I was about to, like, have a bug, basically. Yeah. And I think that that is I mean, obviously, I I got feelings about this particular issue, but I think, like, the meta issue of being allowing people to experiment with nightly features for better and for ill, and then offer feedback on that and have the compiler kind of aware that, oh, by the way, there's this what you're using is actually there's an experimental feature for this.

Speaker 1:

And I think it I did actually great, in terms of the way that engenders discussion and and and feedback.

Speaker 3:

It it is also important, though. I think the the point that was made a minute ago that that also this is, like, tied to not being in stable until it is allowed to be in stable is actually really critical, though. And because we have actually have an existence proof of the downsides of this, I'm gonna pick on Haskell for like just a minute here. Haskell has, language pragmas, you can basically turn on features, in the language. And this was, like, kind of their my understanding, I'm not a super expert on the Haskell development process, but my understanding was this was part of the, like, we're not sure if we're ready for the speech or to truly exist in a language yet or not, so they're turning it on as, like, an extension.

Speaker 3:

There's also some weirdness between, like, Haskell, the language definition, and Haskell is actually implemented by compilers, but, like, it's a whole separate sort of thing. But, anyway, the point is is that you can turn on those features in a stable compiler and, like, use them, and this leads to a dial an explosion of dialects where some people turn on some sets of features in all their projects and other ones don't. And this can also be kind of a problem because it there's no guarantee that they'll work well with each other, and so sometimes, like, somebody will, you know, land their favorite feature they've been working on for their PhD thesis or whatever and then kinda, like, abandon it and a bit rots a little teeny bit, like, doesn't work in some combination with this other feature because nobody did. You know, how do you how do you test the combinatorial explosion of which sets of these features are turned on versus not? You know, it's just like a hard engineering problem.

Speaker 3:

And so that, like but that, like, happens because people in the CMS table can end up using those things and it leads to a lot of, like, fragmentation in in my understanding. That's what I've heard and observed people talking about. So, yeah. So I do think that both parts are really important. The the being able to have a way to try this stuff out and get it in people's hands, while also being like, most You have to explicitly opt into it.

Speaker 3:

I think it's, like, really significant.

Speaker 1:

Yeah. That's a really important point because sorry, Adam. Go ahead.

Speaker 2:

Oh, Steve, I I was wondering. I I, you know, from my perspective, you know, some of these issues I I I dive deep on. Like, for example, when, like, ASM was was gonna be in in stable. You know, I was definitely sitting there refreshing the GitHub issue. Like, I know this is, like, ridiculous.

Speaker 2:

But but, like, I I I was, like, okay. Another checkbox got checked. Like, we're we're 4 out of 5. Like, we're gonna get there. Very excited.

Speaker 1:

It's like you're watching, like, Apollo 13 return to

Speaker 3:

simulator. Yeah. Like, a

Speaker 2:

lot of people were watching, like, SpaceX or whatever, but this this

Speaker 4:

this was You're watching As of Land

Speaker 1:

and I Alcadable. Yeah. Exactly.

Speaker 2:

So but but I I gotta say, look, I don't have a lot of visibility into, like, what the process like, when when you know, how does how does something go from, you know, a, a goofball experimental feature or, or something that is in flight to something people are using to then folks getting, you know, the the cabal, the the council of elders saying, okay, we now let's make a push. Let's get this across the line. You know? And again, with without maybe the the gritty details of how how a bill becomes law. But just what's the general like, how does something get enough momentum to get across the line?

Speaker 3:

I want to think about what I want to see.

Speaker 2:

Totally fair. Totally fair.

Speaker 3:

I realized

Speaker 4:

I realized that he charged me.

Speaker 1:

He used that as if, like, Adam's trying to bribe you.

Speaker 4:

Like, I don't

Speaker 3:

even know.

Speaker 1:

Listen. I'm being a king of favorite charity.

Speaker 2:

I'm not a cop or anything.

Speaker 3:

I'll do it this way. The fact that you don't know that is a problem in the process that there has not been a lot of appetite for solving lately. And so I myself don't really fully know how that works anymore because things have changed. And so I have not been able to keep up with the way in which they have changed.

Speaker 2:

Wow. It is amazing that you constrict that whole sentence without using the letter e. That was that was remarkable. No. I I get it.

Speaker 2:

My apologies, Steve, for for kinda putting on the spot there, but I but I do think,

Speaker 3:

part of it the the way I can say it a little bit more is, like, in the old days, what we used to do is have all our comments development process. But the language team enjoys sequestering themselves away from everyone else, so that's just the way that it is. Yeah.

Speaker 4:

That's how

Speaker 2:

I actually feel about it.

Speaker 3:

And I

Speaker 2:

guess I do I guess I do have some some sympathy for that because it may be that, like, being fully in the open may be distracting in there and especially as you get some some threshold of popularity, like having people jabber at you about some particular feature, disagree with you about some particular feature being ready or not ready, again, may be distracting. So,

Speaker 3:

maybe that's what we're

Speaker 2:

gonna do.

Speaker 3:

That is definitely one good reason to do it that way, for sure. Okay.

Speaker 1:

I mean, you're reading that that discussion is very that is loop thread is like that with the cartoon about React. I mean, did you just tell me to go fuck myself? It's like, I definitely did, Bob. It it it feels like yeah. That's not gonna be very but I can I I I can understand why that's both frustrating, but I can also understand I mean, that's that's not totally nonsensical too?

Speaker 1:

I can understand why.

Speaker 3:

So the the the being public, like what Adam said a minute ago, the threat everything being really public is a problem for a lot of people and does lead to burnout. So I'm not necessarily saying that it is universally better. But there's some sort of back and forth balance here, and over time, it has swung in different directions. And, you know, I'm a little less charitable than I used to be. So that's just like the way that it goes.

Speaker 3:

But it is actually it is actually a real problem, and I'm not gonna say that I think that GitHub issue threads are the be all end all, like, way to design a thing. It's just like I don't know. I just always think back to, like, the the the advice for remote first work is, like, don't make decisions in chat, make them in writing. And, like, I wonder how many of those threads will disappear someday. Like, the RFC's repo is, like, this rich history of programming language development.

Speaker 3:

I've cited the remove the runtime RFC to, like, so many people over the years, and so, you know, I want that stuff to, like, survive, and, it is not clear to me how that happens in a world where all the relevant discussion is on Zulip.

Speaker 1:

Yeah. I mean,

Speaker 2:

that repo is so valuable and

Speaker 1:

so valuable. Yeah.

Speaker 2:

And, and also just, like, has nerve sniped me in so many ways and kind of broken my heart in some ways. Brian, I don't know if you've had this happen where, like, you have fallen in love with some RFC kind of, like, gone gone, you know, 15, 20 threads deep in it only to find find it sort of petered out in, like, you know, 9, 2019, and, like, the people who championed it sort of moved on, or that it's just some, like, ludicrously fucking complex thing, like, like, like, generic associated types or something like that, where you realize, okay, this is actually a ways off.

Speaker 1:

Yeah. The features have broken my heart. That's kind of interesting because I feel that and maybe this is where I'm just, like, a very meat and potatoes rush programmer that the stuff that I get most excited about seems to be the stuff that lands.

Speaker 2:

But you're but you're on nightly and hubris too. So you like But

Speaker 3:

we're we're on nightly only out of necessity. And in fact, I actually have an open PR to literally white list the or allow list the features, specifically, so that we don't add more of them, because we actually don't want to be accumulate we're trying to get unstable as soon as we can. We just can't because there's required stuff for OS development that's not stable yet.

Speaker 2:

Right.

Speaker 1:

So, it it actually seems like this is something I want to say too that that you're because you I think you made a very good point about, it is good that you can't be unstable and use an experimental feature because it it also puts pressure on those people that are using experimental features like us. I mean, Adam, that's part of the reason you're clicking reload and watching the moon landing of of the ASM hit because, like, speaking for Hubris, like, we definitely needed stable as of like we absolutely needed. There's a bunch of stuff that we needed, and that was a big one. I don't know, Steve. What else are we using in in Hubris?

Speaker 3:

The big the big thing that's the big thing that's not immediately being stabilized is naked functions.

Speaker 1:

Right. Makes

Speaker 3:

sense. So there's that.

Speaker 6:

There's there's some PR for that out, actually.

Speaker 1:

It just Oh, sweet.

Speaker 6:

Yeah. But it seems to have stalled, the PR, unfortunately.

Speaker 1:

It's Well, there's my heartbreaker, Adam. You're asking about the heartbreaker. That might be it. Totally.

Speaker 3:

But asm and naked functions were the big ones. We did somebody briefly snuck in, what's the destructuring assignments, but that's been stabilized since. And so, you know, we're technically not, As of my other PR, we won't be having that as an unstable feature soon once I update the tool chain, but that that got snuck in there briefly. There is a, like, CMOS something, whatever feature that's required as part of the LPC55 shenanigans, that, like, has to happen. I remember it was part of Laura's work on the Root of Trust stuff, like, needs a nightly feature that's specific to something that's like deep platform support.

Speaker 3:

But that's really it. Naked Functions and Inline ASM were the 2, like, big features that were really necessary. And we're technically still, we're using the 2 of the sub features of inline assembly, asmconst and asm sim. Sim is being stabilized or is being called for stabilization right now. I don't know where const is at, though.

Speaker 3:

Yeah.

Speaker 1:

Called for stabilization in a zoo thread that we're not in. But, hopefully, we're on that distant planet, I hope that the, the of elders, if these rules in our favor,

Speaker 3:

I think it'll be good.

Speaker 1:

Adam, would that

Speaker 3:

Oh, sorry. My interrupt.

Speaker 7:

Hi. I I as an interested observer rather than someone with anything enlightened to say, it feels like also there are multiple councils of elders, and I, like, never know quite what to read. And I just wanna emphasize or, like, reinforce that point. Like, I don't want to fish through Zulip chats. Like, I really don't.

Speaker 7:

It's not something that I enjoy doing. I don't know what to search for, and, I I'm yeah. I'm totally on board with the idea that actually having this repository of well structured and well thought out

Speaker 2:

No. I'm just kidding.

Speaker 3:

Yeah. No. I think I think another example of how to solve this kind of problem actually is, like, LWN. Like, you can have a reporter. Right?

Speaker 3:

Like, I'm not at down at city hall, you know, listening to every single meeting that happens down there, but I do, like, read the news and I find out when there's a new law that's been passed in my city. Right? And so you could also have, like, dedicated, you know, reporters, sort of, kind of. And that's, I think because, you know, the it's not like the Linux kernel mailing list is also hyper accessible to many people either, even though it's a little more public than maybe a chat thread would be. But, like, you know, there's there's other ways, like, essentially, curation to solve these kinds of problems.

Speaker 3:

And so, you know, we'll we'll see what happens in the future to, like, kinda change that side of things.

Speaker 4:

You know,

Speaker 1:

so l w totally agree on l w n. L w n is, I mean, is more or less Jonathan Corbett. Yep. Maybe we should just convince Jonathan Corbett, like, you're kinda you hate like, this whole Linux thing is kinda played out. Once you come over to Rust and and because I agree with you.

Speaker 1:

Well, so he His reportage is so good on on

Speaker 3:

He is currently hiring someone, and someone with a Rust beat is, like, on the job application, thing. Because because of Rust being in the kernel, he's like, is probably gonna be relevant to us in the future. So it it might also just literally be LWN. But, we'll we'll see how that goes. I I pay for LWN even though I haven't used Linux in years because it's just so good, and you're totally right.

Speaker 3:

It's, like, basically, Justin, as far as I know, are, like, a very small team, but it's, like, super, super important.

Speaker 1:

It is really important. It's actually right. Because it's very it's a very good example. It's very good reportage in that he he's excellent at saying, you know, this this person says this thing and then this other person had a different point of view. He he it doesn't seem to inject his own point of view too much in there, which is pretty remarkable because he's often wading into things that are highly contentious.

Speaker 3:

The Linux kernel development community is not known for people not expressing their opinions on this. And so it is a it is a rarity in that crowd. Yes. So totally.

Speaker 1:

But good report is because because, Tim, I obviously agree with you. I mean, Steve might not agree with you about the importance of the RFCs. I did the, but it it is really, really important to and I found as actually a when I first came to Rust in 2018, I was going into the r those RFCs a lot to understand the origin of stuff. And I think, also, in 2018, I would just know if this is still true today. You know, what, at 4 plus years later but it's certainly in 2018, I felt like you were often ending up in the RFCs to understand why things were the way they were or or weren't the way that you you would expect them to be.

Speaker 1:

But I don't know. Steve, do you have a sense of how true that is today?

Speaker 3:

I mean, I definitely I definitely think that that's a thing that happens over time because as more of stable Rust is a thing, like, you need less of that context because, like, how you do it is the way it's always been done in stable or whatever. Right? Like like, as a feature is about to land, you really care about the RFC, but 10 years after a feature lands, you're probably not gonna go look at the RFC because it's just, like, a normal thing you use. And so I would expect that, like, as the number of things lands and becomes stable and as time goes on, that it it will be in generally less and less, valuable to people. In terms of what I mean, not to people.

Speaker 3:

I mean, like, a working Rust programmer will need to know even less than they used to.

Speaker 1:

Alright. So, Steve, I'm also curious about your perspective on this because I think I mean, we're obviously always victims of our own experience. And I I this is why I feel, like, kinda crotchety about my own Rust experience. I kinda feel like trying to learn Rust pre non lexical lifetimes versus post non lexical lifetimes feels to me like a real watershed feature that completely changed the approachability of the language. But it's hard for me.

Speaker 1:

I mean, but it also happened kind of as I was just getting comfortable with the language. So is is that a fair read, or is that is that not accurate, do you think?

Speaker 3:

So this is gonna sound negative, but I promise it's not, actually. I agree with you only because that's, like, what literally everybody else says. I honestly did not need non lexical lifetimes very often, and it's a thing that's puzzled me for a very long time is, like, what is the way that I wrote code different than everybody else where they were running into it constantly? And I was, like, basically, not really. So I do think it's important.

Speaker 3:

I do think it's really a big change. I think it mattered to a lot of people, but I didn't have that experience personally very much. You sound like you're an sociopath at a funeral.

Speaker 1:

Like, I understand why everyone else is crying, but it's, like, I I understand that you are feeling sadness, but this is not an emotion that I maybe it's more like Data from Star Trek.

Speaker 3:

Yeah. I get it. This is like well, this is just like there's a couple things like that that have been in Rust where it's like, okay. This definitely is really important to people, but, like, it's just not to me and, like, that's that's fine. That's great.

Speaker 3:

I you know? As you said, just because one person needs or doesn't need a feature, doesn't mean it should be added or removed. Right? We're talking about the broader population. I think what's interesting about non lexical lifetimes is to me and I think it's I think it's actually I think it's actually more significant than Rust, actually.

Speaker 3:

I think that not unless the lifetimes is actually a significant step forward in understanding how programmers think about their craft. I'm actually willing to galaxy brain it that that far. And the reason the reason is this. The non Lifetime was originally implemented lexically, partially, I think, because it's, like, easier, but partially because it was believed that programmers truly, like, understand the concept of scope. That's like a very core thing to what we do.

Speaker 3:

And, like, that the idea of scope in programmers' minds would be lexical scope. And so it was, like, considered really, really important that, like, people be able to grok lifetimes, and therefore, we wanted to match the way that we thought programmers, like, mental models kind of, like, worked. And so that was, like, it's very simple. Like, you introduce a variable here, and then at the end of the curly brace, it's out. And so, like, what could be harder than that?

Speaker 3:

Whereas, like, if you're trying to explain non lexical lifetimes in, like, a more formal kind of way, it's like, well, there's a control And so the feature the thing that's, like, technically non lexical lifetimes are far more complicated than lexical lifetimes, But for people, it's actually an easier way to think about it because it matches their mental model of scope more appropriately, which is the last time I stopped using this. It should just be done with or whatever. And so I think that that's like a an insight in the programmer's psychology that's, like, relatively rare that you get those kinds of developments. But, but, yeah, I think it, like, is very interesting for that reason alone.

Speaker 1:

Yeah. Okay. That is interesting. I I mean, it felt honestly when and I I think it's interesting that you did not get inflicted by this as much. And it may have been that I was coming from C, and was making a lot of the mistakes that I think c programmers make where you're just used to having, like,

Speaker 4:

oh, I

Speaker 1:

need to have, like, a back pointer here. It's like rush is like, no. No. Please don't. And so it may have been that.

Speaker 1:

It was really, really frustrating when you had Rust is very upset with you. And because the you you can't do this because the the this variable was still, it this thing. And it felt less like it felt like I was having to to generate spurious scopes that shouldn't be required in order to force lexical lifetimes. Totally. And but yeah.

Speaker 1:

But maybe that that's that's interesting. That maybe

Speaker 3:

I mean, I also write a very, like, nuts and bolts, nothing fancy style of Rust in many circumstances, largely because, you know, a lot of my history is not only writing my own programs. But when I'm trying to teach beginners, you know, I've iterated on the basic syntax like a zillion times. And so I probably just also, you know, you were like immediately getting into stuff that's like relatively, you know, not complicated in the sense of, like, the most complicated thing ever. But, like, I'm often teaching beginners, and therefore, I'm not using fancy stuff or, like, my examples are a little more contrived. And so I probably just ran up into it a lot less because you were, like, getting useful, active work done in, like, relatively complex scenarios right away.

Speaker 3:

So I think that probably has something to do with it too.

Speaker 1:

Yeah. I mean and and I think that, like, that I'm trying to think about other features that were are there other Rust features that were like that that were where the a either a the state of Rust kinda gave us insight into program or psychology and or the way people want to think about the problem.

Speaker 7:

I thought I oh, sorry. Go ahead. So just to kind of pick up Steve's galaxy brain kind of thought, the, one thing that I really liked about non lexical lifetimes was that the Rust the community decided that actually programmers were the important thing here. And actually, we can bend the language to adjust to how people's mental model actually is, which demonstrates, I think, a lot of humility because there's an engineering challenge to kind of refactor something so core, like lifetimes, to Rust. I guess another aspect of that would be kind of a real emphasis on high quality error messages would be sort of similar.

Speaker 7:

Like, compare if you compare the error messages from, say, 2018 to now, I think most people bumping into things are gonna have a better time today than they did a few years ago.

Speaker 1:

Absolutely. I agree with that.

Speaker 3:

Yeah. That's actually a similar I was actually that butts right into what I was gonna say as another example of a feature. It's like this sort of kinda is the debate over the syntax for async await was largely talked about and in ways of, like, how are people going to understand this? And one of the things that sort of helped get it over the line was, like, no. We're gonna parse the JavaScript syntax for async await and recommend our new weird syntax for async await, and that will help solve that problem for when people's mental model of how it should be is, like, the bet the other one from a different language.

Speaker 3:

And so you solve that problem via a good error message and caring about error messages because you're trying to focus on the programmer and the way to think about stuff.

Speaker 2:

Yeah. I think that's a great example, Steve, because I think that the amount of work that I'm sure went into turning that into a coherent error message was was non trivial. And then beyond, like, the some of the technical implementation, the thing that I mean, we haven't really talked about the Rust community, but that's that's the other thing I love about Rust so much. And, so I wrote a blog post about my first use of Rust, you know, like, like 6 years ago or something. And I didn't even look back until, you know, when when Steve started Steve, you you joined DocuSign about, like, 2 years ago now?

Speaker 3:

Little little over 2. Yeah.

Speaker 2:

Jeez. It's nuts.

Speaker 3:

No. Right.

Speaker 4:

And I

Speaker 2:

think it's, like, shortly after Steve started, I for whatever reason, I went back to this Hacker News thread. And Steve's, like, comment was number 1 being like, hey. I'm, like, sorry this was tricky. Like, what what would have been more helpful? Of course, I didn't see it until it was much too late to be useful in that regard.

Speaker 2:

But, like, I thought that was an amazing example of just, like, how much Steve in particular, but the Rust community cared about making this thing, like, good and useful and intuitive and and overcoming obstacles to understanding.

Speaker 1:

Yeah. And so and this is in 2015, Adam, that you did your first and and actually, Steve, it was funny because I Adam was the first person I knew who really went into Rust who was like, I would use, like, you know, one of my peers and someone who's gonna have a a pragmatic approach. And I remember reading that blog and she'd be like, man, thank god Adam did this. So now I'd never have to touch this language ever in my life because this is so clearly a horrific experience. And then Adam's blog entry is like, and in conclusion, I look forward to using Rust again.

Speaker 1:

I'm like, Adam, what are you getting? Read your own blog entry. It's like, what

Speaker 4:

you're in a bad relationship with

Speaker 3:

us, buddy.

Speaker 2:

Such a weird experience, but, because I you know, at the time, I, so I was writing, at the time I was asking a screening question. I've, I've, as people who, I've worked with or have interviewed with me know, I basically have like 2 questions I've been asking for like the last 15 years. And one of them is a screening question that just to cut that we would ask at a couple of different companies. Just like write a anagrammer and do whatever do it in whatever language you wanted. And we had some interns who, like, like, well, I I'm gonna write it Rust.

Speaker 2:

I was like, okay, don't don't show me, but I'm gonna go try this. And I went and tried it, and it was it was kind of brutal. And it was brutal. And I think in the ways that, like, dummies go to learn Rust, which is just to be like, okay, I know how to program. Like, don't tell me, like, I don't need to wait for the translation.

Speaker 2:

I'll just, like, write this code. Like, what's the syntax? Like, it's probably like something else I know. And

Speaker 1:

it's Can I just get something out of my head right now that it's just driving me crazy? Earlier today, you replied to a tweet of someone who's like, when do you see something that automatically you take out the Simpsons? And that is now in my brain, and it's like so, like, literally, as you're speaking this, like, the image that comes to mind is I would Bob's stepping on rings.

Speaker 4:

No. That's that's exactly

Speaker 2:

what it was. That was exactly what it was. But I think as I had time to sort of think about what I had done, you know, and and sort of, like, done the thing that I should have done when I started writing the program, which was to appreciate the differences of the language. I I realized that the unique concepts of ownership and of lifetimes and and these kinds of things that I had never seen in a language. And if I had paused before writing to try to understand, you know, like, if you read Steve's book, like, he takes pains to, like, explain to you, if you just skim past those things.

Speaker 2:

That that's what caught my eye, that it was like, this was a new thing. This wasn't like a language I had used before.

Speaker 1:

Yeah. And I think that actually the you know, I love you got a couple of great lines in there, where I you have you you describe, moving from anger into bargaining.

Speaker 4:

I mean, any I don't

Speaker 2:

know if people still maybe I mean, I know

Speaker 1:

the trust has

Speaker 2:

gotten so much better.

Speaker 1:

It's gotten so much better, but

Speaker 6:

oh god.

Speaker 2:

Brian, have you written any asynchrust?

Speaker 1:

Yes and yes. Okay. Yes. And I know exactly where you're going. Get the that's like I'm just screaming down the the street.

Speaker 2:

So so there there is definitely, like, stages of grief. But there's also, like, do you ever have the compiler is like, hey, this will all work if you use the static lifeline.

Speaker 4:

Totally. Oh, totally.

Speaker 2:

Like, what have I done that, like, this will only work if you can promise me that nothing will change for eternity. It's like, okay. Well, I can't promise that. Okay. Fine.

Speaker 2:

Like, I've I've messed up more fundamentally.

Speaker 4:

Just commit. Why why

Speaker 3:

can't you just commit?

Speaker 4:

Why can't I just marry all

Speaker 2:

my data structures if I love them so much?

Speaker 4:

Yes. Adam, what I thought you

Speaker 1:

were gonna say is, like, when the compiler is like, actually, this will work, but you need to change that to be mutable. You're like, okay. In case that's mutable, the compiler is, like, what

Speaker 4:

the hell are you doing, you dumbass? Now nothing works. And he's, like, okay. I was, like, I'm sorry. I'm sorry.

Speaker 4:

You do you do have the

Speaker 2:

I mean, still at these moments. And I remember, even at the time, like, the Rust compiler being, like, try this. And it's like, who told you to do that?

Speaker 4:

Yeah. Like, what? Why did you think that was gonna be worked stupid? It's like No. That's Like, why are you hitting yourself?

Speaker 1:

Right.

Speaker 4:

And it's actually it's like and

Speaker 1:

then it's, like, so earnest and helpful about the way it's telling you that you, like, lost your mind that you're just, like, in in some ways, it's even, like in some ways, it actually be, like, a little bit easier if it were just, like, look. You're being a dumbass. Like, you just do not I look. I'm sorry. This is the 4th time you tried to do this.

Speaker 1:

I don't think you understand how this program works at all. Like, I'm just gonna,

Speaker 2:

like, I'm letting you know. But but there's nothing like async to help me, like, expose my ignorance and also to, like, vomit out some, like, error message that I need to, like, full screen my terminal in order to even, like, have a hope of understanding what's going on.

Speaker 1:

What was Dave's mess error message early? Do you remember the one that he had that was that was, like, 1300 lines long? It just but did he get an error message that was just, like, it'd be yeah. The it is absolutely monstrous, the kinds of things. And that has all gotten better, but it is still I think it highlights that I mean, you do and actually, I I I really appreciated the, the, the programming Rust book is and, Steve, I know you're emphatic about this too, in the Rust programming language.

Speaker 1:

But just like the need for early programmers to change your mental model, Do not if you walk in a rust with your existing mental model, it's gonna hurt. Like, and if you just try to get a doubly linked list working, it's not gonna end well. You're gonna be in some in the wrong parts of the language, basically. In the in the super

Speaker 4:

go ahead. No. No. You go ahead.

Speaker 3:

In in the super old days, it was really common for c or c plus plus people to join IRC and be like, hey, I'm trying to write this program that's, like, clearly fine, but the compiler won't let it work. What do I have to do to get the compiler to shut up? You have to be like, well, what would happen if that got moved to another thread? And they'd be like, oh. Like, yeah.

Speaker 3:

That's what the compiler is telling you is that you were actually, like, about to do something that does not actually work. Just because you thought it worked doesn't mean it actually works. And there was a really big predictive power, like, basically, the the way you know, it's like, it's like very sort of like stoicism kinda thing. Right? Like you can either try to change the world or you can change the way that you think about what's coming in.

Speaker 3:

And so like, we'd see people be successful if their reaction to that was, oh, neat, versus like, well, I know better. There's no thread there. There's never gonna be a thread there. Can I doubt I'd get the compiler to shut up? And it's like, okay, like, you're talking to have a good time actually.

Speaker 2:

Totally. When when Rusty is, like, asking you questions about your program, it's not bad questions. Right? These are the questions that nobody was asking me about my programs before, and it sort of either worked by accident or it didn't. Yeah.

Speaker 3:

You know And and the trick is to make sure it's right often enough that you trust it. Because if it's not right often enough, then, you know, like like the thing with the the lifetimes that Brian was talking about earlier, then you become frustrated because you do know better than the compiler. And, like, the more that you can get, the the better the compiler is at actually being correct in those situations, the more you're able to trust it and therefore, the more you're able to, like, offload your mental capacity to it. But if it doesn't work, then, like, you know, that then you're it's a problem.

Speaker 6:

Look. That learning curve can be near vertical, though, and and it can be serious gut punch to the ego to have to absorb what the Rust compiler is telling you. And I've seen this multiple places now. In my last project at Google, when I convinced, you know, folks early on to switch from c plus plus to Rust, you know, we found ourselves writing, trying to write c and Rust and then being very frustrated for 2 or 3 or however many weeks. Until we kinda remember, like, okay, we need, like, a of this and that's just, like, I can no longer wrap my identity around being a c programmer, and, like, that's gotta be okay.

Speaker 6:

And once we kinda did that, then we were alright. But, yeah, we had the we had the issue where people were like, this code is perfectly defined. How dare the compiler argue with me? And the

Speaker 3:

flip side of that is

Speaker 6:

that I've seen extremely experienced UNIX people turn around and say, I don't understand why this language exists. It doesn't do anything that c doesn't do, and it forces you to sprinkle unsafe and mud all over the place. And it's like, well, that's you're you're you're thinking about

Speaker 1:

it wrong.

Speaker 6:

It it actually is very frustrating.

Speaker 1:

Yeah. Well, there's actually a pretty good hacker news thread that I think that Adam, you'd seen over the weekend. Right? The the, on learning Rust. I think the and I think as and I see that it's been interesting to you for you to kinda watch, like, the broader programming community change its disposition really towards Rust?

Speaker 1:

Because it feels like now there is a much more I think people are are are much more embracing of the mental model shift than they were 2, 3, 4, 5 years ago. Is that a is that a fair read?

Speaker 3:

I think that's true. I think it it also, like, People You know, you kind of go through Like, crossing the chasm is always, like, at the forefront of my mind. That whole thing is, like, really essential to the way I view a lot of things. And so I think that it's it's not even so much that people are more amenable, it's just that, like, now that the value has been demonstrated and now that, like, you can get a job and now that there's, like, projects that you care about, that you wanna contribute to, or Rust exists, more people are willing to put in the effort to learn something new because they know what they're gonna get in return. You know, like, in the old days, you basically were getting, like, hope.

Speaker 3:

You know, maybe someday I'll I'll be able to a job in this language, and therefore, I'm gonna learn it because I like it. For other abstract reasons, I have some sort of other motivation. And I think now we're getting to the point where there's a much more, like, meat and potatoes reasons to, like, learn the language that's not, you know, I'm a programming language theory nerd and this affine type system is cool or whatever. And so I think that's also part of it too. It's like not even necessarily sentiment changing, it's just that, like, there's it is it is more clear that the cost benefit is maybe worth it, and therefore, people are more willing to even entertain it in the first place.

Speaker 3:

And could you elaborate on what you mean by crossing the chasm? There's a there's a book. There's a business book called Crossing the Chasm, and it's about how, like, how disruptive technologies achieve like succeed in the market or whatever, something vaguely along those lines. And there's this diagram that's basically like a bell curve except for at the first quartile, there's like a there's like a gap. And so it's basically like, and each of those cohorts uses the technology for different reasons, and they start using the technology at a different place in its life.

Speaker 3:

So the leftmost are, like, the extreme innovators or something. I don't remember. This is a business book, so it's full of silly jargon. But, like, those are the people that, like, use a thing just for the sake of using it because they enjoy using it, and they'll, like, always try new things because the fact that it's new is a good enough justification on its own. And the far other side is like the late the late majority or the laggards, I think is the term they actually use.

Speaker 3:

And those are folks who like, you know, that Java thing is probably used enough that I'll start using it now. Like the, you know, like, a a COBOL programmer that's still writing COBOL today that's like getting around to trying those newfangled things that have been successful for 10 or 20 years because they just, you know, are much more conservative with their technology choices. And the trick is that a lot of things die before they can like cross the chasm, they can jump over that gap between the, like, people who are interested in a thing early because they see the potential and the people who, like, just wanna get their job done for the day and don't really care. And it's like, how do you how do you get your thing, or the trick is to get your thing from that early audience to that, like, bigger, more normal audience. And once you've done that, you're successful and you're gonna exist forever.

Speaker 3:

But, like, lots of technologies sort of die trying to get to that kind of, like, you know, larger group of people. It's much more if you look at the diagram, it's, like, very visual, so it's, like, kinda easier to see how this works out. But I hope that verbal No. That's that's

Speaker 1:

a great description. Of course, it it natural follow-up question. When did Rust cross the chasm?

Speaker 3:

Yeah. Well, see, that's, like, kind of an interesting thing because you you don't one of the tricks is, like, you don't really necessarily know until like a lot later. And so I think a lot of people would, like, cite like, Russ

Speaker 1:

like I've got my answer to the answer to this question. So I'm I'm breaking history of your answer.

Speaker 3:

My answer to this question is actually the MVP of async await dropping.

Speaker 1:

Okay.

Speaker 3:

And that is because while everybody not I shouldn't say everybody. While there are a lot of criticisms of async and, like, there's still a lot of work to do there and, like, all this other stuff, If you look at the actual numbers of people reporting on the survey, like, what they use Rust for and what they use Rust for at work, it is network services. And it doesn't matter how many people on Hacker News say that you shouldn't write network services in an unmanaged language because it's the wrong tool for the job. A lot of people actually do think it's the right tool for the job, and asyncawaitlanding was a significant step forward in getting people to be able to write those things, and it honestly is still one of the biggest user groups of Rust just purely by the numbers, and I don't think it feels that way or it's reflected in the social side of things as much. But that's, like, the the actual situation is that that's what Rust is being used for in many, many, many cases.

Speaker 3:

So I think that was the the real point at which it became more useful to a lot of those folks, is because everything touches the network now, basically. He says when his day job is writing firmware, the device is not

Speaker 4:

gonna exist. Well,

Speaker 5:

for what it's worth, that was actually the point for me as well. And and, you know, I'm trying to not turn this into an advertisement for what we do, but, we use Tokyo and Axum and Tokyo console and postgres stack data persistence, and we could not have built what we were building without Rust. And without the compile times, without the lifetimes, without the compile time reliability. It actually was a thing where a lot of us were formerly go programmers and Rubyist, and we kind of said we could not have built this without this. And and, like, I am trying to, like, put a positive spin because I do agree with you, Steve.

Speaker 5:

There's definitely, like, some work to do, and the ergonomics aren't that great. Like, for instance, right now, we bumped everything out to factory, which is kinda like sidekick for those of you who've used it. And, we're we're sort of spawning off jobs when the threads get too big. Otherwise, debug mode, some of our async threads will kind of explode. And and, like, and, like,

Speaker 6:

we've seen it in Tokyo console.

Speaker 5:

We'd like, you know, sort of watch them kinda, like, balloon a little. But But at the same time, it's those kind of moments we're like, oh, well, maybe that's been a go routine, but all the other benefits and everything else that come along with it has certainly been like a, we could not have done XYZ thing without that. So the MVP was definitely there because, you know, a lot of us were kinda, like, silently in the back waiting. We're like, okay. We see the embedded use cases.

Speaker 5:

We see the c and c plus plus replacement scenarios, but we're kinda sorta like, you know, when can I use this, like, my everyday, like, back end or full stack job? And and and I would have said that that, at least from my channels, was certainly where I saw heightened chatter.

Speaker 1:

It's like, Steve, are you playing a 19 forties radio sound effects reel? No. I,

Speaker 4:

I That's why I'm, like, waiting for the door to open and close, the footsteps, the tree.

Speaker 3:

I I have I, I make I make tea in mason jars and put it in my fridge. And so I had I'd set that up right before this happened, and so I was just putting the can the lids on and putting it in my refrigerator, and I didn't realize you could hear that. So my bad. But

Speaker 4:

No. No. No. No. No.

Speaker 1:

It was like but it was like crystal queer sound effects.

Speaker 4:

It was actually

Speaker 5:

so sorry, miss. I do it.

Speaker 4:

I I No. No.

Speaker 5:

No. You're fine. I I I mean, I make chemexes in the morning, and everyone's always like, why is Nick's video off? And then I'll have to, like, put in chat. Like, I'm, like, making a pour over, and it's gonna taste terrible, but I'm gonna go like it anyway.

Speaker 5:

So I I

Speaker 2:

it's probably been there. Yep.

Speaker 1:

So that's interesting. But, Nick, you've got the same feeling as Steve. And, Adam, I think you I wonder if you have that same thought because, I mean, coming into Oxide, you're definitely like, look. I can see Rust for these kinda lower like, low down the stack. That makes tons of sense.

Speaker 1:

Higher the stack, I think it might make less sense, but that's since since it's kind of.

Speaker 2:

No. Totally. So so when I joined so I I I, you know, I wrote my first Rust in 2015. I had dates right wrong, but then I I didn't really do anything with it again. Like, when I when I started my last company in in, in whatever it was, like, 20 2016.

Speaker 2:

I know it's it's

Speaker 4:

13 Dickany too?

Speaker 6:

Yeah. Exactly. It's moving quicker than

Speaker 2:

I thought. The the choices were sort of like Go and Java. And then, I'll say without embarrassment, we we chose Java, but it, like, those felt like the right answers for the kinds of problems that we were solving. And

Speaker 1:

Is now when we can talk about your love affair with Antler?

Speaker 2:

Oh, I I do love Antler. Antler is wonder I'm happy that we could have we could have a whole week long of shows on Antler. I'd be happy to do that. No. I think Antler is really cool.

Speaker 1:

Antler is really it seems really cool.

Speaker 2:

So, but but, you know, I I like rust. I like I like rust the first time I tried it, and I was fired up coming into Oxide. I was, you know, reading books on and stuff like that. But I did come in, and in week 1, I I was like, well, you know, why are we, like, for, say, the web layer or whatever, maybe it makes sense to to use something like Java or maybe it makes sense to use another language. But I would say that it it didn't take that long to feel like the the perceived obstacles associated with rust were far outweighed by all the obvious benefits.

Speaker 2:

And that just, you know, you can trick yourself into saying, like, well, you know, I'm I'm using these these tinker toys with with Java and I can't get myself into these kinds of problems, but you clearly can. And you're bringing on a whole host of other problems with with a garbage collected. So, you know, I, I think that I'm, I'm no longer claimed to be unbiased. I'm hugely biased in favor of Rust. Like I, I, and maybe this is a good time as any, but like, I didn't, you know, people talked about loving programming languages.

Speaker 2:

Like, I I worked with someone who loved Java, and I didn't think I was capable of loving a language. Like, I didn't think that was a thing that I had

Speaker 4:

in me. Me. And and now I am like This heart grew

Speaker 3:

3 sizes larger that day. That's right. That's right.

Speaker 4:

But, like, you know, I just thought

Speaker 2:

it was, like, no. No. You just pick the right tool for the right job and, like, love has like, I don't know. Like like, sometimes Python is the right answer, I guess, or Java or or even Bash. Although, I hope our colleague, Dave Pacheco doesn't hear me say this because he has told me that bash is never the right answer for anything unless you're trying to signal to people that you don't take a problem seriously.

Speaker 1:

That is correct.

Speaker 2:

Yes. Okay. Well, fair enough. But, you know, I still use Bash because sometimes

Speaker 1:

I used Bash this morning. Yeah. I got a gnarly Bash, got the nail right now.

Speaker 2:

I I gotta say, like, a a lot of things are are looking like a rust shaped nail for me now. Like, I I think that I I'd use it in a lot of different contexts, that that a couple of years ago or two and a half years ago didn't necessarily seem appropriate. But in terms of, like, the the crossing the chasm, I think it I don't this is not gonna be as as pinned down in terms of a timeline. And Brian, I've I've been curious to your answer, but I felt like, you know, in that sort of early 2020 timeframe, I went from thinking, you know, a couple people are using this or or it's even used here and there for sort of the inner loop of whatever to to looking up and seeing that anyone who is doing serious systems programming was kicking the tires on rust or or using it in a very serious fashion. And that dam sort of broke.

Speaker 2:

It feels like right around that time. Now I know that I'm biased and I've sort of like, now getting into Rust, but it feels more and more, like, around that time frame was when the the folks doing these kinds of systems problems really kinda jumped

Speaker 1:

in. Well, and that and that would dovetail with Steve's async await timing, honestly. So that would be, that's that's interesting. And so

Speaker 3:

it it doesn't have to be a feature. Right? Like, we're talking about basically, like, timelines of different populations of groups. And so, like, I I'm just saying that I think that's, like, around when it was, but I definitely think 2018 was, like, a bike shed year or a watershed year. Some sort of shed.

Speaker 4:

Quite. Was it was it bike shedding when you talk about which kind of shed it is? Is that

Speaker 3:

the That's right.

Speaker 1:

That's right. But, like,

Speaker 2:

yeah our bike shed moment. No. Yeah.

Speaker 3:

I feel like around 2018 Yeah. For whatever reason was, like, when stuff, like, really cemented itself and started taking off even more than it was previously.

Speaker 1:

You you know, I got on the Internet moments before the internal September of 1993. I got on the Internet in the fall of 1992. So the fact that I got in the rush in 2018, right before crossing the chasm, I think that that's, I'll take that.

Speaker 3:

Yeah. I I also the last thing I would say about crossing the chasm, I think it's really important that programmers understand where they fall on that on that line, and that can change for different things too because, like, you know, I was a super, super early adopter of Rust, but, like, there's like, I don't think I've like ever written a Dockerfile, for example. It's like, I'm like an extreme laggard on Docker, but I'm like super early in Rust and I felt much better about, like, various technologies when I understood how I felt about how early of an adopter I wanted to be and recognizing that other people are in a different stage in that area. And, like, a lot of a lot of arguments happen between people who, like, have an early adopter mindset versus, like, majority mindset, and then they talk past each other because they don't realize they're both getting out of or not getting out of the situation what they wanted just because they're coming from a different place in the first place. So I think it's also helped me deal with a lot of, like, arguing online about stuff, by, like, knowing that that thinking about the mental framework and figuring out where I fit into it for whatever technology we're talking about.

Speaker 1:

Yeah. That's interesting. And I also think that I mean, you're making an important point too that it that where you are in that curve may be more of a function of the problem you're solving and less a function of you as a technologist. That as a technologist, you may be an early adopter in one regard and then actually a late adopter in another regard, and that doesn't make you a dullard or a waggard or or, you know, what have you. But that that it it the and being kinda self aware of that is is is important.

Speaker 1:

Luke, I wanna get you in here because you've been in the Rust community for a really long time. And I like, did you have a sense of when the when the chasm was crossed? To the degree that I think I think we have crossed the chasm, I would assume.

Speaker 8:

Sure. I mean, I feel like a lot of my time has been spent lurking. Like early on I did like do a lot more like when I interned there and other stuff. But then after that kind of went away, you know, doing work stuff, life stuff, but kind of just keeping an eye on it in the background, like, just playing around with it myself. But I yeah.

Speaker 8:

I do think around 2018, right when async the MP MVP was starting to land was like, I think this could actually be a thing that I could convince someone at work that I could use. I actually remember writing, like, right before that release was cut, like, some little project with, like, Async, Tokyo, and all that stuff and then showing my address at the time. It's like, look at this. It was like, you know, I did this in, like, you know, a week and it does so much better than what we are already have kind of thing.

Speaker 1:

Okay. That's interesting, Ludwig. So that that is an interesting kind of acid test when you can go to a new technology and kind of catch up to where the exit technology is in a remarkably quick period of time. I do think that's a kind of a hallmark to when something is becoming really real. Yeah.

Speaker 1:

And so for me because I actually like, the thing that really drew my attention to Russ after I made it was like so Adam's terrific experience, like, never touching that. And but then the when honestly, Steve, and I don't know if it would would have been like maybe 2016, 2017. When was the green threads removed? 2014. 2014.

Speaker 1:

So it's before? Out of interest.

Speaker 3:

It was before 1.0. Yeah. Because that to

Speaker 1:

me, I thought that's a super interesting decision. I did because it felt very pragmatic and, I mean, very much aligned with my own experience and wisdom. But it felt and I'm sure that that was controversial at the time. Was that controversial at the time?

Speaker 3:

Yes and no. It it it definitely,

Speaker 1:

I think it depended on

Speaker 8:

who you were talking to. Some

Speaker 1:

people are all for it.

Speaker 3:

It it was also largely spearheaded by someone who was often the source of controversy. And so I think, also, some people were colored by nontechnical factors when talking about that at the time, if I remember correctly. Sorry, Luke, when you were saying something and I said something.

Speaker 8:

Oh, no. Yeah. I just I just remember thinking depending on who you asked, like, maybe some of the more people familiar with node kind of stuff were like, yeah, I know. Segmented stacks, green threads, that's great. Versus like people who wanted to, you know, run it on the PS 3 or what have you.

Speaker 8:

Or just like, we want libnative basically. And then the difficulty is like, well, how do you deal with like segmented stacks when you have like, you know, inline assembly and other other parts of the language that make it really difficult?

Speaker 3:

Yeah. Every language that's used segmented stacks is eventually removed them at some point. It's Amen. My understanding, basically. Yes.

Speaker 3:

Let alone you know, obviously, a lot of people still do green stuff green thread stuff, but I think segment and stacks is definitely, an idea whose time has gone, for sure. It it it's just it's the details.

Speaker 1:

So the reason that it kinda turned my head, I was like, I guess I found out about I've I've I've got the chronology wrong here. But the reason that it turned my head is because it does reflect people really trying to use the system. And I think that things will kinda happily use green threads when they are actually not really getting into the mechanics of getting something that is gonna run for a long period of time and run robustly. But when you are like, there are so many edge conditions. It feels like it's such a good idea, and it's such a long tail of disasters that are really, really hard to mitigate, that it it it that to me was like, okay.

Speaker 1:

Wow. This is actually, getting real and is is gonna be these are real systems. I came into Rust, for whatever it's worth, in the in I I've been meaning to look into it for maybe 6 months, 12 months by the time I got into it. The although one of my coworkers, Adam, Levinthal's me gloriously by maintaining that I I I that I was deriding Russ to him in 2013 or 2014. That's my way wherever you are.

Speaker 1:

Exactly. I so he I I he had cackled uproariously when I fell in love Russ because he felt that it was a grand comeuppance, and maybe he was. But the I felt like I was looking into Russ out of somewhat out of desperation, honestly, because I felt like the I just couldn't find a home for myself. And I'm like, if it's not gonna be if this is, like, my last best hope. You're talking about, like like, coming to Rust at a hope, Steve.

Speaker 1:

Yeah. And, actually, I think since then, the the the the the environment has actually improved. I think that there are other languages. I actually think this is in part due to success of Rust, is that Rust has shown that there's a space there, and other languages like Zig are starting to be in that space, and I think that that's actually really healthy. I think that that's a good thing.

Speaker 1:

I'm not sure your your take on that, but I I liked having having more languages experiment with different ideas. I think

Speaker 6:

it's good.

Speaker 2:

One thing I very good.

Speaker 1:

I one thing I I also wanted to get to, in addition to kind of pulling people across the chasm, I wanted to just because I know I'm gonna learn something. I wanted to hear people's, like, small features that have been added over the last couple of years that are really meaningful to their quality of life. And I've got a handful of these, but I'm I imagine other people have got got ones that I have not heard of or I have missed. The I I I mean, we we talked about inline ASM. Do you use const generics, Adam?

Speaker 1:

Is that something that

Speaker 2:

Yes. I do. In in a way that, like, is totally different than you guys. Like, I I remember in in Hubris, you guys being very fired up for that. And I got fired up for it in like a really dumb way for a, like an open API, SDK generator that I've built.

Speaker 2:

And this, like, this is such a weird use of Rust or like such a, I don't know. When people think about Rust, it's not for, like, calling, like, dumbass REST APIs or whatever, but, like, JSON schema. Okay. I'm losing everyone, like, by the second, lets you say define an integer that is like a multiple of 7 or fucking whatever. So I I use the comp generic to define that.

Speaker 4:

Oh, nice. I didn't realize that.

Speaker 1:

I didn't realize that story was gonna end so quickly.

Speaker 2:

Yeah. I thought you were like, you're like, oh, geez. This sub story is gonna go on and on. No. It's just like, unless you define a type that's like, here's a number that has some weird properties.

Speaker 2:

Like it needs to be between 12 and a 1000 and a multiple of 7 and cost generics are a way that like, I don't have to kind of do a bespoke type for each one, or it can be structural in the type rather than, you know, just like an input parameter or something like that.

Speaker 1:

Oh, that's very cool. And that's in for generator?

Speaker 2:

That's right.

Speaker 1:

Oh, that's what I need. Oh, cool. Okay. Yeah. So you'd alright.

Speaker 1:

Well, that answer that question.

Speaker 4:

You

Speaker 1:

definitely do. What what what are some other little ones that you are there other

Speaker 2:

I have another one that, like, only I give a shit about, which was, like, I write I I I'm not sure how to write Rust, is the first way I'm gonna say this, which is I think different people write Rust differently. Like, I you know, I've looked in and it's oxide is such a great case, and most of our repos are open, but you can find a bunch of Rust code that looks like C code. And, certainly, like, if you're in my neck of the woods, not that I'd recommend it, you can have Rust code that feels more like Go or Java or something like that. And you can have lots of folks who want to use a for loop for everything, and you can folks who wanna use a, like, for each on an iterator for everything. Is this an intervention?

Speaker 2:

I which one are you? You know which

Speaker 4:

one I okay. I've been

Speaker 1:

trying to get better. I've been trying to be more, like I'm trying to get more mappy, foldy, but I, you know,

Speaker 2:

I No. No. I'm what I'm saying is I'm way too mappy foldy to the point where

Speaker 1:

This is an intervention. This is an intervention. Look. I'll I'll change. I can get better.

Speaker 1:

I will use more I I will stop using for loops.

Speaker 2:

So No. So no. No. So, like, I I'm to the point where seriously, if I have to name a variable, I think I fucked up. Or if I have to have something be mutable, I feel embarrassed.

Speaker 2:

Although, like

Speaker 3:

used into iterator on option?

Speaker 2:

Yes. So that's exactly what I'm so that's what I'm go so not only if I use

Speaker 1:

iterator on

Speaker 2:

option, Steve, but I am using the bull has a, then.

Speaker 3:

Then? Yeah.

Speaker 1:

Yeah. Uh-huh.

Speaker 2:

I've been I've been using a bunch of bull then so that I can launch myself from the pedestrian world of of of, like, integral types into the lofty world of things I can I can, try with a capital t or iterate over or or or reduce? I'm saying this is a cry for help, not an intervention, Brian.

Speaker 1:

No. I feel like because I I I'm just not I feel that I myself, I try I'm trying to be more Mavi folding. And the and Clippy is trying to help me for whatever it's worth. Clippy is Clippy is like, you moron. This should not be a form of like

Speaker 2:

Do you ever Klippy recommend something? And you're like, okay. Fine, Klippy. Let's do it your way. And then the compiler's like, this

Speaker 3:

is terrible. Like, this

Speaker 2:

this is garbage. Come on.

Speaker 4:

Mom and dad are fighting. Exactly. Don't tell me that Clippy told you to do this. I mean, if Clippy told

Speaker 1:

you to jump off a bridge, would you do it? Of course not.

Speaker 3:

Yes. I would.

Speaker 1:

Actually, I probably would. Actually, I would go to Steve, and I would say, hey, Clippy is starting to jump off a bridge. That doesn't sound right. Could someone, please? No.

Speaker 1:

You really should be jumping off a bridge.

Speaker 3:

Okay. Fine. Jump off a bridge.

Speaker 1:

I think I think

Speaker 9:

it actually touches on something interesting that has been sort of a a detraction I've had for Rust. I just wanna start off off the bat. I'm a huge fan of Rust. I wish you nothing but success. But I think when Adam said that there's a lot of different ways to write Rust, I think that's totally true in terms of what you end up with.

Speaker 9:

But as a practice, I think one of the reasons that it's hard for Rust or was hard for Rust to jump over that chasm is because it kind of shifts the line about what a programming language is because I don't know anybody who understands how to write Rust without Rust analyzer in Clippy. There's a sort of Esperantoism of Rust where it's not really the language that anybody writes sort of unassisted or it's not their their sort of, like, first language. It's not the thing that they really think in. They have sort of a conversation with their tools in order to construct the program. I don't think that's necessarily negative, but it's very interesting.

Speaker 2:

It's a great point. And I think that one that sort of leans on modern, like what we can do do in a way that then becomes structural, but also important. I'll, I'll, I mean, I'll go one further, which is when I'm looking at code reviews in GitHub, I sometimes find the Rust unintelligible. Because it's like, you know, let variable name equals whatever. And I, and I am desperate for Rust analyzer to tell me the types of everything.

Speaker 2:

Like I'll sit there and assign, assign things to types, just so that Rust analyzer can help me figure out what, you know, what's coming out the other end. But but you're right that the these types have become extremely I mean, these these tools have become extremely load bearing for how, I guess, how everyone like rice rust.

Speaker 3:

Better ID support was, like, one of the number one things on the survey every year for a very long time. Yeah. For exactly that reason.

Speaker 1:

I I like syntax highlighting, which I also don't don't use. I have learned, like, not to bring this up in mixed company that I don't use Rust analyzer. I I I not pejoratively. I just don't end up, I'd and part of the reason that I'm not, like, mappy foldy, always because I it is easier. Although, again, I'm trying to get better about that and trying to, like, rewire my brain around it.

Speaker 1:

And it has it does, I think, yield better code. But but, sure, I think to your point, I actually do think Rust is becoming the way I think about a problem. Rust has become the way I think about it, I should say. I I it is my first language at this point. And, actually, I went back to write I at least I hope it's my first language because when I went back to write c recently, it was, otherworldly.

Speaker 2:

It was a very strange experience. Very, like, jeez. Okay. How do I pattern match again? Like, how what's the syntax for that?

Speaker 1:

I just feel like with c, I feel like I'm going, like, cave diving where I'm just like, okay. I've gotta go, like, triple check all the equipment. I've got, like this is a 100% on me, and a lot of people die down here. So I need to be, you know well, I'm not in the Rust swimming pool here where the like, nothing is gonna help me out. I need to be very, the compiler is not gonna help me out.

Speaker 1:

I've become very accustomed to the compiler helping

Speaker 3:

me out.

Speaker 6:

Does anybody feel that learning Rust has made them a better c programmer?

Speaker 1:

For sure. No question. It has made me a bet you because and that is, Dan, why I'm so I've got such trepidation. And I mean, I've I said this early on with Rust that the one of the things that we don't talk about enough with Rust is the integer safety. And the, with the one of the the most serious vulnerabilities in DTrace was an integer safety issue.

Speaker 1:

That Lint did not catch, the compiler did not no one, like, helped me. I felt like abandoned by everybody because and I had done something that is extremely common in c where you're saying, if bounds plus size is less than my limit, then it's good to go. And it's like, nope. Not necessarily. And no one is actually gonna actually check on that.

Speaker 1:

And if if if you have, integer unsafety, so I do feel it's made me a better C programmer, although also a more cautious one as a result. Dan, do you feel it's made you a better C programmer?

Speaker 6:

Oh, definitely. Definitely. And so I I went to our exercise a few years ago, rewriting MIT's x v six operating system in Rust. And, you know, having and and and that was really it was a very interesting exercise because having the c code next to the Rust code was fascinating because I saw bugs in the c code that only that I would've never seen had I not actively been writing in Rust and thinking about those things.

Speaker 1:

So did do do you have some little features that have been added over the years that you particularly like?

Speaker 6:

Well, so it's weird. I've spent the bulk of my time writing Rust code, writing bare metal code for large scale systems. So I never like, it it's weird. Async, was mentioned earlier, and and it just mystifies me. It's totally foreign to my experience.

Speaker 6:

When I got to Akhmed, I found myself writing a very different type of Rust than I have in writing. But definitely, ASM, oh my goodness. The new ASM well, it it's not new anymore. It's, like, 4 or 5 years old now. But the the the sort of stabilized ASM syntax changed my life.

Speaker 6:

All those weird, like, mix that you had to put in with the GCC style LLVM and line asm stuff. And it's like, okay. You put an m here, and I think that means a memory operand. But nobody really knows because this is all just kind of strange. And put a star there, and maybe it'll do something different, and maybe it'll do what you want.

Speaker 6:

Like, when when the new add them syntax came in, I was I was ecstatic. That just blew my mind.

Speaker 4:

Yeah.

Speaker 3:

I saw a tweet I saw a tweet recently that somebody said, like, if you show me some assembly written in gas syntax, I'm gonna assume that you're a serial in your spare time.

Speaker 4:

So, anyway, it makes sense.

Speaker 1:

Another one that I that happened, I guess, not too recently, maybe earlier in the year, but, capture identifiers and format strings. Do you use this, Adam?

Speaker 2:

This is where you can do, like, open curly name and variable close curly. Yeah. I I I, you know, a

Speaker 4:

colleague of ours, John, John Gallagher, was was using that. I was like, cool. I didn't know

Speaker 1:

It's really cool. And I like your cons generics where you've I I've got some residual shame over why I like captured identifiers so much format strings. Because I'm, like, I am strung out addicted to build RS, and, like, I'm a hardened I mean, this is actually where you do a you know, Drew, you've been making it or or your point that it's like, Rust blur some of the boundaries. One of the boundaries that it blurs in a great way is the boundary between the build system and the artifact. And build RS lives in in the this this kind of interstitial layer, And the ability to generate code programmatically has been, to me, has just been huge for programming of hardware software layer.

Speaker 1:

And that's actually ends up being, like, a lot of format strengths, and that ends up being a lot of variables and format strings. So it's, like, it's I have a guilty use case, but it's been liberating.

Speaker 3:

I like this feature for a obscure reason, which is it's very similar to the way that you do it in Ruby, which you have a pound first and then the curlies to put a variable to interpolate a variable there. But back when I used to teach Ruby, I used to explain to people to help them remember the syntax that the curlies are like little crab pinchers that hold the variable in place in that part of a string. And so for that then to end up in rust and the whole crabs thing, like, years later is, like, very satisfying to me.

Speaker 2:

That's awesome.

Speaker 1:

So Homecoming. I just Steve, what what what are some of your little the or actually, listen. I can see you. I'm getting there. Wait.

Speaker 1:

Do you have a do you

Speaker 4:

have a favorite one that does?

Speaker 8:

Yeah. I have a small one that was recent. New Cyclic.

Speaker 1:

Oh. Oh, okay. Tell me about that one.

Speaker 8:

It's just like you lets you create an arc. And at creation time, you give a disclosure that where you get the weak reference to it so you can store it or whatever. So you can create these like soft referential things much more easily without having to resort to a bunch of unsafe like we were doing in Purple's for a while.

Speaker 2:

So what what are you using this for?

Speaker 8:

Sometimes you just want to hold a weak reference to something

Speaker 1:

Okay? So just, like,

Speaker 4:

you know, just get off. Yeah. Friends.

Speaker 3:

Sometimes you just need to do

Speaker 4:

it. Right?

Speaker 1:

That's very cool. Yeah. I had not I that's a good example. So I mean, I that I knew it. I was gonna have a favorite thing.

Speaker 8:

Like, 1 dot 6 o.

Speaker 4:

Okay.

Speaker 1:

A couple months ago. Yeah.

Speaker 2:

Yeah. What's so cool is, like, in the run stocks, it tells you that. Like, 1.6 o, it puts it right next to it. I mean, there there's so many nice things like that. Where if you went to it and said, why is this not working for me?

Speaker 2:

It has it right there in the documentation. Like, why it's not working for you? And how you get to the version that does work? I I love this thing.

Speaker 8:

Right. And a little older one is not needing to put externcrateblah everywhere.

Speaker 1:

Oh, yes. Superbure. When did that stage because that that's one of those things that I think I didn't even notice had happened. I think I just forgotten extern crate, and I was just no longer being yelled at by anybody. And I

Speaker 6:

That was 2018, and that was magical. Magical. Like, actually, real deterministic syntax for figuring out what is coming where with with respect to a crate. That was a game changing feature for

Speaker 3:

sure. There is a little extra crate in Hubris still, Brian, so you'll have to remember at some point briefly.

Speaker 6:

You have to do it for Alec. Like, if you're implementing Alec yourself, then you're kinda you you have to do external create Alec, but that's kind of the only one I did.

Speaker 8:

You have to do it for macros for a while?

Speaker 4:

Yeah. Right.

Speaker 1:

That's right.

Speaker 4:

I mean, I remember doing it for macros.

Speaker 2:

Yeah. I still bumped into it with some older crates that are still doing it for macros.

Speaker 1:

But Steve, did you just step on a dog toy? That is

Speaker 3:

fantastic. I did, actually. I did step on a dog toy. Yep.

Speaker 1:

I was like, this is doing nothing for my view of you having a 1940 sound effects reel. They it are you waiting for, like, a cloud horn?

Speaker 3:

But those

Speaker 4:

of you

Speaker 3:

who don't work at Oxide, I have this, like, program I run on my camera where it filters out everything behind me so it only shows me. And so there's, like, a joke the other day where I had the dog. I, like, took that down or whatever, but it's like, oh, you can finally see what's in my apartment. So this is kinda like the opposite. Now everyone's, like, hearing what's in my apartment, like, mapping it out.

Speaker 3:

The CIA

Speaker 4:

I am.

Speaker 3:

Out my apartment by the noise or whatever. Yeah.

Speaker 4:

I thought

Speaker 6:

it was just how excited you were about not having to write external credit anymore.

Speaker 3:

I definitely was psyched about it for sure. I have my list is a little strange because it's a it's a tooling feature and a not actually stabilized yet, but should be soonish kind of feature that I will enjoy a lot. And then also a ridiculous analogy, back to the earlier bit about programming languages, growing what a programming language means in Rust analyzer stuff. The thing that I the the biggest, like, small thing that's a big thing for me is RustUp can now get link dot exe on its own from Microsoft instead of you needing to go download the Visual Studio tools and install all that

Speaker 2:

crap yourself.

Speaker 3:

That is, like, super, super clutch for people getting started on Windows because it's, like, the number one step that, like, you get wrong and it's, like, a big giant pain. And I don't even know how they did it because Microsoft doesn't distribute that stuff independently for whatever weird reason they do, but however they did it, I don't even care. They just it works now. So in the latest Rust up, if you install it on Windows, you don't need that

Speaker 1:

the ability to to write programs for Windows would be so low bearing for myself. But at Oxide, because of the double e's in particular, have a lot of tooling that is only on Windows, it has been I mean, singularly valuable to be able to generate software that runs on Windows. So that's actually that's really important. That's great to hear.

Speaker 3:

Yeah. The, the one that I think is, like, super maybe life changing is a little wrong, but I think is really awesome, is not quite stabilized yet is the x86 interrupt ABI. So Dan referenced xv6 before, but like, classically, you know, xv6 has a Perl script that generates the assembly, that's the prologues, and and, afterward for all of your interrupt handlers. And, like, the way that's always been done since the basically, the beginning of time is to always push and, you know, pop the state that you the state for every register that could be possibly mangled by your interrupt handler because, you know, you don't necessarily wanna think about exactly how that's gonna be cogent and all that stuff. But when you had the x86 interrupt ABI, now you can just write a normal Rust function and it will, like, cogen for you and it knows which registers it's using and not using, So it'll only push and pop the stuff that you actually use based on the actual cogen of the stuff that you wrote.

Speaker 3:

So it actually be, like, more efficient and it's easier because you don't need to deal with, like, developing all that stuff stuff yourself. You can just be like, This is an interrupt handler. Please make it callable appropriately for me, please. I think it's a really cool, like a thing that you maybe assumed couldn't be done by a compiler, but, like, actually can, and it's both easier and better, which is, like, extra wild and awesome.

Speaker 6:

I'm gonna agree. Push back on that. I I I and the reason why is that very often in interrupt handler, you want to manipulate the state that you're gonna return to. So you actually need, like, a mutable reference to a data structure or something that has all the contents of the registers on it. So usually what you end up doing is creating some data structure in assembly language that you sort of push onto the top of the stack, and then you pass a pointer to that as an argument to the actual handler function.

Speaker 6:

And, like, I mean, I hear what you're saying, Steve, and I'm I'm I'm I actually kind of apologize. I'm not trying to be a

Speaker 4:

a jerk about

Speaker 6:

it. But I just I I remember seeing that, and I was like, oh, that's kinda nifty. And then I I kinda thought about it, and I was like, actually, it doesn't work for my use cases. So I've never, unfortunately, used it.

Speaker 3:

Totally. Yeah. I mean, this is the thing about this with the super low level stuff is that, like, you know, it'll be useful for some people and not for others. Like, most of my most of my usage of that feature is, like, messing around with toy OSes, so I can, you know, not do those techniques. So it's more meaningful for those kind of things, I think, than it is necessarily for everybody for sure.

Speaker 1:

And the RFC is in the interrupt calling conventions RFC. Is that right? Am I

Speaker 3:

right? Yeah.

Speaker 1:

I think yeah. So that's from Philip from who Yeah. Wrote the the blog OS. Yep. So that's that's interesting.

Speaker 1:

That's that's coming from.

Speaker 4:

Cool. That's yeah. That's that those

Speaker 1:

are at opposite ends, I I feel, of the stack, Steve, in terms of your Yes. The the honor downloading.

Speaker 3:

Definitely. The the the silly analogy thing is is I think so it's just, like, a little more than a programming language, and there's also, to some degree, about the, like, does it make you a better c programmer? I think that there is a deep affinity between Rust's viewpoint on the world and the way that the Dutch build roads, which basically is like it's it's so okay. The way do you know how we set speed limits in the US? What we do is we, like, we, like, send an n turn out on a sunny day, and we watch all the cars drive past, and we knock off the top 15%, and then that's the speed limit.

Speaker 3:

So we, like, build a road, and then we observe how people act, and then we set the rules based on how they act, which is, like, a problem for safety because you get spaces that are designed purely for cars and car speeds and, like, all that kind of stuff and the Dutchman and everything else. The way the Dutch view building roads is they actually have a now they have this classification system, and there's 4 different kinds of roads. I won't get into that thing. But the point is is they look they go, okay. This is a residential road and a residential street.

Speaker 3:

Therefore, for safety reasons, we want cars to only go 25 miles an hour. Therefore, how do we design the road so that a driver will feel that 25 miles an hour is an appropriate speed to drive, and they don't even necessarily need to, like, look at the speed limit sign or, like, feel limited by the speed limit. It should just be the natural way that you drive. And so there's techniques and tools that you use to, like, make that happen when you're designing a road.

Speaker 1:

We're just gonna make this road, like, shit scary at 30 miles an hour.

Speaker 3:

Yeah. When you, like, put up a lot of trees along the side, you make the things narrower. Like, one of honestly, one of the biggest differences we believe in the US that you make roads safer by making them wider. Turns out that means people feel more comfortable driving faster, and it actually makes roads more dangerous. So they'll actually make very narrow roads with like, speed bumps and stuff, sort of things like that.

Speaker 3:

I could go on with this a long time, but it's not the Dutch road building meeting space or whatever. But Russ, Russ' attitude is, like, is, like, different in that, like, more similar to that in that, like, we're gonna construct an environment where you don't have to think super hard all the time because humans are fallible and make mistakes and they get tired and they maybe drink a little bit and, like, you know, all these other things that happen. And if we can construct an environment where you can do stuff and a compiler will be like, no, no, no, actually, like, you know, I'm gonna nudge you towards right thing, it means you don't need to put as much cognitive load on these things that don't matter, and you could think about your problem a little bit more, as opposed to, like, necessarily needing to remember. Like, because when I go back to Ruby, for example, like, now, I'm, like, terrified because there's no thing that checks to tell me if what I'm doing is ridiculous. Like, when I write Rust, I'm, like, not thinking that much because I know that the compiler has my back.

Speaker 3:

And so I rely on it, like, to to handle all these things that I don't get in other languages because we've created this environment in this way that guides you towards an appropriate, you know, part of the space. And so I think for me, that's like it's not even so much that I, like, become a better programmer in other places. It's just that I realize how much other languages are, like, let's widen the roads to make it safer, when that's, like, not actually the right way that you make things easier for programmers. Like, giving people ultimate amounts of choice really ends up meaning they drown in thinking about all the details too much whenever what we really need is to, like, create a thing that will get you to do the right thing without needing to think about everything all the

Speaker 6:

time. Okay. I have to I have to jump in here because this really brings home something for me that that I think is a is a big deal. Especially in the systems programming community, there is just too much gatekeepering, and I think so much of that is based on kind of the corollary to what Steve just said. It's this idea that people can keep all that complexity in their head with languages like c and c plus plus, and therefore, they are somehow better qualified than the people who are mere mortals like myself who just can't.

Speaker 1:

Yeah. It's

Speaker 6:

Yeah. And so therefore, they look at a language like Rust and it lacks I'm I'm you know, the machismo or whatever you wanna call it of a language like c where they're like, look, you know, I I can I understand undefined behavior, and I've read every word of, you know, the c eleven spec, and I can apply it this, you know, forwards, backwards, and sideways? Therefore, I am better at doing this than you are. And I feel like that is a huge, huge barrier to entry to, say, doing carnel development. And I'm actually really glad that Russ takes the opposite approach.

Speaker 6:

They kinda like, no. Let's make the roads narrower, and let's, you know, decrease the surface area with which you can cut yourself because it turns out that's actually really important.

Speaker 5:

And I think that that's gonna

Speaker 6:

democratize things and make it easier for people to get involved.

Speaker 1:

Totally. And then the compiler can actually help you a lot. That's, to me, is, like, the big I I did not think you and, Adam, just you said you didn't feel you could love again. Maybe those weren't your exact words.

Speaker 3:

No. That's how

Speaker 1:

it was.

Speaker 2:

Yeah. Or even love for the first time.

Speaker 1:

But yeah. The but I felt that, like, the compiler was just always was a burden. It was not something was something to be dealt with, not something that could actually help me write better software. And, Dan, just to your point of, like, that's what Rust does. And, Steve, you might not have seen it.

Speaker 1:

Dan had a had a tweet during our conversation. I think it's pretty interesting about when he felt the chasm was crossed. And I didn't I think it was a very good point. The hard copy publication of both the Rust programming language and programming Rust, which Yeah. That was really and I remember buying both of those at the same time and reading both of them, and I totally agree that that's a good point about the the the chasm being crossed then.

Speaker 6:

When when we were advocating for switching Hyperion to be written on Rust from c plus plus at Google, we had to write a document to justify that. I mean, that was an extraordinarily controversial decision. And so myself and the, you know, and the tech leads sat down when we wrote this doc, and that was one of the big data points. And I was like, look, people have committed to putting these words onto dead trees. That means that language no.

Speaker 6:

I'm I'm totally serious. I mean, that means that this language has reached a point of maturity where people are basically betting that it's not gonna change that much in the future. And that means that it's gonna be relatively stable for us to program against. And that was huge.

Speaker 3:

Interesting. It also is huge for the book market because after people saw how well both of those books did, that was also why you see this, like, a year or 2 later, a giant explosion in the amount of books that were written on Rust because everybody went out and bought both books. And, like, people looked at that and were like, oh, holy crap. Okay. This is a real thing, and therefore, publishers started soliciting more authors and, like, all that kind of stuff.

Speaker 3:

So it definitely was, yeah. Totally. That's cool. Big moment.

Speaker 5:

I'm also thinking of John's book that

Speaker 6:

came out in the past year. Yes.

Speaker 3:

Oh, yeah.

Speaker 1:

That's so good. That

Speaker 3:

Rust for Rustations.

Speaker 5:

Rustations. Yeah. That one is, absolutely phenomenal.

Speaker 1:

Okay. I didn't you know, I have not read that yet, and I'm gonna I'm buying that now.

Speaker 3:

Oh. That You definitely should.

Speaker 5:

Like Yeah. Like, sitting like, the I I'm trying to remember, like, 2018 because that's when I started writing. And or or 2019, early 2019. And I think it was actually John who's Twitch streams I found. I was, like, in the programming section because I was, like, watching just random things on Twitch, and I was like, oh, you can, like, watch people program.

Speaker 5:

I think that's pretty cool. And and then it's kind of cool to see that come full circle. I know if anyone else here, feel free to chime in if any of you have seen his streams, but they're pretty sweet.

Speaker 3:

I've heard many people express that opinion. I personally haven't watched them, but I really like the way that John teaches stuff, and I'm sure they're great.

Speaker 1:

Yeah. Yeah. I'm I'm sorry. I can't talk ordering book. I've no.

Speaker 4:

I I I

Speaker 1:

I'm I'm literally ordering the book right now. And unlike, you know, normally, I'm I am I'm I'm being a skinflint and, you know, spending a dollar 98 for a used book. This one's I'm buying new, baby. This one.

Speaker 2:

You you and me both, and I'm expensing it.

Speaker 1:

I'm expensing it too. That's why I'm buying it new. I feel

Speaker 4:

I, yeah,

Speaker 1:

I I I feel like I can't make Pierre de la Man pay for, like, the 15th history of tandem that I'm buying. But, you know, actually, the the the frustrations I feel we can put on the company is nickel.

Speaker 8:

But, you know, like, speaking of those videos, the one that I always go back to is the atomic and memory ordering one because it is It's so hot. Explain. I mean, it's just that. It's like I feel like it's really hard to get those subtle details right. So every so often, I'll just, like, rewatch, like, the relevant part, and it's, like, so well explained and definitely elevated my understanding of them.

Speaker 1:

And this is And this is 8

Speaker 3:

stream? Well, I think you watch it

Speaker 8:

on YouTube. Like, it was definitely live stream, but you can watch, like, you know, the VOD of it.

Speaker 5:

Yeah. John John, he he he switched to doing, like, crust of rusts, and I think they're, like, a little shorter format, and they get reuploaded to YouTube. So I'm gonna call it, like,

Speaker 4:

a little

Speaker 1:

short. It's,

Speaker 8:

like, 2 and a half hours.

Speaker 3:

Yeah.

Speaker 4:

But it

Speaker 3:

has to show off.

Speaker 1:

That's awesome. That's definitely something to check out. Ben, I you I I know you were looking to get in here a little while ago.

Speaker 10:

Yeah. Among the the recent features that

Speaker 6:

that hit home, I I

Speaker 10:

I feel like I have a a a niche one and a more common It

Speaker 2:

When you're when you're muted muted, we're getting we're getting some echo from you.

Speaker 10:

So the in in searching for, UB in various published creates, I found, Rayon and protobuf were doing, invalid out of bounds get unchecked in order to access the uninitialized region of a back between the length and capacity. And that seemed interesting. Yeah. Especially because the the valid way to do this in Rust used to be a little bit complicated, at least especially for for what Rayon was doing. Right?

Speaker 10:

When I when I raised this with the the Rayon authors, they said, oh, you know, we actually wanna have a slice to that region. We wanna make sure that the lifetime is correct. And so they they didn't just wanna use pointer arithmetic directly from the from the pointer in the back. And so there was an unstable API to do this. Right?

Speaker 10:

Spare capacity mud. And so I just commented on the tracking issue, and I was apparently the only one who'd really noticed that there was a lot of need for this. And it just got stabilized pretty quickly after that, which was which was really interesting.

Speaker 3:

That's awesome.

Speaker 1:

That was really satisfying too. It wouldn't be like, hey. I was able to kinda connect these get connect this kinda effort over here with the need over there and help make it happen.

Speaker 10:

Yeah. Yeah. It was it was one of those experiences where I'm I'm not sure if people knew that they needed this, and now I'm now I'm wondering how much we'll be able to get people to actually, use it, but I'm I'm hoping that people find it in the docs when they're actually looking.

Speaker 1:

And this is you said it's and I I'm also gonna reveal that I think maybe I I mean, it's a common theme that I mispronounce things, but I say mute when I read it aloud in my I do too. You do too. Mhmm.

Speaker 10:

I I go back and forth, honestly.

Speaker 2:

Good. Is Wait wait. Wait. I'll only be wrong half the time.

Speaker 1:

Is this, like, rust cube cut over this cube CTO is whether Okay.

Speaker 10:

Oh, no. Okay. We gotta talk about this. You got me started on Cuddle, and nobody else that I have talked to says that.

Speaker 1:

Says Cuddl.

Speaker 6:

Sorry. This is I I I told the MX card here. This dates back like, 19 yeah.

Speaker 1:

Are we talking when you say, like, I personally got you started on that because I Yeah. Oh, boy. Yeah. I I I realized that, the I had the I was in a the changelog podcast a week and a half ago, and someone said, you know what? I realized after listening to this podcast that I've been mispronouncing the word n a d I r.

Speaker 1:

And I'm like, no. No. No. Wait. Actually, stop.

Speaker 1:

Before I think I may be mispronouncing it. How do you pronounce that word, Steve? Nadir? Do you? Is it because of me or did you make it no.

Speaker 3:

I just that's what it looks like. It should be that's a little how it looks to me. I don't think I've ever heard you say it.

Speaker 1:

Okay. Good. Oh, god. Thank god. God bless you.

Speaker 1:

I if this is just part of the the the larger intervention around fold and map and fold, that's fine. Yeah, I do say Nadir, but, Adam, you say Nader.

Speaker 6:

That's right. Sorry. Brian's in Brian's in the clear here. It is Nadir.

Speaker 4:

Brian's in the clear.

Speaker 1:

Dan is waiting. Alright. Oh, benevolent Dan. Weigh please weigh the hearts of the those before you. Are maybe you could pronounce it either way.

Speaker 1:

So I don't know. Kuddl, I think you gotta put that in the maybe in the other either bucket. But I do say mute when I am reading Rust aloud to myself. Adam, do you say mutt or mute?

Speaker 2:

I try to avoid it entirely by not having anything be mutable.

Speaker 1:

Oh, are you a safe

Speaker 4:

Well, from the high ivory tower of mappy foldy

Speaker 3:

Don't don't even declare a variable as mutable if you don't declare any variables

Speaker 2:

in the first place. So

Speaker 1:

Aren't you a saint? Shouldn't we all live like Adam and never use the keyword? Adam's like, is that even a keyword?

Speaker 4:

I don't even know. I don't

Speaker 2:

I don't know what you're talking about. It's a new language feature I've never seen. Is this what we're talking about? Can I just add this?

Speaker 5:

There is definitely this, like, addicting element to, like, like, start using closures and pattern matching. And it's like, I wonder how few statements I can write. I'm not sure if anyone else has ever gotten that sort of power trip before, but

Speaker 2:

it's gonna

Speaker 5:

happen a few times and totally unnecessary too. I'm just like, I just wonder how far we can go to have this road.

Speaker 6:

I I feel like I feel like like Rust programmers go through these stages when they first start out. It's like you start out fighting the borrowing checker, which, you know, is something of a controversial statement, I believe, but everybody kinda goes through that. And then it's like, oh, wow. Traits are so cool. Let's use them everywhere.

Speaker 6:

Yes. Traits gone wild. He's

Speaker 1:

a Yeah.

Speaker 6:

Yeah. And then it's like, what are the other neat features of the language that I can use? And then after, I don't know, I wanna say, like, 6 months to a year, people start writing pretty reasonable code that starts to seem idiomatic. But it's like, it definitely takes a while to come up to speed and and become, like, a proficient idiomatic rep for car.

Speaker 1:

Yeah. And I I feel like also, at least early on, I feel I needed a cliff to bless some of the things that I was doing as there's not a better way to do this. I feel like with Rust, it it Rust is constantly driving you to think, is there a better way of doing this? And it can be helpful from an experienced frustration to be like, actually, that's basically that's pretty good.

Speaker 3:

There's a blog post I can't remember that's, like, about stages of somebody writing a programming, like, like and they they show them writing, like I think it's a lisp. Like, they're like, write like, and then they just learn Haskell's. They write that function this way, and then they learn Ruby, and they write it that way. And it's, like, showing different styles of programming, but I cannot remember what the name of it is whatsoever.

Speaker 6:

There's one where, like, the Haskell programmer discovers point point arithmetic and things of this nature. And And then, like, at the and then and it's like writing hello world or something. And then, like, at the end, they get back to the original program written. Like, oh, wow. That really simple program is actually pretty much the way that you do it.

Speaker 1:

Totally. Hey. Hey. I wanna get to a small feature that, Adam, I discovered in looking at what small features I might have missed just in preparation for today. Nice.

Speaker 1:

Cargo ad. Have you seen this?

Speaker 2:

Yeah. I did see that recently. And it and it because it adds it to the Cargo TOML. Yes. It gets the resources.

Speaker 4:

It is the best.

Speaker 2:

And you don't have to sell it yourself with, like, opening an editor.

Speaker 3:

I've wanted it for so long. I'm so glad that Epage was able to put in so much work to make that happen because it was great.

Speaker 1:

Yeah. It's that that I mean, and that's one of the things that I'm sure was, like, a bit early to actually do, honestly, because it's kinda rewriting you know, it's rewriting one of the files that you got. And, but that is the that one, I have not used yet because I only discovered it, like, you know, 15 minutes before we started, but I'm definitely putting that on the list. Another one that for me, I love, Steve, that I I don't know what your take is on. Links in Rust doc, I actually find really valuable.

Speaker 1:

That's a

Speaker 4:

good one. It's not that That's

Speaker 5:

really important to note.

Speaker 3:

To a lot of discussion. So good.

Speaker 5:

For forgive me for interrupting. My bad.

Speaker 3:

No. I was just saying, unfortunately, I need to go because it's getting a little late here.

Speaker 1:

So I I which is a great segue. We we are I we're we we definitely wanna wrap. I know we've gone on a a bit long. The, absence party, You wanna

Speaker 11:

Yeah. That's me. Zeeshan. I would say I think, 2 things to say really quick. I I think you mean Kyle Kingsbury's typing technical interview?

Speaker 3:

That's definitely related. It's not the one I'm thinking of, but it's definitely a similar one. It's very good, and anyway, everybody should go read that for sure. Absolutely.

Speaker 11:

Yeah. Yeah. I Anyway, I was just gonna say, obviously, the the Rust links as well is, to me really huge, because also the documentation in Rust is a big thing to make people understand, like, why this language? I think it's just another reason why it showcases, like, oh, like, we're doing this. You can actually read about what's happening.

Speaker 11:

There's really good docs. A lot of languages kinda suffer from really great documentation. So

Speaker 1:

It definitely do. I know I'm I'm sorry to take the wind out of your sales, but

Speaker 5:

I got I'm I'm glad that you're gonna say

Speaker 1:

the same thing. I actually I love Rustoc. I know, Adam, you've used it a ton, and made great use of it in in and elsewhere. So it it, it's a terrific attribute of the language. Well, this has been, Steve, thank you so much for joining us, Steve Lukman.

Speaker 1:

Yeah.

Speaker 3:

Thanks for having me.

Speaker 1:

It's great. I mean, you YouTube obviously been in this community a lot longer than than than we have, and I've got a lot of longevity here and and great perspective. But, honestly, it's been so great that Rust I think unlike so many things I use where updates are something to kinda dread because they're gonna break things, I it's like wrapped presents under the tree on Christmas morning and waking up at, like, 5 in the morning to go unwrap them. It's really exciting to move to the

Speaker 6:

latest. So

Speaker 3:

It's gonna be 10 years for me in December. So I'm finally gonna be able to answer all those job ads that need 10 years of Rust experience. Exactly.

Speaker 1:

Nice. Awesome. Well, hey, Adam. Thanks for the tweet too. They they got us kick started on

Speaker 4:

this one.

Speaker 1:

And and and in the end of the movie, did your heart grow 3 times as large? Would you like

Speaker 2:

At at least. At least.

Speaker 1:

Awesome. Alright. Thanks, everyone. We're gone next week, but we'll be back in 2 weeks. I'm

Speaker 5:

looking forward. We got a a guest lined up for

Speaker 1:

2 weeks. I'm looking forward to that. Alright. Thanks, everyone.

Speaker 4:

Talk to

Speaker 1:

you later.

Speaker 7:

Peace.