Add a meeting Rate this page

A

Easier in the club.

A

All right, hello, everybody um welcome to the february ctcft. This is uh the first one. We've had in a few months, uh the first one of 22 uh 2022, and so I just want to say, welcome back to having this opportunity to have talks between different teams for rust and share some of the stuff that we're working on um more internally.

A

And so I just as a reminder. I do want to say that we're going to have a decent amount of time for questions today, and so, if you're attending live and you're interested in asking a question for either of our talks, then you can just uh put your hand up like this in the uh question in the chat and then we'll add you to the queue also, I just remind her to meet yourself and turn off uh the video unless you're the one queued up to speak and so to get us started here.

A

We have a bit of a smaller agenda today with with different content and stuff like that, but I think this will give us a good opportunity to potentially ask a lot of questions, and so we have the rust 2021 survey results and so nick's going to give us an update on that.

A

We also have wesley and potentially felix giving us an update on the compiler team, compiler team ambitions for 2022., and so the theme of the cc ctcft is planning for 2022 and so I'm kind of just exploring uh what type of what kind of stuff we have coming up for the next year, which I think is a pretty nice theme to start of the year with um afterwards. As always, we'll have our 60 minute social hour. It might be a bit longer today, depending on when we get started with it.

A

When we finish the talks today, um we'll have uh I forget, if we normally have the announcement or like open mic at the at the closing of the ctcft or right now, um but I'll put it at the end for for this month and then, if anybody has any announcements that they'd uh quickly like to shout out, we can do that right at the end.

A

So without further ado, I will pass it over to you nick and we can get started on the survey results.

B

Hey, thank you, um okay. So I'm going to talk about the survey, so we've been doing an annual survey of the russ community kind of every year for a while. Now I don't even remember how many years, but there's quite a few um last year, um ryan and I decided to give the the the survey a little bit of an overhaul. So um we we've kept around some of the kind of old favorite questions. But we've polished a few questions.

B

We added a bunch more, um and uh so it was a bit different um in 2021 compared to the previous few years. um So thank you. Everyone who, who filled it out lots of people, did we had uh just over 9 000, complete responses, which is a new record um and I think around 12 000 kind of partial responses.

B

So a lot of people feel that so so, thanks very much, and um thanks also to well for um the folk who helped translate the questions and have been translating the answers and also to uh a bunch of folk who who gave some really good input while we were kind of working on the overhaul of the survey.

B

um So most of the rest of this slot, I'm just going to like talk about some of the the results, um the as far as has popped up. We got the blog post uh that came out last week and that has um a summary of some of the results and is worth giving a read. If you haven't already I'm gonna, probably repeat some of those um and talk about a few more um exactly what we're gonna share, kind of, like more long term, is still being decided.

B

um If you have um uh opinions about that, then there's a kind of policy proposal on the survey repo. I can post a link to that pr later. If people are interested in that, but probably the next step is we're. Gonna, try and put together a kind of summary report that captures pretty much all of the results, but without too much analysis and we'll send that at least to everybody on a rust team, um so that that can hopefully help with your your planning and thinking for the for the year.

B

um I'd like to make as much public as as we can as well, but we're still kind of like talking about that uh and um and then a bit later in the year, we're going to try and do some kind of like deeper analysis on the results.

B

um So if there's anything that um you know, the rust teams or working groups would like to know, then please let me know- and we can kind of like work, that into that kind of like deeper analysis that we're planning to do a bit later on.

B

Okay, so well, I already said: we've got like 9 000 responses um of those like 90 were rust users. We do ask for kind of non-users and form users to fill out as well, but usually in a minority of those rust users, we tend to see a lot using rust at work. uh So this year, 40 people said that they use rust a lot at work.

B

um So that's either as their kind of like main language or soul, language uh and another 19 percent said they use it a bit and 41 said they don't use it, uh and this is one that's a bit hard to compare to previous years, because we asked a slightly different question. I don't have like, like previous year's data, um to hand it anyway, um but people always ask like how that compares to previous years. uh um For now and for this talk, I'm just gonna focus on on what we got this year.

B

um So I wanted to start off with just some kind of feel-good statistics. Really we asked a couple of different questions about um uh kind of, like sentiment, kind of questions, whether you agree with these statements, um so only one percent of um uh respondents uh felt that programming with rust was not fun. um So I like that that like makes me happy as a as a statistic, even fewer just a quarter of a percent thought that rust was not beneficial um and and another small number. Only.

B

