Rust Programming Language Cross Team Collaboration Fun Times, 17 May 2021

Previous Meeting

⏯

youtube image

►

From YouTube: 2021-05-17 Cross Team Collaboration Fun Times (CTCFT)

Description

Agenda, links to slides, and more:

https://rust-ctcft.github.io/ctcft/meetings/2021-05-17.html

A

A

Welcome to the first uh rust cross team collaboration, fun times meeting, uh and uh I'm really excited to see lots of people here. This is great. um I'm hoping this will be a useful resource for us. I wanted to kind of walk through a few things. um First of all, you can go ahead and check out the agenda at any time, uh but that link didn't really work. That's okay!

A

It's here and if you click on this presentations link you'll see like a list of all the presentations if you want to follow along with them um on your own computer and click on links and things like that.

A

uh Secondly, um thanks aaron, for that awesome, blog post uh rust is six years old, that's pretty cool and yeah without further ado. This is the agenda. That's lined up for today. um I've kind of picked these uh because they were things that I felt were impacting multiple teams. um So the goal is not to have kind of generic status updates, but status updates. If we're going to have a status update, it should be on something that that I think will affect and impact a lot of different teams in some way or another down.

A

The line so 2021 edition is kind of obvious error handling seems to me to be a pretty cross-cutting thing that will turn into like how tools report errors, as well as language support, potentially down the line. Libraries things like that um and then some discussion topics on so these are meant to be kind of longer presentations about an idea that may be useful or maybe it worked, maybe it didn't and what what we might learn from it for other teams.

A

um At the end of each of these, oh and finally, some time for an open floor um for people to just make comments at the end of each section or especially, discussion topics. I wanted to leave a few minutes for questions and things like that, but I figure most of the real conversation will take place afterwards in all our usual places, zoolop and internals and so forth.

A

So in terms of speaking, the idea is we'll use a meeting queue you can type into the chat.

A

If you want to add yourself with this little wave, icon or type nevermind to take off and santiago, has kindly agreed to manage the speaker queue which I have open in another window, or I thought I did to find it now, so you can um just do that right. Now: okay,.

A

So you can um see what's on who's on it, okay, and I think it's better if you, everyone stays muted, when not speaking, uh and please try not to just spam the chat with stuff, because it makes it really hard to follow. If there's someone talking and chat, I would also say we should probably keep our video off, except for at least when discussion times, so that we have the people who are speaking are visible and not lots of other people. I think that usually works out better all right. um Thank you.

A

So, let's start out with the rust 2021 edition tomorrow, we didn't actually coordinate whether you or I was going to present this.

A

A

Either way is fine, I guess I'm, I have it up on the projector, so I'll walk through it. This is just a brief update about the 2021 edition for those who haven't been following. um First of all, it's happening.

A

It's pretty exciting and we've kind of finalized the feature set, so we went through a we went through a different process.

A

This year uh we focused like, whereas in 2018 we were sort of positioning the addition as the sum of all the things that had happened over the last three years um and a bunch of kind of coherent themes this year, we're focusing more on a minimal set of changes, kind of the things that actually need migration, uh and we had a stage process to figure out what that set of b would be starting earlier in the year.

A

um The set of things we would include- and this is the list I'll just go through them- real fast- we're, adding some things to the prelude, so you can call try from and call try into, um and you don't need to import anything that is a that requires um a tiny amount of migration uh to watch out for other traits. That may have been imported that may have had those names, and you may introduce ambiguity.

A

I think there's a new cargo resolver, um that is opt-in and you can opt into it by going into the new edition or by in the older editions that work slightly differently can now iterate over arrays with intuiter.

A

In particular, this this all additions will be able to iterate with for loops, but in ross2021 the method syntax also works, which in prior editions it does by reference, because of the way that method dispatch worked out um disjoint capture. This is a big change to the closure semantics, so that, instead of capturing self closures, will capture self.threshold, which means that you can have less borrow check errors.

A

Panic, macros uh are gonna, be more consistent. They're gonna have the same macro and standard and core formatting works.

A

This is all meant to allow us to use this nice notation, so you don't have to write foo out of line anymore and also, if you want to panic with a specific value, you use panic any now and finally, we're reserving some syntaxes we're still working through this. But the idea is to reserve these hash, prefixes and other kinds of prefixes so that down the line we can give them more meaning, like maybe we want format, strings or something like that.

A

So if you're interested in helping you can click through to the project board, this shows a bunch of different columns of the major stages we're going to go through. So we've kind of we've now we're now at this stage, where the feature set has been assembled and we're working towards getting everything feature complete. So there's some bugs here that still need to be finished off um and then we're going to do a public testing period and then try to stabilize that's the plan, and one last point is say a bunch of thank yous.

A

There's a lot of people who've been working on this. This is probably an incomplete list, but it's still a pretty good one. So, thanks to all of you, okay uh jane, do you want me to walk the slides or do you want to um to share.

B

Your screen, we can try just having you walk the slides, we'll see how that goes. It's going to be like a mix between having to press sideways and down because of how reveal js works. So hopefully it's not too error prone um yeah. So quick update on the error, handling project group and kind of the changes that we're looking at making um so like next slide.

B

