 Hello everybody that's loud hello everyone well we're about to get started but before we go I just want to take a moment to say thank you to our gold sponsors Skylight Mozilla Intel chef you guys are great we would not be able to do this without you thank you very very much so we're gonna talk a lot about what's gonna be happening over the next year in Rust before we do that of course I want to look back about what's happened in the past year sort roughly since Rust camp last year which was also more or less the 1.0 release we've all been working pretty hard and a lot of things have come from that so we've had a lot of progress for example in the library when we first released 1.0 you may remember we had a kind of minimal let's stable API surface we've expanded that dramatically we've added 175 new features to the stable list covering all kinds of areas so you can now really use the standard library for most tasks that you need on stable which is great we've been building a lot of language features so for example specialization infiltrate the question mark operator now the macros one one RFC and I'm sure there's a lot of things I forgotten these have all been designed gone through the RFC process have been implemented they're all on nightly now at varying degrees of completeness and hopefully they'll be making their way to stable and they're not that distant future and in the meantime while doing that we've re-architected and re-implemented a lot of the compiler so we added a new internal representation which we call mirror and it's now on default it's now the default backend on nightly it's going to be the default backend on stable and a release or two I think it's on beta I can't remember yeah it's enabled on beta in fact and with that we've already been able to add for example more efficient code generation around drop which is a dynamic drop something we've been discussing for I don't even remember how long before we got it to work and we are now recently released their kind of incremental compilation is starting to make progress we're in an alpha period it's working except we have a lot of bugs to fix to make it get better reuse and before we're willing to let people you but we're willing to recommend that you use it let's put it that way but if you're a brave person you can give it a spin and we've been doing a lot of work on error messages lately and I think that works going to continue trying to make them more readily understood better formatted more attractive so finally we've been working hard on cross compilation we have a rust up tool now that lets you switch tool chains very easily and we have a lot of tool chains available and you can kind of customize it per directory and so forth so I could go on and on about the technical details but I think what's most exciting is that in the year since we released it rust has remained kind of a language basically a language that people love to use right and we love to use and that is really great so one indicator of this but there have been many was this Stack Overflow survey where rust came in on top with 79% of people who use the language saying they want to keep using the language so that's really cool we have a friends of rust page now where people who are in industry can sign up or I guess anyone betting money on rust is kind of our catchphrase can sign up and get their logo on the page and there are now when we started there were a few logos there's now 35 and you can kind of watch a video here where I awkwardly scroll through the list because I can't figure out how to make it work smoothly someone should tell me but you can see there's a lot of logos there so pretty cool and finally the rust community itself as evidenced by this conference right here but it's starting to really grow and so we have if you believe we have 14,000 people attending rust meetups around the world we have a new community team that's working on mentoring and other opportunities we have three conferences taking place this year so there's rust conf here and then another in Pittsburgh and Berlin so there's a lot of excitement about rust and we're really excited to see it happening but for that I'm going to turn it over to Aaron for some kind of prognostication thanks Nico yeah it really has been a remarkable year and before I get to the prognosticating I just want to sort of echo the theme that you know for me the most exciting thing on a daily basis is just the rust community the level of you know passion and energy and kindness so I think you know that's what keeps me going day to day and it's only getting better so thank you all for that yeah okay so that said you know I think what's on a lot of our minds here at the conference is where do we go from here what's ahead for rust and you know I'm happy to say we don't actually need to look at a crystal bowl to figure this out in fact the Rust core team has been putting a lot of thought into how we set out a vision for the next increment of rust how we execute that vision how we communicate that vision and so there's been an RFC recently that Brian Anderson from the core team wrote up sort of laying out some thoughts on how we build this process and so I want to walk through a bit of that just to sort of frame out what we're going to talk about in the keynote so this is this is the new Rust map Rust roadmap process so the heart of this process is the idea that every year we're going to come together as a community and try to set out a vision for the next year of Rust and the way this should work is we spend some period of time really gathering a lot of data doing things like the Rust survey that went out talking to production users talking to people as we're trying to teach them Rust as we're doing outreach in conferences you know anywhere we can encounter people using Rust or trying to use Rust we want to hear from them hear what kind of problems they're encountering and then take all of that data sort of try to digest it down and talk as a community about what are the biggest problems that are coming up and from that build out some themes for the year and you know sort of a realistic vision of one year from now how can we have knocked down some of those obstacles to using Rust so this process is already underway hopefully many of you have already participated in the thread but if not there's there's a thread on the internals forum that's basically starting this conversation and it's going to go for most of the month so please join in in the meantime this keynote is going to make a pitch for a particular part of that vision that I think is really important but before we get there there these other aspects I mentioned before about you know it's not just setting out the vision but it's how do we execute it how do we communicate it so another core piece here is we want to start a milestone process where every six weeks aligned with our release cycle will be setting a GitHub milestone and that milestone will contain the work that the various teams that are part of the Rust community are trying to do toward our vision right so the idea is at least every six weeks we're taking a step back looking at what we're trying to do in the year and making sure we have a concrete increment that is actually taking us in that direction so you know that's good on an organizational level but I think also at you know I've been sort of saying communication is really important here the goal is and anybody you know in the Rust community so I think a lot of you are Rust enthusiasts and are sort of up on things but people who maybe aren't following so closely it should be really easy to you know hit up the Rust homepage and figure out where is Rust heading what work is going on how can I get involved and help Rust achieve its goals right so that that's a big part of what we're trying to do here and you know one last piece of that communication front is at the end of the year right as we complete one of these cycles we want to take a look back and see how do we do you know did we actually knock out the problems we wanted to you know where where did we fall flat and then synthesize all of that into a kind of retrospective that we can release to the world so every year we want to put out sort of a story about where Rust is going that everybody can listen to and that gives a really coherent narrative and that should be looking at the whole ecosystem right not just the compiler not just the language okay so that's that's the big picture of the roadmap process and like I said the keynote is really going to focus on this this vision aspect and you know I mentioned that we want this to be driven by various sources of data and one of the big ones is the Rust survey that the community team put together a couple months ago and you know I think we were all blown away by the results of this survey and a lot of respects you know one of the biggest being how many people responded right so we got over 3,000 survey responses and one thing that's really exciting about that is over a third of those responses came from people not yet using Rust right so this if you put this all together we actually get a pretty informed picture of the obstacles people face whether they're using Rust or whether they would just like to use Rust but you know aren't able to for one reason or another so let me go through some of the challenges that sort of came up time again in the survey okay so far and away the biggest challenge we would see is the learning curve right this this is a theme that was repeated in one in four responses and I think you know what what we often hear when we talk to people about Rust who have come to love the language and are sticking around is well the first two or three weeks were pretty rough right I had to like fight a lot with the bar checker I there was a lot of new stuff to learn it wasn't easy but after I got over that hump and really started to understand what the language was about I fell in love right and that's a great story but we can do better right because we're losing a lot of people on that early part of the curve right so that's going to be a major theme another one we hear often is the library space so Rust is a very young language right only a little over a year out from 1.0 and so while the ecosystem is growing really quickly so while the ecosystem is growing quickly you know there's perhaps more we can do to focus on building libraries that people need another piece is just overall maturity so not just in the library space but also tooling compiler performance debugging and so on there's there's more we can do one thing I think that surprised a lot of us was how important IDEs were on the list right so if you look at all 3,000 responses it was like 1 in 19 but if you narrow to the you know a third or so of people not yet using Rust IDEs came up a quarter of the time as the reason that they were not yet using Rust and that's really interesting and I think in a lot of bigger production shops IDEs are an essential part of people's workflow and basically if your language doesn't have a good ID story you're just a non-starter right so this is a huge thing that we need to be looking at and of course compiler performance which I think we're all pretty well aware of and this is something we hear a lot from production users as their number one complaint as they start getting bigger code bases compiler performance is a big problem okay so so those are some of the sort of high-level takeaways I guess from the survey but it's a lot of stuff so I want to sort of step back and try to identify a common theme running through all of these issues and I think you know through the survey through conversations through thinking like the way we're looking at this is productivity is key there are lots of different ways to look at productivity lots of different questions you might ask in terms of is a language productive as an ecosystem productive but I think the biggest obstacle to rest today is its productivity so zeroing in on that a little bit right there are some aspects of productivity that rust gets really bright today right so if you need to write a piece of code that is reliable rust is a great way to get there quickly if you need to write a piece of code that's fast rust is a great choice for that right so we have we have some good strengths here but then there are these other pieces that don't really sound much like rust like rust is a fast way to get up to speed writing code or rust is a great language for prototyping right these are these are not things that feel very true of rust today and it's tempting to think that there is a fundamental trade-off here right that rust has some core values around performance and correctness we're placing those above all else and one of the things we're sacrificing is early learning curve or getting teams up to speed really quickly let me tell you about trade-offs so here's a slide from rust camp you know last year that was trying to sort of sum up what the 1.0 release represented in terms of you know what rust is at heart and I think probably all of you have seen these slogans if you've been around in the rust community but each and every one of these things represents an apparent trade-off that rust has been able to overcome right before rust came on the scene you would think that well you can have memory safety if you have a garbage collector but if you are forgoing a garbage collector good luck getting a memory safe language well rust gives you both at the same time right or if you want to do concurrency especially shared state stuff you're gonna struggle with data races well not anymore right rust lets you do concurrency of all kinds while guaranteeing data race freedom right so I think a big part of the spirit of rust is having our cake and eating it too I think it's something we're really good at and so my challenge to the rest community this year is to do it again right so we all know that speed and reliability are core values of rust I think productivity needs to become a core value of rust too and we need to find a way to have all three together all right so with that we're gonna go through some of the different teams and aspects of the rust project and look at what it means to have productivity as a core value right so when it comes to the language itself I think it's as Aaron said it's important to kind of look and realize when it in terms of being productive while also having code that runs fast and is reliable we've done a pretty good job so far right I mean what do people love about rust I can tell you what I love about rust is this feeling of kind of galactic power at my hands and I can just like throw a few lines of code and then what I want happens kind of like a wizard or something right so I can write an iterator like this that takes a string breaks it into lines finds the maximum or the lengths of the lines finds the maximum and not only is it look pretty I could do that in a lot of languages and have it look pretty but in those languages it would probably make an object for every line and it would be kind of slow but in this version it's as fast as some C code that has a little pointer and skips along right or I could write a snippet of code to traverse over some paths load up a bunch of images in parallel and collect them into a vector and it just takes a few lines of code and again I could do that in some other languages but I made a mistake I'd have data raises and maybe 1% of the time it just doesn't work the way I expect a few images get lost something goes wrong I don't have to worry about that in rust or using this newer work on futures that Aaron and Alex have been working on and also Carl we see we can send an RPC request out and we can get back a response and process it and it's a few lines of code but it performs really well right so here's a little chart that they put up in a blog post and you can see that here are some servers that the different kinds of servers implemented in different ways processing hello world requests right now if I told you don't look at the labels yet if I said which of these do you think was written in the language with the strongest safety and reliability guarantees and using the most kind of idiomatic abstract code all the way down the stack I know what you'd say you'd say the fastest one of course right no that's not what we normally think we normally think we have to trade one or the other but Rust has really turned that on its head I think that's something we can all be really proud of what we find people saying a lot and what I feel also is that over time right with the language the compiler becomes kind of like a trusted pair programmer who's kind of got your back who's looking over your code helping you think of cases you might have overlooked before and so even in this simple little routine that takes in an optional string which is the name of a user I guess they might want to remain anonymous or something and prints it out we already can kind of see some of that and so we have the option type in Rust so instead of using a null pointer for the string which we could overlook we have to notice that maybe the user doesn't have a name and we have to customize our greeting for that we don't get some kind of null pointer exception and of course this is a reference to an option of string which is the key to the whole kind of house of cards we built up here in our house of grass the wrong metaphor key to this beautiful structure that we built up basically you know it's it's what lets us have safe not need a garbage collector and avoid data races and so forth and we can indicate that with just this one sigil so that feels good so you know I feel pretty good about this code if I take it to compile of course I know it's gonna work right oh wait no it's not gonna compile I'm gonna get this mismatch types error that's a little bit a little bit aggravating but that's okay I know what the problem is an experienced Rust programmer I just have to put this star here because I don't want to match on the reference I want to match on what the reference refers to so I have to dereference it okay good now I can compile the code and everything's fine except oh yeah right I can't move out of borrowed content here that's alright too I'm an experienced Rust programmer I know the thing is when I say sum of n I'm taking ownership of the string that's inside the option but I can't do that because I've only borrowed this option so I need to borrow the string as well and I write ref to make a reference to the string and now if I recompile it's gonna work and so this is you know these are minor annoyances when you know what to do it's still a little bit unfortunate that I my code looked a little prettier before but you can get used to that but if you're an experienced programmer that's how it feels right but if you're coming for the first time and you're still trying to understand what ownership and borrowing even are this could be a total game changer this could be like I'm just going to walk away from this language I can't even print a string on the screen I'm feeling a little frustrated and so unfortunately I think there are a lot of places in rust where we take what we surface these kind of small details constantly right to the user and you have and you once you learn to deal with them any one of them is not a big deal but they can kind of build up so here's another example a pretty common one if I have a function that takes a string you'd think I could call it with a string literal right that seems logical but I can't because string literals are compiled into the binary we don't have to free them afterwards so they have a different type that makes a lot of sense there's a really good technical reason for that but it's not necessarily a reason that I care about any particular point in time right and it's particularly not a reason that a lot of new users are familiar with so when I do my introduction to rust tutorials literally the very first thing I talk about is this right okay let's just talk about strings for a second and it's kind of a shame because it's not the most exciting topic to cover first but so a similar example I think a lot of us have experienced is that you know if I have a reference to a map and I get a key from the map then when I find the key in there I now have a reference into the map and I've borrowed the map and I can't mutate it and that's kind of the basic system we can learn those rules but when we come if we find that the key is not present in the map we still can't mutate the map right because the checker has a kind of lexical notion of how these things work and it doesn't understand control flow as well as it could and that's something that can be very frustrating when you're if once you understand that it works on a lexical scope you kind of get it but before that you might think you don't even understand the whole borrowing system when really what it is you don't understand how dumb the compiler is being right here right it's not as it's not seeing it the way you see it so this is a list of some of those things that bother me or that I've heard about you probably have your own I'd like to hear what I'd like to hear about them actually not right now afterwards but so I think as these are kind of all of these exist for a reason right there is a technical reason that these distinctions exist and sometimes it's very important to have control over these details if you want your application to work right but it's not always important and it would be really nice if you could kind of choose these details in a few places and let the compiler work out the rest of them for you right and then if we do that I think what we'll find is that this trade-off we see where it feels like these explicitness and total control or at odds with nice ergonomic programming we can kind of resolve that and just sidestep it and have it not be an issue whatsoever right and I think part of the reason that I'm confident we'll be able to do this I don't have solutions for all of these problems necessarily though we have given a lot of thought to most of them I think we have good proposals that we'll put forward but if we look back we can see we look back to these kind of galactic power examples I showed before we can see that a lot of these trade-offs are there or there are trade-offs there that we've just managed to hide and take care of right and resolve so for example the biggest one I think is closures or biggest example of this trend closures is something that are like a fundamental building block for abstractions right you see that every one of these examples has a closure it's not more than one closure and it took us a long time to get this design right because they have to be usable in so many different situations you have iterators that stick within one thread you have multi-threaded programming where the closure serves as the body of a thread then you have things where the closure is being run in parallel with itself many times like in the loading images example I'm running that same closure for every image and the RPC is a little bit different and so balancing all of those trade-offs seemed like it was going to produce this kind of infinite family of closures where the user has to pick just the right thing but what you'll notice is in the syntax and in these examples we don't really see all those trade-offs at play right they're there but they're not right in our face and so an example a specific case would be if you look at this variable my socket this is something from the environment it has to be either borrowed or moved or mutably borrowed into this closure but I don't have to say that right we figured it out based on how it's used in the closure if you moved it in the closure then you need to own it if you only referenced it we can take a reference and so forth and so I think closures is an example where we did a really good job collecting diverse and seemingly contradictory set of constraints and resolving it into one kind of ergonomic but also fast and reliable abstraction and I think we can do similar things for some of these other examples so if we look kind of at this matching case that I showed first you could imagine that instead of requiring you to say if a binding is a ref binding or not we examined how the binding is used and we figure it out just like we do with closures so you might say ah this printlin is doesn't need to own the end it can just printing it I can make this a borrow right and similarly instead of making you dereference name manually you never really want to match on a reference that's not very interesting you're always looking at what it's referring to maybe we can just skip over those through those references right and then the code that I originally wrote would have worked in the first place but it would have worked the same way and my final code did right just as efficient similarly here with the string literal if we could extend the string type to know that sometimes it is containing memory that comes from the static binary instead of being always a heap allocated buffer then it wouldn't have to free it when it goes out of scope then we could allow a coercion from the string literal type to string and this code would just compile and better yet it wouldn't do any allocations or anything like that so it would be as efficient as if the user had typed antistatic stir as the type instead of capital string right it's not that this distinction is going away it's just that we're surfacing it differently or less and so finally this example if you've been following Rust for a while you're probably pretty familiar with it the map example and here I think we've we have a kind of well-known solution to this we can make the compiler smarter about control flow that's been a long time coming it's been very challenging but now the mirror is in place we've kind of got the pieces there we have everything we need so hopefully we'll be seeing that and again we can kind of overcome this see me make these rules basically just simpler to work with right and what we've done all of this right the language we have not given up any reliability we haven't given up any performance in any of these examples we may even have gained some in some cases like if we can prevent some allocations for strings but instead we've just made it nicer to use right and I think that should be a big goal for us so when we think about new language features we tend to think about exciting new capabilities extending the language in some way do something you can't do and those are important things and we have to keep those in mind especially if they sort of unlock an important domain for us but we also can look inwards and say okay what what are we doing now how can we tune it and improve it and make it more productive than it is today so alright thank you very much on that but let's talk about libraries thanks to go okay great so you know every team has something to contribute here so from the library perspective what does improved productivity mean so that's that's kind of a big question libraries are a big topic but I think there are a lot we can do just at a very basic level right so when people in the survey talk about libraries or maturity being an issue I think what they tend to be talking about is they have some pretty basic need for a library to do some work they're trying to do and they want that kind of library to exist in the ecosystem they want to be able to find it easily and when they start using it of course they want the library to be of high quality and you know what I think high quality means of course is fast reliable and productive all over again so that's a fairly basic kind of goal to shoot for I want to spend a few minutes on sort of each of these dimensions highlighting some specific things we can do to improve our library story okay so let me start with libraries that should exist or should exist in a more mature fashion I think one thing that's been getting a lot of attention recently that people are very excited about myself included is Rust on the server I think this is one of the biggest opportunities we have for getting Rust into production I think there's a lot of interest from really high-scale internet companies and using Rust you know in exactly the cases where Rust has a lot to offer but it's also a huge lift right what is Rust on the server even mean there's so many different sub-domains right so we're focused right now on building the foundations for this story you know 1.0 shipped with a very basic IO story that was blocking IO which is fine for a lot of things but when you want to scale up to a big server async IO is essential right and so we've been developing a story run futures which I think really gets at the fast reliable and productive trifecta right so there's a lot of excitement around it it's very new stuff there's going to be a lot of iteration but I think async IO is going to be a big theme this year but that's that's just the foundation right just having async IO doesn't mean it's easy to build a server right so on top of that you need protocols you need you know HTTP you need to talk thrift you need to talk to databases and so on and so forth right so we want to work on the next level up on this stack and there's the Tokyo project which is focused on that and then on top of that you want middleware and so on so there's there's potentially a whole ecosystem here to develop and I think it really deserves to be a major area of focus for Rust community this year sort of related to that and one of my favorite topics is parallelism and concurrency right I think Rust concurrency story is one of the most unique things about the language right the fact that you can freely use concurrency without being terrified of data races all over the place I think that's really cool and you know I think we've got some good examples but I don't think we're fully delivering on that promise today and the reason is you know we have the basics in the standard library you can sort of see the vision but we don't have that fully productive story across the board yet right so what I want to see is like Nico's rayon library which you you know didn't point out that he was showing his library earlier in the galactic slide but it was there and and I think it's really cool right this this fact that you can you know just change from it or to par and all of a sudden you're getting parallelism totally safely right I think there's huge potential there but we've really got to push on those libraries to get them to a 1.0 state where people feel confident using them in production they have good documentation they're starting to feel mature right so I think there's a lot of good work we can do maturing that part of the ecosystem this year as well for a lot of you who are using rest today serialization may be a sore spot in that you're probably using sturdy sturdy is really cool but sturdy traditionally has required a nightly compiler and that's all kinds of painful for the ecosystem so we've got some really exciting stuff in the works with macros 1.1 you may have heard about the TLDR is we want to get sturdy unstable as soon as possible and it's looking like you know within the next few months that should be on the horizon and I'm looking a little so so looking a little farther afield you know I think there are more specific domains where rust might have something really interesting to offer that we haven't as a community sort of really highlighted or put a lot of weight behind so numeric computation scientific computation machine learning these are all places where scale performance reliability really matter and if rust can couple that with a highly productive story I think we could do great things right so this is another place where there are some great libraries out there you know there's like NDA rate for example but they need more sustained attention to get to a really 1.0 place to build a foundation and I would love to hear from all of you again after the talk on you know what what other gaps in the library ecosystem are really holding you back okay so that that is sort of about getting libraries to actually exist but once they're out there how do you find them right so you know discoverability superficially seems like a fairly easy problem just use Google you know or do a search on create say or whatever but it's actually really subtle right if you are trying to use rust in production and you need a library you want to very quickly establish that you know this library is going to meet your needs that it's well maintained that it's high quality and so on and so forth that's compatible with the rest of the ecosystem there are a lot of attributes that you're looking for beyond just does this library exist and so then we start getting into things like you know curation and rating and so on but there's a tricky balance to try to achieve there right because we want to highlight the best libraries and draw people toward them but first of all what is best mean right we all have different ideas about what we're looking for in a library and we have to calibrate that in the right way so we incentivize the right things but I think even more concerning right rust ecosystem is very young there's a lot of innovation waiting to happen and we need to be careful not to sort of coalesce around a particular library when something better could be coming down the pike but now that we've like highlighted this one you know first mover advantage has locked it in right so somehow we got to navigate this balance and it's going to be a tricky thing I think one source of inspiration here is projects like ember observer and you know so ember is a JavaScript framework it has a big community around it and faces similar discoverability problems ember observer tries to curate the ecosystem in a pretty sophisticated way so there's sort of a mixture of like objective criteria like does this add-on have good documentation does it have tests so on and so forth and then there's some measure of actually human review and that all gets put into a score that then you know highlights add-ons in particular areas right so maybe something like this could work for rust and we won't be starting from square zero here there are already some good curated lists of libraries and rust that we can draw inspiration from as well but I think we're approaching the time where actually having some official curation and search tools discoverability tools is a pretty high priority I'd like to see them on crates I own personally okay so that's that's discoverability the last thing I mentioned about you know what you want out of libraries for productivity is quality and my perspective here is we want to focus on ways to improve quality across the board like what kinds of tools can we build that make it easy to produce high-quality libraries that sort of raise the tide for everyone so documentation is a really important example right if the library is not documented it might as well not exist for a lot of people and you know I was super pleased to see in you know in the last month a new site pop-up docs RS which totally automates the documentation system right so if you have published a library to crates I own and you go to Docs RS it's doctor up basically without you having to do any work you know and I think there's a lot of interesting potential there for actually integrating docs across libraries so that the ecosystem feels very coherent you can you know if APIs are being shared across libraries you can browse from one to the other and so on so I think that's a really important area to keep focusing on Docs RS has made huge strides already another related thing for quality obviously is testing and as with many of these things like Rust is already in a pretty good place but we can aim higher right so we have good CI tools we have Travis integration and so on but you do have to know how to set it up there's some work to get that going we could make that more push button right we've done that in a lot of places why not have cargo new automatically generate Travis integration for you something like that right and then similarly Rust comes out of the box with a unit testing framework and that's great but we could really open the door to more custom testing and benchmark frameworks and you know the sky's the limit in terms of what the community can do so I think that that's another really important area to focus on and then looking more at the code itself I think there are many important questions about rust the language as you're developing a library particularly if you're writing unsafe code you know what can you assume about safe code what do you have to guarantee it will future versions of rust break your unsafe code right these are some tricky questions so we've recently formed a strike team to start laying out some of these guidelines and actually starting to specify these core pieces of rust that's going to be a long haul this is really hard work but I think it's vital to the long-term quality of the ecosystem right and we should look for other kinds of things like this like restarting the API conventions system you know so we have good documentation on you know how you should be designing your APIs and so on these are all things we can do to increase library quality across the board cool okay so that was the library story let's look at one more team and a little bit of detail so the tools team right has encompasses quite a range of things I'm gonna focus on just a few here and I think tools are one of the places that have the greatest potential to improve productivity right it's like the obvious thing so rust up was a really exciting thing that came out this year from Brian Anderson Brian right so so probably you all know rust up is a way to get rust itself to upgrade to new versions but it's so much more than that right the vision is rust up is a way to acquire tool chains for things like cross compilation right and this is another place where we really want to push button experience so if you want to develop on a Linux box make an Android app we want there to be one line you write to rust up to say I want Android and it'll download everything necessary on your system you know NDK wise to actually get that done as well as the rust will change itself so we have some pieces of that today the NDK support is an ongoing thing hopefully we'll have some news there in the next couple months and then Brian again has also been hard at work on getting rust hooked into M script in and and wasm so that's compiling rust down to JavaScript to run on the web which is amazing so I think there's a lot of potential there and again rust up you know will be used to to acquire those tools another thing that's really important for productivity is not having endless bike sheds about code formatting and so we have the rust format tool thank you Nick for spearheading that effort but of course we have yet to actually reach consensus as a community as to what that format should be so Nick very bravely is heading up the bike shed of bike sheds so we have we now have a rust format strike team which I think had their inaugural meeting earlier this week and the plan is to actually lay out rust format conventions that set the defaults for the tool that the whole community can use and so we can just not think about this ever again okay and then last of these core tools is cargo which of course everybody loves cargo cargo's a great draw for rust but there's more we can do so you know one of the pain points in the ecosystem is to do with the way that sembers managed in the way that dependencies of a package may or may not be duplicated under under various circumstances I don't want to go super into detail but basically there are some pain points managing this process right now if you have a dependency that is not actually sort of exposed in your API so we have some ideas about making a distinction between dependencies that are basically private to you and ones that might matter to your clients and we think that this will you know help cargo scale up to a larger ecosystem another really important area of focus as we've started to talk to really large shops that want to use rust one of the holdups is they tend to have really large build systems with really large opinions and cargo has its own opinions and it's not clear how to integrate this so you know again we have some initial ideas about what this might look like if this is a problem for you talk to Alex or you who to and let's get to the bottom of it okay but of course IDEs are the big topic for tools especially given the survey results so we've made a lot of progress on IDEs in the last year probably a lot of you have seen or used racer so racer is not an IDE but it's sort of part of a package that could go into an IDE and it aims to provide things like auto complete and go to definition really really quickly and it does this in a pretty heuristic way so it's not actually using the compiler at all because the compiler is not quite there yet speed wise and racers come along you know quite a long way so they're already like some good tools in that direction along a very different axis we have the IntelliJ Rust plugin which is also rapidly maturing IntelliJ uses a whole different approach they have a very intense sort of framework for writing IDEs which is basically building a whole compiler themselves so they have started this process for Rust and things are coming along quickly but I think you know one of the things we're excited about in this space is to try a somewhat different avenue right so so far the plugins that are out there don't talk to the compiler at all and you know partly that's for performance but it's also a shame because you're missing out on some things that you could be getting if you were talking to the compiler like the ability to accurately refactor you know or get perfect answers to you know questions like go to definition or find all references and so on so Nick and Jonathan who are going to be demoing in just a second have been hard at work in this space and the vision is we have an IDE maybe it's VS code maybe it's Adam maybe it's something else it's talking to a central service called the Rust language service which is then in turn talking to some variety of sources of answers about your code so when you need a fast turnaround time maybe you talk to racer when you can take a little more time to get you know something more detailed you talk to the compiler and they've been making amazing progress on this tool and I'm gonna shut up and let them show it to you yeah okay cool so as Aaron was saying we had this idea a couple weeks ago what if we took like a best of both worlds approach we use racer we want something that's more interactive and then we can use the compiler the compiler's metadata directly when you want something that's a bit more deep like precise knowledge about your project so we wrapped it together into this prototype very early proof-of-concept prototype idea of this Rust LS so the the RLS allows us to do the same kind of things that you already are used to doing in racer so for example we can do the same auto completes that we did before gives us a list we can scroll around and pick a you know a method that we want to call and you saw as we were selecting that that we had type information sitting there that racer hit already kind of parsed and figured out but what can we do if we have like you know precise type information so if we have precise type information for example we can hover over things and see the types if there is Rust docs we can see the documentation and so this is starting to feel like oh this is starting to feel like a little bit more like an IDE you can see the squiggle here for example so we have errors you know we're using the compiler behind the scenes if we hover we can see the error we can see a little bit more about what's going on and of course since it's straight from the compiler it's exactly the same errors the compiler would give you so we can do you know types on hover we can do error messages the next thing that we need to be able to do is to do navigation through your code so we can do to like a go to symbol so just type the name of the symbol and then when we do we can jump straight to its definition so you've seen some tools already out there that can do this kind of thing but with the precise type of information we can just go straight to the definition we can find all the references for a given symbol for example and here you see you know like the full list of where that symbol is being used and again this isn't like searching through your code like rep this is the precise information and if we have the precise information we can kind of go that next step that you're used to IDs going we can actually use that to do a refactor so we can oh oh yes so this is inside a macro that we found a reference here so we can see right through macros we can see really complex types of the generics and so forth because we have the whole power of the compiler behind us thanks Nick I know it's gonna forget that one it's like remember macros remember macros all right so we can do final references and if we can do final references again we can do this refactoring to be able to rename that symbol and precisely rename it rather than doing search for a place because we know all the references we can do a safe rename refactor so we're really excited about what this can grow into again like I said this very early proof of concept lots and lots of duct tape but we want to tear that duct tape down and build it back up to being the real RLS we kind of showed it working in VS code but of course we built it in such a way that you can plug this into any IDE any editor and if you want to help us move it on to the your favorite IDE just come talk to us later we'd love to hear you thanks so the last thing I had to say is basically that we have also a lot of efforts from other teams for the docs team for example is embarking on a new book based on what we've learned about how people learn rust trying to take a different approach that should be more effective and improve on the one we have which is already quite good we're also working on looking at different ways to improve the ecosystem documentation as a kind of community wide effort and then we have a new community team which is focusing on assembling new learning materials and especially working on a rust bridge effort in collaboration with or as part of I guess the bridge foundry which is going to essentially learning rust as your first language from the ground up and of course the compiler team is hard at work on making things faster and less buggy and nicer overall and so that's about all I had to say if this comes up I do want to show you this picture but it's not so I won't it's too bad that's all right sorry we're done here thank you guys very much