One percent said that the the benefits were not worth the challenges of of using rust um and when we asked about whether people were were using rust for projects at work, 90 people who have done so would use rust again or sorry are likely to use rust again in the future. So so those um are the kind of statistics that we want to track year on year into the future, um but they they make me happy for for this year so far.

B

um So why do people use rust?

B

um So I think these um answers kind of uh that they're not surprising, but they um confirm our kind of like assumptions that we make really so 96 percent of people use it for correctness um and and uh to produce bug, because it helps them produce bug free software, 94 for performance 89 for security um and 89 for fun.

B

I guess that that last one is maybe a little bit interesting, like the numbers are up there with the kind of strong technical reasons, um 74 use it because they want like precise control over what their machine is doing.

B

um uh Sorry, these uh there's there's not much of a narrative, I'm kind of just reading numbers out, so I'm gonna kind of like hop over to the the next topic, which is um where people are developing um software again. This is not particularly surprising but kind of confirms the kind of assumptions we make 70 of people develop on on linux, another 31 on windows and 32 on mac.

B

So um you know that's kind of like a strong majority for linux and I think it's interesting that windows and mac users have about equal numbers um where people target so um so, where rust is running again. Kind of 80 on linux, um 39 on windows and one that was really surprising, was um a full 24 are targeting wasm web assembly um as a as a target. So these are. This was a multiple choice. Question um and lots of people take lots of of boxes, and I think there's.

B

This is one place where kind of like a deeper analysis of that is going to be really interesting, um because I'm pretty sure that there aren't a quarter of all rust developers targeting just web assembly, um but but even so, that's I think, an interesting statistic.

B

Okay, so um we've had over the um years kind of like quite an interest in what version of the the tool chain people are using. So um 91 people are using a stable tool chain, 36 using nightly and only three percent using something else.

B

So uh you'll notice, these numbers don't add up to 100, because it's multiple choice, uh questions um but yeah it's about three times as many people using stables nightly um and as for why people are using nightly so 72 it's for for features either a specific feature or for all the features that come with nightly and that's like the overwhelming reason people are using nightly is for is for new features, but then the the next most important reason, 24 percent of respondents use nightly because a dependency requires it and 20, because a tool requires it, um 11 use it because they test it in nci.

B

uh So I again, I don't have like previous numbers, it's interesting to see how we're tracking, in terms of how many people are using kind of like stable versus a nightly tool chain, and that analysis will will come later um and a similar measure, I think kind of like um we. We ask questions about stability as well, so just about the stable compiler. um I think we got really good numbers here. um Only two percent worry about their code breaking when they update their stable compiler and obviously we have our backups compatibility promise.

B

But that's working like people do not worry about upgrading their compiler version and that's all they're stable compiler version. I think that's really great, um even fewer just one and a half percent um feel that they sometimes have to make non-trivial changes to their code when they upgrade their compiler.

B

um So um so yeah, that's again, something that I feel is is quite positive.

B

Okay, so.

B

uh So kind of like making a little leap again like one area that kind of like I've always been kind of like you know, pushing and rust, is tooling, and I think kind of the survey is a really great opportunity to get um information about which tools people are using and how they're using them. um So uh I think this year, kind of like two kind of d. uh Two areas that can like stood out to me were ids and debuggers, um so we asked people how they edit their code and again multiple choice.

B

Questions people take more than one, but 77 people use an ide of some kind. um That's that's a lot um like more than I would have guessed. 40 people use kind of like a more basic text editor. um So uh so I feel, like that's, probably a change compared to a few years ago of the ide folk. uh Sorry not of the idea of all users.

B

The most popular id was was vs code with 60 of users using it at least some of the time um versus about um 27 prefer kind of a more kind of like traditional full-featured kind of ide um and in terms of kind of peop of sentiment like 66 people have a positive impression of id spot and rust, which is, I, I think, pretty great compared to 20 28 having a negative impact and 56 think that it got better in the last year.

B

So I think that's kind of really impressive um and you know shout out to everyone kind of uh his word on bust analyzer, rls jet brands, etc. For doing that, good work, um debugging is interesting.

B

um uh I think it's interesting whether you know debuggers are kind of like um traditionally a really essential tool for persistence, programmers and there's kind of like a bit of a feeling that in rust you don't need one so much so I was interested in just interested to see like whether the statistics back that up so 65 percent of people um use some debugger some of the time. um So so that means obviously like 35 of people, never use a debugger. um I thought that would be.

B