So the main thing we're focusing on right now is this like problem, it's being too easy, there's like foot guns and recording errors essentially, and it's like too easy to lose context, and so to elaborate, what I mean uh we'll look at panics, first, so press down and so upgrading an error like a recoverable error to a non-recoverable error is like a fundamental operation of the language we provide unwrap and expect to do so, and so you can imagine you have an api that returns an error and in our application we want to declare that it is uh like fundamentally unrecoverable because we always expect the conflict to be there or something and like next slide down.

B

What we get right now is that this currently goes through the debug trait, and so you get the the string that you provide to the expect followed by the debug representation of that type, which, for errors, is frequently the wrong thing, and so we would like to do is have these methods go through the error trait instead of debug. So like next slide, and so in this one, we would like to be able to access the dying error instead of the stringified version of the debug, in the panic handler and field of format.

B

Reports that look more like this, so you actually get like all the source errors uh next slide, um and so this has a couple of blockers that are preventing us from doing it at the moment. uh Next, so first uh we have to move the error trait into core, and so this is the main blocker, and so this is uh the main issue is the well there's two issues that we're both working on.

B

The back, trace type is not currently compatible with core, um and then the downcast method has box in the interface, and so we need a way to have both of these types. All right, both of these interfaces, accessible and core, may be, like defined separately, like have to deal with coherence issues. So we're working on that. I have a proof of concept that I'm working on next there's also.

B

We need to use specialization because we want to be able to have this apply automatically to all the existing places where we're unwrapping errors, um and so we want to be able to specialize, expect and unwrap to use this new interface for like provide like reporting, a panic from a dying error type, um and this is currently blocked on some soundness issues.

B

You can press down to show the thing for that um with lifetime dependent trait nipples, I think, is like the the source of the soundness issue and there's like some potential workarounds next with uh always applicable impulse uh and we're like looking I'm trying to like look into and understand this better and see how we can apply that for these um and then next problem that we're looking to solve is the missing reporter, as I call it, and this is to say that the error trait as it's currently designed implies like the need of something that iterates over sources.

B

So if you like press next you'll see the example- and here we have like a just a little method for doing a while loop until sources are none, and this is like doing this by hand everywhere. Every time you want to report, an error is like particularly annoying, so we should provide like a reasonable default way to do this right, yeah. You can go to the next one. um So right now the way we the ecosystem tends to do this from what I can tell is by abusing the debug trait.

B

So you should be able to show an example next- uh and this is just like using that like you'll, have a report method or something- and you put like you- might put it in the debug and pull on your error type or you might use like air and anyhow, which there debug impul, does a human readable report. We kind of see this as like un-ideal. We don't really want to have to use the debug trait, which is intended for like inspecting the internals of your types and being able to like look at additional detail.

B

That might not be part of your air reports, but now people are using this for other human readable reports for errors, and this is like unideal.

B

So we want to separate this, and so, if you go to the next one, the and you press next one more time, we want to provide a reasonable default of like a stood error report that can wrap the dyne error type and basically acting as an adapter from dying error to display and it'll have like, like we're thinking like multiple formats, because these are kind of the formats that we commonly see on the ecosystem, where you might be able to do multiple line with the causes or you could do like a single line where everything is separated by colons from, like the previous slide, um yeah, a single line where everything's separated by colons and then go forward, two more um one more yeah.

B

And then we want to also have uh like a convenience method to make it easy to wrap error types with this. You don't have to like always be like doing the going backwards before your type to type out the thing, etc, etc. um This is not as important, but I I feel like it would be useful, also um possibility of associating custom uh formatters with your reporter formatters with your error types, because this is with the self-sized bound.

B

It wouldn't be part of the v table, so it'd be like the outermost error type would determine how all of the errors in the chain are displayed, so it would be a consistent format. So the goal here with both of these changes is to improve the consistency with error. Reporting make it so we're not losing information and make it more convenient. So people like, instead of like the pit of success essentially to people the easiest thing to do, is to report errors consistently everywhere in your application um next slide.

B

So in addition to that, we're working we're continuing to work on stabilizing the work, that's already in progress, so this is there's three things: press next three times uh back, trace error trait in the termination trait um the error. I've already touched on we're working on making sure it can go into core for the panic stuff. The termination trait similarly has some of the same specialization issues that unwrap and expect have so we're like trying we're looking at the same like the same solution that applies to one.

B

It's gonna apply together um and then next slide almost over um next we're like looking at mitigating problems with box diner um right now, if you press next, this is like first to me, the diff that shows the exact problem and then one more next. uh This is the box box dinar specifically when the temp, the type in the parameter is uh unsized. It does not implement the error, trait and so box. Diner is itself non-error, and this is this negatively impacts.

B

How you can like compose it with other error types makes it a bit more annoying to work with. There are plenty of mitigations like this error.

B

I think handles it seamlessly because it's aware of the type, um but we would like to get it so that box nine error can work with all of the other improvements that we make, which wouldn't apply because it's non-error type and so we're looking at adding specific specializations for box diner so like when you return results box diner from maine, you should be able to get the full report and we we can already add that today we just have to like do the bike shed on the report format.

B

So that's probably the first thing we're going to start working on right now. um In addition to this, we're like looking at potentially making like a replacement for box niner that can't implement the error trace. We can do that with the new tri trade rfc, um but like deprecating box and introducing new results. There's like it's a big ask, and so it's like still very much like drawing board stage and then last slide, there's other that's not all the things are working.

