Algorithms + Data Structures = Programs - Episode 107: Jane Losare-Lusby on Rust! (Part 2)

Episode Date: December 9, 2022

In this episode, Conor and Bryce continue their conversation with Jane Losare-Lusby about the Rust Programming Language.Link to Episode 107 on WebsiteTwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Jane Losare-Lusby is currently on both the Rust Library Team and the Rust Library API Team. She is also the Error Handling Project Group Lead, the Rust Foundation Project Director of Collaboration, and a Principal Rust Open Source Engineer at Futurewei Technologies.Show NotesDate Recorded: 2022-11-02Date Released: 2022-12-09https://cheats.rs/ADSP Episode 106: Jane Losare-Lusby on Rust!Rust std::slice::iterRust std:IntoIterator::into_iterC++20 ConceptsRust TraitsC++ Pattern Matching ProposalC++ Pattern matching using is and asO3DCON 2022: Keynote C++ Horizons Bryce Adelstein Lelbachwww.crates.ioADSO Episode 92: Special Guest Kate Gregory!C++Club Episode 155: WG21 October mailing, Carbon, Cpp2, SafetyIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Right now, the prevailing attitude is more aligned with your attitude, which is like all the programming languages, like there's not one right way to do things, that all the programming languages have value, and we should all be learning from each other. Welcome to ADSP, the podcast, episode 107, recorded on November 2nd, 2022. My name is Connor and today with my co-host Bryce, we continue part two of our conversation with Jane Lazari-Lesby on the Rust programming language. Be sure to check out part one, link in the description if you haven't yet. So the difference between Intuator and Iter is Intuiter is a trait. Iter is a function with a name that is by convention. And so Intuiter, with a vec, you can take a reference to a vec

and put that in parentheses. So ampersand, vec variable, identifier, parentheses, dot Intuiter. And that will do the reference to into iter trait implementation. So it's like a reference to any type that implements into iter will do, or I think it might actually be a direct implementation on reference to VEC. I'm not positive on that one. Whereas iter is just a free function associated with the vec or possibly the slice type that will just basically do the exact same thing that if you were to give it a reference in front of it, when you call the intuiter, it's going to give you a iterating over references iterator.

Whereas you call iter, it's always going to just do the iterating through references iterator. And so calling iter is useful in situations where you don't want to have to deal with like adding that reference at a time you just want the auto ref to like handle getting through going through the slice or dereferencing or whatever is necessary because it's like it knows the exact type it's going to be resulting to versus into iter it's generic receiver and so it can you could run into inference errors sometimes or you might end up like iterating by owner, like owned values or something. And like Intuiter is more flexible in that,

that like you can have like owned iteration or non-owned iteration. And it's actually implicitly called in for loops. So when you put, when you add the iterable item to the, like the second expression, the for. So you have for variable identifier in expression that is expected to be a type that implements into iter. And iterators, the iterator trait is reflexively

implemented for Intuiter. So if you give it an iterable type, it just automatically is itself. Or I guess that's an identity conversion. And, but like, if you were to just give it a VEC with behind a reference, like a variable name to the VEC behind with an ampersand in front of it, then it will iterate by reference. If you did a mutable reference in front of that VEC,

it would iterate by mutable reference. If you just did the VEC itself, it will take the VEC by like own value, take it apart and iterate by value and destroy the original VEC in the process. And it's like, all you have to do is like what reference you put in front of that variable determines how it gets iterated by the Intuiter trait. Interesting. Yeah, that makes sense. Because I think one of the times that Clippy modified it from an Intuiter to iter was when I was using the Windows function, which I think was returning slices or something like that. So that makes sense then because it was potentially unnecessary what I was doing there.

Cool. I have a question now. How do you write traits in Rust? How do you express a constraint? The way that it's done in C++ I find very quirky. So in C++, it's done essentially through these usage patterns where you say like, oh, suppose I have an object X of this type that I'm constraining. And then you have to be able to be able to call this thing on X and then that thing on X. And if you call this thing on X, it returns this type. So what's it like in Rust? How do I describe a trait in Rust? So it's, I can't remember the formal terms, but basically, instead of describing what the type needs to conform to, it's kind of like an abstract class sort of thing. Like you're describing the interface.

Yes. And when you implement it, you implement that interface within the impl block of the trait. So for like, normally, if you're defining like a free function for a type, you like open up a block that's like impl type and then open block. And within that is where your functions go.

And you can like have a self as one of your parameters. And that's going to refer to the type in the impl block etc etc when you're doing the trait function implementations you're going to do impl trait for type and but otherwise it's going to be the same thing but like the functions in there are going to be only the functions that are defined in the trait you can't just put like random functions in there. And if you like implement that exact function in like a just as normal impl block, it doesn't get associated with the trait. It is like it has to be in the traits impl block. And you might be able to have the same function name in two places and then just cause like fun ambiguity errors where