I thought fewer people will be using a debugger to be honest, but um so, but that's that's pretty interesting to me um and in comparison, 68 of people do debugging using some kind of logging, whether that's print line or using the debug macro or using something more formal, like a tracing library or whatever um so they're kind of comparable numbers. So that's like 65 percent use. Some kind of debugger compared to 68 do some kind of logging to debug their problems.

B

um On the other hand, only 41 percent of people have a positive impression of debugging and 38 of people have a negative impression um and only 21 people think it got better over the last year, and so those numbers don't seem quite so um bad, but um it turns out kind of like people who fill out.

B

The rest survey are quite nice and certainly in comparison to to kind of like the sentiment that we saw for other parts of that question like that kind of 41 38 split is, is fairly negative for for debugging, um okay. So talking of kind of like this kind of like sentiment about things, um I um uh wanted to kind of like quickly go over kind of some of the the percentages of people like kind of like positive sentiment about stuff, because I think this is um kind of good to know so.

B

um Kind of most um positive impressions were about documentation and uh compiler error messages, both of which had like 90 percent of people thought they were good um in comparison um on the compiler. Nobody will be surprised that compile times got a pretty measly score, 36 percent, um but, on the other hand, get a compiler errors. So that's like isis, had a 73 kind of positive impression, which is is pretty good. um We didn't ask about many kind of like domains of programming. We probably should have asked some more.

B

We did ask about async programming, which only got 39 and gui programming, which only got five percent um positive impressions, um but that's probably not too surprising either, um given the the state of kind of like gui, programming and rust.

B

um uh Sorry, I'm just kind of seeing where we've got to okay. So one of the really interesting questions um that that we asked- and this is a suggestion from from from now on- um from the foundation and at microsoft, um so she suggested asking like what people's um biggest worry was for the for the future of rust um or what things were. So this was again um like a multiple choice. Questions people could take more than one so don't expect the numbers to add up to 100. um the um the biggest sorry.

B

The most popular worry was that there was not enough industry usage of rust, and that was at 38, um and I given kind of like how positive 2021 has been in that direction. I would expect that number to kind of like be falling from previous years and fall in the future as well.

B

um The next biggest worry was that the the language would get too complex uh and 33 of our respondents have all sort of the the rust users who who filled the survey had that worry, followed by thirty percent, worried that um uh the uh developers on the project weren't getting the the support that they needed and 26 percent of people were not worried about anything at all. um So so that's the the nice number um and and ever every other warrior there are.

B

There are a few that we listed got less than than that not worried number um okay. So the final number I wanted to to share was about.

B

um We asked quite a lot of information about um developers, kind of experience and and about who they are, I guess, um but um but and um kind of we'll, we'll we'll get deeper into that in the and the the data we share later on. But for today the the bit I wanted to share was about um people's experience with other programming languages. So where they've come from, um so we asked whether people had any.

B

um You know whether they had no experience or whether some a lot or experts um so just to make that into one number and kind of like taking the the expert or kind of like a decent amount of experience and bucketing them together.

B

So the the the most popular kind of oh- and I said so so this year we we changed slightly from previous years. We previously asked about individual programming languages. This year we asked about kind of like classes of programming, languages or or paradigms um so the the most popular was dynamic programming languages. So this is um or scripting languages, so javascript, ruby python. That kind of the 83 of our users have um decent experience with those languages.

B

Next up was kind of your your classic statically typed languages. So this is your java. C-Sharp go um 72 there um and then c and c, plus plus, was kind of is kind of like the uh or system traditional system spoken. Languages is kind of like a fair ways down from that 58 and then kind of modern um languages with um kind of serious type systems. So this is like scala, kotlin and swift. That's 24 and um functional language, statically typed, functional languages like haskell um was 17 um and dynamically type function.

B

Languages, like list was even fewer, just 13, um so I I think it's helpful to understand kind of like the the the backgrounds of where kind of like rust users are coming from, and I think it's really interesting that um uh you know the um the kind of like the the the nearest languages or languages that maybe have kind of like a lot of influence on rust.

B

I actually have fairly low numbers of people overlapping, whereas the much more mainstream, more popular languages, perhaps unsurprisingly, when you frame it like that, have much kind of like higher numbers of overlap.

B

Okay, so that's that's all the numbers, hopefully I haven't, bought everyone to death, um like I say, they'll, be kind of like um a summary report for for team members.

B

Hopefully soon we don't have any kind of like firm date yet, um but what would be really useful to know um both for for the analysis that we'll be doing this year and also for for planning the survey? um You know the end of this year and in future years, is what you'd like to know like as a as a team as a working group? What would you like to know about rust users?

