01-Nikita-Baksalyar.txt

Welcome, and Learnable Programming with Rust - Nikita Baksalyar
[Music] 
> Hello! 
> Good morning, everyone. 
> Hello, good morning. 
> So how did you all like part one? I mean, I saw there was a lot of activity on the chat, so I'm guessing people stayed up for that, and, of course, APAC enjoyed that. 
> Some people tried the snake game. You managed to crash it after 2.5 hours! 
> I mean, that is a lot of dedication, though! 
> Some lasted 2.5 hours.
> I'm pretty proud, and it was Rust, so, hey, I crashed here. It's fixed again, so, please, crash it again! [Laughter]. 
> Not the snakes, just the game. 
> Just the game. 
> All right, so we have Stefan:  would you like to do a bit of an intro? We have some stuff to go through before we get started with the talks. Got to get the preparatory caffeine in first. 
> Ready! All right! Here we go. 
> That's just me! 
> What's up! So, welcome. So this will be fun, because there are three of us, so we will keep talking all over each other. Welcome to the second block of RustFest. Welcome to the UTC, or Europe, or euro-African time zones. What is RustFest all about? It started out as the community conference in Berlin, went to Kiev, to Zürich, to - I'm getting this wrong - Paris, then Rome, then Barcelona, and now we are in the Netherlands somewhat. 
> Kind of! 
> Or I am! 
> Jeske presenting! 
> Yes, so, it's about meeting people, connecting with people. That's why we have a huge amount of chat rooms. I don't know if you've seen that, but if you're watching us on RustFest Global, there is a house icon, and then on the right side, it opens a box, and the chat, and you can enter each - for each talk, there is a chat room that you can enter. Click on it, and then Ferrous, our trustee admin bot will invite you to the room, and you can ask questions there. There are also moderators. 
> Yes, there are moderators, and we also have - I mean, for this round, we have life scope of noting. If you go - *we have live sketch noting. You can follow Malwine doing live sketch notes which is super cool - not just presenting it at the end, but as far as I understand, you get to see stroke by stroke, and like the erasing and everything. I know I'm going to be watching that. I'm going to be watching that when I'm not presenting someone! 
> Yes. 
> You can see yourself being drawn! 
> Hmm. 
> That's pretty cool.
> So what - there are also buttons on the bottom. One is the snake game, the other is the sponsor, and there is a little "e" with a slash which has the live transcriptions, which I hope people that cannot hear me find on their own. 
> I think it will be announced on the chat anyway, and it's been shared, so, hopefully, the people that need it can find it. I actually really prefer using - you know, it's a global conference, not everyone is a native speaker, so I find it so cool that we have this, because not everyone can understand accents, or - you know? It's so helpful to have. Thank you, White Coat for joining us! 
> Thank you. All right. We talked about this, multiple communities. If you allow me this political side note, thanks to certain countries and their politics, Europe has benefited from that, since we have speakers from all continents from the very start, which is great for us. And now, it's live. All over the planet! So, RustFest isn't just for super high-tech people that work on the compiler, it's for everybody, actually. The next talk, which Jeske will present, is very beginner-friendly, in my opinion. You were going to say something afterwards? 
> From the three of us and the most senior level, so very suitable, I would say, it's a good start to the early morning here in Europe. 
> I mean, absolutely, and I think that's part of the reason why this is such a - like even the technology might be complex when you go deeper. The community is so wonderful. I didn't know anything about Rust when I first attended RustFest in Paris, and, like, oh, such a welcoming, amazing community, and it's so sad that we can't all be together to celebrate and hug, and just have an amazing time together, but we are all here, so, you know, definitely join the chat, tweet out stuff. And let us know how you're enjoying it. I don't know, take a selfie of you watching it at home in your PJs! 
> I think the screens are our Twitter handle, so if you have any questions to us, just tag us, mention us, and we will respond. 
> Or ask @RustFest and then the whole team can respond. 
> If you have something super cool to share with everyone, they might retweet it too.
> Yes, 21 talks, all confirmed. 24 speakers, 12 artists, three teams. I think we are in eight time zones right now, so, ... - 
> Thank you, day light saving time! 
> Yes. Vote for normal time if you get the chance too! So these all the artists. In our block, it's Earth to Abigail after, and Aesthr. 
> DJ Dibs. We are super lucky. This is so cool. I'm so excited about this, especially because it's global, we get to have artists from around the world, and that it's much easier for everyone to join. Not everyone has to drag around their whole kit. You've seen when artists attend conferences, that they have to bring everything with them, they get stopped at the airport because of the electronics, and everything. Now we just all get to share, and enjoy, so that is super cool. I'm really excited about this. I hope you all really enjoy it. This is appropriate. There are some/ing lights. 
> Artists have lights that might be triggering for photosensitive people. If you are not comfortable, if it is unsafe for you, it's better to opt out. We just want you all to be okay. You could also listen in, because there will be musical performances too.
> Like minimise the tab, or something. 
> Stay away from the blinky stuff! 
> Pilar already said it would be that we have a wonderful community, and part of that is because we have a code of conduct, and, lucky us, we have hardly ever had to enforce it, because people think about it, and they say, "Okay, I can agree with that." It's basically be very kind, and assume the best of people. Especially keep in mind that most people like us have English as their second, third, or fourth language, so - 
> For sure, be considerate. Because this is a global edition, you might be impacting people from a different culture, upbringing, different understanding of the world.
> Completely different sleep level! 
> [Laughter]. That's true! If you've been watching from the beginning, oh, boy! I'm going to be extra kind! [Laughter]. We urge you please to read the code of conduct. If there are any misunderstandings, if you need any help, please reach out to us. Us three will be probably a bit busy, but for sure, the team are out on the chat. Please reach out. We're there for you.
> We don't have any - like when you scroll down in the chat system, and you can see the administer or moderator. If you text Ferrous, you may not get an answer! 
> I think it would be good to read it out so we can have it in our transcription because these slides cannot be screen read, as far as I know. 
> Would you mind? 
> So our code of conduct: RustFest is dedicated to provide a harassment-free conference experience for everyone. Harassment includes, amongst other things, offensive comments related to gender, gender identity, and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, religion, technology choices, deliberate intimidation, stalking, and unwelcome sexual attention. Thank you all for listening to that. Hopefully, you've read it on the code of conduct, and you're familiarised with it. Yes, be kind to each other. Please be respectful. We are all here to have a good time. 
> Thank you. 
> I like that we have these so ingrained that we keep on going over things that we've already said! 
> Wonderful. So, we go ahead. The schedule is online. On a side note, if your browser detects the wrong time zone, you can change that on the top of the page. But, on certain browsers, this dropdown menu takes quite some time to generate, so if you click and nothing happens, just wait, let's say up to 15 seconds, and then you can select your time zone, and then it will recalculate all the times to your local time zone so you don't have to do the math in your head. 
> The chat that we've been talking about over and over Chen, rustch.at, which is funny if you're in the German area, but it's really fun. 
> It's matrix-based, and most people have been able to log on. Otherwise drop us an email or tweet.
> So this is the - I have to drink something! 
> Hydrate! So this is the APAC team who just signed off. We're so grateful to each and every one of them. You know, they've been pulling all of their weight, and more, for this edition, and they're hopefully taking it easy now. If not, you know, indulging in watching a little bit of the UTC timeline. Stefan, did you want to say something? 
> No, no. Same. Thank you very much! 
> Big applause to them this they did a lot of hard work. 
> So this is us. 
> This is us. 
> Maybe we can say also, because I think we already said, that we're all on the same time zone, for sure, but Pilar, I'm in Amsterdam, so whereabouts are you? 
> You can see I'm the stand-out name in the team, originally from Chile, but I'm based near Vienna. I live in - if you know Lord of the Rings, I live in the shire, in the middle of nowhere in Austria.
> You have a lot of dogs there? 
> They might make an appearance every now and again. The mail is coming. So I've banned them from the streaming room! But if they behave ... maybe they can pop on later and say hi. What about you, Stefan?
> I'm currently in Switzerland, in Zürich. It's quite nice here. We have fibre optic cable to the house, so -. 
> The luck of some of us.
> The luck of some of us. The internet is really fast and close here. 
> That is also the reason why you chose this place, right?
> Yes, yes! Well, not just ... 
> If you're going to be locked down somewhere ... 
> Better have 6.5 gigabits per second. 
> I think you also have to think a lot of the other members here, thank the other members here, Alexander, Jan-Erik, Flaki, and everybody else, they've all been real troupers here. 
> Jan-Erik has not slept yet! 
> Won't. You see him in varying levels of drowsiness. Naah, he's a superstar! 
> The European time zone, that is the three of us, so we are looking forward to it. [Alarm sounds]. 
> We should have finished-by-now-time. The upcoming is from Latin America. I think they're mostly on the east coast, right? 
> That time zone?
> I'm not that sure. I mean, let's leave it up to them, and they will introduce themselves! 
> Curious already! 
> So, huge thanks to our sponsors. Thank you very much. Thanks to Coil, Embark, Parity, Mux - Mux is also part of the streaming infrastructure that you're seeing in this one. Thanks to Mozilla, Centricular, OpenSuse, Mullvad VPN, OBB, the Rail Company - Redis, TerminusDB, Nervos, Truelayer, Technolution, Iomentum, and Ferrous Systems from Berlin which you might know from the embedded Rust conference, Oxidize. Thank you very much! Now, enjoy and have fun. 
> We've taken up enough time. It was lovely to get to set the stage for you all. You will see all three of us throughout.
> If you allow me, there may be T-shirts on the horizon! [Laughter]. 
> We're very jealous of his T-shirt. 
> I turned on my purple light. You all are way too ahead of me. Purple T-shirt ... the green screen. I just can't compete! We will leave it up to you.
> I think, indeed, as the process will follow, like every presenter will have a short intro, and then we will have a ... and then we will drive into the talk. The first talk is going to be Nikita Baksalyar from Scotland, push Rust developer tool kits forward. I'm especially into this, because as we already mentioned, I'm a beginner of Rust, so this is going to be a talk that is really good for that. So it is system engineering and decentralised systems. If we can start, I will speak to you afterwards. 
> Technical problems. You know it! 
> Nikita makes Rust interactive, so if learning it is your directive, you won't need to fight to see what is inside to become a bugging detective. 
> Hi, I'm Nikita, and today I'm going to share with you a different approach to writing documentation and educating people about programming in Rust. Let's start by dephenotyping the problem. What exactly is learnable programming? It is defined by Brett Victor in essay of the same name, as a set of design principles that helps programmers to understand and see how their programs execute. And some of the defining characteristics are of this idea are seeing the state of a running program, and giving the programmer tools to easily play with their code. And these things have become available and important when they apply to the problems of education and writing documentation because they can help to lower the entry barriers for people who are new to programming, and, today, I'm going to show you how we can apply these ideas to Rust and systems programming in particular. So, let's see how it it looks in action. Let's imagine you're someone new to asynchronous programming in Rust and you want to learn more about it. So you go to the Tokio's website, and you see they have really nice tutorials. Before you can start experimenting with asynchronous code, you need to follow a number of steps because they have prerequisites. You need to set up a new Rust project and then add dependencies through Cargo. Then you can take a look at the code provided in this example, and this code connects to our Redis-like server, and sends a key to "hello with value "world" and gets the request with the same key and verifies that it has the expected volume. Before you can run this example, you need to make sure that a mini Redis is running on your machine. Why don't we try including all the necessary dependencies right there on the same page, so that a user can immediately run this code and see the results? This is how it might look. I go to the same example and I click on the Run button. This is compiled, and, on the right side, I can see a key "hello" has been set to value "world". This gives the user an immediate context and response of what happens with their code and the state of the mini Redis server can be observed right there in the browser. But we can take this idea a little bit further and make this code example editable, so I can change the value of the key and run this code again, and I can see that the state has also changed. Or, I can add a new key while you pair "hey, RustFest" and you can see there is a new key now. This approaches requires a minimal set-up so I can start exploring the Tokio API straightaway and I believe this is something we should do to make Rust more accessible to more people. Of course, setting up a new project is also an important skill, but, the first impression to show that this whole thing is not really that complicated is also important, I think. And, well, it's not some kind of magic, because we already can make it happen. We are able to run the Rust code in the browser by using assembly, and the platform support is constantly expanded and improved in the compiler so we can make it work quite easily. When you click on the Run button, the code that you have in the editor is sent to the server where it is compiled by the Rust compiler, and the model is produced as a result. This model is then executed in your browser, and you can see the output. This approach can be expanded way beyond Tokio or any other single library, because we can use it to enhance documentation that is produced by Rust doc automatically. This can be used in interactive playground in which you can execute in your web browser. And, while it already kind of works like that with the standard library documentation because if you go, for example, to the page that documents ... we can click on the run button in any of the examples and you will be directed to the Rust playground where we can see the output. Of course, you can also play with this code when and what I think it, but what if we make it simpler by running examples in the browser on the same page, and showing the output besides the code? This will make it easier for people to just immediately see the output without switching the context. But there is a problem if we go beyond the standard libraries. So the problem is how do we deal with dependencies, and especially those dependencies which won't compile? The thing is we don't really have access to dependencies on the Rust playground either, because Rust Playground has a limited set available to us because it's an isolated environment and that's an expected thing because the Rust Playground suits the code on their server, and they want to make sure that the code is not malicious, and they limit things like inputs and outputs, and loading the external dependencies. On the other hand, this makes it harder for us, and practically impossible to run examples from codebases, or even from public crates, and it makes it harder for us to mentor and educate people through examples. WebAssembly does not have this problem. The sandboxed environment is not someone else's machine or server, but it's your own web browser, and this sandbox is secured by definition. But the main problem remains: not all Rust code  compiles down yet. Even if it don't, we can argue that this is a good thing, because if you want to add this kind of interactivity from your project, it will also incentivise you to make your code more portable, and make it compilable into a new target. When you write tests for code that, for example, sends network requests, usually what you want to do is to - meaning your code won't really send real network requests, but instead it will pretend to do so. So, you can test the behaviour of your code in isolation from the external environment, and that exactly the same thing that we want to do with our interactive documentation too, because we want to give the user the option to run their code independent of the external environment. The main thing so look for here is the API performance, because we want to make sure that mock functions that we call have the exact same interface as your real code. And while you can do this manually by using feature flags, for example, or you can use one of the many Rust libraries for automatic mocking, but the main idea remains, that you want to provide the same interface, both in your real code and in the mocked version. And this idea of running the Playground code in the browser can go a lot further, because we have lots of techniques for visualising data. So, for example, on this slide, you can see some code from the documentation of an HTTP client library called Request. It sends a get request and outputs the response. This example demonstrates only the abstract idea of sending an HTTP request, but how do we know how it actually works? And what kind of request it actually sends? In this case, we can output the HTTP request, and it is really helpful to see what kind of request gets sent when you send this code because it can help you learn more about HTTP, and, more than that, it can also help to you debug problems, because with an interactive Playground like this, you can replace the code with your own code and observe the changes, and observe its behaviour. And the good news is that a lot of cross libraries already do something like that with tracing, and logging, but to use that, you also have to choose a logging library, and enable it to just get the log output. With WebAssembly enabled, Playground, we just need to provide our own login library that will redirect output from the logs to a user's browser. And the user's code can also be seen as data that we can visualise and inspect, and some of the components of the Rust compiler are already available as libraries and there are even some for creates that can be used for parsing the Rust code. Almost all of them can be built in the WebAssembly so we can parse the code and extract the information that we can use to show hints to our user, even before they execute their code. It can make our examples even more clear, because these hints can be shown as a user types code, and they can provide context information almost like in the case of IDs. On this slide, you can see the request documentation again and it encodes parameters as HTTP form data, and, as you look at this code in the editor, you can see what result this or that function returns with your chosen hints because this compiler provides us with information about the function names, and types that are used there, and all the kinds of expressions, and it is really straightforward work with code as data because all expressions are actually variants of one large - so you can use pattern matching to work with this enum as you normally would do with Rust. There is one more thing that we can do this year, and this is highlighting the code execution flow. It can be compared to how you work with the debugger which can go through a program step by step, and while it goes through the program in this fashion, it also can show the internal state of the program at this particular point in time, and we can do the same thing for our interactive Playgrounds, because, it can really help in understanding the cases like, for example, ... and on this side we can see an example from the Rust standard library documentation to instruct the enumerators in a functional style, and while it makes some sense, it's hard to see what kind of output we will get when, for example, we call the filter function on the third line. But we can give a user this to go through the example line-by-line, while also showing what each function will do. And we can also combine this technique with the others we have discussed so far, because this time, we can have access not only to the static context information that is provided by the compiler, but also to the dynamic state at the runtime. And we can display data like local variables, or function call results, and as a user steps through the code, it becomes really easy to see how the state changes with each function call. With asynchronous code, this approach can really make a difference in understanding how it works. If we treat each step with its own function call, we can do an interesting thing here. We can record each state at each step and move it forwards and backwards in time. Since we are talking mainly about things like short snippets of code, and examples instead of, like, large codebases, it's possible to give a user a kind of a slider to go back and forth to really see the execution flow, or they can just jump straight to a point in time that is interesting to them, just by clicking on the slider. And, again, this is not some sort of magic, because even if we don't have an immediate access to the WebAssembly execution engine in the browser, and we don't have a kind of fine-grained control over the execution, we can transform through the compilation step, and we can do that even without modifying and talking to the Rust compiler. This transformation technique is actually pretty well known, and even the Rust compiler itself uses it for asynchronous code. It works by basically breaking down each block into individual function that represents a single execution step. This is known as continuation, and it means that we can continue the execution of a function from the point that we left it at. And Rust has an unstable feature called Generators, and this is used for using the Async/Await syntax. While it works almost exactly as you see it on the slide, so we have an struct that holds the variable state and local variables, and each block is transformed into a separate function. So, when you want to execute this snippet, all you have to do is to call these functions one by one, and the state changes. So these functions can be called from the browser, and we are very flexible in choosing in what order we call them, and what kind of state we record. So far, we have discussed some implementation details for these ideas, but, overarchingly, how do we actually make it work? And how to make it accessible to everyone? And there are several problems to solve here, and not all of them are technical. So, first of all, the Rust compiler itself cannot be built into the WebAssembly model yet, so this requires us to have a compiler service that will build arbitrary Rust code into the WebAssembly for everyone. So we already have something like that on the Rust Playground, so it's not that big of a deal, and, well, so I tried implementing this idea in production for a systems programming course, and surprisingly, this infrastructure is not really hard to provide, and it's not expensive, because a single CPU optimised virtual machine can easily handle hundreds of thousands of compilation requests per day, but, still, we need to make sure that this infrastructure is easily available, and it should be possible to deploy it, to deploy this compilation server locally and privately. There is another problem that we have discussed briefly. If we start to include dependencies in our small code snippets, the compilation will take a large amount of time, and resources, and the resulting module will have a huge site easily taking up several megabytes, making it harder to scale. While the obvious solution here is to compile these dependencies as separate assembly models instead and link the dependencies when we need them, but, this problem is made worse by the fact that there is no dynamic linking standard for the WebAssembly. So you're basically left with the only choice of statically compiling the dependencies. But, technically, the linking is still possible, even though there is no standard way of doing it. It's possible to make two of the assembly models work together. Each model consists of functions that it exports, and that would be our Rust functions, and it also has functions that are declared as imported, and these imported functions are provided by the caller, and usually they're used for calling JavaScript functions from the Rust code, and this is what makes it possible for Rust programs to interact, for example, with DOM and browser functions. We can use this trick. When Rust module A calls some imported function, what we are going to do is to call an exported function from Rust module B, and this works, but it works, but there is another problem with it. Each model has its own separate memory, and this memory is not shared between the modules, and this means that if an imported Rust function tries to access its state when it is executed, it will fail because its memory reading does not contain the expected data. What we will need to do is to basically copy memory from module A to module B before we can call an imported function. The main disadvantage of this approach is of course that it is not standard, and can be currently, it requires manual implementation. Ideally, the Rust compiler should take care of this for us, but for now, to make it work in the general case, we will need to find a way to automatically link Rust dependencies which are compiled as WebAssembly modules. Now that we have covered all this, what is the conclusion? I think that it is well worth the effort to make our documentation interactive, because, it will help us to bring more people into Rust, and part of the reason why JavaScript is so popular is that it is so easy to use it and access it. You don't need any complicated set-up. All you have to do is open a console in your web browser, and you can start writing and experimenting with code. With WebAssembly, we have a really good chance of bringing this simplicity into the Rust world. But we still have a long way ahead of us, because the WebAssembly ecosystem has not matured yet. But still, we can try our best in making this as easy as possible to have add these sort of interactive elements to any project, because we have tools like Rust Doc which can generate documentation from the source code. What we need to do is to improve Rust Doc to automatically generate Playgrounds for our documentation, and we also need to have a tool kit to simplify building these interactive playgrounds. The good news is that we don't have to start from scratch. The most crucial part is, actually, the compiling of the code into WebAssembly, and the Rust compiler has got us covered there. We just need to build the tooling around it. I have started a project that contains the Docker image for the compiler service and some front-end components. You can find the repository at the address you see on the slide, so, if you're interested, you can join the development effort, and help to make this a reality. And that is all from me, and thanks for your attention, and I will be answering your questions in the chat room. Thank you! 
> Hello, everybody. Thanks for the interesting talk. I like the idea of the interactive documentation from mocking and visualisation with the help of WebAssembly. As Nikita already mentioned in his talk, he's online in the chat, so, if you have any questions, or you want to follow him, or you want to follow up on some issues like he is active in the chat right now, so, I do encourage you to ask any questions over there. Rest assured that the next talk is going to be in five minutes, so, at 1050CST, I would say, thank you all for listening in for the first talk, and I will see you in the next one. Thank you.