you have to like specify the like the long form like at like type as straight colon colon function name or something like that i'm pretty sure that works but not recommended most of the time it's probably just gonna cause problems so that that's sort of how i want to be able to write concepts in c++ but can't and there were proposals at some point in the history of C++ that allowed you to write concepts like that, but they went away, is the polite and simple way to say that. If I could ask a question about C++, how's the pattern matching proposal,

or the patterns proposal going? I know there was like some work there. It's not? it's not. C++ 29? The thing is that a lot of development of a large part of the feature set of C++ has stalled because the C++ committee process was not well prepared for the pandemic and the C++ committee, admirable attempts were made to adjust to the new world. But the reality is that a lot of work stalled out over the past two years.

So there's a proposal that two years ago looked like it was on track, but I don't have high hopes for things that have not made progress in the past two years, even if they were in good shape two years ago, because it's disruptive best practices can change i think people are maybe surprised to hear that but that the best practices you know within even within a big language like c++ that moves slowly the best practices do evolve um like we the people who are building language we learn over time um mostly through making mistakes and then we're, you know, we don't want to do that again. So, you know, we should do this instead. And so the best practices evolve.

And then the more time that your thing goes without being updated, the further and further away it is from the state of the art. And that makes it harder for something to come back, even if it was mature before. And I think that this is ultimately what happened to some of the bigger features of CFUS Plus in recent memory that have stalled out or that the committee has in some way rejected. Like the networking TS is one. It was something that was evolved in the mid-2010s and we published a TS on it and we got it pretty close to being ready to go into the standard. But then the best practices changed a lot and then there was resistance to updating it and also it was a big thing.

So when you've got a big proposal that nobody on the core team has looked at in two years it's going to take a while for everybody to get familiar with the thing again oh yeah um and then that means that it takes longer to get started working on it again and then it becomes more out of date and it just if you're not constantly making progress on a thing uh uh it's more likely than not going to become abandoned yeah yeah no i i i know that from library teamwork like it's the longer the gaps between reviews the the more just the more difficult it is for like everyone involved or it's like we see this a lot um with like software updates like uh at nvidia um it's been a a um a struggle over the years for me to get various internal teams and sdks to move to newer compiler versions and to drop older compiler versions.

And one thing that we repeatedly see is that if you update from upstream once a month versus once a year, you're actually doing less work if you're doing it once a month. You might think, oh, well, we update once a year and it'll be 12 times as much work than updating once a month. But it's actually probably more like 20 times or 40 times because the cost of making all those changes all at once instead of doing them incrementally is far greater. You're not able to start making changes naturally as things evolve. You end up in the situation where you're like, oh, now we have to do this whole big refactor to update to the newer thing.

And then, of course, that takes time and then that means that it's longer until you've updated to the newer thing then there's more changes that you have to deal with and again you end up in this uh death spiral of uh of sadness i mean on that negative note you did still highlight it in your top three bryce just gave a keynote a week ago at o3d con in texas and one of his top three future c++ features was pattern matching so yeah it's good stuff those top three features that i highlighted were um a reflection um pattern matching and um and senders and uh i mean there's like channels yeah more or less yeah i'm gonna say yeah and there are a bunch of people who i work with who um may be upset at me but yeah you have the basic idea

okay um but yeah i mean i think those are are the most transformative things that C++ could do outside of, you know, obviously I think the whole question of package ecosystem is probably more transformative. I've said for like a while, the single most important thing C++ Committee could do is to figure out a story for the packaging ecosystem and then improving the C++ Committee evolution process.

I saw something on Twitter earlier today that really stuck with me, which was something in the effect of junior engineers think about how are we going to solve this technical problem? How are we going to do this thing? How are we going to execute this thing? Whereas senior engineers think about, is this team positioned for success? Do they have the support that they need? Are their metrics and their KPIs set up in a way

that they're going to be successful? Are they happy, etc.? That really came true with me. That's one of the reasons why I care so much about the health and the...

What's the word I'm looking for? And the modernness of the evolution process of a project. Because if your thing can't evolve and improve, it doesn't matter how good it is. Eventually, other things that can evolve and improve faster will outpace it. Preaching to the choir. Yeah. I didn't mean, I didn't even, when I was listening off all this stuff, I didn't even mention, yeah, the package system crates.io. Yeah. Although I do have a bone to pick with rust here oh um so my understanding is that the rust uh crate system is