B

Oh sorry, I should say like we are we're not just constrained to the kind of like the annual um community survey as well like it might be interesting to do other kinds of surveys.

B

So what we'd like to know is what you would like to know and if we can figure that out from the data this year, then we'll try and get you an answer, and um if we can't, then that's really good feedback for us for for next year, as well. This year's survey um and and future years surveys. So so, please, let me know or ryan, and I know um if you, if you have any of that kind of feedback, um so so yeah. That's that's all thanks!.

A

Great, so I think we have a little bit of time here to do a question period. uh Nico I'll hand it over to you. First, it looks like you have your hand up.

C

I do I have a question um nick I'm curious: did you cross-reference the backgrounds that people came from with anything else like their biggest worries or like what they why they use, rust or and so forth? So.

B

We have not done any of that kind of like deeper analysis yet, and you know deep is a is relative and I realize that's not super deep, but, like we haven't done any kind of like cross-referencing, we haven't really dived into the data beyond just trying to um get kind of like the the basic numbers at this stage. um So uh I think that's kind of like that kind of cross-referencing is super interesting.

B

um We would you know, there's obviously a lot of different cross-referencing. You can do and kind of like a with a you know, data to size, so it'd be really interesting to know like specifically, what like folk are interested in like particularly like um interesting, because it's actionable for the team's planning or whatever, not just interesting, because it's.

D

Like.

B

Interesting um but yeah. So if there's like specific things, I'd be really keen to to hear what it is. You want to do and we'll try and work that into the the actual analysis of the data. We're planning to do.

C

The other question I had was whether you asked about the sort of domain that people are targeting when they write rust, like embedded versus async versus whatever we did.

B

There's it's so uh I thought that would be an interesting thing to say today, but it's actually um kind of difficult to interpret because there's a lot of um overlapping um areas. So um uh so for um um so sorry, I'm just kind of.

B

Looking at the numbers, I.

C

And we can dig into it offline.

B

Yeah, so so, basically, it's kind of the the largest domains that people are working in were basically kind of like um the the kind of uh web back-end networking cloud infrastructure that kind of group of domains um we asked about it. It was a multiple choice. Question we asked about so many different ones that it's actually kind of hard to compare.

B

um So, for example, we asked about embedded with an operating system and without so maybe if we combine those two, then it will be. You know higher up the list than it looks at the moment, um but maybe it won't. This is multiple choice and maybe everybody's already ticked both of those.

B

So it's it's one of those questions where even to kind of like get the simple answers takes a bit of analysis, um but that's that's certainly one of the ones that I plan to kind of like dig into a little bit for the um the initial summary data that we're gonna send out. Okay,.

C

Yeah I'll see I'll see the floor to josh, but I'll just note before I go that um I I think it's really good to focus on what you do in response to the data. I like that, but also that um I think like with domains in particular, I would be interested to try to do some of that cross-correlation because knowing I think that does seem very actionable to me to know. For example, you know people who are doing embedded have these specific concerns.

C

Those same concerns if they come from a different group of people like might have different answers. You know like embedded yeah anyway.

E

All right josh, so um I am thrilled to hear so many positive sentiments about rust. I know many people are uh the thought crosses my mind that, like we try to reach people who uh are interested in answering the survey but aren't necessarily uh involved in rust or using rust actively. But it's clear that, like 90 of people who answer the survey are using rust.

E

So we are missing a substantial audience of people who, for example, try rust and bounce off and aren't necessarily connected enough to the rust community to go answer a survey about a language they don't currently use.

E

Are there any plans or have there been any discussions for how we can make a concerted effort to reach and survey people who have bounced off of rust are waiting to try rust because there's some blocker for them? Basically, the set of people that we are going to miss information from because they're not here yet, and that's a circular problem.

B

Yeah, so I I I don't think we've had kind of very many discussions about anything to be honest, so kind of, like part of the the problem has been the the survey or kind of like this broader kind of like area of understanding.

B

Our users really has not really been owned by anybody and has just been kind of ticking along over the years, um and so uh we ryan- and I have kind of like started with the annual survey to try and kind of uh get deeper into this area, um so uh yeah, so absolutely kind of like understanding the users who bounce off is is really important, but also kind of really difficult, um and I think it's interesting that we get like 10 may not sound like very many, but that's like over a thousand um respondents who um uh who no longer use rust, filling out the survey- and I think that's kind of um that.

B