B

This is just kind of what we're focused on, but in the future, we're also going to be working on a book. um We're also going to just keep going um ergonomic changes.

B

There are changes for improving ergonomics, because that's a thing that I hear people complaining about a lot, we're kind of leaning towards like looking into getting a custom derived into stood, uh we're like I'm cur, currently kind of leaning away from the check, exceptions, style approach, but we're like looking into that because there's like plenty of people who are asking for that too, um there's also making a the generic member access rfc, which we've already written up, which is kind of you, can think of it as a generic version of the backtrace or source function, or you can extract any type of context from your trait we're looking to get that added error, return, trace is kind of tip, pulls off of that and then last not least, aborting panics is another thing.

B

We're looking at there's like current ways to do this, but we're looking at maybe making it like part of the language or something um yeah. That's all I could think of when I wrote this. But if you have any questions, let me know.

A

Yeah I was gonna say: let's take a few minutes for questions on either this or the 2021 edition, um whichever I'll run a timer.

A

uh I just realized, I don't have my window up with the speaking cue. I don't see anybody in the queue. Are there any questions.

A

Felix supposed.

C

To use the chat.

A

But that's okay, I'll freak you! I guess.

C

We can always raise hands. I missed that. I missed that note at the beginning. Sorry, um so I this may be too technical. um I was curious uh if you all consider doing like adding a new trade like a standard ferment report instead of a rapper struct. um I know there might be that might be more infrastructure than we want to add here, but it was the first thing my mind went to.

B

uh Yeah, actually, that was kind of the original proposal was to to have like a stood format. Report trait and then have like a change to the grammar to have like braces colon exclamation mark would be the report one and then we'd have like maybe a blanket impul for error types and then, like your custom report, types could provide their own impul or something, um and we we decided like against pushing that initially, because it should be possible to add that completely backwards. Compatibly with the changes that we're making right now like that.

B

Could in theory, then like call out to the report type or I'm not sure, if, like the report type, would necessarily integrate exactly yeah. It was. We talked about that to a degree and yeah. It is something that I would like personally, but I think the first step is just to get the minimal thing and like getting the formatting kind of bike shot.

B

Is I think the gonna be the first walker that we have to get through.

A

D

Yeah, I I think it's really cool that there's going to be an error handling book, because I I think that could help a lot of newcomers. uh How will newcomers be redirected towards this book or will this book be kind of.

B

uh Sorry say that again, there's like a fire alarm going on, so I might have to like leave in a minute. It's okay, tending.

A

To a literal, fire is an acceptable reason to leave.

B

Oh uh yeah, we we've not really gone that far to plan out exactly how we're gonna like integrate this with the rest of the ecosystem. I mean we would talk with the teams who maintain the website and stuff to get it. I think yeah. I should probably go so sorry.

A

B

A

Please be safe: okay,.

A

Okay, well, that was interesting. Any other questions.

A

I had a question for jane, but she's gone now um all right cool, then we'll move.

B

A

So the next thing uh was vision squared or so you want the vision here. uh Just me and tyler. um I wanted to talk about the async vision, doc that worked that you may have heard about, but a little more generically actually about what vision docs could be, I think, and some of our experiences and so forth. But let me start with this um so also my daughter drew these awesome, drawings sure cool.

A

She was insistent that she should be in this. I was happy uh so if you you know, I think this is a situation that will sound familiar to a lot of you that there's like some exciting thing. You would like to see and russ some big change that could have a big impact on how the language works, but there's all these details and they're like kind of hard and every time you start trying to map it out.

A

You get turned around in circles, because one depends on the other and maybe there's a lot of different people involved, and they don't quite agree on what you ought to do so at this point, I think this is the kind of this is basically the kind of problem that we don't have a good solution for, in my view, and that I think vision, docs are part of the answer uh and the basic idea right is of writing this.

A

This document, that kind of lays out where you are, where you're going a few years from now and some of the steps you see happening or it doesn't have to be a few years, but down the line and the steps you see along the way. I think it can really help us to scale up what we're doing.

A

I think it can help us, I said scale up open source design by that. I meant like by letting us focus on these end goals that are further out first and doing that kind of product design up front and similarly having those goals in mind can help us stay focused right. What are we going to work on? Well, the thing that takes us to like the most important part of that goal, um and also, I think it can help us to get on one page right.

A

So if, if we're focused on what we want to achieve uh that can sort of help, people realize that even if they don't necessarily uh that they they share the same goal, even if the way they want to get there is different, um but I would say that they have a lot of potential, but it's it's been pretty hard. It's been different to do than I expected, and that's where I wanted to talk about it about what we've done, what we found good bad, um what we might try.

A

So let me go back to january where the idea from a vision doc came in so shane is aws is director in the foundation but she's also the manager um for the rest group, and we were talking and she was sort of saying well so nico. What do you think rush should be like in a few years from now you know show me your vision, and I was. I was like all right.

A

I got this, that's fine, I'm going to come back in a few days with a perfect document right um and then, a few days later, I kind of sheepishly joined the call and was like well. That was really hard. I don't really know what the future should look like, um so we started looking into you know. Why is that so hard to do? um Well, it's it's a big question.

