 Hello, folks. Welcome back. I have a lot of thoughts about potential streams I'm gonna do, but I figured that while they're like brewing in my brain, it'd be useful to do another Q and A. It's been a while since the last one I did, back in August, I think. And like life has changed a lot, both in the world in general, but also my life in particular. A lot of developments have happened in the world of Rust. And I figured I would just sort of take some time to sync up with everyone and take some more questions. In the video description, for those of you who are watching live, there's a link where you can submit additional questions or vote for questions have already been asked. I highly recommend you look through some of them, a vote for the ones you think they're interesting, and I'm going to be answering the questions in sort of popularity order. So the way to ensure that we get interesting questions in the session is gonna be to vote for the ones you think are interesting. If you're watching this after the fact, you won't be able to have a say in what questions were asked, but if you look at the bottom of the video, there should be like chapters for each question, so you should be able to skip away pretty easily. So let's start with the very first one. What is your approach to learning a new code base and what advice would you give to people who are just starting to learn Rust? So this whole concept of like learning a code base has always been weird to me because I very rarely sit down and just like learn a code base, just like read all of the code to try to understand it, because I found that except for very simple like library crates where you can do this, like single purpose library crates like pin utils, for example, for anything larger than that, that's not a meaningful way to really interact with the code base. If you wanna contribute to something like cargo or RACI or CERTI or anything like that, that just won't scale. You can't read all the code and understand it in any meaningful amount of time. So instead, what I've found works a lot better is figure out a particular thing that you wanna know how works. That might be a type that you use often, a function you use often, a trait that you don't quite understand why it's there, or like some API design where you feel like some method is missing and you wanna figure out why it's missing or whether you could add it by submitting a pull request and then learn the things that are related to that. Like that gives you a much better way to understand the code base in a way that interests you and that's targeted and sort of limited in scope. And then usually what will happen is you start digging and then you branch out to all the other parts of the code base that you need to learn to figure out this thing and now you have more knowledge. And then you do that a couple of times and you start to construct this like web of knowledge that in the end, if you do this enough, starts covering the code base pretty well. That's sort of a more organic way to learn the code base. And I think this is also a good way to learn Rust. Like I obviously always read the book first. Like the book is really good. It's there for a reason. It's not waste of time, read all of it. But then after you've done that and you start writing some programs in Rust, even simple ones, start thinking about like, huh, I wonder how this function from the standard library works or this type from the standard library works. And like go look at it. The source code is pretty easily available. Like on any given documentation page, you can click the little source link and actually see how it's defined. It takes a little while to get used to having to navigate a Rust code base. So that's gonna be a skill that if you start doing this, you'll pick up pretty quickly. Like how do you find where different modules are brought in from? Usually the way this works is you click source and you find like the relevant code bit. And it refers to some types or some functions that are defined elsewhere. And then you sort of look at the use statements at the top and figure out where did that thing come from? And then usually what I do is I go to GitHub or whatever they used to host the repository, find the source code there because it's easier to navigate files there than through the Rust doc interface. And then you just start navigating through the module system and finding the code that you need. Or if you can open this in your editor and you have something like Rust analysis setup, you can use something like go to definition. And that's also a great way to just like jump through and figure out how things fit together. All right, next question. What's your experience at AWS? What are you working on? So my experience at AWS has been really interesting. And the biggest reason is because so far in my life I've mostly been a student, right? Like I have worked on big code bases but they've been research code bases. I have sort of worked with users of the software that I've built in the form of open source software. I even did like a decent amount of web programming in sort of a professional setting up through the years but this is the first time where I sort of join a tech company and work on tech. And that transition has been interesting. Like I think the biggest, not a ha moment but the biggest change for me was that suddenly things matter, which is maybe a weird statement but like I could make a mistake that costs Amazon like millions of dollars which is just not a thing that happens in academia, right? Or something that like suddenly like 100,000 users get a better experience because of something I do. It's just like the impact is so much larger than anything I'm used to. And that's really interesting to me. It's a fascinating, it's just a fascinating change. In terms of what I'm working on specifically, I work on the Rust developer experience internally at Amazon. So specifically I work on if you are developing Rust code at Amazon, what are the tools you use? How does sort of the internal tooling, the internal build systems integrate with the like real Rust tools of like Rust C and cargo? And sort of trying to essentially keep the delta between Rust at Amazon and Rust outside of Amazon as small as possible. Ideally, what I want to do is make it so that the upstream tools are good enough and integrate nicely enough that they just work internally. I want there to be almost no difference. Oh yeah, the stream died there for a second, I think my internet cut out, but hope, oh, that's annoying. Yeah, I'm aware that the stream is cutting out. I think my internet is acting up. Hopefully it stops doing that soon. I'll try to not answer anything until it comes back on. I think it's back now. I think it's both Twitch and YouTube. Hopefully they should both be back now. Is that right? Oh man, what's going on? Can you all see me again now? Sound has been mostly okay through it. So maybe it's video, that's interesting. It's good now, audio keeps working mostly. Interesting. Well, hopefully it's back now. Yeah, it seems to be streaming again now, weird. Audio's fine now, video choppy, maybe bitrate, voice is fine. Is the video back to normal now? Good now, okay, great. Let's hope it stays that way. I tried fiddling with all of my cables to make sure they're in properly. All right, so let's move on to the next question. I want to contribute to open source, but I'm afraid that I would end up getting flack for the quality of my code. Were you ever in the same position as me, regardless, what do you think would help? So this is an interesting question that I actually hear a decent amount of people being worried about contributing to open source because they don't think they're good enough, or they don't think they know the code base well enough, they don't think they know the language well enough. And I think this is sort of an unfortunate perception of open source. I think it's not realistic. Very often, the people who maintain open source projects, this varies from project to project and maintainer to maintainer, but in general, we're very happy to get people to come help. If all you're doing is like drive by and drop an issue, that might not help as much. But if you're like looking to contribute and willing to work on a PR, that's what matters. It doesn't matter whether your initial contribution is perfect. In fact, most of them are not, mostly because people maybe are new to the language, maybe they are new to the code base. And so they don't really know, they don't know everything that you would want to the PR to do. But that's the whole process of submitting a pull request is that you work through, you sort of submit your initial draft of the change and then you work through any problems that might be with it. It really is like an educational experience. It might be that if you submit to a very like, like I'm sure there are open source projects that are just gonna say your code as garbage go away, but those should be few and far between because a project like that would not be sustainable in the long run. I think most projects are just very happy to sort of guide people through making a good contribution and making a good first contribution. If you're worried and you want to find a way to sort of improve, the best way I can think of is just to start making contributions, right? Cause once you make your first contribution, the second one becomes a little bit easier and you'll get better at making contributions from making contributions. It sounds a little weird, but the moment you have gone through your first like round of a PR and getting it merged, you're already a better developer, you're already a better open source contributor. And I really think that's what would help you the most. And in terms of whether I was ever in that position, absolutely, like when I first started out, I had no idea whether I was doing anything good, right? I was just sort of, I had a problem, I wanted to fix it so I'd sent some code somewhere. And then over time, I managed to sort of convince them that this should be merged and they had a bunch of sort of proposed changes. And that's the process you go through. Like I still go through this. There are projects that I submit PRs for and then I get a bunch of reviews that say like, oh, can you change this thing? This is not quite what we wanted. Like this interface is good, but maybe this one should be different. Maybe you could use this API. My PRs are not perfect the first time around and no one expects them to be. That's just not how programming works. So don't feel bad that you just like, that your first contribution is small or that your first contribution gets a bunch of comments for how to improve them. Like that's how you learn. It's a good thing. Next question. How many hours do you spend coding each day? That is interesting. So this varies a lot from day to day. So I spend most of my like workday coding. This has changed a little bit now that I'm at AWS because I have more meetings. And these are, don't get me wrong. I've found that the meetings that I am part of are for good reason mostly, but I'd still say like 90% of my day is coding. Although when I say that, remember that coding is not all about writing code. A lot of that time is spent just sort of designing what the implementation is gonna be like, documenting it, testing it, setting up sort of infrastructure around it. So those things to me are still coding. They're not necessarily writing code, but they are closely related to that task. In terms of like hours I spend actually typing out code, maybe half of that, it's really hard to say. I do also spend some time sort of weekends and in the evenings, although that has changed a little bit recently for a couple of reasons. And I can't actually talk about all those reasons, but I'm excited that one day I will. But I would say like a workday's worth of coding, probably every day and on weekends, like however much I can get away with without my girlfriend getting annoyed with me. But I'd say like probably like a four or five hours each day on the weekend as well. Next question, what are your views on Go versus Rust in web development? So Go and Rust have very different approaches to how they like get at web development, at least in my mind. Like Go, it's a little weird to me to write websites in Go. I think Go makes a lot of sense for web APIs, whereas if you're doing like HTML and templating, like actually making the front end site, it's less clear to me that Go is a good fit there, but maybe I haven't really used it much in that regard. So it could be that there have been a lot of developments there since last time I used it. Rust also to me feels like for the very front end, it seems a little odd. Like I feel like there a more dynamic language might make the experience a little nicer. At the same time, if you have like a DSL, like a domain specific language for templating, these are all probably fine. I don't know that there's a good reason to choose between Go and Rust for web development really. Like I think they're both pretty good at it. I think it comes down to what programming model you prefer. Rust is much more focused on like making the APIs type safe, like making good or good is the wrong word. Making interfaces that are hard to misuse. Like Rust focuses on making things compile time errors, which Go does not really do. Go though, I think is, I think it has better or more mature libraries for networking, especially for sort of web interfaces than Rust does. And it's probably easier to sort of get like pick up and go with, pardon the pun. But I don't think they have sort of, I think it's mostly subjective differences, more so than like one is objectively better at one thing or the other. Next question, apart from Rust, what other areas of computer science are you excited about? And do you think would be promising areas to work in right now? Ooh, so also Rust isn't really an area of computer science. Well, it's changing a little, like Ralph Jung has written some cool papers on the academic sides of Rust. But I'm taken from this question, like what areas apart from like programming languages maybe? And to me, I think there are a couple of areas that I think are important. And then I think there are a couple of areas that are interesting and some are both. I think a big one for me is like ethics and machine learning. This is a topic that I think is extremely important for humanity going forward. Like machine learning is getting increasingly deployed. And we don't understand very much about why it makes the decisions that it does, how we ensure that those decisions are good decisions and how we sort of moderate, live with those decisions. Like I think that's a really hard problem and one that's important to work on. And it's to some extent a soft problem, like it has to do with like defining human morality and stuff, which is just difficult in its own right. It's like a philosophical problem, but pair with some very hard problems in computer science. Another area that I think is really interesting is the work on distributed systems. I think distributed systems is interesting to me because it's not really just about multiple computers, although to a large extent it is. To me, distributed systems is also about like if you have multiple cores, that's a distributed system. If you have a computer that has like multiple sockets with cores or multiple NUMA nodes, like that's also a distributed system. And you need to sort of program towards that. And I think what we're seeing increasingly is that, and this has been at the trend for a while, CPUs aren't really getting faster, but we're getting more of them. We're getting sort of people have access to more computers, often with smaller cores. They have access to more cores. They have access to more specialized cores, sort of heterogeneous computing where you might have one core that's really good at floating point or graphics is a good example. And another that's really good to just like crunching numbers and one that's really good at like machine learning and neural nets, how do you combine those in good ways? How do you ship data from one to the other? And I think that the algorithms and protocols that are in play there are only going to become more important over time. So I think that is a big one that has been relevant for a long time. And I think we'll continue to be relevant for a long time. And then I think the last one that really sort of occurs to me is I think the debugging of complex software systems is really important, especially in the form of like, how do you prevent the bugs or how do you detect the bugs that occur really infrequently? So this is sort of the formal verification approach is the most promising I've seen here of if you have a program that does something that is like of a safety concern, like the traditional example here is like, you're flying something in space, things can't go wrong or bad shit happens. But I think this extends to a lot of what we do with computers today. They're so ingrained in our society and do so many critical functions that making sure that they do the right thing and that we even know what the right thing is is really difficult. And the sort of traditional approaches of like, you run it and if it crashes, you debug it is not always tenable. Ideally what you want is you want to catch these problems ahead of time. And in some sense, Rust is moving in that direction, like Rust was a step in that direction by introducing the borrower checker and trying to have more things be compile time errors. I think there's a lot more we can do in that path. I don't know if fully formal methods like something like Calk or Daphne is the right approach, but maybe I think they're currently too hard to work with. But something where we can be more confident that our software is correct from the outset is going to be a meaningful step forward in computer science. And I think there's some really cool, there's some really cool progress being made there. Next question. What do you miss most about Norway? Ooh. So right now what I miss is seasons because I now live in LA and here there aren't really seasons. It's the same every day. And I miss it being winter or fall or spring. It's just here, it's just always the same. And that is something I miss. I miss some of the food like in Norway or in the US, I feel like people eat less healthy by default. I miss good bread, just not stuff that's airy loafs. Like I want a solid piece of bread. And so that's something I miss. This is just a bunch of stuff we eat in Norway that you can't really get here. We eat a lot of caviar, but not the expensive Russian type. Like this is caviar that comes in a metal tube and you squeeze it out onto bread. And it's delicious and cheap and everyone in Norway grows up with it. And it's like healthy as well, like it's fish. I miss that or like mackerel fillets and tomato sauce. It's a bunch of like that stuff that I miss. I do also miss my family at this point. Like because of the pandemic, I haven't seen them in quite some time. And that makes me sad. And sort of I have a lot of family and friends there that I haven't seen for a long time. And I want to go back and see those people again. I think I also, this is less about Norway specifically and more about a thing that I'm not a fan of with LA, which is that I miss being in a walkable city. Boston is pretty walkable, LA not so much. You sort of need to get a car for anything that's not in the immediate vicinity. Most of the European cities are very walkable and I miss that. Just being able to walk wherever you want, having a lot of interesting things and walking distance and good like public transport, I miss that too. All right, next question. Any advice on how to take notes? So this is actually a topic that I've had a lot of discussions with other people at MIT amongst other things. And one of the things I realized is that I don't really like taking notes. I prefer paying full attention to the thing that's going on. And then like trying to remember and write down notes after. Realistically what happens is I pay a lot of attention and I feel like I absorbed a lot of what's being spoken because I pay full attention to it. And then I don't really write the notes. And then there are a bunch of details that are lost on me later. So that's not great either. But I find that if I stop and take notes, I miss more of what is said. I know there's some research on like note taking, like just writing things down, helping you remember them. And I think that's totally true. It's more that for me, the act of taking my attention away from what's going on in front of me is detrimental to my learning. What I ended up doing for most of university was I forget what this note taking system is called. But it's basically, you take a sheet of paper, you have a narrow column on the left margin and then you have a broad column that's lined on the right hand side. And then you have a box at the bottom. And the idea is that you write relatively quick notes in the big box. These are notes about what's going on in the lecture, but you try to do them in somewhat short form. And then after the lecture, you summarize each segment, like each part of the big box in the narrow column on the left. And then you summarize the whole page in the box at the bottom. So the idea is that when you go back to review your notes, in the beginning, you can review like the full page. And then after a while, you start reviewing just the little column because that's a summary of what was there. And then you start reviewing just the things at the bottom. And then you sort of construct this hierarchy so that you can easily find and reference any content that you're after. Cornell notes, that's what it's called, the Cornell method. I've been pretty happy with that. But ultimately, to me at least, it's more important to pay attention to what's going on than taking the notes. I found that that serves me better. Can you share your job in AWS? How is it going now? Yeah, so I talked a little bit about this earlier, but my job is essentially looking at the developer experience using Rust internally at Amazon. So this is like, how does it integrate with the rest of the Amazon build system with other Amazon like internal packages? How does it interact with the upstream tools like DocsRS or like crates.io? And also looking at how can we make the difference smaller between what's used internally, like the experience internally and externally? For example, I wanted to be so that like Rust Analyzer and all of the like Rust integrations for editors, all of the tools like Clippy and Cargo outdated and all of that stuff just works. Ideally, I don't want you to know that you're coding internally. I want it to just work the same as Rust works everywhere. And a big reason for that is there's a huge value in being able to take advantage of the upstream ecosystem. And when I say take advantage, what I mean is to be able to leverage the resources that everyone is already producing like something like Stack Overflow. Ideally, if you have a problem internally, you should be able to look up that problem on the public Stack Overflow and find other people the same problem and find the solutions and have them apply to you. If you have too much like custom stuff internally, what you end up with is people have a lot of problems and those problems are due to internal weirdness. And that means that the problem has to be solved internally and you can't rely on the sort of grander ecosystem to help you out. And the flip side of that is I want to try to contribute back to upstream anything that is like stuff that's needed internally. So the example of this from recently is this PR I've been working on with cargo on trying to get support for HTTP-based registries for like Amazon has like an internal registry that we use for like internal packages and stuff. And I want that to use an HTTP protocol instead of the Git protocol because it's just much easier to proxy, much easier to manage. And so I've been working with upstream to try to land that upstream, which is something that is gonna help a lot of consumers of cargo elsewhere as well. So essentially trying to sort of find ways to synergize, if you will, the internal and external tooling. How's it going now? It's going really well. So I've been at Amazon for two and a half months now. I'm enjoying it a lot. I think there's some really fun, interesting challenges. I think the biggest observation I've made is that Rust is really up and coming. And I wish more companies were putting more people to work on Rust. I think we have the opportunity to be sort of ahead of the curve and we need lots of people to make sure that we actually do get ahead of the curve. And when I say we, I mean like the ecosystem, like it's not just Amazon, but I want lots of companies to invest a lot in Rust because I think now's the time. And we are seeing that already, but that's like my biggest observation. What are some intermediate project ideas in Rust? This is a hard question to answer in the general because I don't think that there are that many objectively good project ideas. I think a project idea is good if it will make you learn stuff and you are interested in it. If those two are not true, it's not a good project for you. It might still be a good intermediate project for someone else. And this is why generally whenever I'm asked a question like this, my answer is look for a problem that you're experiencing or an area that you want to learn more about and then find a project there. That's the way to go about it rather than look through like a list of projects. Like it's very hard to come up with something like that. And don't worry about building something that already exists. Like that's, it's fine if you build another instance of, I don't know, a MySQL library. Like it's gonna teach you a lot to just implement the MySQL protocol. It's gonna be super interesting. You're gonna learn a lot. And it might be that you build something that no one uses and that's fine. You have still learned something and become a better developer. But it might also be that whatever you build ends up being better than what exists in the ecosystem today. And that's great too. So like just find something that interests you and then just build it. Do you think WebAssembly will replace JavaScript? No. I think of WebAssembly as, as the name implies, assembly. A very low level but common language. So I think WebAssembly is gonna be the language that's sort of, it's gonna be a common compilation target. And we're seeing this already between the, and sort of an interaction format an interaction platform, if you will for cross language, like foreign function calls and stuff like that. I don't think it's gonna replace JavaScript. I think JavaScript is probably here to stay. I think realistically what's gonna happen is JavaScript JavaScript integrates very closely with WebAssembly but I don't think that you would ever want to like write WebAssembly yourself really. You'll probably continue to write it in a higher level language than then gets either transpiled or compiled to WebAssembly or something like it. How is life at AWS? I'm gonna skip that one because I feel like I've already answered it. Oh, actually, no, this is a little different. So life at AWS is, I'm gonna say different to what I feel like the external impression is of AWS. I feel like this is like a common impression that AWS like works you really hard. And that's not been my experience. In fact, quite to the opposite, I've found that there's a lot of, just like understanding for, at least in my team, I mean, I can't speak for all teams that like if you need time for things, that's fine. You work when you feel productive. And what matters is that you like do good work and think things through more so than like trying to just work every ounce out of you. So I found life there to be pretty good. It seems like the balance is pretty good and I enjoy the people I work with, the problems I work on and the communities internally. I've been very happy with it. What is your process for building knowledge? Ooh, so I don't know that I have a process for building knowledge in general, but I feel like for me, it's usually accidental as maybe the best way to get at this. Like I learned by like osmosis, like just by doing a lot of things and just learning from the absorption of doing it over time. I rarely sit down and like, I'm gonna learn this area now and then just read 12 books about it. Like that's not really the way I go about it. I'm much more project oriented or problem oriented maybe that I'm like, I wanna figure out how this thing works and then I work sort of outwards from there rather than go in, if that makes sense. What crate you wish was available but isn't? I think so far I've been pretty good about just if I feel like something should exist, I just build it. I can't, ooh. So there was a thing that I ran into with during my research, which was I really wanted there to be a good Memcash D library. There are a couple out there, but they are bad. Bad is the wrong word. They are underdeveloped and under maintained. I think there'd be a decent amount of value in someone just like implementing the text protocol, the binary protocol, designing a good interface for it. Like a high performance Memcash D library I think would be really nice. And I'm sure it's something that people in industry would probably want to. In my software engineering undergrad, we spend a lot of time doing formal analysis, UML diagrams, use case diagrams, scenarios, activity diagrams, et cetera. How practical are these things in big projects? So this is funny. I remember doing this as well. I took a class called software foundations, I think, or software, maybe it was just called software engineering, which was all this like high level design work. And I'm not gonna say that it doesn't matter because I know that there are, people who are sort of software architects do do a decent amount of this and this can be useful. But my experience is that being very principled about these things usually doesn't help me. I find that it's mostly overhead. Instead, what I found to be useful is make sure you write documentation. And when you're writing good documentation, that might mean including diagrams. And maybe then it's useful to know about different types of diagrams. But it's sort of backwards to me to start from the diagrams. That said, it's true that when I'm designing a system or some collection of services, I will often on a whiteboard draw out, okay, here are the different pieces, here are the talk to each other. But the formalization around it, I have not really found useful. I'm sure there are people who do it, but to me, the formal structure around it never made that much sense. Now, I don't think it's quite true that you should just do the code. Like I don't think that's true either. I think there's a huge amount of value in planning your software. And especially to do things like API design and modular design, like figuring out where should the sort of service boundaries be between different parts of what I'm building. That I think is hugely valuable. It's more that the, I think you can do that without necessarily knowing what UML is, if that makes sense. Like I don't need the formalism, but I do think it's important to think about the structure of what you're building before you build it. How are you? Okay, so I have two answers to this. The first is this is a question that I think society is really weird about because to me, how are you is a question that actually warrants an answer. But it seems like in reality, it's an empty question very often in society. I feel like if someone asks how are you, chances are they're looking for a short answer. And I feel like that's sad. I feel like people should feel sort of be allowed to ask this question and give a longer answer. And I think we need a variant of this question that can be used for just the short form where you don't really care or where you're fine with just getting a fine answer. I am doing pretty well. The pandemic is fairly annoying, but it hasn't touched me very personally, which I'm grateful for. I'm happy with my work, which I'm also happy about. I'm still like... I still don't really love LA, but I'm fine with it. I feel like it's gonna be fine to be here for a couple of years. I'm very happy that I now have a cat that gives me a lot of happy moments, although she's still meows at like 7 a.m. in the morning because she wants to play and that gets a little old. I'm gonna start baking bread speaking of I want better bread in the U.S. I'm gonna start making my own, which is gonna be interesting, which seems like a trend that a lot of people are doing these days. Which is funny. I miss people. Back before, I did a lot of board game nights and I miss those. There's a social deduction game called Blood on the Clocktower that I've been very involved with and I used to run... It's a big group game, so it plays like 5 to 20... 5 to 15 to 20 players. And I would run that several times a week with groups of 10 people, more many of which I did not know. And I found that really fun and I can definitely feel myself missing that. And it's not quite the same to do it online, to have like big... It's like a social deduction deception game and that's just... It's different in person and I miss that feeling. Oh, the cat's name Chai. She was here, but she went downstairs probably to eat or because she was annoyed with my voice. But normally she sleeps in the window right over here. Makes me very happy. Any advice for newbie rustations applying for rust jobs or going through a rust interview? So I have many thoughts on technical interviews. I'm not gonna bore you with all of them right now, but I think what I would say is try to understand how the company you're interviewing with interviews before you go through the interview because companies have very different ways of doing interviews. Some have the very like sort of algorithmic questions like invert a binary tree or implement quicksort or stuff like that. I think those are bad questions to ask, but many companies still do. And if you know that you're gonna get asked questions like that, the preparation you need to do is different than if the company is more like, we're gonna give you a realistic task in our software and you have to implement the fix for it or implement a feature request, which is a different way to get at a technical interviewing. There are some companies that are more behavioral in their interviewing. So they're like, how would you approach solving a problem like this? And I think those are, like all of these are very different interview settings and you prepare for them differently. And it doesn't really matter whether you're a newbie or not. I think it's, this is just sort of interview etiquette and we're not even etiquette, but just being good at interviews requires that, and I'm not saying I am, requires that you know what the interview is gonna be like because the preparation for each is different. I think the biggest advice I would give is there's a qualifier here that there are always exceptions to these rules, but in general for a coding interview, your code doesn't have to be perfect. Like there's not necessarily a requirement that like if someone copy pasted it in, like imagine you're doing like a whiteboard interview or you have just an editor that doesn't have compiler errors or anything like that, there's not really an expectation that someone can copy paste your code into your compiler and it'll just compile. Like don't worry about the very low level stuff. What interviews are usually looking for is understanding how you think, right? They wanna understand, they wanna understand how do you solve problem? What's your approach to solving problem? How's your approach to writing code? How's your approach to planning code? Do you think through the decisions that you make you write code in a way that's someone maintainable? Like for example, during one of my interviews, there was a, I forget what the exact problem was, but as I was working through, I sort of pointed out that if I was building this as a piece of a larger software, I would factor out this method or make this argument generic because that way it would be mockable, for example. Like you don't necessarily need to do all those things but articulating your thought process as you go through is really helpful. I actually found that doing live programming streams helped me a lot for interviewing because they're almost the same where while you're interviewing, it really helps if you're articulating what you're thinking because that's what the interviewer is trying to understand. Will you or do you plan to also work on the Rust compiler? I haven't really done much compiler work and there isn't really a good reason for that except that I haven't had problems that required me to change the compiler. Usually the problems I've had have been either in the build system like the cargo registry stuff or in the standard library where I've made some contributions. The compiler itself has generally worked pretty well for me. The compiler is also a little bit of a different beast in the sense that it requires understanding more about the compilation model and I haven't taken the time to sit down and read the Rusty book, which I really should do, I just haven't. But I think the problem there has more been one of motivation. Like I haven't needed something strongly enough that I also feel is a change that I could implement to sit down and do it. Like for example, back in the days before non-Lexical lifetimes, I really wanted non-Lexical lifetimes. But I felt like I would, as someone who hadn't been doing compiler work, I was not the person to sit down and implement it or really help with the implementation. So it's like a weird intersection where you want, you need to have a very specific problem to be solved that you really care about, but it also needs to be contained enough that you feel like you could do it and it doesn't have to be done by like Niko or Felix or someone like that. So I very much want to make compiler, like I have this desire to be the kind of person who contributes to the compiler. I just haven't found a good, motivating use case for it for me yet. How do you learn and retain that knowledge? So I don't know that I retain knowledge very well. I think, because I'm not great at taking notes. I don't go back and revisit my notes very much. What I do do is write reminders for myself for like things that I have to do. Like if I have a thought at like midnight and I'm like, oh wait, I think I need a phantom data for the value type in EV map. Just like some random thought. I know that I'm gonna forget it. Like my memory is not that good. And so I'll like set an alarm on my phone for a time when I think I might be at my computer doing open source code stuff to revisit that thought. But there's sort of broader knowledge of like knowledge of how binary trees work or something like that. You know, I don't retain most of that stuff. I have a general idea of how it works, but if I need it, I will go back and look at it. This is one of the reasons why I think technical interviews are kind of stupid if they're algorithmic, because I think in a real work environment, no one expects you to remember how quicksort works in detail perfectly off the top of your head. That is never a valuable skill outside of a technical interview. Because realistically, if you had to implement it and that should rarely be the case, you would just go to Wikipedia and read it or like some other, like open a textbook. You just would not be required to do it from memory. And this is why I think knowledge in that very sort of specific technical knowledge interpretation, I don't think you need to retain a lot of it. I think what you retain is the experience or the skill at learning. I think that the biggest thing that I've gotten better at over the years is like search and walking documentation and maybe designing, like sort of planning out code. But notice that all of those are more experienced, they're almost more soft skills than they are hard knowledge, like memorization. I don't think there's that much you need to memorize because realistically, I spend a lot of my time just like looking things up in documentation, like Googling things or like sketching out designs on a whiteboard or discussing a design with my peers. Then I do like writing out the code for quicksort. So I don't think you should put a high value on like memorizing algorithms or data structures or that kind of hard knowledge. Let's see, what are your thoughts if you had a chance to look on the new Rust for Windows stuff? I think it's really cool that Microsoft is sort of diving this officially into Rust. I think it's a great sign, I'm very happy to see it. To me, this indicates that they sort of buy that Rust is potentially a viable replacement for C and C++. That's what this says to me. And it's really nice to see them being willing to sort of put some backing behind that. And I think it's great. I haven't looked at the API design or anything in that crate, but I think the act speaks a lot for both what Microsoft thinks of Rust and also Rust's maturity in the space. Async stood small or Tokyo. Okay, so let me give a little bit of a disclaimer here. So I've done a lot of work on Tokyo after the years. I'm still fairly involved in the Tokyo community. And there's a lot of, unfortunately, I don't know if drama is the right word, but there's a lot of friction in this particular space, like between Async stood and small in Tokyo. And this is something I think the community has noticed and experienced as well. And some of that is for good reason. Some of it is for historical reasons. Some of it is for like philosophical differences. And I think I want to focus on the philosophical differences here. And what I mean by philosophical is more the approaches to what a library should be doing or an Async runtime should be doing. Tokyo is very focused on being used in large production settings, where stuff like spinning up a runtime without the user's knowledge is not okay. Having multiple runtimes at the same time is not okay. It's seen a lot of battle testing up through the years. It's seen a lot of sort of very careful design work up through the years. It's I think the most mature of these three libraries and is the one I would recommend completely over the other two. Small is, and I think Stjepan pointed this out too, started out really as almost like an experiment. Like can we do things this way with sort of a very small core? And is that enough to build something meaningful? It was, I don't think it was ever intended to really be a production system, like to be a production runtime. It was more like a, what's the word? Not really a prototype, because it was intended to be usable, but as almost like a proof of concept of an approach. I think it was interesting as that, I think it showed some potentially promising paths forward. Some of those paths have been experimented within the past as well. I don't think I would recommend using small in anything these days, unless you're just like, you just have a little toy thing where you're interested in runtimes, you wanna try it out. I don't think there's a big selling point to using small. I also don't know if it's maintained anymore. I think Stjepan sort of stepped back from it. Async Stud is a little weird. It sort of came, it came up because the, because Tokyo was built sort of from the beginning for the like future 0.1 ecosystem. And Async Stud wanted to sort of say, we're gonna just go all in on the new Async await stuff and we're really gonna model an asynchronous version of the standard library using those primitives. And so in that sense, it was like an experiment in where do we go going forward? Experiment is the wrong word. It was like a, we're gonna build the runtime for what futures will be. I think these days, like Tokyo is the same. Like Tokyo moved to futures 1.0 and actually mirrors the standard library pretty closely too. And when it doesn't, it's for good reason. So these days, I don't think there's that big of a difference in terms of sort of coverage or the APIs. But Tokyo has seen a lot more battle testing that Async Stud has. It's also more actively maintained that Async Stud is. And so I don't really see a compelling reason to use Async Stud over Tokyo. What made you decide to leave academia? Ooh, so there are a couple of answers to this. I left academia primarily because I like building things that people use in an academia that is not as valued, at least not in computer science. There are exceptions to this, both in terms of like particular universities, particular professors, particular fields. But in general in academia, the focus is on the sort of insight. It's on coming up with new solutions or new problems or both and sort of having innovative ideas. And that's sort of where it stops. Like if you have a good idea, you build a prototype, you demonstrate that the idea works, that's sort of what there is to it. Like then you publish a paper and then you move on or you develop some new interesting idea to your project. But for me with Noria, for example, like if I decided that I wanted to spend a year writing documentation for it or six months or three months, that would sort of be considered a waste of time because it's not a production system. Like documentation is not valuable in an academic setting necessarily or it's not valued at least. I think it is valuable, but it's not really valued. Similarly to develop the code base to be like more easily maintainable or easier to run on other platforms or easier to run by other people, there's not really that much value placed on that. Like that is considered sort of wasted work because you're not spending time on doing research. I think that those incentives make some amount of sense for an academic community, but it didn't make sense for me. I'm too motivated by building stuff that other people will find useful and they'll make like other people's lives better in some sense and I didn't really get that from academia and that's part of the reason I wanted to move to industry. The other part was just I was curious, I've been in academia for a long time and I wanted to see what is this like working life like? What is it like to work on an industry rather than on research all the time? What is it like to not be a student? I'll also confess that the money was a part of it for me too. I've been a student for a very long time and at MIT as a PhD student, you are paid a stipend but you're living on student wage and I think just being at a job where you're paid, I mean, this particular position I'm paid pretty well but even just not being paid a student salary like something more than that was certainly a welcome change after so many years as a student. I have no regrets. I think I got a lot of value out of academia and I think now I'm getting a lot of value out of industry. You think Rust will replace low level languages in the next few years? That depends on the area a little bit. So I think Rust is starting to replace low level languages in some areas. I think in embedded systems, we're seeing this a decent amount, for example, which is really cool to see. There are some spaces where it'll be harder for Rust to get in. One example is the Linux kernel. We are seeing some progress in that regard which is also really neat. But in particular, any field where you have to integrate with an existing large codebase is not always straightforward. Rust's FFI story is pretty good, which helps a lot here. Like this is why Firefox could like start to replace certain components with components from servo. This is why the kernel work, for example, is not insurmountable. Like it's possible to start writing kernel modules in Rust is because it integrates so nicely with sort of the C ABI basically. But once you get to more complicated integrations, like you need to call this like huge C++ vendor library. They just have a bunch of C++ header files and a binary blob. Like Rust is not great for that at the moment. It maybe it could be. Like maybe we can get to a point where interacting with C++ is as nice as interacting with C with bind gen. But that's a longer path. Like if you wanna do like Intel DPDK or something, like that's a huge API surface with just like this big vendor library. And it's not trivial to do the work to make that integration with Rust nicely. I also think that there are some places where sort of really low level like assembly and C makes some sense. But I think over time what we're gonna see is people are gonna move to Rust for these. That's like my anticipation. And I think we're starting to see this already. But remember that there's a huge amount of momentum in things being built in C. And there's a lot of friction in moving to Rust. Like you need to have a new compiler tool chain. You need to change your build system. You need to change like your linking. You need to build all of the sort of interface boundary abstractions again in Rust. So there's a lot of sort of inertia that needs to be overcome. But I think we are starting to see that path. How is the virtual onboarding process for AWS? It was pretty good. Like AWS has this like big launch plan like virtual. Basically when you join, you're given like a long list of like, here are all the things you should do next. And this is like a mix of like talking to different people, like specific people, watching different like seminars and videos, going through various like tutorials and quizzes and like trainings with like proposed due dates and like they give you a whole like calendar like thing. And so I think that was pretty good. I think it's not the same when you don't meet the people. This is not an AWS thing. It's just like, I'm working with a bunch of people I've never met in person. And I get along with them well. I feel like we work well together but it is a little strange to like not have been into an office or met them face to face. And I think that would be valuable. I don't think, so I think there's an interesting distinction here between the onboarding and regular work. Like I don't think being around the other people in my day-to-day would have made much of a difference but I do think that for the purposes of onboarding there's a lot of value in physically being there. I think maybe the biggest experience from the onboarding process was there was so much. And I think this is probably the case for most large companies that you're entering into a large organization and there's just a lot of stuff for you to learn. There's a lot of like both terminology, like words that are only used internally at the company. There's a lot of just knowledge specific to the company like what's the build system? How does it work? What's the source control system? How does it work? What's the desktop setup? How do you authenticate the things? What are all the websites, like the internal websites? So there was a lot of just concepts, knowledge to try to absorb and make sense of while you're going through all of this training. And so it was overwhelming as maybe the wrong word but there was like a sea of things that you're just slowly chugging through. And the onboarding process is pretty good about walking you through it, but there's a lot. I feel like much of it maybe is not necessary to do immediately, but I think it was pretty good. Since you just finished your PhD and got a job, what do you think helps during the interview and getting a good job in the industry? So we talked a little bit about interviewing earlier and I think what helps for interviewing is figuring out what the interview is like so that you can prepare for that interview as opposed to preparing for interviews in general. As for getting a good job, that's a much harder question. My advice is still like find something you care about and work on that, look for jobs in that. Things you care about, you're going to do a better job at and if you do a better job at them, you're more likely to get a good job doing them. There's some limitations to this to like if it's too niche, you might not be able to find anything, but just in general, like if you develop a lot of domain expertise in a particular field and you get really good at that and known to be good at that and you care about it so you enjoy doing it and you do it well, that's the way that you sort of eventually find a job that lets you do that thing. But it's hard, like I don't really have a recipe for getting a good job, that's harder. How do you decide which of your open source projects to work on? This is tough, this is something that has actually been a big difference from when I was a student. So as a PhD student in particular, you have a lot of control over your own time. Like even when you're working, like you're just doing whatever you think is good for your PhD. Which meant that I did a lot of open source work during the work day because either because they were dependencies of what I was working on or because I just felt like this was important work to do. Now that I'm working in industry, during the work day, I'm at work. Like I work on the work code basis. I don't do open source work while I'm at work. And this is partially just for like legal reasons. Like I don't wanna get into a point where like, there's like an argument that I worked on this while on work time and therefore this is now belongs to my employer. Like I don't wanna get into that at all. So when I'm at work, I only do work. I don't do any open source stuff. And I have like a separate, so this is my like home desk and then across there, I have a desk with like my work laptop and stuff. And I do my work there and I do my open source stuff here and I don't mix the two. But that means that I now have less time to do open source stuff than I used to, right? So after the work day is done, I go have dinner. I like sit down with my girlfriend, like I pet my cat. And like I have other things going on in my life as well. And so the amount of time that actually I can devote to open source work has gone down. And that has meant that I've had to prioritize more or let things grow stale for longer and then do like this weekend, I'm gonna catch up on open source work. In general, I think what that's meant is that many of my projects have gone from actively maintained to passively maintained. Like I won't do work on them unless I have a particular idea that I want to implement. So this is what happened with the EV map to left, right change that I livestreamed a while back. Like then I will find the time to sit down and just do it or as a part of a livestream. But most of it is now just sort of monitoring GitHub notifications for if there are PRs to projects that I work on, I'll sort of nurture those PRs forward. If I get issues filed, I'll sort of work on those. But it's a more reactive than a proactive role. It makes me a little sad, but it's sort of the reality of the situation. I think one day what I would like to see is like, it would be great to just work on open source, like just be a freelance open source developer. Unfortunately, that's really hard to do. Just getting paid is hard. Like no one pays someone to just do open source. We are seeing a little bit of a cool development there with things like GitHub sponsors or a lot of developers setting up Patriots and stuff. Unfortunately, because I'm in the US on like a student visa that has just, I'm on like practical training. That's the reason I can actually do work at Amazon. I can't have a Patreon or a GitHub sponsors or anything. Like I'm not allowed to get paid outside of an employer on my current visa, which means I can't have those things. So one day when I like move from the US, I'll hopefully be able to like start those things and then see maybe one day I'll like make enough from just the open source contributions that I can do that full time and that would make me happy. In terms of the actual question, like how do you decide which project to work on? That's mostly demand driven at this point. It's like the projects that have users that want to contribute in particular or have issues and stuff, like I try to address those. So it's really driven by where are there users that sort of need me to work on the projects? And I still really love like helping people along with PRs. This gets back to the question a while back of how do you contribute to a new code base if you're sort of a newcomer to the language or to the project? And this is sort of my side of that coin is I love it when people come with a PR and I can help them roll that forward and sort of improve it and learn in the process. I'm confused about non-null and unique. When should I use them? So non-null, so there's non-null, there's unique and there's just a raw pointer in Rust. Raw pointers have basically no guarantees to them. Like they can be dangling, they can be null, they can be unaligned, they can point into like an allocated memory. Like there are basically no rules for raw pointers. Non-null has a couple of more requirements. In particular, non-null cannot be null. The biggest thing that this enables is that it's eligible for the option optimization. It has a fancier name, but I forget what it is right now which is if you have a, what's an example of this? Imagine you have an option VEC, that is actually the same size on the stack as just a vector because the case where the option is none is represented as a VEC where the pointer is null. So that, and this is because the vector internally has a pointer that the compiler knows is not null and therefore it's allowed to use that pointer being null as a representation of the option being none. It's a pretty cool optimization. There are a couple of other things like that. And so non-null enables that optimization for pointers that you know will not be null. And the other big thing about non-null is that non-null is covariant over T. Variance is probably something we're not gonna get into in this Q and A stream, but, and the Nomecon has a really good article on it, but basically if you have a raw pointer to a T, you can't use that pointer as a different type, sort of transparently without a cast. So for example, what's the best example of this? If you have a raw pointer to a static reference, a reference to a string whose lifetime is static. Whoa, my hair is crazy. If you have a raw pointer to a reference to a string where that reference is static, you can't pass that to a function that takes a raw pointer to a reference to a string that has a different lifetime. Even though the static lifetime sort of can be used as any other lifetime, that will not work through a raw pointer for reasons that the Nomecon goes into. Non-null on the other hand does let you do that. So if you have a non-null static reference to a string, you can pass it to a function that takes a non-null non-static reference to a string for reasons. This is a good property in some cases, but you can't just use it willy-nilly because sometimes that's wrong. Sometimes in particular around if you are allowed to, if you ever mutate the pointer through the non-null, the sense of being wrong. So I would say don't use non-null unless you know that you want the type to be covariant. And if you don't know what covariance is, probably just use a raw pointer or sit down and learn what variance is. Unique is a little different. So unique is also a raw pointer, but it comes with the additional requirement that no one else has a pointer to the thing that the unique is pointing to. This matters for a couple of reasons. The biggest one being that it enables some optimizations around aliasing. So basically with unique, the compiler knows that no one else has references to it. So it's allowed to do a bunch of tricks with the pointer that would not be safe if that pointer was aliased. So for example, Vec and Box use something like unique. Unique also interacts with the drop checker in different ways because it knows that it technically owns whatever the thing is pointed to because it's unique. And so it lets you avoid putting some phantom data in there. There's like a lot of unsafety involved in this question. I think the Nomecon has some details about this too. So I recommend you reading that too. Oh yeah, it's called the niche optimization. This like option Vec or option pointer where pointer is non-null. It's called the niche optimization. Oh, should I show you the cat? All right, let me show you the cat. Hey, Chai. Do you wanna come say hi? Yeah, do you wanna come say hi? Look at that, it's a microphone. See that? It's a microphone. Don't come say hi all the way up to the camera. She's normally very talkative, but if she gets curious if there's a lot of new stuff, then she just looks around. Yeah? Yeah? All right, I'll let you go down. Hi. She also is really good at opening doors, which is sometimes problematic. Let's see. Do you enjoy mathematics, any particular area you're interested in? Did you do any proof-based math in your past? And if so, do you think the logical reasoning you've learned helped you as a programmer? So I do really like mathematics. I certainly did when I was younger. I was the kind of person who like, when I was shown the rules for derivatives, for example, I was like, I need to figure out why these rules are right. And I would sit down and work through the proof and for the proof for why the derivative of AX squared is like A to X. I forget what the exact rule is. But I would like worked out the proof for that and then keep that next to like my bedside table. That was weird. I love like the proof for the Pythagorean theorem. I definitely enjoy proofs and I would do a lot of that. I also just really like maths in general. I think I thought it was interesting. I like the fact that it had like rules to it. And that probably ties into my enjoyment of programming too, is my guess. Well, I don't know whether sort of maths taught me logic which helped in programming or whether I just really liked logic and therefore I like both math and programming. Like I don't know in what direction the implication arrow goes there. I think you don't need, and this is an important point, I don't think you need to like or even be good at maths to be good at programming. I think they are different skills. I think there's a common sub part of it which is just like logic and reasoning that it's likely that if you like that you like both but it's not necessarily true. I in particular, I think there's a lot of bad mathematics education which makes people not understand that it's logical which seems sort of weird given that mathematics are logic. But I think what happens is people are often just taught maths as here are a bunch of rules. No one explains to you why they are the way they are or why these things fit together. Just like memorize and apply the rules and you will be fine. And it's a bad way to learn mathematics and it's certainly not a good way to get you enthusiastic about it or about the underlying logic. And so I think that's a big reason for the problems. Let's see. Oh, there was another, there was a question for from chat that I wanted to answer or was it? Oh, I missed it. Let's see. When you come back to Norway to hang out with your bro, bro, bro, I'll be back one day. We just gotta get through this pandemic stuff and I'll be back. What do you think about the U framework or Rust for creating user interfaces in general? I have not used it. I haven't done any of your programming in Rust at all. I think it's important that we get a good one because I think that is still a place where sort of C++ in particular has a big, not selling point, but just there's a big user base for whom like they use C++ to do like native graphics or native applications. And Rust doesn't really have a good answer to that, but I am happy to see that we're getting frameworks in that direction. Do you work with Niko and Felix in Amazon? What's that like, if so? So Niko and Felix are at a slightly different team than me. They work more on the external side of Rust than the internal side. So I mentioned that I work mostly on the, how does Rust work for developers internally at Amazon? Whereas the team that Niko and Felix are on are more like, what is Rust like for people outside of Amazon and how can we make that better? We do talk a lot though and I'm really happy to have them on board, but our focuses are slightly different. Niko also just joined, so I haven't interacted with him too much internally. I did actually meet him a couple of times in Boston because we both lived in Boston for a while, but I haven't interacted with him too much internally. Are you still working on Noria? I'm not. So I, and I think I've said this before, I sort of feel like I got my fill, right? Like doing a PhD, you end up spending a lot of both real time, but also just mental time on that particular project and problem. And having worked on Noria for almost six years, I feel like I needed a break from data flow and databases. I had a decent number of job offers that were in that sort of avenue and that's just not, like I needed a break from it. I don't know for how long, like maybe someday I'll sort of get back to it, but for the time being, I'm not working on Noria or anything like it. Are you excited about the GCC Rust compiler? I don't think it's that important actually. So keep in mind that there's like a difference between compiler frontends and backends. Like I'm really excited to see more Rust compiler backends, like CraneLift for example, as like a replacement for LVM as the backend. It is cool to have multiple Rust compiler frontends too, but I think that's arguably less important. Maybe for like the long-term health of the ecosystem, it's important, but I don't see the need right now. I think also one challenge we're gonna run into is that the language is changing fairly rapidly still. Like there's not even that good of a reference. There is a language reference, but it's changing pretty rapidly. I worry that this alternate frontend right now might be premature, but we'll see. I think it's, I don't think it's a bad thing. I'm just, I don't know that it biases that much at the moment. Thoughts on writing an OS in Rust and how to start. I think that's a great learning experience. There's a really good blog by Phil Opperman. See if I can, Philip Opperman, yeah, called Writing an OS in Rust. That's a really good just walk through, like it's a long series of blog posts that walks through basically all the building blocks you need and it's a fantastic read. I highly recommend you read it, especially if you decide you wanted to build this yourself. I can also recommend going to read MIT has a class called 6, 8, to 8 operating systems, which is a really good class on sort of the principles of operating systems. It also has all the labs are public and they are really good to work through. That isn't C though, but I think that paired with this is going to be a really good preparation for understanding how to do it. You can also look at something like Redox, which is a much more developed operating system at this point, to sort of learn some of the ideas from there. I think one thing that's really neat about using Rust in the operating system setting is that I think you might be able to use the type system to avoid, hello, meow, meow, meow, meow. Hi, hi. You might be able to avoid a bunch of just like traditionally tricky kernel problems or error prone use cases of kernel APIs just by enforcing them through the type system. I think that's really neat. Is there hope for packaging of Rust libraries in major Linux distributions? This seems to be a large blocker for adoption of Rust in many companies and projects. So this one's tough because mostly because Rust doesn't have a stable ABI. The biggest reason for that is that it's really hard to have an ABI when you have generics. Basically, generics sort of mean that you need to publish the source and you need to compile from source. And this in turn means that it's not clear that it makes a lot of sense to package Rust crates because you would just be packaging the source. It makes a lot of sense to package something like a C library because you can just compile it into either a statically compiled library, like a .a file or a bunch of dynamically linked libraries like .so files or DLLs on Windows. Like that makes sense as a packaging thing because then you can have other packages that depend on that because all they really depend on or the library is those library files. And Rust does not quite true, right? Like if you wanna compile some Rust package, you actually need the source of your dependencies. I think trying to retrofit that into the traditional like Linux packaging is probably not gonna get you anywhere good. Maybe one day if Rust finds a way to solve like the ABI problem, then maybe. But I don't know that we've seen a lot of traction on that. There's also, I think Swift recently landed a proposal for a stable ABI that supports generics, although at some cost. I don't know that we have a good answer for this, but I think actually packaging Rust libraries as packages and Linux distros is probably a decent way off. It's not really clear to me either what that buys you except like dynamic linking has some pretty, pretty advantageous effects when it comes to security upgrades and Linux distros and stuff. So that might be a big part of it, but Rust is not really amenable to that at the moment. Should I watch your stream on YouTube or Twitch? What is the difference and would you prefer? I think you should watch on Twitch because YouTube has a longer delay. The quality is usually a little worse. And that's really the only reason. I don't think it matters that much. Like this is one of the reasons why I've set up this like chat sync and stuff is so that it shouldn't matter. But I feel like the lower delay, especially for something like Q and A matters a decent amount because, or even for live coding, it means that if you have a question, I'm gonna see it basically as I'm doing it rather than 10 seconds later where I might have moved on to something else. So if you need me to give you a recommendation, I would say Twitch. If you had to suggest one non-fiction book to read, what would it be? I really like the code book by Simon Singh. It's a book that gives you an introduction to cryptography in a really interesting way. Yeah, I really liked that book. I read it many years ago, but I really enjoyed it. The pragmatic programmer, I also thought was really good. That's more sort of computer sciencey. I think those are the two, I would say, like one CS and one non-CS that I've enjoyed a lot. How does it feel having more money now working? It's nice. Not gonna lie. Like it's not like I suffered being a student. Like the MIT stipend is good enough that you don't like worry about money. Like you have enough that you can eat and like do stuff, but I now have like discretionary money. I have money that if I want something, I can maybe buy it. And as a student, that was not really the case. Like I sort of kept a wish list. Whereas now that I'm working, I can buy things even if I don't really need them. That's maybe the wrong way to phrase it, but I can buy things that I don't desperately need. And that's been a nice change of pace. But I think like it hasn't really changed my life that much. Like I live in a, like I don't have roommates anymore. That's nice. I have a few more things that I've wanted for a long time, but didn't really have the money to justify buying. But apart from that, that's the biggest change. It's just, it's more comfort really. And I like that. Like I think realistically the answer to this is students are underpaid. Like we should reward people for being students and paying them a marginal stipend is, we can do better. Like the pay difference between being a student and working as a software engineer is like six or seven X, which is way larger than it should be. Like that makes no sense. There's no, like no wonder people decide to not study more, right? Like the opportunity cost is too large. What do you think of using clean architecture and Rust for building backend applications? Is that more difficult in Rust than in other languages like Java, for example? I don't know what you mean by clean architecture, but I don't think it's harder to design the backends well in Rust. In fact, quite to the opposite. I think Rust is really good at letting you express constraints in the type system, which makes it a lot easier to build modular, modular backends or applications or libraries because you can more easily enforce contracts in the API. What do you think about Rust in embedded software and how mature do you think Rust is regarding its use in these systems? I think Rust is revolutionizing is probably the wrong word, but I think Rust is doing really well in the embedded space. It seems like people are really excited about it and that makes me happy. I haven't done a lot of embedded programming myself, but it seems to me like Rust is making really quick inroads into that system. I did a little bit of embedded programming back during my masters with, I forget what were these systems even called, tiny something, both of these were C and sub something. I forget what these are called. These are embedded programming frameworks and they were awful to work with. Not just because they were in C, but they had these really archaic sort of lot of C macros. It was just a pain and I think Rust can make that experience a lot nicer and that's exciting. But I think the people who are well versed in embedded systems are probably better at answering that question than I am. Your idea about Rust and the blockchain. I've seen this question come up a couple of times in chat. I don't really like blockchains. I think that especially most of the common implementations are a huge waste of compute and power and the environment. I don't think they buy us that much. I don't think they're that interesting. I think that there are some designs that are interesting like proof of stake systems, for example, it can be pretty cool, but I'm just like not really on that train. I think that the idea is interesting. I don't know that this is the right way to get there. In terms of Rust and blockchains, I don't think it makes a difference. Like I think the selling points for Rust are the same. Like I don't think blockchains are an interesting use case where Rust has particularly unique qualities. There's been some talk about like maybe you can use Rust as like the embedded language for smart contracts. I'm not convinced that buys you much either. Like you would have to enforce it as only safe code, but you have to enforce that all the way down or like mark certain unsafe regions from the standard library as being okay. I just think you're gonna end up with something calls an API that you thought was safe and then your whole smart contract things falls apart. I think you need formal verification if you're gonna do that. What other programming languages do you use beside Rust and what do you like about them? So I use a decent number of other programming languages, but I use them much less. The biggest one I use apart from us is probably just like Bash Script. I write a decent number of Bash Scripts and I still love Bash to this day. I think it's great. It's fantastic for just like if you have a task you do a lot that just involves running a certain number of commands in some order, like just automating them through a Bash Script and making sure that you handle all the errors and corner cases and like color output in your terminal and stuff. It's just great. Bash is not a great language, but it works really well. I'm also a huge fan of just like pipelining and sort of like command line pipelining of using sort of very domain specific languages like said and awk and to some extent, Perl. Like I've written some Perl scripts, but even just like Perl one liners for shell pipelines are hugely valuable. I think it's actually meaningful to learn that stuff. It can really reduce the friction for doing a lot of just like data wrangling. If you, so I did a lecture series a while back called The Missing Semester of Your CS Education at MIT with Anishin Jose, two of my lab mates over there. And that class has a lecture on data wrangling that I recommend you go watch. Other programming languages I use, I do do some amount of Python, although rarely anymore that was mostly in like the academic setting for things like generating plots for figures or doing like log processing and stuff. I think Perl or Python works decently well there. I still use Rails for some web programming for a couple of websites I maintain. But these days to be honest, most of it is Rust. I don't really want to work on other code bases. Even if I'm building just like simple command line applications or scripts, I often just write them up as a Rust program. Like I had to do some like wrangling of CSV files in JSON recently and I could have done it in Bash. I could have done it in Python, but instead I just wrote up like cargo new dash dash bin like add certi json and CSV and then just write out the code and then run it and it's super fast and the code is nice and in a language that I enjoy. Let's see. Perl is the devil's language. Do you have any plans for a crust of Rust regarding debugging? That's an interesting idea. One challenge I have with debugging is that or with crust of Rust in general is I think it's extremely hard to learn without a compelling example. And the biggest part for me of coming up with new crust of Rust is not finding a topic. Like I have a lot of topics that I want to cover. It's coming up with a good demonstrating example for that topic. So for lifetimes, for example, that was like the string searcher example that I think was instrumental in helping people learn why multiple lifetimes are important. I don't have something like that for debugging. I don't have an example that I could just like write out that is clearly interesting to debug. I think once I find one, then there's a lot I can talk about. This would be something like print line debugging, GDP debugging, RR debugging, which is fantastic. Maybe even delving into something like Valgrind and Cachegrind, like Perf maybe even. So there's a lot to talk about. I just don't have the example. And one of the challenges there is I think for the example to be compelling, you need a non-trivial application. I don't think it's that interesting to show debugging of an application that has an obvious flaw. And so I don't, yeah, I just, I haven't figured out what to focus on, what problem to solve. What's Rust at Amazon like? Do you like it? So Rust at Amazon is fairly similar to Rust outside Amazon. There are some oddities about integrating with the build system. And those are basically things that I want to fix. I want to make it so that you can't tell the difference. It's basically my job. But I think they've done a decent amount of work at trying to make sure that it's not, that it's mostly the same as outside of Amazon. Certainly the code itself is, right? Like the Rust code you write is the same as what you would write outside. What would you suggest for interviewing a software development job at Amazon? That also depends a little bit. So Amazon is weird because they have a single like interview pipeline for things like the screening interview and stuff. And then you have interviews with like the, the particular teams you're interviewing for and some people related to that. And that experience varies a lot with what team you're going to join. And so it's hard to give general advice there. I think my advice is to, to remember that what they're looking for is how you think. And so try to make sure that you articulate your thoughts while you're doing the interviews. Like I'm not saying like talk out of your ass, but if you go quiet and just sort of sit and think, that's fine. Like you're not expected to know the answer to everything. Like that would be insane. But rather just try to articulate what you're thinking because that way you are demonstrating the knowledge that you have. It's like show your work in maths, right? It's the same concept in an interview. Say I want to learn Rust to contribute to servo and it's worth committing one to two years to me. Can you give a plan of what I should learn in what order and how I should manage my time as a Node.js dev? So I don't think you should plan your next two years to contribute to servo. I think what you should do is first learn Rust. So read the book, read some of the good stuff that's written around it. Like I really like learning Rust with entirely too many linked lists. It's a great like blog post. Even like Phillip Opperman's writing an OS in Rust is a great way to just learn how the language is used in practice. And then go figure out a change you want to make to servo, right? Like try to download, build and run servos like step one and then maybe look at the issue tracker or just like try it out and find something that doesn't work and try to fix it. Maybe just improve the documentation or something like that. I don't think you should lay a plan for learning how to contribute to it as much as you should just like dive in and like make sure you learn the language first but then just dive in and go, I'm gonna build it, I'm gonna run it, I'm gonna find a problem that matters to me and then I'm gonna try to solve it. Will AWS allow remote work post COVID? So I can't really speak for AWS. Like I'm just a lowly engineer. So I can't really answer this question. I think it probably comes down to the team whether they're like remote work friendly or not. I don't know that there's like a company-wide policy but I don't know. The real answer here is ask the hiring manager you're talking to and they will tell you. It's gonna be like they know better than I do. I am lost between different fields of computer science, ML distributed systems, system programming and security. Any suggestions how to pick one and commit to it? You don't need to. Like over the course of my PhD, I sort of did a lot of systems programming, I did distributed systems, I did databases, I did security and that's okay. Like you don't have to pick one area. It depends a little bit on how far long you are in your academic career. Like generally over time, you sort of narrow down your focus towards the PhD. But very few projects are like clear cut in one category. Usually there's like at least a little bit of overlap with other fields or at least I found that those projects are the most interesting ones. I think my recommendation would be like try to take a class in each one and see which classes you're excited to go to and which ones are just like, oh, I have ML today. And just go where your interests lie and where your interests drive you. That's really the way to pick. It's just observe yourself. Like this is like the introspection part. Like just observe your own behavior when you learn about these things and follow the one that seems the most interesting at the time. Can you do a video reviewing subscriber code? I don't think I'm gonna do that. The biggest reason is because chances are I would get a decent amount of code that is fairly rough, like something that people just wrote up and then they want me to take a look. Maybe that's valuable. I worry that it would become maybe too specific to that particular project. Like it might not be interesting more broadly, especially if people write libraries on things that I don't know much about. Like if someone writes a machine learning library or something, like I'm not really an expert in machine learning. And so while I could look at the Rust code, I might not be able to say much about the rest of it. I think the closest approximation to this that is trying to get at the same kind of thing is the open source contribution streams that I've done a couple of where we find projects that have interesting contributions we can make to them. And then we work through like, how do we figure out what change to make? How do we make that change? How do we submit that change? I think that's maybe a better way to go about it. And probably a better use of both my time, the ecosystem's time and the viewer's time. How do you stay productive and focused throughout the day? I just really like what I do. I think is the real answer to this. Like, I told my girlfriend this a couple of days ago too, like over the weekend, I said, like I'm really excited for Monday because I have more work to do. And that, like that's a, I'm very privileged to be in that position, right? But this ties back to my recommendation that do stuff that you enjoy because you'll get better at that stuff. You hopefully you get hired to do that stuff and then you still enjoy your job. Like for me, being at work is not draining. It's exciting because I work on things that I care about and think are interesting and I feel like I learn from them. If that ever changed, I would look for a different job. And so I don't really have this problem of staying productive and focused. Like if anything, my problem is the reverse, which is I enjoy it so much that I don't do other things. Like I should probably take longer lunch breaks. I should probably actually leave work at a reasonable time instead of working a little bit longer cause what I'm doing is interesting. Like I should, I don't know, take 15 minutes to work out during work hours or something. Like I probably should do these things, but I don't cause I'm into what I'm doing. And that's, I mean, that is a good thing, but I sort of have the reverse problem. Now, I think if you're not in that position, I don't really have a good answer for you except find something you enjoy and do that instead. And that might mean switching jobs, which is not always easy. But yeah, I think the real answer is if you enjoy what you're doing then staying productive and focused is not a problem. Any plans for 2021? Well, I have some plans that I can't reveal yet. Which is fun, but hopefully soon. Apart from that, my biggest plan is I want to go to Norway again over the summer. So I work at a summer camp for kids there and have done for the past like 15 years. I didn't get to go last year because of the pandemic, but I really hope that I'm able to go back this summer. I, I don't know. Apart from that, I don't have any big plans. I'm excited to start baking bread. Like I think that's the thing that I'm gonna keep doing. Well, we'll start doing and continue doing, I hope. I want to do more streams. The biggest challenge there has really just been finding, as I mentioned, like good examples to work through. It's not really a lack of topics. I get so many people who are like, can you do a video about this or this or this? And all of them are good ideas. It's just that figuring out how to do a good video on it. Like how to actually produce educational content from it is hard. And that's really where my bottleneck is. And so, so that's a thing that I hope to do more work on. Bread live stream, that's funny. I do actually have, I'm making a sourdough starter from scratch. So I have that standing downstairs now. It's just like brewing. There are no, there are literally no companies using Rust in my country. Do you think it's still worth learning the language for me? Yes, the reason is two-fold. One is you can work remote. Like the world is increasingly becoming remote friendly. And so even though maybe no one in your country is using Rust, although it seems weird, but could totally be the case, then try to find a remote job that let you use Rust. The other reason is because I think learning Rust is, at least for me, interesting. And I think it makes you a better programmer. I think like getting the bar checker, like ingrained in your head, makes you better at programming in other languages, just to have that way of thinking in you. There's also an argument that like, maybe they don't use Rust now, but that might be changing. And so you'd be ahead of the curve. Like when companies are starting to get Rust developers, you might be one of the few in that country who know that language. So I think the arguments for learning it is still pretty strong. You got to weigh that against the arguments for learning other languages that might get you a job right now. And that might be tricky. But I would say in general, like all else being equal, learning Rust is still worthwhile, even if there are no employers in your country at the moment. Do you think Rust will replace Go as it is used in cloud infrastructure? I don't think the goal of Rust is to replace Go. And I don't think it should be. Go is really good at certain things. In particular, it's really good at making it easy to write networking code, like network server code. And it's really good at that. In Rust, that is a little more painful because like the async code is good, but Rust is much stricter about getting things to compile as a higher learning curve. And it's not quite as seamless. And the biggest reason for this is like Go has a runtime. It makes code asynchronous for you and it does garbage collection for you. So it's just an easier language to do things in. And that carries a lot of value. Like for companies, especially like it means that they can invest fewer developer resources in training people. It also means that the code bases tend to be maybe easier to read. There's an argument about whether they're easier to debug and whether they're more error prone, but that aside, like there is a somewhat compelling argument to be made that for some of the service code it's more important that the code is easy to maintain for as like there's a like new engineers come and go for example, then that it's more right, which is sort of what Rust would give you. I don't know. I think that Go and Rust have disjoint arguments for why they should be used in something like cloud infrastructure. Personally, I think everything should be Rust in that space. I think the upsides of Go are not worth the downsides, but I acknowledge also that the friction in getting there is pretty high. Like it is more painful to learn Rust. There are fewer developers who know Rust. It is probably harder to understand and maintain for the people who didn't write the code in the first time. It's not anywhere as bad as something like Perl which is like a write-only language, but it is a, it's more of an investment and especially if you have a lot of code written in this applies not just to Go, but to any language. If you have a lot of code already written and battle tested in that language, rewriting it is often just not an option. Maybe you can rewrite it piece by piece, but just a from scratch rewrite is very rarely worth it. Like you're gonna remake a lot of mistakes. You're gonna spend a lot of engineer time on basically no benefit, at least not for a long time. So I think this whole like rewrite it and Rust is probably misguided in many cases. I think realistically the way that you get Rust into these spaces is you replace smaller components one at a time where that's possible. Can you speak of the value of getting a PhD versus just learning it in the industry? I'm currently an undergrad student. So I think learning, so I think a PhD is very different from learning in industry. They're just not the same. A PhD is much more focused on learning to learn and learning to think. In industry, you're very problem driven, right? Like you have a business problem and you're developing a solution to that business problem. And you might learn some stuff in the process of doing that. You might learn some stuff on your spare time by taking classes or whatever. But if you're doing a PhD, you are 100% dedicating to learning lots about a thing and getting really good at it, getting becoming like an expert at it. You're developing your sort of research skills for that particular domain and getting really just like what's the right word submerged in that topic. And you just can't do that in industry. You don't have the time. There are too many pressures on you doing what's needed for the business compared to a PhD where literally your entire day is learn more about this thing. So I don't think they're comparable. I think the outcomes are different. That's not to say the one is better than the other. Like what industry teaches you is to get better at solving problems that matter. It's very pragmatic. Like you probably end up a better coder, for example, like a better software engineer from being an industry than an academia because in academia, software engineering doesn't really matter. Like it's a tool. It's a path to the end goal, but the end goal is unrelated to the code, at least in most fields of computer science. Like the techniques, the algorithms are what matter. Whereas in industry, like what matters is that you build services that like don't fail and scale well and like do right by your customers, right? Like those are the values you're targeting and these are just different. I think there's a lot of value in doing both. I think a PhD, I would only recommend if you really like learning and there's a particular topic you're willing to dive into for five, six years. I don't think you need a PhD. I think a PhD is something you should want. Or rather, sorry, that's poorly phrased. I think you should only do a PhD if you want to do a PhD. If you want to spend five years just like learning a lot about a thing. You should not do a PhD because you think you need a PhD or because you think you will be better at the end than if you didn't. I'm not convinced that you'll end up a better engineer if you take a PhD, not clear to me. If you want to be a professor, you probably need a PhD, but if your goal is to be a sort of a software engineer in the end, a PhD is not gonna improve you as an engineer any more sort of objectively than being an engineer for those five years. It's gonna make you better at solving certain types of problems. But you'll be worse at solving the more practical problems that you have experience with if you were an engineer for those six years. So they're just very different. I would say do a PhD if the thought of spending all of your time just learning for six years and not solving practical problems and sort of like that's really the, if that's what you want, then do that. Otherwise, go into industry. Do you have plans to eventually go back to academia? No, I think I'm done with academia. I'm pretty happy in industry. I think I'm probably gonna stay in industry. I might move into like a more open source role or an educator role, that'd be fun. But I don't think I specifically want to get back into academia, no, I'm like writing research papers and stuff, I don't think that's where my life is heading. I'll also note that there are like 100 questions left, like literally, so I'm not gonna get through all of them. So I highly recommend that you go through, I'll repost the link as well. I highly recommend that you go in and vote for the questions you want to see me answer just so I make sure that I do the ones that most people care about. The URL is here in chat. Is it worth to take notes in the terminal? Markdown, text or text files allow you to use tools like ripgrep, FD, et cetera. Compared to what? Like compared to taking notes on paper. I think taking notes on paper is extremely valuable just because it's usually, I find that my notes are richer when I do them on paper because it's easier to do things like draw a little diagram or draw arrows between things, which you can't really do if you have a, like if you're in an editor. That said, as you've observed, like if you have it in an editor, it's easier to cross-reference your notes. There are sort of in-betweens here, like you can take notes on, like a digital note taking app where you can draw on stuff, but it does like handwriting detection and stuff so you can search your notes. I haven't used any of those myself, but I've heard that I've heard good things that that sort of strikes a good balance. I personally use, where is it? It's downstairs. Remarkable, which is like an E-ink tablet that I take all my notes on. I did that for the last like probably three years. And it also lets you annotate PDFs and stuff. I've been very happy with that. It doesn't really let me search, although I think in theory I could make it, but I just haven't really needed to do searching over notes that much. As long as you organize the notes in a way where you can find back to things, I don't think you really need the pure text search format. In worst case, you can always like annotate PDFs with that to make that doable. Why are you using Vim instead of IDs like VS Coder, Clion or something else? I don't really like GUIs. I don't like using the mouse. I like using the keyboard for everything. And I don't think an ID buys me anything over Vim in that regard. Like, it's true that like stock Vim without any integrations probably would be two bare bones for me. Not necessarily like, but in general, I don't think it would. But if once you have like Rust Analyzer integrated there, you have like syntax highlighting, you have something like control P for quickly jumping between files, at that point an IDE doesn't give me anything. Like I have everything that I want in Vim directly without all the overhead of a GUI. Vim is also super easy, just like jump back out to a terminal. Like I can have it open in Tmux in one of the panes that I can switch really quickly between that and a terminal. And it's not like an embedded terminal. And generally the terminals in the IDs are just really bad because they're not real terminals. They're like an embedded terminal. And I find that developers of terminals are better at implementing terminals than ID developers are at building terminals. So I just haven't seen an upside. The biggest argument I hear for IDs is debugging. Debugging, like you can just click a line and then click run or to run your tests or whatever. And that's not really how I do debugging. Like I find that I watched a good talk recently on from someone who did a talk on RR on one of the big problems with traditional debuggers is that you don't normally know in advance exactly how you're gonna end up debugging. And so forward like GDP debugging or breakpoint debugging only works for a very small number of debugging cases. RR makes that nicer, but it's rare that RR works well in your ID. And even then like you can do the same thing in VIM. Like VIM has the same integrations and it's had them for years because GDP was developed basically with VIM and Emacs. So the integration with the ID is just like not really better. So yeah, I don't see the upside is really the answer. It is true that they usually give you a better like out of the box experience. But once you've customized VIM it does everything I want and more. Oh, it's C lion, not client. Ah, close enough. Someone wrote, the most valuable thing in IDEs are code analysis, semantic navigation and refactorings. All of those I get in VIM. With something like Rust Analyzer, I have code actions. I can use like Rust Analyzer's rename functions and it does like semantically aware renaming. I can do semantic navigation with things like go to definition. I get code analysis like Rust Analyzer integrates with a compiler. All basically like what VS code gives you is language server which integrates with Rust Analyzer. So anything you get in VS code, I also get in them. Also VIM emulation is terrible in all languages, in all IDs. It's just not good. Usually because they try to implement VIM as a set of known keyboard shortcuts which does not have VIM works. Like they don't actually implement the VIM data model of having like verbs and objects. And that means that once you start trying to do anything that's slightly non-standard, it just does not work. Let's see. Okay, so someone made the comment in chat and probably slightly ingest that I like editors that don't need a tutorial. I completely disagree on this point. And the reason is I spend most of my time in the editor. If there's one tool I'm willing to learn to like spend time to learn and that can make me more efficient, I'm completely willing to put in that time. And I really think that is the outcome that if you're willing to learn your editor really well, you become significantly more productive for at least some portion of what you do. And I think that's worthwhile. All right. Do you have a language for the too complex for bash but not serious enough for rust scenario? Do you just use rust? Yeah, I just use rust for that. Like I've written some fairly complex bash scripts and I've written some very simple rust scripts. So I don't think it's like bash and rust and there's like some space in between. I think it's really more like this. Like there are some things that I'm using bash for that I probably should use rust for. And there's some things I'm using rust for that I probably should use bash for. But anything that's in the overlap region, like it doesn't really matter. They're, they could go either way and they're fine. I think I would say though that for anything that is important, like for anything that matters, I would probably rather write it in rust than bash because I get type checking. It's too easy to make stupid mixed-case in bash. Actix web warp or rocket. I have a lot of qualms with Actix web. I would not recommend it. I don't know to what extent, like this is based slightly on historical information on my part about Actix. And I know that there's been a lot of changes to that since the sort of problems back in the day. But that certainly has a lingering concern for me. Like it's really hard to turn big code bases around. And I think that leveraging stuff like the improvements in Tokyo are really worthwhile and not sort of rolling your own the way Actix web to some extent does. Warp and rocket. I haven't really used warp much. I've sort of looked at it a little bit, but I think rocket is probably the nicer thing to use. It was basically developed as research into how you do this well. And I know Sergio, I've met him in person a couple of times too, and we've talked about this, like he cared really deeply about doing it the right way and making it really easy to use by leveraging every possible part of the language. And this is why rocket was nightly only for so long and didn't sort of compromise to work on stable was because Sergio was like, no, we should do this the right way, which requires the nightly features. So we're gonna keep being nightly only until those features land on stable. Warp is, I think, it is more like it's a cool model for how to do something like a web service. I don't know that it's better, but I get the sense that rocket is nicer to use. It might not be as composable, which is one of Warp's big advantages, but I'm not sure. What are your thoughts on the movement towards web 3.0 in that a large P2P-like, mostly blockchain-powered, distributed internet removing the middlemen like Google or Facebook? Okay, so I have many thoughts on this. I think my first instinct here is that the internet is already distributed. The problem we have is one of platforms being too large, not of the internet being built wrong. I'm not convinced that something like peer-to-peer is the way to go because I think you need to put money behind things. I think that the way you get good systems is someone has to be willing to pay for the engineers to make the systems good, reliable, and to keep things up and available. And people don't do that. Culturally, we're not willing to pay for things as individual users. Like most people are not. They expect things on the internet to be free, partially because that's what these corporations have taught us that we should expect by sort of paying with privacy, if you will. But I'm just not convinced that individual users are gonna be able to sustain something on a large enough scale, to replace something like Google or Facebook. That said, I think there are some really good thoughts in there on, and there was a good article I read like a year ago on protocols versus platforms. And I think the move towards something like Mastodon where you have a standardized protocol for disseminating the information and then you have these like sort of local hubs that people can sign up for, that might work because the hubs themselves can put money behind a given effort and then still cooperate with other services. Maybe that's a way to sort of straddle that gap. I'm not convinced. It's just really hard to get most users to move. I think it's really easy to get very privacy oriented, tech savvy users to move. The problem is that's not most users. And that's where you start running into problems once you start to want to like change the world. Yeah. I also, as I mentioned before, like I'm not convinced of the blockchain, at least in its current forms, biases that much. But I'm also not convinced that it's not a thing we should keep pushing on. I just think in its current instantiation, I don't think it buys as much. Any thoughts on the new president? I'm very happy that there's a new president. I think I have, okay, so I'm gonna, there are two halves to this answer. The first is I'm very relieved to have a proper president, like not one that's like a man child. I am very happy to have someone who seems like they are responsible and thoughtful and empathetic and takes the job seriously and is not gonna just like fucking throw away the rest of the world in the process or alienate large portions of the population. That I'm extremely grateful for. And then the sort of criticism side is, given that there's a lot, like I come from Norway, I come from a sort of much more progressive country than the US is. And I'm still baffled by some of the, to me, very sort of backwards right-wing policy positions that are prevalent in this country. And I wish we could see even more push towards at least some progressive policies in the US. I think the Biden administration is a good step in that direction, but I want to see more. But at the same time, I also recognize that this is still a huge step in the right direction. And I think that it would be a mistake to push. You don't want to push so far that you don't get anything. I think this was probably the right step this time around. And then I hope we can continue in this direction going forward. I'm very relieved that the Democrats won Georgia. For the Senate, I hope that this means that things will actually get done, but we'll see. What changes would Biden make to the Rust compiler? That's a good question. I don't know. Is curing practical and Rust? Initially, it seemed to me that there's some difficulty borrowing and moving parameters that is can borrow or move but not both. I haven't seen any credible proposals for curing in Rust. I don't think it's inherently impossible. But I think you need support on the language level. I don't think you can do this as a library. Maybe it's like a proc macro. It could be that you could have a proc macro that sort of invents the intermediate types and just like strips off the parameters one by one. So that you could call a function with any subset of the parameters. You might need something like function overloading for that to work. Like it's gonna be a little janky and you probably would need language level support to make it really nice. But I haven't seen a practical proposal for how to do it in Rust at the moment. I don't think it should cause any problems with the borrow checker really because the job for the borrow checker remains the same which is the moment you curry a function you have effectively used all of the parameters that you passed in and those remain used until the curried function, the continuation if you will. It's not a continuation but the curry continuation until you actually complete it. Like when you sort of force the thunk if you will. And so I think this would still integrate pretty nicely with the borrow checker. Will there be a missing semester lectures this year? We haven't planned any missing semester lectures for this year. Part of the reason for that is the pandemic. Part of it is because I'm no longer at MIT. Part of it is because we felt like we covered a lot of the topics we wanted to last year. Like we're pretty happy with the videos are online, lecture notes are online, the exercises are online. We still get PRs. So we still improve some of the content here and there. But we just didn't feel like it was necessary to do another one this year. Feel like much of the content would be the same. The biggest one that we've had people ask about is like cover IDs. And I've already covered my take on this and it's similar to that of many of the other lectures that it's not clear what we cover when it comes to IDs. They're all fairly different and we're not even convinced that they give you that much. But we've gotten a lot of pushback from audiences that like, oh, everyone that programs for real uses an ID which is false, but that's the biggest pushback we've gotten. But apart from that, we've been pretty happy with the content and probably wouldn't really change it. So what is your ideal question? So this is a bit of a fun personal story. So back when I was dating, one of the questions I, or it's not really a question, but one of the statements I used to make was, I would tell whoever I was sort of meeting, I'm gonna give you a virtual token. And this token allows you to ask any one question. And I promise that I will answer it entirely truthfully and not conceal anything about the answer. I do this in general for questions that I'm asked, but in general, like you always sort of tailor your answers or you sort of scope them down to only the thing, especially in a dating setting, only to the things that you think are relevant or that you're like prepared to reveal. But I would give this sort of virtual token and say, you can use it whenever for whatever question you want. Just make sure that you want to know the truthful answer to whatever you end up asking with this token. And the reason I did this was because I found it, it doesn't seem like a question, but it's a incentive or it's a way to ask them for a question that they care about. I do this sometimes with like new people I meet too, just like outside of a dating setting, like I don't really date anymore because I love my girlfriend. But it's been really interesting just to observe the one question that people choose to use. And I think that says a decent amount about them. It tells you what they really care about, what they're willing to hear the answer to and how long it takes them to ask that question is interesting. So that's a question that I really like asking which is disguised as not a question. In terms of what my ideal question is like, what's your favorite dinosaur is a great question. It says a lot about a person. And it's always ends up being a fun discussion unless you're interacting with someone who's really boring and then it's a really boring question but I found it to be pretty funny. Have you ever written malware? No, I've written, I remember back in the very early days of my programming, I wrote a virus. But the virus was just a Windows like batch script that would open and close your CD drive like three times and then shut down with the computer. And I gave it like an icon that looked like it was a game. It was not a virus. It didn't spread, didn't do anything. But to me, that was very exciting with my first virus but no, I've not written malware. Which is, I've read some malware. Like it's really interesting that it's a very different way to approach code and it's fascinating to read but I haven't built any note. Do you have any tips for reading Rust library docs? I often find it difficult to look at a function and understand what the intended use is. So this is partially a problem with the documentation you're reading. It suggests to me that you have documentation where like the traditional example of this, right, is if you have a function that just says like the function name is like frognify and then the discretion, the frognify and it takes a bar argument. And then the documentation just says frognify is a bar and that's really not documentation. That's just restating the function signature. So usually to me, the question here indicates that you're interacting with a code base where the documentation is bad. The documentation should be saying what is this function for? How do you use it and how does it interact with sort of the rest of the system? That said, for many functions, its use is sort of obvious once you know how the system works, which doesn't really help but that's often the reason why documentation is hard to write because as the developer, you know how the system works. So you're like, oh, this function obviously does this but as a consumer who just like doesn't really know the system works they're just trying to get their code to work like you don't know how it all fits together. You're just like typing function signatures until it does what you want it to. In those cases where the documentation is like lacking, I found that the function signature often gets you pretty far. Like go back to the type that the method is on and read its documentation, look at the type signature and try to figure out what that might mean. Like click in Rustdoc, right? You can just click the individual types of the arguments and the return value and look at the documentation for those. And hopefully that should give you a little bit of a picture of what is like the input and output domains of this function and hopefully that gets you closer. I often also like to just open the source of the function and see what it actually does. That does tend to help, although it requires you to like borrow through the code a little bit. I think usually it just helps to write some code. Like this is why it's so valuable to have complete examples in documentation. I don't think you should have an example for every method, like that doesn't really make sense to me, but I do think that it's valuable to have sort of top level module or crate documentation that has a complete usage example because that is usually where as a reader you understand how the pieces fit together. And that often helps more than just documentation on any given function. So someone asked what is my favorite dinosaur? And the answer is obviously the Leopoldon, which is a large carnivorous marine reptile that's sort of a mix between like a shark, a whale and a crocodile. And it's real cool. So that is obviously the right answer if anyone's wondering. And if you said T-Rex or Triceratops, you're kind of boring. Or rather you're uneducated about dinosaurs and I've only really seen them in Popsae. Have you looked at Wasm more since the podcast? No, I haven't really had a chance to look much at Wasm sadly. The biggest reason for this is because I don't have any use cases, the requirement to use Wasm. And I don't have any motivating examples for me to start diving into Wasm. Again, as I've said before, I'm very driven by my personal needs. Like that's how I learn is I have a desire to build something and I need this thing and therefore I go understand that thing. I don't have anything that I really want to build that requires Wasm and therefore I haven't really learned Wasm. What are your thoughts on Golang? I've talked about this a bit in the past, so I'm gonna skip this one. What do you do in your free time other than Rust and YouTube? So these days not that much, I pet my cat, watch a bunch of TV. I working on a bit of a secret project which I'll announce at some point. But pre-pandemic, I really liked Rock Climb. I've mostly done it indoors. So that's pretty fun. I also used to play at least in my squash but not so much anymore. What else do I do? Listen to a lot of podcasts. I have a lot of good podcast recommendations. Apart from that, I think that's, I also, I really like listening to audiobooks. I'm re-listening to The Wheel of Time which is a fantastic series if you haven't already read it. I highly recommend it. But yeah, I think other than that, I'm pretty boring. Yeah, my secret project is more cat petting. That's funny. So one of the questions that now got the most votes is what did your girlfriend use the question token on? That is between her and me. That's a secret. Often because, so to give a little bit more information about this, the, usually when you do this like question token thing, the question you get will often be surprisingly personal. Like if it isn't, that suggests that the person is not taking it seriously or just thinks it's dumb, in which case they're probably a boring person and you won't like them anyway. At least that's my experience. Like I want someone to take this seriously and it's like, I gotta figure out a really good question. So sometimes you get like very personal questions and that's sort of the point. Tugs on brain, that's funny. What do you think is the trajectory of the Rust language? Do you think your work shapes that trajectory in any way? So I think Rust is, Rust adoption is growing really quickly, which is really fun to see. I think adoption is growing very rapidly in industry. I think the challenge that Rust is gonna have is that because it's mainly been a language that sort of grown organically from people being interested in it more so than companies and that's changing now. That means that a lot of the tooling hasn't really been built for like enterprise use and a lot of libraries that you need in the enterprise setting do not really exist because it's really been a community language, a sort of side project hobby language and we're growing out of that really fast but there are still these sort of holes that need to be filled for it to be a viable candidate in the enterprise setting. Part of that is education. Part of it is getting companies to work on building libraries for things that they need and I'm thinking of stuff like very few people in the open source world use Oracle DB but in the enterprise world, a lot of people use Oracle DB and so there aren't really good client libraries in Rust for Oracle DB because no one in the open source community built it but in enterprise they're gonna need it, someone has to build it and so that I think is one place where the sort of Rust adoption curve, we need to make sure that those things are dealt with so that the curve can continue and another one is in the enterprise setting there are a lot more requirements on the language, like there's a lot more tooling you need to integrate for like build systems and test systems and just sort of conforming to internal policies like security stuff. This is like an example of this is the internal registry business where most companies can't just use crates.io for licensing reasons or for security issues or like for namespace collisions or whatever and so they need to run their own internal registries for like even just for private packages that they don't wanna publish to the world and while Rust does have internal registry support in cargo, that is still in the fairly early days and hasn't really been tested out in like a serious enterprise setting and I think those kind of features are gonna be both stress tested and more of them are gonna be requested over time and the owners is sort of on the enterprise consumers to contribute to upstream to make these better and that's part of the work that I've been doing but that's hard work and it increases the adoption cost for these companies and we need to make sure that they still feel like it's worth it. In terms of whether I think my work shapes that trajectory, I hope it does. Certainly part of the job I feel I have is to make Rust a viable candidate for internal use and part of that is improving the upstream so that it is which hopefully will also mean that it's more likely to be a viable alternative for other companies. Thoughts on C++ 20 and forward. Not really, I haven't looked at it carefully. I've heard that they made some cool changes but I don't know enough to really give an informed answer. What do you think is missing most from the Rust educational ecosystem? So I think that what's missing is contents for people who want to use Rust for real have read the Rust book and don't learn from live streams. Like I think it's really hard to teach people how to use a language for real to sort of go from, I know the basics of the language from the book to I can use it in a production setting. That gap is pretty large and this is where, like with my live coding videos, a big part of that has been trying to address the subset of people who learn by doing or learn by observing to sort of show them, we're gonna write real code and you get to sort of come along. So I think that's one way to cover this that works pretty well, but not everyone learns that way. There's also the, there's like a blog series that's Rust from zero to production that's still in development. I think that's another way to sort of bridge that gap. And I think we need more resources to address that but I think it's a really hard segment to deal with because it's a hard thing to teach how to become a productive programmer in a language. Like it's, I feel like the only real way to learn it is to just do it a bunch, but that's, you can't really tell people, the way you get better is you do it for five years. Like that's not tenable either and finding out what the resources are missing there and addressing all the different ways that people learn and making sure we have resources in each bucket, I think is good. This is where I think the, there's like a Rust educational working group. I forget exactly what the name is that Ryan Levick is working on that's basically trying to just figure out what are the needs here? How do people learn? How do people want to learn Rust and how can we address those? Oh, the faster than line blog is really cool too. If you haven't read this, they're fairly long articles but they are really good about going into a lot of just like interesting detail and asides. I like that a lot. Oh, upstream. So when I say upstream, upstream is, imagine you're building something in Rust. Your upstreams are all of the projects that you depend on that are not your own. So you have like, if this is your thing, you have consumers, which are people who use the thing you built and you have upstream, which is the things that make things that you depend on. So upstream, for example, you can say, imagine that you were using like a fork of cargo. Your upstream would be the cargo that's maintained by Rustlang. So it can both be used as like your dependencies, but it can also be used as your originators, if you will, if you're running on a fork. Do you have a little ritual routine you do before streams, code sessions and research sessions? Um, I try to make sure I always have tea on hand. I really like tea and I like drinking lots of different types of tea. If I don't have tea, I'm not as productive. I think that's the biggest one. I don't really have like a little thing that I have to do. I know some people have these. I have that for other things, but not really for programming or for streaming. Um, I do know that I, um, I get sort of into the, the zone pretty easily when it comes to coding, mostly because I think it's really interesting and I don't want to stop. So I try to make sure that I can stay there for a while, which usually involves like, like eat something, drink something, go to the bathroom just before you start so that you can stay in that zone for the longest amount of time before you're like, I need to go now cause I haven't eaten in six hours or whatever. That's the biggest thing I can think of. I've never been a coffee person. No, no, it's always been tea. I just don't like coffee. It tastes burnt and I don't want to add just like lots of sugar and milk. Like that doesn't seem worth it. Why I can just have delicious, delicious tea instead. I don't really put anything in my tea either. Like Earl gray all the way. Love that. Just black, but I'll also have like, I have a licorice root tea that's delicious. Like a chamomile and honey and vanilla tea. Peppermint tea, peach tea, Roybus tea. I have like an Oolong. Like just, I love tea. Can have tea all day. I probably have like six or seven cups a day, probably more. How was the move? Moving during a pandemic is weird. It's really weird because everything is closed both where you leave and where you arrive. Like I've lived in LA now since like September 5th or something. And I haven't really been anywhere. Like I've walked around a little bit around the neighborhood. I've like been to the shelter to adopt Chai and been to the vet and been to the grocery store. But apart from that, I haven't really been anywhere. And that's weird. Like I've been here for what, three, four months and I haven't really seen anything. There's like a museum right next door. There's like a botanical gardens, but it's all closed. I can't see them. And that's strange. And similarly, just like shipping all your stuff across the country is just like a weird experience. This happens every time I move far. Like you pack up all your boxes and then you travel across the country and then you arrive at a place that you've never been before and you have nothing and you sit on the floor because you have no furniture. It was weird. But I think now I'm really feeling like we're settling in. Like there's no big furniture we need. Like I have my office set up. We have like, it's just, it's more settled now, but it was an interesting affair. Do you have any ideas or tips for getting started with distributed systems? I would really like to get into this area. Yeah. Take 6A to 4. So 6A to 4 is MIT's Distributed Systems class. I TA'd it a couple of times. It's a really good class. All of the lecture notes, all the papers and all the labs are available online. The grading scripts for the labs are available online. Take the whole class. Like on your own time, just do it. Do all the labs. Make sure you like get all the points on all the labs. It's gonna teach you a lot. I'll be my biggest recommendation. Have you heard about ZIG and any thoughts on that? I have heard about ZIG. I haven't looked into it enough. Like, I think mostly because I don't have a reason not to do things in Rust. Like I haven't felt the same kind of curiosity about ZIG as I did about Rust, probably because I know Rust now. From what I can tell that the selling points of ZIG are mainly that it's like Rust but trying to go even further in using, like programming language innovations to make the experience better. And apparently solve some of the annoying things you still need to deal with in Rust, like around on safety, for example, I think there are more things that are considered safe in ZIG. But I haven't looked at it enough detail. It seems like an interesting language. I don't know that there is like the mental space in the world of tech at the moment for yet another adoption of a big language. Like I think Rust is that. I think it's gonna be hard to start a second transition so soon. Think about it like C has been around for a long time and there have been many languages coming that has been like, this is gonna replace C. And we don't even know if Rust is gonna be that yet but I think Rust is the closest we've gotten to something that might actually looking after the adoption trends. I don't think that ZIG is gonna replace Rust in that adoption curve. Have you seen anything yet in Amazon where you think, ah, I can make that better for sure? I think there's a lot of value in being new to see the low-hanging fruit to improve workflow. Yes. I can't really necessarily save what those things are. I think the biggest, the thing I can say is that most of the infrastructure for working with Rust at Amazon, as I suspected is that at most companies these days is really community maintained. And by community, I mean the internal community of developers at Amazon who are interested in Rust. They sort of built a bunch of infrastructure to just be able to write things in Rust but it wasn't really maintained or supported or officially designed. So it's sort of a little bit of like a makeshift thing that kind of sort of works but no one is really looking after it and it's non-idiomatic in a bunch of ways. And there were a bunch of things where like they couldn't quite integrate nicely with the build system or upstream didn't support a feature they needed and they didn't have the resources to go fix upstream. And so they just sort of found some hacks that work. And so there are a lot of very obvious things that I can do now that I'm like paid to sit down and fix this and I have the time and resources to do it. The biggest challenge actually is that I'm only one person and there are so many things that I think could make things much better both internally and externally. And I'm working through them as fast as I can but I'm only one person. So I think yes, there were lots of things that I think I can improve and change for the better. And I'm sort of working through the backlog of that. Rust having no garbage collection seems appealing. Can you go into Rust memory management? How do you find out when it's time to optimize memory allocations and how do you do such optimizations? So I mean, Rust memory management does sort of the same as C memory management or C++ memory management really, which is, it's RAII so resource acquisition is initialization which is a fancy way to say that if you create a thing if you own a thing, then you are responsible for that thing and also its destruction. So basically if you own a heat pointer then when that heat pointer goes out of scope it gets dropped and freeze the memory. So you don't really have like, it's much rare that you have things like memory leaks they're not impossible, like they're still safe but they're less common. The biggest difference in Rust there is that you have to, if you come from a garbage collect language you have to think more about where your memory is but that's more for the borrow checker really. It's not really about the memory management so much. In terms of optimizing memory I haven't really had to do that that much. Like in general the memory allocations are fast enough. You do need to think about a little bit about your allocation patterns if you're running really high performance code but in general the like memory allocations unlikely to be your bottleneck unless you're running really low level very high performance code. And if so you can use something like like Valgrind has some modes for measuring doing memory profiling. So I would use something like that or J Malik like just switching to J Malik might help enough or at least give you the introspection tools you need. Any good resources for system design in Rust? Do you find a difference from established enterprise languages? So I think API design in Rust and the way that you structure your applications is somewhat different. There's sort of a different expectation for how your modules are set up, how your APIs are designed. I don't know of any good resources that really talk about this. Like the zero to production series might be the closest I can think of for like how do you go about designing a larger system from scratch in Rust? I do recommend that you look at like Philip Opperman's writing in OS in Rust is pretty good about just how do you design the abstraction boundaries? But of course that's in the context of an operating system and not really in like a service oriented architecture. I don't know apart from that that there are any good like documentation on it. There's like some in the form of the Rust API guidelines which I highly recommend everyone read. But that's more at the level of if you're designing an API, here's a checklist of the things you should make sure you do. It doesn't really tell you like this is where your module boundaries should go or like this is how you should structure your design like the architecture of your system. I think high level architecture of like what should be the services that I think is fairly similar. So I think the biggest difference is like how do you go about structuring your modules internally? Mostly because like once you have generics that changes a lot if you come from a language without generics. Rust also doesn't really have the same introspection capabilities as Java. So you have to use slightly different patterns for being able to make things mockable for example. How might a junior software engineer get to a place where they can work with Rust at Amazon or AWS? Same procedure as getting to work with Rust at any company really like learn Rust and then look for a position at that company where they're looking for Rust expertise. It's the same as any other language. Like the role I'm in is a little special because it's not programming in Rust as much as it working on Rust. That is harder to get hired for just because there are fewer roles that do that. But what we're seeing increasingly in industry is that a lot of like service teams at the big companies are building things in Rust. And at that point it's like any other program language where if some service team is like building a thing in Java they're gonna put out like an open position that you can apply for that says like expertise in Java required and for Rust is the same thing like expertise in Rust required apply for those jobs. And I think the procedure there is the same as for any other language which is you gain some experience in the language you make sure that you sort of know what you're doing and then you apply for the positions. And if you're a junior engineer you apply for a junior engineer position where they don't require like five years of Rust experience, which would be hard anyway for most people but just sort of where they say something like experience with C or C++ is valuable, Rust experience is preferred. Like look for those kind of positions. Show the cats that we can say hello. She's sleeping. Oh, are you not sleeping? You wanna come say hi again? Is it cat break time? All right, let's get the cat. Do you wanna come say hi again? I'm sorry. Did I pull you away from a deep comfortable sleep? Hey, what are you seeing? What are you seeing over there? Anything interesting? Me. Do you wanna say something? I think they all wanna hear what you have to say. I think she just wants to go back to sleep or maybe just get scratches. Oh, where are you going? You gotta use your legs. She's just like, I put her on my lap and she just sort of like lumped over on the side and started sliding towards the floor, which seems not ideal. I was like, you gotta use your legs. Yeah, she's definitely half asleep. Her name is Chai. She's like one. So we adopt her from a shelter. So we don't know exactly how old she is, but the vet said around one. She is obviously very busy. It's true. She has a lot of stuff she needs to do. Like there's a lot of grooming that has to happen. Where are you? Now she's just sitting on the carpet over there just staring at my books. Maybe she's trying to figure out which one to read next. How hard was it for you to pass a fang interview? Any tips? So fang for those who don't know is like Facebook, Amazon, Apple, Netflix and Google. I still don't know why Netflix is in that group, but like it's like the big tech companies. So I still think that tech interviews are kind of stupid the way they're usually done. I don't know if I would say that it was hard, but it was just weird. Like I ended up doing like I had to implement quick sort. Just felt like a pointless exercise. I had to do like, one problem was like basically implement like designing like an elevator algorithm, which is kind of cool. I like those kind of conceptual problems better where you're still writing code, but you're really just being asked to think and that's what they're trying to evaluate. I would say that if you know that you're gonna have like a technical interview where they're gonna ask algorithm questions, there's a bunch of just like prep that you have to do and I had to do the same. And this ties back to the fact that I just don't think that you should memorize algorithms and data structures that much. You need to know that they exist, but how they work doesn't really matter because you can always just look it up if you need them. But in the technical interview setting, if you know that you're gonna get a quiz on how something works, you just got to sit down and learn them. And so that's what I did. Like I sat down and just like did a bunch of studying of algorithms and data structures, which just felt entirely like a waste of time. But I don't think it was that hard really. There were some like higher level, so some of the interviews are technical and some of them are more like behavioral where they're looking for like sort of leadership qualities as they call them or leadership principles. They're looking for sort of are you sort of, what can you provide in terms of skills outside of the merely technical? Like how do you work? How do you work with other people? How would you go about designing things? What experience do you have with designing things? Those kind of questions, which you can't really prep for, they give you some advice on like, there's like a whole handbook you get and I'm guessing this is the same for the other technical companies, like the kind of things that you should be thinking about ahead of the interview. Following that is like a bit of work. I don't think they're hard. I think what it really comes down to is whether you can sort of contribute things that the other people who apply for the role can't, which is hard to argue, hard to evaluate. I did have to do some whiteboard courting, although it was not on whiteboard, it was like in a shared editor, but a similar kind of thing. All right. Are you excited about the GCC Rust compiler? Already answered that question earlier. You think elite universities such as MIT and Harvard are worth it for CS degrees? This one's harder to answer. I'm inclined to say yes, just because like, sadly brand naming is a thing when it comes to where your degrees are from. Like, especially for people who are not themselves in academia or even in tech, like recruiters, they don't know the relative quality of different programs. They don't know that it probably doesn't matter that much where you got your CS education between, like if you went to, I don't even know which names to use, but like there's a certain amount of weight that comes with a name like MIT and Harvard, even though like the MIT and Harvard CS degrees are very different from one another, but externally people don't really see that and don't really know that. And it's just the case that like if you have one of those names on your diploma, like that counts for something even though it's unclear that it should. So in that sense, it does add some value. I think the bigger thing that the elite universities give you, elite is more appropriate, is you get to be around really top tier people. Like I think it's more about the community than about what you learn. Like the classes at MIT are pretty good. Like they're taught by good professors, but I don't know that they're like an order of magnitude better than the CS classes you would get at any sort of respectable university. I'm sure there are universities that are just bad CS educations. I'm positive that's the case. And the higher tier universities are unlikely to be in that category, although there are bad classes there too, but they're just less likely to be there. But I don't think that's where the value comes from. I think the value there comes from the community around you of both professors and other students that are really interested in what they're doing, really good at what they're doing. And you get to just like be around them and have random conversations with them and bounce ideas off of them. And that's where a lot of the value comes from. Can you make a beginner series for Rust explaining how various Rust features work? So I get this question decently often of can you do like a beginner friendly Rust stream? I don't want to do that. The biggest reason is because I don't think that's the best use of my time. I think that there are a lot of people who can do those videos and do them well and that many have already done so. And I think that it's more valuable for me to spend my time on the kind of videos that I'm not uniquely positioned to make but that I have experience making, I enjoy making and I'm able to make them. Like, I think that this set of people who can do a good video on, I don't know, types, bad example, how to write a function in Rust or how to work with standard in and standard out in Rust or how to write like tic-tac-toe in Rust or something like that. I think there's a lot more people who can make that video than someone who can make like a video explaining when you need multiple lifetime annotations in Rust, right? I'm one of the people who can do the latter. I can also do the former but I don't, I think it's more valuable for me to focus on those intermediate streams and then leave the beginner streams to other people. I'm not the only person who can make intermediate streams not by a long shot but I still think that's the best place for me to spend my time. And so that's why I don't really do beginner videos. The crust of Rust is probably the closest I get where I try to tackle single topics and cover them relatively completely so that even someone who's somewhat new to the language can follow them but I think that's about as beginner as I'm gonna get to. Can you explain the trait stuff around borrowing and dereferencing? For example, deref, borrow, ask or if et cetera. I talked about these a little bit in the smart pointer video for crust of Rust. That's the one I would check out. I think we're now getting into like the single digit votes on questions part and we're now, we've now been going for about three hours. So I'm gonna take, here's what I'm gonna do. I'm going to take about three minutes where I want all of you who are watching to go to the Q&A site. I'll post the link again. Look through the questions. Vote for the questions that you care about and then I'll do another five questions maybe. And then I think we'll call it a day. So this is gonna be like just make, let's make sure that the last five questions I do are actually ones that you care about. So go in and vote for some questions and then I'll go through them. I know there's like a list of a hundred there now. So there's a lot to just scroll through, but just like scroll to a random point or look at the ones that already have some votes and see which ones of those you care about the most. I know the interface is a little awkward. Someone asked in chat, what is Q&A? It's questions and answers as hopefully evident by what I've done so far. It's amazing to me just like how long these streams end up being. I always think like a Q&A that's just gonna take an hour. Like people don't have that many questions. And then look at us now like three hours later being like, there are a lot of questions. I love answering them. I'm not complaining at all, but it's just fascinating to me that there are this many things that people want to hear me rant about. So in chat, there's now a bunch of people being like, vote for my question, vote for my question. This one, this one. It's funny. Oh no, does it reorder the Q&A list while you have it open? That's really annoying. I guess do something like, I think you can sort by the number of votes the thing has already gotten. So maybe that's a worthwhile way to go about it. I really need to find a better way to do this like Q&A voting because it's so silly you click the link and then you get a thing that just says open Q&A is the only thing on the page. I don't know why it works this way, but it's the best one I found on relatively short notice. All right, another minute and then we'll get to it. Oh, someone asked about my chair. This chair is really comfortable, but it's also very expensive. Like, I think it was a worthwhile purchase, but a chair should not cost as much. This is the steel series, steel case series two chair. I think it's what it was called with the headrest. It's very comfortable. I'm very happy with it. All right, I think it's time to go to the next question. Feel free to keep voting. My list updates automatically too. Any plans for an FFI stream? I really want to do an FFI stream. It's pretty high on my list. Here too, the challenge is figuring out what example to use, what motivating example to use. I think what we'll want to do is to build like a probably a fairly simple rust interface to some C library and it can be something that already exists. I just don't have a good sense for which one because it sort of needs to be small enough that we can cover a reasonable amount of it in like the time of a cross of rust or maybe a live coding stream. So like between one and three hours maybe, but it also needs to be non-trivial enough that it's actually a project people care about and know because if they don't, the stream is gonna feel a little uninteresting maybe. And I don't want to just like make up a C library and then write bindings to it because it becomes too trivial. One thing that maybe we could do is something like curl. There already is a rust library to curl but we could do another one. Maybe that would be interesting. I don't quite know yet but I do really wanna do an FFI stream. If someone thinks of a good C library then like don't post it in a chat here because it's just gonna go away but maybe just like DM me on Twitter or mention me or something. Mention is probably better because then other people can see it with a suggestion. I very much want to do one. Thoughts on AKT's and Monads and Rust. All right, so higher kind of types and Monads. So I have occasionally needed higher kind of types and not had them but it's pretty rare. Things like being generic over collections. It's maybe a big one. There there's some really promising work on associated generic types. And I don't know if you've seen it but Niko Matsakis had a cool blog post on something he called trade families which is basically a way to get something kind of like or at least a subset of higher kind of types or a subset of what higher kind of types give you using associated generic types or generic associated types and traits in Rust that's really cool. I think full blown higher kind of types in Rust is probably not something we're gonna get for a little while. I don't know what unique thing it would enable that generic associated types would not also give us. I know that it's like, it's a big just like it's not just a matter of implementation. It's actually like some pretty serious design work on how would this even work? Like just the formal model of it. Monads and Rust I have less experience with like arguably like question mark is a monadic operator but I haven't really had a need for like monadic sort of formal monadics in Rust really. I don't have a good motivating use case for that. Do you suggest Rust for backend development like API development? Absolutely. At this point I suggest Rust for almost everything. I would say that if you're building an HTTP API there's still like a little bit of friction there. Rocket is getting really good. Warp also I've heard good things about but I haven't used myself. But it is definitely an ecosystem that's still evolving and developing. I think that in the next year or two as sort of enterprise consumers start being more involved. We're likely to see more libraries that do things like RPCs and HTTP endpoints and restful things like libraries and frameworks for doing those things. Tonic I've heard really good things about which is like a GRPC framework for Rust. So I think if you want to build a backend and sort of a sorry, if you want to build a backend in general Rust is probably a good pick. Assuming you like Rust. What are your thoughts on mock testing? Do you think mocking is idiomatic in Rust? Mocking is kind of hard in Rust because you don't have runtime introspection. You can't just like replace things behind the scenes in the same way you can in some other languages. So you need to do things like dependency injection or you need your types to be generic over more things than they otherwise would have so you can stick in like a generic implementation that you just used for mocking. In terms of whether mocking is idiomatic Rust, I think it could be. I think you can totally design interfaces that are generic in a way that make them easy to mock. But I don't think we've quite figured out the right mocking story for Rust because there's some that are based on like trait objects or some that are just based on generics and traits. There's some that are based on neither. They're just like sort of based on procedural macros, for example, and I don't quite know where we're gonna land. But I don't think the story is hopeless. I think we do have some promising avenues to explore but it's still early days there, I think. All right, second to last question. Do you think it's possible to shift from being a front end engineer in TypeScript to a systems programmer in Rust? Anything that comes to your mind that I should focus on if I want to jump the fence. If you come from TypeScript, you're already better equipped than many to come to Rust because TypeScript is already a stronger typed language as the name implies, then something like JavaScript or Python. That I think there are a couple of hurdles you're gonna have to go through. One of them is that moving from a interpreted language like TypeScript to a compiled language, TypeScript has sort of a compiler or transpiler but it's not the same. To move into a compiled language like Rust is quite different. What you're gonna experience is that you get a lot more errors upfront. Like it's harder to get your code to compile. The thing you need to keep in mind here is that what matters is the overall time you spend on making your software good. It's not, how long it takes for you to get your program to compile the first time is not the full story. So when you come from TypeScript to Rust, you might find that the time it takes to compile, get to your code to compile is longer. But the amount of time you spend on debugging at runtime is probably much less. And so the overall time is probably fairly similar. But I've found at least that I would much rather debug compiler errors than runtime errors. The second thing you're gonna experience coming from something like TypeScript to Rust is the move from a language with a runtime and with garbage collection to one that is not. That's gonna be where much of the sort of cognitive dissonance is coming to come from where you feel like this code should work, but it doesn't and I don't understand why. And it's because the mental model is different. This is where the bar checker ends up like biting a lot of people. It's because they don't have the right mental model. They haven't learned yet about Rust's notion of ownership of the fact that you need to think about memory allocation and deallocation and how long a given object lives and where it gets deallocated and stuff. That is a hurdle to jump. And my advice there would be that you sort of just gotta stick with it and after a little while it clicks and then it stops being a problem. I think the last question or the last part of it is like, is it possible? Absolutely, it will be a transition for you. Like it's not gonna be seamless. You're gonna have to learn a bunch of things. You're gonna have to change your mental model for programming a bit. Going from sort of front end to back end programming is also a little different. There are lower level concerns that you have to start thinking about but overall like it's still programming. It's just you have a different toolbox. I think that the more languages you already know the easier the transition will be. If TypeScript or JavaScript is the only language you know that the hurdle might be larger but I think it's very doable. You're just gonna have to sort of stick with it for a while and sort of start programming and don't give up but this is where it's important that the first project you start to do make sure it's one that you care about. That you're like, I really want to build this thing and I'm gonna do it at Rust because that way even when you experience setbacks where something is hard you're still motivated by you really want this thing you're building. You're really curious about it and therefore you decide to stick with it despite the sort of hardship. All right, last question. Let's see what it is. Is reading the Nomecon a good idea after reading the Rust book? Same question for the O'Reilly programming Rust book and some people say that it's much deeper than the book. So the Nomecon is intended more as a reference than something you read start to finish. At least that's been my experience. I think that if you read the Rust book and then go read the Nomecon you're gonna feel fairly overwhelmed and it's most of the stuff in there is not gonna be of immediate use to you. My recommendation would instead be after you read the book start writing Rust code and then only when you run into something especially when it comes to unsafe code that's when you go look at the Nomecon for things that are relevant to what you're doing. If you're particularly interested about like weird corner cases and stuff absolutely read the Nomecon as a fascinating read but I don't think it's a required read for most Rust programmers. The O'Reilly programming Rust book I haven't read myself. I get the feeling that it's like the same as the Rust book but maybe sort of goes into more detail on things could be. I don't know that you really need to read it after reading the Rust book. I think you read one or the other. I don't think you need to read both. I think the Rust book is enough to get you started to just like write real Rust code and I think that's gonna teach you much more than reading sort of a second introductory book. That'd be my take on it. I do think that there are other resources that are maybe more worthwhile to read than going to like the O'Reilly programming Rust book or any other like teaching you Rust like reading a second teach you Rust book. I don't think it gives you that much but reading something like Philip Opperman's blog or something like learning Rust with entirely too many linked lists or something like the Fasted on the Line blog like those are continuations to the book that they go into, now we're gonna write some actual code and get a feel for what this language is in practice and show you how this code is actually being written and how you need to think to write this code or like honestly watch something like a live coding video it doesn't have to be mine but just something that exposes you to people using Rust for real or when I say for real, I don't mean like in production or enterprise or anything I just mean like the writing real software or real code that's not just examples in Rust. That I think is the best continuation coming from the book. Yeah, that's my take. I think that's where we're gonna end it. There are more questions left than there were when we started. So I think if I kept going, I would keep going for another three hours which I'm not really prepared to do. What I'm gonna do before I sign off is I'm gonna do a quick shot round of just giving a very short answer to the next 10 questions. Oh yeah, Rustlings. Rustlings is another great thing. Rust by example is great if you just want more things to do. All right, quick shot round. 10 questions each of them with a very fast answer. Best way to get comfortable with Win, with Win. Use it as your main editor and disable the arrow keys. What do you think of Amazon's horrible build system Brazil? I don't think it's horrible but I do think it's old. Will Rust be the next C? I hope so. I think it may be but there's a lot of C code and we're not gonna replace it all overnight. Thoughts on real HKTs, not Gats and Monads and Rust? Not really. I think they're somewhat a theoretical exercise. I think you can get fine by without them. What do you think about using Rust as a purely functional language? I think you are artificially constraining yourself and it doesn't really buy you that much. How do you spell say meow in Norwegian? Meow? You know, I don't know. Oh, no, I do. M-J-A-U, evidently it's been too long since I was in Norway. M-J-A-U, meow, pronounce the same but spelled very differently. Do you exclusively write open source software at AWS or do you have to contribute to their internal code bases? I read a decent amount of internal code because I'm working on the internal tooling. And is that nine or 10? Do you have an opinion on AWS suspending parlor? Yes, but it's complicated. I think it's entirely a reasonable thing to do. And I am, I'm gonna end the answer there. Just one more, fine, fine. Okay, last one. Any advice for convincing enterprise people to use Rust? Yes, I have a short answer to this. Show them my considering Rust talk. I know the audio is terrible. It bothers me so much because I think it was a good talk. Alternatively, just like send them the slides, they're also available online. I think that's a good talk. That's my best way, that's the best way I know of to convince enterprise people to pick up Rust. All right, I got under 100, that makes me happy. So with that, I think I'm gonna end the stream. Three hours and 20 minutes. I think we did pretty well. Thank you all for coming out. I hope you find this interesting. I hope I'll do another across of Rust or unsafe chronicles or live coding stream in the not too distant future. Thank you for sticking with me and I'll see you next time. Bye, everyone.