You know the only data we have of anywhere near this kind of like scale about those users, um and you know you know, obviously far more than a people kind of like fit in github issues or whatever, um but- uh and I think kind of like one thing we kind of struggled with- was what exactly we wanted to kind of like ask those users um so so yeah I mean, I think that the the survey is like.

B

Actually, the the annual survey has like a bit more reach into those kind of former users than than any other tool we have at the moment, and so thinking about exactly what we want to ask them like in in the following years would be really good to know um beyond that. I think that kind of, like it's important, not to get too hung up on surveying.

B

um I think that, like getting information about how users is super important, um but often like a survey, isn't the best way to do that, and especially with users well non-users, who are hard to actually kind of like track down and get to take part. Then we might get much more useful data by um doing kind of like one-on-one interviews or focus groups or usability.

E

Of the other principled fashion, yes yeah, obviously.

B

Focused.

E

On the survey in that way, I just wanted to ask if there had been any thoughts of how to extend that reach or how to specifically reach those people, I'm thinking specifically of like, as we try to make the language more usable. I would love to make sure that we are hearing concerns from people who bounce off and don't come back and not just people who bounce off lightly but are still close enough to know that the survey exists right yeah.

E

That's.

B

That's.

E

I want to make sure that we're not consistently missing a con particular class of user.

B

Yeah but.

E

Yeah, it sounds like there are thoughts on that front and also.

B

We could do something more.

E

Definitely thoughts but nothing concrete. Okay, thanks.

A

That was all I had.

A

All right, um I don't think we have a few comments in in chat here, but I will, I think, pass it over to wesley now and we can get started with uh the compiler team.

D

Ambitions would you mind uh pulling the slides up for us? Oh yes, I can do that. I just like to be able to look at my notes.

A

No worries, let me just figure out where I put them.

A

All right here we go.

D

Perfect great, thank you um yeah, so this uh this talk is basically about um an upcoming blog post. uh That's getting published titled compiler team ambitions for 2022 uh by felix, and I um based on some funding we did, and so most of this talk is actually about kind of the meta pieces of that planning and not so much about the content of the blog post, um but there's a sneak peek at the contents of the blog post at the end.

D

So if you could go to the next slide, uh yeah so kind of the background here is just um an observation that in previous years the compiler team is often kind of oscillated between having planned.

F

Out.

D

Ahead of time plans for the year and processes to try to achieve those plans and working groups and things like that and then other times uh things have just been very unplanned and ad hoc and um and that's fine too, but for this year we wanted to be a little bit more organized and that's sort of in contrast to last year, which was which was very ad hoc, um even though lots of really great stuff happened. So next slide so part of the goals of our process. Here was um a few simple things: one.

D

We wanted to find out what contributors were actually working on, there's a lot of people in the compiler team and especially on the compiler team contributors uh sub team, and most of them are self-motivated to work on things. um It's not really top down. You know felix and I can't come up with a list of things and tell people to go work on them. It's really what interests, people and and what they want to work on and that sort of decides.

D

You know the the different things they contribute um and it's not always clear to us what people are interested in working on or might want to work on, um but aren't sure if you know there are other people that could support them, working on those things or not um kind of related to that we wanted to see if there were common themes to those uh those things that people wouldn't work on between different sets of contributors, uh we were really hoping that there would be.

D

Ideally what we would like to do is spin up some working groups or project groups, um or even if it's just you know, one or two people like try to get some people connected um so that they know you know who's, maybe interested in working on that same thing. Who could they bounce ideas off of who? Could they ask for code reviews um things like that?

D

We wanted to give the community an idea. What we're working on the release team does a really great job showing off what's in every release that goes out, um but I think it's not always obvious to the larger rust community. What might be coming? You know in the very short term or in kind of a more medium. You know over the course of 2022 kind of time frame.

D

um We wanted to highlight some of the ways that the community can help out, uh even though, like I said before, we kind of are a large team. We want to keep growing that team. We want to enable new people to contribute to the compiler.

D

um We want to grow people in the roles that they already have in the organization, and we also you know going back to what people want to do. We heard from contributors that some of them were interested in mentoring, people for specific roles or specific kind of projects, or things like that, and so we wanted to be able to highlight some of those efforts and then finally, we also wanted to showcase the growth and maturity of the project.

D

We have a lot of very consistent contributors. We have people who work on rust in their free time who are paid to work on rust and really just showing off how many people uh get back the project or contribute the project in various ways. I think is a really big sign of maturity for the project um and really speaks to some of the stuff that you know we're doing so uh next slide.