A

What are you have to sort of decide? What are the most important problems to fix? That's the ones you want to focus on right um and there's all these details. It's too much for one person uh to kind of get it all in their head at least easily and there's a lot of sub communities with different consensus and there's not necessarily consensus on the overall goals. um This applies, I think, particularly to async, but also to other areas too, and so we had the idea of okay.

A

Let's try to build it collaboratively like we haven't done the research and work we need to do to have the answers to all those questions um and that's a great time to try to involve the community. um So the structure of the vision, doc is really kind of taking aim at each of those questions. So, in terms of what are the most important problems, there are the status quo. Narratives are there, so let me back up.

A

I mean I thought I had these slides, yeah, okay, there's narratives that tell you about what's happening in the status quo, meaning a kind of story about one of the characters going in and using some feature and the problems they encounter. That's there because right the act of writing those helps you understand what are the most important problems and gathering that data right to deal with the facts that the space is really complex, the dock intentionally, it's not an rfc, it doesn't lay out a specific design, it assembles kind of the bigger picture.

A

So you don't have to deal with all the complexity at once. You can see the field and it also lets you engage. It gives you a mechanism and a tool to engage with people and ask them sort of what they think is important and help them help. You learn from them in terms of what should be what you need to know about their side of the space right so for async.

A

I think that comes in, especially with things like embedded and all these other sub communities that have distinct needs, that you can't hope to have a total survey of that and finally, in terms of working with consensus, focusing on the end goals we want to achieve is definitely better in this way than focusing on all the details along the way. It's a good way to figure out. Well, perhaps it actually is more compatible than you think so.

A

The way I see it, the shiny future is part of the vision doc, but this is sort of the shiny future that I see of potentially of vision docs in general is. I would like to see that when we get projects get to a certain scope, I'm not sure what that is exactly.

A

They can start to work on a vision dock to help lay out their path right. So async is something we're working on. We've started in the const generics group working on a dock. That's a much smaller effort, uh which I think is interesting like you should be able to tailor how much work you do to how big and complex the space is. I don't know there's a bunch of other spaces.

A

We just saw error, handling, jane kind of laid out a bit of a vision uh which I think could make a nice dock, but embedded ffi interrupt. I don't know, I'm tossing out ideas, I think, there's lots of spaces. We know that we need work, but we don't have consensus about what that work should be and what that future should look like or if we do have consensus. It's not well documented and vision. Docs might be a useful structure.

A

um I'd like people to be able to come and see these vision, docs and kind of get an idea of what's happening a few years down the line right say: oh, I can't wait. That's really exciting, um but also for team members like if I have to review a const generics rfc and I haven't been following in detail. I would love to be able to go to the division dock and say no. Okay. Now I have a picture. I see that the path I see how this puzzle piece fits into it, and I can.

A

I can decide whether I like it or not. If it's taking us closer or not, there, that's often really challenging to do so just to walk through the parts of the vision doctor. I want to share a little bit of how they evolved and what we've learned from each part um and why they're there so starting with characters, we have these four characters: um alan grace niklas and barbara they're all named after programming language designers.

A

um If you, if you, if you were following the vision doc in the beginning, it took us quite a while to come to this definition, so we ended up with they. Each have their own background. Alan's coming from a garbage collected language grace is your c plus plus hacker. Nicos is new to programming in general.

A

Barbara's a rest expert and what's kind of interesting about that, is that if you look at what those different backgrounds, what you get from those kind of languages and what you want from rust, like what you're not getting and what you want to get also from rust, it it lines up kind of perfectly, with rust's core value propositions right.

A

So in these garbage collected languages you have safety from the garbage collector, but you don't have the performance control that you are looking for in c, plus plus you kind of already have performance, you don't want to lose it, but you want to gain safety.

A

um Niklas is not programming yet, but they're very excited, and you know they want to be part of a community uh and barbara well, barbara's the rest programmer she's got it all already, but she wants the new parts to kind of fit well with the stuff that came before so this kind of workmanship and that's pretty cool, I'm pretty excited about that. We had a bunch of iterations where first they had specific projects, they were working on that didn't seem to be working um and so forth.

A

I think that the I'm not sure of the language background, sometimes I think, also confuses people. So I think one of the areas we're still working on is how to set set up the characters to make it easier to tell which one to use but the goal. If we could, if it works right, I think we'll know it works when, when you can use them to kind of quickly decide and help, you remember what impact a feature might have on a given sort of set of rust users right.

A

So the story that shane told me early on was like coming from a different project she had worked on was that they were proposing a change and one of the characters or one of the developers in the room was like that. If you do that, you know you're gonna mess it up for bob or whatever. I would like that only for our characters. I think that would be the best status quo stories. I'll just walk you through one, as the easiest way to show you how they work.

A

This is a abridged version of alan needs, asyncs and traits it's basically, a narrative form he's working on a project with barbara he's trying to abstract away the http implementation. He tries to create this trait writes async fn, because that seems like the obvious thing, but he gets this compile error.

A

One thing about it: is it guides him to the async, trait crate tries to use it. He learns how it works. It works pretty well for him, but when he goes to support no stood, he can't because it uses boxing it's implementation, um so the story kind of is meant to tell you how things are working include lots of specific details. So you really understand and um and kind of give you a sense of the impact of these little details.