uh still as a model where everything is built from source yes yes and there's no binary distribution? No, but they're looking at starting a project right now for a safe AVI. So we're going to look into trying to find a way to have a subset of the language that we can expose as a stable AVI without having the entire Dyn linked AVI be stabilized? Yeah. So my bone to pick here is essentially, I don't think it's sustainable in the long term to have a package ecosystem that's solely from source. And it's for two reasons. One is a scale. As you get up to building at larger and larger scales, it's increasingly difficult to build everything from source. Now, of course, for a language like Rust, where the static analysis is sort of a key element of the language, this is, of course, a challenge. But the other piece is closed source code, which, while I am an open source person and have pretty much only worked on open source projects my entire career, including most of my time at NVIDIA, you know, the reality is that closed source is out there. And I think for Rust to be truly successful and

become a top, you know, five or a top three language, it will need to support that part of the ecosystem as well. And, you know, I think for Rust really to truly become one of those top languages it's not sufficient to just have all those closed source projects be limited to oh well you have to expose your closed source stuff through a C-ABI

you know or C++ ABI I think people are going to want to write things natively in Rust and so that is one thing that I have said for a few years, I would expect Rust to evolve on. And I'm glad to see that there's now some movement in that direction. Not as fiery of a debate as i was

as i was aiming for we're all just like yeah this yeah it's working on it i mean it's a baby project it's like a long way from like even even having anything to show for it yet but it's it's definitely there's you're not the only person i think who wants that I definitely am much more on the open source side but so like I have like it's not my priority to work on support close support stuff personally though I understand that people want to work that way I just don't think it's as effective a way to work

but you know we don't need to get into the ideological debate and yeah it's there's definitely plenty of reasons even beyond those like just like binary size like being able to not have like the same dependency duplicated in every application that uses it and things like that where it's like rust needs to be able to do it and so there's there's no there's no debate there yeah so jane do you remember um that we actually met uh once before and i think it was at an lvm yeah lvm developer meetup 2019 i think yeah that sounds right yeah uh and i don't i think at the time you were just like starting your your rust explorations you weren't like a full convert yet no i was yeah

it was still that was still when i worked at scale so i was still a professional c++ developer i think i was like quite well and deeply into the hyper focus on rust yeah so i was like you know not not necessarily on like on the lips team or anything like that yet um i think i was i think i might have already been on the Clippy team at that point. I remember hanging out with Tyler. I think you were because I seem to recall you talking with great glee about Clippy.

Thanks. It was a good time. I enjoyed that trip. Connor, what else should we talk about? There's the Shinkansen no no we're not we're not getting we're not getting to that yet so i recently heard bjarne strustrup i got i gotta share something that my girlfriend just texted me and i gotta i have to just appeared i just have to pray to god that she never listens to this podcast oh no

so um does this have a backstory i thought you're just gonna read us a text my guy it has a backstory we have how long is this our dog our dog oh my goodness very smart oh my goodness i can't i'm not airing this i'm not airing this and i just got a text from the girlfriend this is the worst literally you know so this is what happened jane bryce has just gone downhill as the co-host ever since episode zero and so the beginning no no i went i went i went up because episode zero i didn't have a proper microphone then i bought the good microphone so then episode one that was really where it peaked

and from there so when you said episode 101 that wasn't like a this is a vinnik intercourse this is like the beginning of the rust learning it was actually the hundredth and first that was a hundred and first episode yeah did you aim that to be oh no that was totally an accident and i'm just realizing now that the 101 episode correspond to us trying to learn stuff that was literally totally you trying to learn something and me apparently teaching it to you yeah but i've been threatening bryce for like episode 90 to 100 when we had kate gregory on uh because bryce was like eating his dinner and kept on interrupting and you know asked kate a question about the cabin she was in let her get

four words into the question and then like interrupted her to tell her something about his dog and i was like bryce what are you doing and then i said you're on you're on thin ice and then i said i'm gonna start trying out new co-hosts. Then I went and did. I tried out a new co-host, former co-host of CppCast, Jason Turner. And then Bryce, last week, said because I

indicated that I might have recorded without him. And then I could just tell Bryce was heartbroken. He was just like, don't record without me. And now here I am being like, you know what? I did the right thing, Bryce. You're back on thin ice. Except this might not even air because people are just going to be confused on why I'm giving you a hard time. Because they won't have heard the story that you just told.

It's inappropriate, Bryce. Clean up your act. You can just like cut right after. He's like, I'm going gonna tell you the story and then just cut to like we're not airing that all right back to the question that i had so this is going to be we're entering hot take territory we'll see what we can get out uh from jane recently on episode uh 155 which really they only started it recording them at like episode 120 of another podcast called C++ Club.