D

So um this process was kind of come up, informally and and on the fly it wasn't really given a whole lot of thought ahead of time. So, um while this I think has worked well for us, there's definitely you know tweaks and things that could probably be done to streamline or improve it. But the very first thing we did was just open a thread on the tea compiler suelop channel. To literally just ask people to spitball ideas for what could go on the roadmap and kind of see what people might be interested in working.

F

On.

D

Or what they thought you know would be a good thing to work on um and then separately felix and I wrote up kind of lists um based on some of the feedback in that thread, based on things that we knew people in the project were already working on or that were they were very interested in working on or things that we thought could um you know would be great to tackle if we had the resources or whatever.

D

So then, after we did.

D

That separately, we came together and we consolidated those listed in one document and one of the kind of really interesting things that emerged at this point was um a very clear distinction between a list of things that we felt like we could achieve this year very concretely and we decided to call those things initiatives and then there was another list of things that we both thought would be excellent if we could get done, but as it is now, we don't really know um that those things will get done this year, and so we called those things aspirations.

D

um So after that we went back to the compiler team and the compiler team contributors, we send some emails with links to the consolidated document and scheduled one of our friday design meetings just to go over the document and read it and talk about it with people and see what the feedback was, whether we were on the mark or had missed things um and even just pm, to people to make sure we got feedback from everybody on the team and there wasn't something important. We were missing or whatever uh and then.

D

Finally, the result of that was kind of distilled down a little bit and reported for more general consumption. And it's going up on the inside rust blog tomorrow, which is very exciting. Next slide.

D

um Some of the takeaways we learned from doing this it it always takes longer than you think it is going to like every step of this took longer than we kind of thought it would, or maybe we were just hoping it would um in the end.

D

I think it was totally worth it, but it is a time investment to do something like this um related to that we set deadlines for various pieces, and I think that was really helpful as a forcing function to make sure that stuff got done, um but it was also important to kind of remember that a lot of these were kind of self-imposed, and so if there was some really important reason to delay something or whatever, then we could do that um and not to get too fixated on on hitting every single deadline.

D

You know exactly and then I think one of the really interesting things that came out of this, for me was um the outcome of just having people talk about what they hoped or what they wanted or planned to do. This year was extremely valuable.

D

um There were multiple areas where felix, and I thought it would be really great if we could do this, and maybe even one or both of us were interested in doing something there. We just didn't know you know, would we have enough people to make it an initiative instead of an aspiration and debugging in particular, was one area where we thought you know. We really need to do something. The survey.

B

Results.

D

Nick mentioned earlier, debugging was uh one of the pieces that really stuck out from that as currently very lacking to people in the community, and um it turned out that there were a lot of people um on the team that were interested in contributing here. So we're actually spinning up a debugging working group this year um to make some progress on that.

D

Next slide.

D

So uh kind of a sneak peek as to what's in the blog post, um there were three main things or three main themes. I should say that we identified for 2022. one was uh fulfilling russ promise, which is really.

F

Kind of about identifying.

D

The gaps between expectations and reality for the three main pillars we have on our on our site, performance, reliability and productivity, and then addressing those the developer delight.

D

We wanted to answer the question: what would delight for us developers and not just meet the bar for where things should be, but surpass that and then finally contributor workflow um to the compiler specifically.

D

So um this is typically improvements to uh the technology or the tooling or the infrastructure or whatever, that benefits people, maintaining, maintaining and extending the compiler itself next slide, and so between those three themes and the things that we concretely thought we could do the initiatives and the things that we hope or would love to do if we had infinite resources, but we're not sure that we can actually get done this year. We have these lists of topics so addressing issues of unsoundness in the compiler.

D

We think we can make concrete progress on that this year. We think we can make concrete progress on various pieces of asic rust, like implementations for async functions and traits, and some of the other enhancements around just using async rust. We think we can make a lot of great progress on debugging.

D

We think there are some pieces there that are probably going to be more aspirational in nature, um really deep integrations with gdb and lldb and windy bg and visual studio and the multitude of debuggers out there is. uh We would love to have that, but we think that's probably aspirational this year this year, we really like to focus more on um fixing some of the kind of fundamental issues and making things have a really solid foundation there.

D

um We think that we can make progress on compiler throughput and improve things there um again, there's so much, there's such an open-ended area there that some of that is aspirational, but we think we can make concrete progress there.

D