A

Right and that's part of the point is, if you just sort of list out abstractly abc this- is the pros and cons it's harder to tell how what is the overall impact of someone who's trying to solve this problem and they hit problem a and then they hit problem b and then they hit problem c. um So I think the story. I would share about the status quo is when we first started doing it. It seemed like nobody wanted to do it. I wanted to skip it. Everyone wanted to skip it.

A

We just wanted to talk about our ideas for what we could make better, but um I don't think you should skip it because it really does help. You understand the problem and in fact, now that we've done it turning to the shiny future has been much less fun like we're. It's really fun to do the status quo. I kind of love to keep doing it. We did this stuff, like these group writing sessions. These work pretty well.

A

It took us a while to understand them where we had people join us here at zoom call one person would drive with a shared hack, md and and sort of other people would share their experiences right about what they encountered using async rust and we could kind of knit them together into a story. So a lot of the stories came out of these sessions and thanks to ryan for running a bunch of those too, um and we also did some within companies like within aws and within google, and so on, um so the shiny future.

A

The truth is, we're still figuring out the way to write the shiny future. That's hard. Even now. Having done all this work, I think it's a lot easier. We've got a good sense of what the big pictures are, um so I think we're going to evolve the best way to organize this part of the vision doc. We have a bunch of shiny future stories that we've brainstormed so far, but I feel like we, we didn't quite mail it this round. This iteration, um I think one of the things we learned, though, is you need.

A

We got so many more status quo stories than we expected. You need to take a step to organize them and sort of extract the themes out from them, and that gives you the kernel of what your shiny future is like going to try to address.

A

That was something we did through this meta-narrative and so on, and the other thing we've been finding is you know, figuring out. The future is really hard. A good idea is to use this as a tool to explore different options.

A

So maybe, if you don't know which way something should work write two stories, one with both options or if you hit a dead end, write that too, let's write out like writing out the dead ends is really great, because maybe somebody else comes in and says ah this is a way we can twist change that um that story and by dead end I mean you worked out the design and it hit some problem. You couldn't figure out how to resolve, or this and so forth.

A

um The one thing I say we have pretty much seen is it's really try to avoid getting too hung up in the? How of how you're going to achieve it? I mean it shouldn't, be some fantastic thing that you have absolutely no idea how it could work, but I think we really want to you know we're designing rust. We have the option to change the language and change the library, so should focus on what we want people to experience and then kind of go backwards from there to how we can actually implement it.

A

The the last point about shiny future is that I'm pretty sure that all the shiny features we write are gonna be wrong. um That's okay, they're meant to be a few years out we're going to come back. We're going to revisit the doc uh they're meant to give us enough information to figure out what the next step is, and after we take that step, we can reassess and tweak details.

A

So that's uh that's what I had to say. I have a few resources for you uh if you want to click through at some point. This is the async vision doc. This is the work in progress, const, generic's, vision, doc, and this is a really work in progress. In fact, it's totally useless, but I, like the name so much. I had to put it out there repository that's going to house sort of templates and and other some of the material from this presentation, for example, for how to help drive visions on forward.

A

So I would take some questions um and also tyler. uh I am uh I put some sample questions here to to for people to consider, but I take any question um so thank you all for for listening.

A

C

Do you expect the cast of characters to be fixed at this point? Are you expecting to need to need new fat cast of characters for other visions.

A

I would really like is to have one cast of characters for all the docs. I think the docs might use different subsets of them more or less, but I'm not 100 sure that we have the definition right. uh That's one of the things I want to look into. I think it would be.

A

I feel like it will make a much stronger experience like a much more coherent feeling for all the docs. If they're sharing the same cast one of the things I didn't cover, but that we did add in there was a concept of sample projects which uh which are like, like we have for the async doc.

A

We have an embedded project and a server doc project and a couple other ones, and that that that's something I would expect to change so it's sort of like the same characters, but they work on different projects depending on the domain and that lets you capture some of this sort of hard constraints, a little better.

A

So I'll just answer this question directly from the chat richard asked like the mcu, but for us but richard I don't know what the mcu is marvel cinematic universe was a joke. Oh.

E

A

E

Like take that's more serious.

A

Well, no, but you're exactly right, uh so iago asked I'm surprised you did not need more characters. Do you think it's enough forever? um Actually, I would say: we've had the opposite problem. We haven't used all the characters that we have. If you, if you look in the doc they're, almost all alan and barbara and roughly the allen seems to be the go-to character for sort of a problem you hit when you're.

A

First learning and barbara is sort of the problems that remain hard, no matter how much you learn, um which might be a breakdown like it's a different breakdown. It doesn't have such a pretty chart and line up with our core values, quite as clearly, but maybe that's a way to break things down um so yeah. I think we don't need more characters, I'm really resistant to adding more.

A

I think they'll be hard to even people already forget, which one is which but uh ralph asked c exactly which ones were alan and barbara again alan was the garbage collected programmer ralph, that's the one people tend to go to for new new to rest and barbara was the experienced rust user.

A

We do have a fair number of grace stories: cbos plus user.

A

We don't have very many niklas. We have one from some some physics, students which was pretty cool because they're kind of learning to code things.