Bjarne Stroustrup, they just, it's like a Zoom meeting and they just record it. So Bjarne sometimes joins, creator of the C++ language. I assume everyone knows that. And at some point in the podcast, it comes, Bjarne ends up saying, I don't even really remember the lead up to it. They end up making a joke about Rust, saying that, oh, Rust is good

because we don't want to get like, you know, downvoted on the internet by saying something bad about Rust. And then Bjarne says, oh yes, the Rust community is much better at propaganda than C++.

The Rust people are very, very good at propaganda. Far, far better than the C++ crowd. And I was a bit confused because I've only been dabbling around in this language for like a week and a bit. And from my experience, it's just better in a lot of ways.

That doesn't seem like propaganda to me. That just seems like you got a better story. So I think Bjarne is almost certainly referring to what I talked about earlier, which is the memory safety thing. That, that... How's that propaganda, though? Because for whatever reason, I think some uh of the in the c++ community feel that um that the memory safety aspect of rust is nonsense in some way or that we can achieve

the same effect in c++ or something to that effect but but but my But my strong suspicion is that what was meant by that is a hyper-focus on the question of memory safety. And I'll prove it to you, because almost all of the response

from somebody like Bjarne to Rust has been around improving memory safety in C++. Like, oh, people are concerned about, you know, this one aspect. This is the problem. This is the problem with C++, that it's not a memory-safe language. And if we solve that problem, then all of C++'s problems will be solved. Everything will be perfect.

What's Jane? Jane, what's your take? And also to layer on top of the question, because you're inside the Rust community and like part of a couple of the Rust teams. Is there like inside of Rust, are you aware that people outside of Rust think that you guys have a propaganda machine?

Well, okay, okay. This is one person, one person. I mean, I do get a sense that like a propaganda machine. Well, okay, okay. This is one person. One person. I mean, I do get a sense that, like, a lot of C++, especially on slash the subreddit, C++ subreddit, like, they just, they don't want to hear anything about Rust. Like, they're uninterested in what Rust devs and the lessons that Rust people have learned have to share. And as, like, a polyglot that loves all programming languages, including, you know, some of the

most widely hated programming languages like Perl, I love Perl. Perl's great. You know, very similar to Python in a lot of ways that people seem to be refusing to acknowledge. But anyway, so I find that kind of just like, that's just hurting us by doing that. And so I'm just interested, interested like from like a rust insider's point of view is this news to you does do people inside the rust community are they are they aware and any inside details you could share i'm sure i know i would be interested to hear and some of

our listeners i'm sure so there's a meme in the rust community and i think you can google this and see some really beautiful some really funny and hilarious vaporwave art um about the rust evangelism strike force the resf there's this a real thing yeah there's like subreddits to it too um so we're definitely very aware of this uh this kind of perception and i think there's definitely i think rust has a tendency to to get people really excited when they get into it and so like you won't find people on the project going around and evangelizing aggressively i think like if you look at like actual project contributors they're they tend to be pretty reserved i think they're i think right now the prevailing attitude is more aligned with

your attitude which is like all the programming languages like there's not one right way to do things that all the programming languages have value and we should all be learning from each other and that but like especially people like new people who are really excited they're a lot more likely to be like running around and being like have you heard of rust and like that that does happen i mean and i'm sure that c++ developers see like other c++ developers who are learning about rust coming in and being like well you should have rewritten a rust that would have solved this this one bug you ran into or something and it's like you know not always the most helpful suggestion and it can be exhausting and there's definitely i would say even like within the project like a pushback against people

like actually engaging in like the rust evangelism strike force or like rewriting and rust memes and like kind of supporting that because it can be like a bit counterproductive and um definitely a preference for kind of mutually supporting other communities and being respectful um so we don't we like i don't think there is actively there's there's definitely no active propaganda machine within the Rust project. Like, I think there are times in the past where we've been a lot better, especially like when we were doing 1.0. I think they were a lot more effective at marketing. I think these days there's there's a lot more chaos and we're not as coordinated in that regard.

And it's something that we're working on we like if you if you look on the blog post on the blog there's like multiple blog posts over the last year about updating rust governance at the top level which is one thing i've been involved in um and i'm very excited about and this is like when you're talking bryce about like getting the effective language evolution this was like kind of speaking to my heart because like yeah i think i understand how important it is to be able to set up an environment where people can collaborate effectively and it's something that like we struggle with too like i know you you feel like rust has it all like just like really good at the moment i do think like we're probably in a better spot the i think the difference is um the at least i'm aware that there have been some problems

in Rust evolution and leadership as of late the difference that I see is the willingness to address and improve things I don't see that the C++ did you say i'm sorry yeah like empathizing not apologizing that's amazing that's i thought you like kind of whispered that

and i was like oh wow like that's very nice that you're like i uh that's unfortunate because it is thanks for listening we hope you enjoyed and have a great day