Expressiveness is really kind of about the gap between things that have been approved in russ the language and things that are stable on a stable compiler for things that are not implemented at all, currently in the compiler and there's a lot of those. So we we think we can make progress in some of those things and other things are probably going to be. You know in the future and then finally, librarification is really about splitting out pieces of compiler so that they can be reused across other projects.

D

um This impacts things like uh using mirror for formal verification, or even some of the things within the project like miri and address sanitizers, and things like that um and then finally, the things that we would love to do, but we think are probably at least currently not going to get done this year, um addressing the backlog, high issues.

D

We have plans to try to triage them, but I don't know that we will actually make progress in resolving you know a vast majority of them or something we would love to have. You know improvements to how the compiler team runs organizationally or procedurally, we would love to see more work on some of our alternative back ends like cogen, gcc and cogent and crane lifts, um and I think there probably will be things that happen there this year, but I don't know that we will be able to drive those.

D

You know to completion on a stable compiler this year, at least with the current resourcing and then finally diagnostics.

D

There will certainly be improvements that land to diagnostics this year, but I.

F

Don't know.

D

That it's going to be a big push on diagnostics this year, at least currently.

F

So just want to jump in quickly here, um because I watching leslie talk. There was one thing here that I want to stress. um Anything that you want to add to the compiler is in some ways an aspiration. These concrete aspirations were chosen, particularly because, um while we don't have the resources today to do them based on what people's timelines are, they do have owners. These are things where. If someone were to show up and say I want to help with this, we do have a plan in terms of there's a person named who says.

F

Yes, I am willing to help um mentor somebody with getting started in this area. So it's really important to me that we've teased out the aspirations as things that it's deliberately meant to be a way to invite people to come in and help us succeed this year um and the other detail there is. A number of these items in this table are specifically ones that they're meant to be things where you don't have to have a lot of expertise in the compiler source code itself.

F

To make big impact you'll see the spelled on the blog post itself, but I want to stress it here, since we have such a mix of people in this audience. I want to stress this there's items on here, such as the team operations item, um where there's big bullet points for things that you we hypothetically do not need. Necessarily someone who's got compiler um expertise to deliver in other ways. uh The examples there are things like automated test reduction.

F

Tooling is an area that I think we could make big strides on, and you don't have to be a compiler expert to do that and our performance um uh profile. Our what's the word, our benchmarking suite yeah our performance, benchmarking infrastructure has a lot of needs that don't require compiler expertise to deliver on. It just needs that a lot of us don't have expertise with like web front-end things.

D

Yeah yeah, thanks for uh adding that I definitely I was trying to trim the chart down a little bit and and cut off uh the owners and things, but um there's more details on all of these things in the blog post and, as felix said, there's also um links to the people that own all of these certain areas. um Some of these areas are split across concrete initiatives and aspirations, and so they have different owners, some of them for those different things, but all of the details in the blog post is going out tomorrow.

D

So that is the last slide. So I guess we can take questions if there's any questions.

A

All right, great yeah, so we have a few minutes for questions here. um I'll wait to see if anything comes up in chat, but I'm not sure anybody has uh put their hand up just yet uh niko I'll hand it over to you.

C

Yeah, I didn't see any hands up, but I have a question uh and thank you all a second remy here um I was wondering I was thinking about um sharing knowledge and plans and I think the mcp process, and so on has been great, but I'm realizing like as I watch some things go by that I at least partly a function of just not having as much time as I would like to follow along in zulip. Don't really know like how we plan to re-architect here and so forth.

C

um Have you all thought about team mechanisms for kind of sharing knowledge beyond the mcp, like maybe reorganizing, the rusty lecture series and so forth, and I guess somewhat separately.

C

Would team organization be a kind of topic that would show up on this roadmap? Or is it all technical topics.

F

So this wrote, the content of this document proposal was mainly focused on technical stuff. Like there's a point where I think I especially called out- and some of it like we're just focusing on technical stuff here, not social processes et cetera, um and I don't I don't- have a good reason for why we chose to do that. It was just, but I figured be of interest to the larger audience at um and that's the other question you asked about knowledge. Sharing. I'm curious is your is.

F

Are you asking that about specifically about cro uh sharing knowledge across other teams? Are you meaning both sharing knowledge within the team and across other teams?.

C

uh I meant more like amongst compiler team, uh but and sort of, I guess the somewhat larger, like compiler team and adjacent people who hack on the compiler uh like. I would love to to to hear more about the plans around around here stuff. You know specifically, um but I and I just think that there it would be great to try to have some organizational like organized effort to to have more conversations like that happening, um and I'm wondering if that's something that could be a good working group.