A

Yeah felix points out, other visions may engage in the clause more. I believe that's true.

A

Any other questions before we move on.

A

Oh there's two people in the queue. Oh, my gosh.

F

A

Oh you're right daniel silverstone go for it.

G

Hi, I just wanted to say that when I was doing a similar thing with tooling design in in my my current job, one of the things that we found really helped with uh with the personae was to have both a professional goal set for them and a personal goal set. You know. um In particular, we found that when we were writing some of our future stories, there were compromises that we had to make where we could satisfy someone's.

G

You know need to get the job done, but in the process make them slightly unhappy or we could keep certain characters happy at the expense of making it harder for them to get their jobs done and being able to find and make those trade-offs was really really valuable.

A

Was your were your characters based on like how did you break them down.

G

um We started with with, with uh with roles we were dealing with uh software integration uh stories, um so we had sort of the the the integrator, the the the person who was dealing with issue triage people who were dealing with the the high level project, stakeholders and so on um and building from there to to you know what did they need to do to get their job done?

G

um What was what was the task they were trying to achieve, but also what was it about their job, that drove them and what was it about the the tasks or the problems that they were encountering that caused them pain.

A

G

um We were, I know your personally. I think in this, in this context, are quite small. You know if you can summarize it very trivially in that table. I appreciate there's more text behind it. um Then that's simpler personae, but you know we had almost life stories for these characters.

A

Yeah we might want to go that way, I'm not sure all right thanks daniel leslie, let's take wesley's question and then I want to move to the next presentation.

H

Sure I'm just a little curious if the uh personas are derived from data that was gathered like maybe during the rough survey or some other kind of survey like that or if they're kind of more just abstract like these are the kinds of programmers we think are using rust, um because I've worked with ux projects before and having data driven. Personas has been really helpful in the past, so I'm just a little curious about the background. There.

A

I think they came from a loose collection of data like stories that I mean, I would say we started out with different approaches of looking at their backgrounds and then went from our experiences with peop, like with that set of programmers. Oh, but it's not as data driven as you're suggesting, and it might be that when we like right now, tyler and I are in the process of going over all the stories and trying to collect them. We did this big brainstorming period.

A

Now we're trying to kind of bring things together and maybe we'll that will lead us to some directions. Yeah richard writes we should have eigenfaces, but for personas. What I will say is that I have been wanting to kind of put out a call for people to draw pictures of the personas, but I haven't gotten around to it. I think it'd be awesome. We need more pictures, all right, I'm gonna jump because I'm, I think it's time uh I want to get to this last thing.

A

uh Tyler did you have something you want to add, but why did I just cut you off just appeared.

E

uh I can I can make a comment on just like the nuts and bolts of actually doing this, which is um for me it's fundamentally been a very social process and, like thinking I can just engineer my way to like crafting a status quo story for future definitely did not work like the only way to really hack.

E

My motivation was to to do it with other people, and that also makes the result better, so um yeah, just like every step along the way and not not just initially getting the feedback, but also crafting outlines and like um summarizing stories like metanarratives. All of that has been I. I can't motivate myself to just sit down and do it it's much more helpful. If you have someone else that you can kind of pair with or multiple people.

A

Yeah, that was a.

D

A

Like side effect, it's a great community building getting to know people and so forth. All right felix. Do you want me to drive the slides again? I guess that's easier. Let's just do that.

C

Okay sure um hi felix wesley's going to go ahead and I think I'm going to be on video too, but I'm going to do the most of talking um see ya next slide. um So this is going to be about um the sprints, a custom sprints we did and the main thing is we wanted to sort of. You know, get a feeling for the outcomes, both positive negative and also like we're welcoming feedback here and we'd love to know of some other people's thoughts on things.

C

You know how you do sprints or things like sprints next slide. um So there were two main categories of sprints. There was a a compiler team sprint that we did the first week of march. That's the shrink member sprint and then there's also talk about some polonius sprints. um We did a retrospective on the strength. Sprints there's a link there to it. So for the shrink mem sprint.

C

The whole point of it was that the compiler uses a lot of memory when you bootstrap it, and this is terrible um in particular, for some contributors, their machines just die um or the build times become totally it just is not workable because of the overhead of memory swapping in the virtual memory, so there's ways to mitigate it, but they have other downsides. So we want the reduced amount of memory. We use next slide. Please, um and so here are some things that came out of this.

C

We got some interesting ideas and things to try out. I don't want to get into the details here. You can follow up with us about it, but the point is we did get some engagement contributors and that's that's good right um next and we were actually able to reduce our max rss and some of our performance benchmarks. So that's that's good. Next um and uh ollie ran some video calls and they were actually a hit.

C

um The people who joined in they said it was a really positive thing that they got out of this, so that was good next um and we actually have docs for how to do memory, profiling, which is a really important outcome of this, um because we didn't have good like documentation, for you know, guidance for how to do this sort of thing to get information on this front next negatives. um So when we started this sprint, we only had a week-long sprint and we didn't even have a list of tasks to do um so.

C

We spent the first day. Just can you come up coming up with that list? There are various reasons for that, but it was bad next. The uh video calls were ad hoc that I mentioned, and so it was not advertised well and people didn't even know they were necessarily happening so that wasn't great next um and then yeah. We had some things didn't pan out, which is just life.