C

I don't think it should all fall on youtube would be better if we could make it more independent.

F

Yeah, that's a good question.

D

Yeah, I I think that would be great. um I think it sort of falls in a little bit with some of the team operations things. I think there were a few non-technical things that did get called out there um and that would probably be a good fit for some of that.

C

Like another, related topic would be like rusty dev guide, based initiatives and so on, yeah. Okay, thanks any other questions. Since I'm trying to maintain the list.

F

There was a question in the chat from frederick tens. um Is there an overview of what's concretely planned in the short term, for the improvement categories which have concrete initiatives? I think the best answer there is sometimes uh like. I think that the text of the blog post, which we'll see when it gets posted it does spell out some amount of specific things for the different, different, concrete initiatives in terms of spelling out what their owners are planning to deliver.

F

But I will admit, I think it didn't get into as enough as much detail as some people would hope in terms of I've. Definitely had some people read the document and gave me feedback. This thing that you listed here is like a multi-year initiative. What are the actual goals and milestones that you're going to be delivering on this year, and my reaction is to say well this thing's this document's already late as it is.

F

um I don't want to go back around and try to get like that level of detail, but like what like what is said in terms of future iterations, the document I think, if it could, it would be good to get that level of concrete detail into the document on the first go-around. If we can do it.

A

All right, um it looks like we're at the end of questions I'll, give it another few seconds here um all right, perfect! Well, thank you! So much uh wesley and felix for uh the talk here. I'm just gonna pull us back over to the agenda, um we're almost at the the top of the hour, and so I'm just gonna leave it open for another few minutes. If there's any announcements, people like people would like to make, but if not, that is all good.

C

I have an announcement um so doc jones and I have been discussing- I don't know if any of you saw, but there was a paper that came out a while ago about doing analysis of non-coding roles in open source communities and they analyzed like npm, contributor data and other stuff and doc jones, and I have been discussing some with the authors of that paper who are really interested in applying their kind of metric analysis to rust, and one of the things I was hoping for is that if people are on this call, who would like to chat about that?

C

Maybe we can do it in the social hour if there are like kinds of analyses, you would like to do uh to look at what kind of projects are active, other kinds of data that you or just or who are who knows what piece of code best or things? There are questions that you feel like you could possibly answer um I'd like to chat about them during social hour. So that's the announcement.

A

Great thanks nico uh anything else from anybody.

A

uh Yes, josh I'll hand it over to you.

E

uh Just a mention that uh instrument coverage is going to be stable soon, and uh I wanted to invite people to. If you have performance sensitive rust code, you will soon be able to do instrumentation based uh code coverage on your uh code. Try to figure out more about. What's going on with it, I'm looking at doing some of the same stuff with profiling and, uh more generally, the.

E

There's a number of efforts going on right now to try to stabilize some of our long-standing. This has been unstable, forever kinds of features like cargo's timing, option or strip or 20 other things, and I would encourage people who are keeping an eye on particular features that they think will never be stable and uh who have kind of given up hope on them being stabilized to revive that discussion and like hey, I'm still interested in this. What can I do to help with this?

E

What's the blocker for it to be stabilized, sometimes it's easier than you might think, and it's a really rewarding activity. People care a lot about a feature showing up in stable.

A

All right and then I'm just taking a look at chat uh wesley. I can't see the characters that you put in because they're showing up as blocks for me, but I assume that was um not putting your hand up at justin. uh Sorry, those are those were just celebrations for uh instrument coverage being stabilized, perfect. Yes, good reason for excitement all right, so in that case um I will close off the ctcft, uh we'll hop over to the social hour. So thank you, everybody for coming out to the february ctcft and we will be.

C

Here, that's why.

A

Wait for us wait. Yes,.

C

Part of one other thing all right, we were, uh we were saying we're gonna, do a longer talk about this next time, but we're looking for ways to to grow the set of or to incorporate suggestions on what kinds of things would be great to cover during the ctcft.

C

So if you have ideas of things you'd like to hear us talk, I just want to add that you can throw them in zulu. For now and in the next meeting, I think we'll be talking some about a more organized approach. We plan to take.

A

Indeed, yes, uh organization would be a very nice for our background uh setup of the ctcfts all right, so yeah we'll hop over to the social hour, and we will see you next month.

A

Forget to stop the recording all right. Did it stop? Oh, is this working on stopping.

C

I don't know if it stopped.
youtube image
From YouTube: 2022-02-21 Cross Team Collaboration Fun Times (CTCFT)

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).