C

I think when you're talking about experiments, um but still it can be disappointing uh next and a number of people during the retrospective pointed out that only a week is too short a time to make meaningful progress and there's a tension here between. Like you know, people who are just volunteers asking for like donated whole much time over two weeks is tough, but it's even tougher to say: oh we're only gonna do a week, and so you get you don't have much of outcome. Your outcomes are not that great.

C

So that's that's a real, difficult problem. Okay! Next um this we just want to mention. There are other sprints. The bologna's working group has done. A number of sprints and they've had they've reported very successful results in particular they've done. They use a different structure. um They did have one week, strength sprint, but they dedicated four hours a day um to it. We didn't. We had more free form thing in the compiler group um next and so yeah it was.

C

It was important that the participants were already familiar with it, so they were able to like just be enthusiastic and um keep things going next, and uh it was mostly about scheduling um in terms of making it those four hours work next uh and a crucial thing to is the counterpart to what we said with our group that there was this concrete set of tasks, conquered work items, and that was a really important thing for them the sprint to be successful. Next, apparently, they were awesome and nothing.

C

Bad happened um for the polonius sprints, so yeah our lessons here that we have to put more planning time in which you know it's tough to invest, but we got to do it if we're. If this one's going to work out um next um and we need to start with a set of tasks in mind, that's the you know from both these sets of sprints. The lesson here is: when you don't do it things, don't work so well and when you do do it, it works out. Well, next, um we need to coordinate conversation better.

C

The video calls were awesome, but we didn't coordinate well in terms of having people know about them and the status updates. I I know I tried to like make. uh You know ways for us to do status updates, but it just didn't work didn't pan out well, so we gotta coordinate that better to get enthusiasm going next and we probably should we deliberately the compiler team did said we're not gonna try to do mentoring for people.

C

We want to just focus on existing members, but the reality is that when you want, when you want to drum up excitement, the important thing is to try to actually offer mentoring. I think the project has seen a lot of success in the past by explicitly working on mentoring for newcomers.

C

Next um and finally, let this video call stuff a lot of people said it was just nice to be social and that might be in part because of you know, coronavirus and whatnot. But the point is, you know: forget: the sprints like just being social could be good, and maybe we should try to set that up um separately from sprints and I think that's.

A

It next no more okay,.

C

A

Well, let's take some questions in people have.

A

A

I have one if no one else does. Oh ralph does.

I

A

I

All right, another question: just a comment plus one.

C

F

Hours or something like that, that sounds.

I

Great, I I mean we used to have these um all hands once a year which now didn't happen twice. I'm not sure what the plans for that are, but, like also it's like physical and hard to get to internationally and everything but like having selling something social would be, would be great. I think.

C

Yeah yeah I'd love to make that work.

A

B

uh Kind of building off of this, like, if we're looking for social hours- and I think he also mentioned, like more effort put into mentoring.

B

um One thing that I was like throwing around was like a social call to like build up mentor instructions on like various things that, like team members, have like context on uh so yeah. I'm I'm very, I'm also very interested in this idea, and I think that we should like set something up. That's just like kind of hang out and prep like talk about what work needs to get done, that we don't have people for or something like that.

C

That's a good idea.

A

J

I'm wondering if there are similar plans to uh to do a sprint for parallel compiler, because I feel like that would be interesting and restock would probably benefit from parallelization and rendering, and it requires the compiler data structures to be parallelized.

C

Yeah I'd be honest here. I think that comparal compilation is explicitly something where we just said. It's not currently part of our. We have too many things to accomplish on our plate to try to work on and it's a difficult topic. um So it's not in the short-term plan for this year. I think it's more important for us that we get our, for example our bootstrap times down in general, but longer term. Of course, it's the only way forward. I think to improve things there as architectures go more and more parallel.

C

I don't know if wesley any thoughts here or things I've missed in terms of my thoughts on that I was.

H

Just going to say more explicitly that we are planning to do another sprint in the future, specifically focused around bootstrap compilation, time, not memory usage, so.

C

Yeah, but not parallel is the point yeah unless, unless there's some easy win with parallel, that doesn't require a huge change that then helps the bootstrap time.

A

um Yes, you get a question nico, I guess it's me yeah, it's more! It's sort of half question half comment, just that I thought that idea of jane's was really exciting and one of the things I've been really interested in, like, for example, reinvigorating the rusty lecture series and having people walk through just just walk through like big prs or big how this code works and then turning that into documentation, and maybe the idea of doing a sprint that is focused on building the rudiments to make further sprints more successful is even better than one.

A

That's focused on some technical goals, something to keep in mind.

C

I did speak quite quickly in part because I know there's other items in the agenda, um but I don't know what nico's thoughts here are in terms of uh yeah.

A

Let's take one more question and then we'll move on uh we're almost done anyway. This is the last major thing. Tyler.

E

Mandry um yeah, so I had a question about the like the four hours a day for the polonius sprint. So, um first of all, were everyone doing the same. I do four hours a day was just like a synchronous, four hours, and you think it could work with different people coming in at different levels of time each day. Or do you think that everyone doing the same amount was important.

C

So nico and team lqd- and uh I don't know who amanda is, but so I myself wasn't involved with the polonium sprint so nico. Do you want to speak this really but led straight.

A

Into it yeah we did. I've learned it's liquid last time.

H

A

uh We did we did all uh like. We can speak if they're here, but we did four hours synchronized. uh I think liquid even took vacation, which was awesome uh but and uh the that was pretty useful, but we were like three people who had already been working on this stuff for a while. So it really was helpful for us to have shared context. I imagine I think it.

A

I think it's important for there to be synchronous periods, I think, probably for the broader compiler we might like to have more than one or something because time zones like it just so happened that I get up early in there in europe and that worked out fine, but.

A

Yeah, okay, cool: let's go to the last thing, so I wanted to have I'll go really fast, because there's not that much to say uh just wanted to say: there's this twitter account! Although twitter, like blocked me because I it said, I'm too, I have suspicious activity or something but hopefully that'll get resolved uh and there's the website I'll announce future things there, um and this is the plan time for the next meetings. Third, monday of every month, uh I'm shifting the time of day. So I know sorry for those of you in berlin.

A

That's I'm not expecting anyone to wake up at 3am. On the other hand, it covers beijing and sydney much better, and if you have ideas you can file issues on this repository for what the next month's agenda should be and there's some there's some uh there's an issue template that will guide you to help. Explain why it's a good idea um and I'd love to hear thoughts. I think afterwards on things that worked well, what we might do differently for this meeting and so forth.

A

uh So I want to just leave the last five minutes as open chat. I think that's important. So anyone.

F

A

Speak, go ahead and sign up.

C

Sorry felix did you.

A

Mean as in use that.

C

As and use the queue or okay, so yeah.

F

I just want to see okay.

C

I'll raise my hand.

C

Go ahead: okay! Is there a space for us to chat with your text in response to these things, because I asked the beginning, I didn't think I didn't see a response. Is there a zulu.

A

C

Anything or there is a ctcft zoolop stream. uh How do I not see this okay? So I'm just blind. Okay, I'll look again.

A

Yeah, that's probably a good idea. People can jump in there if they want.

C

I see it now: okay,.

C

A

Any more comments or thoughts.

A

I'm just going to read what daniel wrote or daniel do you want to read this out loud all right.

G

I think I was just just saying that um large groups, it can be really difficult. We've had a couple of comments in the in the chat now about things like zoom breakout um rooms, uh my workplace uses a self-hosted work, adventure which is quite fun, there's gathered uptown and they offer spatial arrangements so, like everyone bundles into the same chat as it were, but then you know three or four of you can go off in a group somewhere have a chat.

G

Someone might wander over and talk to you and, and it can be, it can be a nice way to have a social interaction that works um despite having a large group of people, because you can kind of join and leave chats. As things are interesting.

C

It's like a space you're, a person like a multi, a massive multiplayer online role playing game or something like a with an avatar or.

G

You literally have like a little avatar. You wander around a map and when you get close to people, you join that chat. Okay,.

A

Hey doc, I'd like to hear that spoken out.

A

If you don't mind or I'll read it, if you want.

F

You mean the part about the mentored sprints yeah.

A

That sounds cool.

F

um So they're um the python community, uh in conjunction with pi pycon for the last three years, um there's been a separate group that ran something called mentored sprints and basically, what it is is you bring together people who have never contributed to open source or are intimidated by it by it or haven't done a lot?

F

uh And you have uh you know: senior members of the community uh people from different aspects or different working groups who uh get together for a one day, um sort of training session walk through where you're actually helping people do their first pr.

F

um That may not be the exact thing that you know the the best content for russ, but I ventured sprints is amazing because you get to network with a lot of people you you do have that social aspect and you also build confidence in being able to contribute to an open source.

A

Project all right, felix, you raised your hand last comment before.

C

A

C

You're not gonna like this, then um I wanted to point out. There might be a tension with this whole vid like mixing like actual productive work with video calls or even or any kind of recorded call. I just in common compilation working group. We got some pushback because we were doing zoom calls that were recorded and posted on youtube and some people who would have participated said they were not willing to participate because they did not want their um visage.

C

On that context, and that's, I think, fine for a thing like this, because people can come, they are not come, but if we actually want to be inclusive and credit than most people involved, then there might be a problem there. So, having said that, I still like to really like the idea of actually doing something, directed and productive with the social hour. So maybe it's just you just suck that up and say yep too bad. If we aren't willing to you know, have those people come or those people don't want to come all right.

C

Last comment: doc.

F

I just wanted to point out that I've participated in a number of meetup groups who make really good use of breakout rooms uh in zoom for managing like group size and allows allowing people to spend it's time frame. So you have, you know like 15 minutes in one breakout room and then you joint rejoin the other, the larger group, and then you break out with a different group uh so that you're you're, you know spending time kind of rotating through uh people that want to attend um and that works really well and it's they.

F

It's used for all kinds of things. So um if there are different subject, different content that people want to talk about, or if it's just social in nature, it works, it works well.

A

uh All right, I'm going to end the meeting now so that everyone can go after their days. Thank you so much for coming. This was really great and I wanted to say that on the zulip I opened a topic for this social hours conversation because it seems like people have a lot to say, and I think it's pretty cool thanks. Everybody see you next month.