The Rust language: memory, ownership and lifetimes [linux.conf.au 2014]

oh great thanks very much hi so yeah my name is Nicholas Metis I work at Mozilla research and I want to talk to you guys today about the rust programming language which we're developing well I shouldn't say we're developing it because Mozilla research is kind of spearheading it but the truth is that without the community that we've got involved we wouldn't be able to do nearly as much so I'm really grateful to everyone don't know if there any volunteers here but to all the volunteers out there thank you very much and before I get going I want to say two other things first I have stickers if that appeals to you come talk to me afterwards second if you have any questions as I go please feel free to ask them while I'm talking and not wait till the end because a lot of the ideas I'm talking about kind of build on one another so if you get confused in the beginning it could be easier or the rest of the talk might make more sense if we clarify it first the first thing I want to answer is the question I get asked you know first when I say that I'm from Mozilla research and we're working on a programming language most people say kind of Mozilla what you know I thought you guys made Firefox why are you working on a programming language and the answer is that you know first of all yes Mozilla has a research arm and our goal is to kind of look at what we can do to make the web model more successful and make it apply to more things so things like as MJS Firefox OS that were mentioned in the introduction those came out of Mozilla research actually well to some extent or our collaboration with us and another thing that we're looking at is what can we do just to reaaargh attack the browser itself it's not just HTML and CSS and expanding the scope of those but the browser itself the basic design hasn't really changed a lot since netscape days and computers have changed a little bit you know we have multi-core now we've got a lot more capacity and web pages have changed a lot so we're hoping we can improve security and performance and get a more parallel bars or architecture and that's a project which we call servo but part of that question is well if we're going to rewrite the browser core what language should we do it in right now if you look at every major browser they're written in C++ and not just a little C++ but like millions and millions of lines of C++ I think Firefox is repository has 8 million lines or so and the reason for that is that C++ gives a lot of control and browsers are in some parts at least pretty low level you know programs similar to operating systems in some regards and they need that kind of control to get good performance to make sure that when you scroll it doesn't you know jank around and move in a you know in kind of an uncomfortable way and so forth and the problem is that although it gives us good performance C++ gives really no safety guarantees so when you have 8 million lines of code you can bet that somewhere in there you know is more than a couple seg faults and security vulnerabilities and so forth and so that's kind of a good reason why not to use C++ but maybe there's another language out there why do we have to make our own right the problem is that most languages that are out there fall along a line like this they kind of trade-off control and safety so for C++ you get a lot of control but not a lot of safety and then you have on the far extreme on the other side something like Haskell which gives you a whole lot of safety but very little actual control of what the machine is doing you have to know a lot of if the compiler will do a lot of fancy tricks and the runtime does a lot of fancy tricks to make it run fast but if you as the programmer want to get control it's a much more complicated process and in between I think most other languages kind of fall somewhere along this line so there's something like Java where you have a lot more control than Haskell but you still have this runtime in the background and so on the idea of rust is to say can we just step off this line altogether can we have the same control or similar as we get in C++ but with the same kind of safety guarantees that Haskell gives us so no seg faults no data races you know no overflow overflowing arrays and that kind of thing and so the purpose of this talk basically is for me to convince you that yes we can and show you how we're doing it and to begin not everybody knows C++ I guess presumably so I will just kind of give an idea what what I'm talking about make it more concrete when I say control and also safety right here's a little fragment of C++ and the first thing it does is it creates a hash map and one of the nice features of C++ is you can put this hash map kind of on the stack and we'll see what that means in more detail in a second but basically it means that when this function returns or this block exits we know deterministically the map is going to get freed right then alright and that's good for keeping memory usage down and so forth it's also it's just efficient and a lot of reasons and another thing C++ does is let us take pointers right into the middle of data structures so if I fetch an item from a map in C++ this lookup it doesn't copy the data out of the map it gives me a pointer right back in the middle and that means if my if the value that I'm putting in this map is big that's that's a better way to do it and I don't have to have layers of indirection and so on but I can make some really trivial mistakes so here I'm going to take that pointer right into the middle of the map and I'm going to return it to my caller and the problem is I just told you that the map is going to get freed as soon as my function returns so now I have a pointer into freed memory and I'm returning it to the caller and that's a recipe for disaster right so let me sort of I'm going to do this sort of stepping through the execution a couple times in the talk so let me do it here for the c++ to reiterate what I just said so what that program does the first thing it does is it creates a map and in fact the data is not all on the stack it's actually split between the stack and the heap but you wind up with the fields of the map on the stack and the data itself is on the heap because it needs to grow and resize and so forth and then we create a pointer right into the map and you see what I mean this is a single pointer and it goes directly into the heap there and then finally we return that pointer so what's happening now is that pointer got copied from the topmost stack frame into the caller and then we're going to free the the topmost stack frame and all of the data that it owns and when I do that now you see this pointer here is just pointing out into that greyed out hopefully that works yes okay that grayed out space and that's what we call a dangling pointer and that's a really bad thing because later that if you when later allocations occur that memory might get reused and now I have a pointer into some other memory which wasn't even originally you know which contains some other data that may not even have the same type as what I before and that's a recipe for crashes but also security vulnerabilities and so forth so now when it comes down to is that C++ has a lot of safety rules that you have to obey they're not all written down or at least not in a simple way and if you don't get them all right throughout your entire program every eight you know every line of those eight million lines you have a problem that can crop up anywhere so it's kind of like this house here from my view anyway each of those bricks is a piece of memory and if you just have one that's taken from the wrong place the whole thing can come crumbling down right so what do people normally do in most languages they will use a garbage collector to solve this problem and that is a great solution a lot of the time yeah but the problem is in some particular spaces a garbage collector isn't so good so what a garbage collector does is instead of freeing the memory manually it'll basically just periodically search through all the pointers you have and find all the memory that you don't have a pointer to and it will free it then right the problem is that this introduces overhead it introduces kind of unpredictable pauses and there are various ways to to address this by making interruptible garbage collectors and so on but nonetheless you have this runtime in the background and that makes it really hard to integrate with a lot of other languages so one example is just taking a library that requires a runtime or a garbage collector and using it with some some random C program is a little bit difficult but it's also hard to integrate with other virtual machines and especially with other garbage collectors like for example the one in JavaScript right so since we want to write a browser we have to worry about that kind of thing and this is just not really the best way to go about it so what we've done in rust is take a different approach essentially what we said is let's take that same C++ and all those safety rules that you were supposed to be enforcing but you weren't necessarily doing it and let's have the compiler enforce those safety rules for you and the compiler is going to be pretty rigorous about it you know so basically it amounts to coming up with a set of conventions that guarantee that you're following all the rules you're supposed to follow and enforcing them in a religious sort of rigorous strict way the advantage of this is you don't need a runtime because you're not making them states that the runtime was supposed to catch for you so to be fair I called this the rust solution but really the rust solution is taken by bits and pieces from lots of other languages and a lot of academic research and so forth so I think the made the biggest influences are probably C in C++ of course Haskell and Erlang and cyclone which is an academic language but you know I think gives you you know a lot of programming languages will see things that you recognize as I go along so in summary you know if you take one thing away from this talk I would like it to be this slide which is that the goal of rust is to support the patterns from C++ that you you know know and love like pointers into the stack and into random data structures and so forth but without all the bugs that make you pull your hair out for three days and then only crop up when your customers are overloading your website or whatever and we want to do that without requiring a lot of runtime you know in a way that basically is as flexible as C so that means we could use rust for example to implement a kernel or to implement a library that plugs into some other program and embedded projects things like that now there's one caveat I have to point out I say that we prevent all the these horrible bugs and we you know do except if you link to C code well we can't help you you know you got C code going you could do anything and we also have this thing called unsafe code that I'll talk about which lets you basically break the rules so you might think well what kind of guarantee is that if I can just break it and the answer is as long as when you can confine the set of code that might break the rules down to like a thousand lines of code or a hundred lines of code it's much easier to review it and read it carefully versus if you have to search every one of the eight million lines right so there's still a big advantage here so this is what I'm going to talk about in the talk the first section is kind of rust memory management strategy the second section is how we do parallelism and the final one is a little bit about this ability to break the rules and what I'm not going to talk about is a kind of comprehensive overview of rust syntax or some of the you know fancy features that we have but suffice to say we've tried to take a lot of the nice niceties that you may have found on other languages like pattern matching and so forth and we tried to offer those two to make just to make everyday programming a little more pleasant and one of the things we do offer or at least plan to it's still being hacked on actively as we speak is an optional garbage collector because I spent some time trashing garbage collection but the truth is it's often very useful it's only in certain contexts where it's it's really not what you want so we try to make it optional and on a per thread basis so you can even have like one thread maybe your compositor thread or something which needs a much more precise timing guarantees and other threads that don't have that don't have that requirement so let's talk about memory management basically you have this control and safety dichotomy I talked about right so the most the way to get the most control out of your memory management is probably something like malloc and free it's pretty flexible you know exactly when memory is getting freed it's when you called free but it's pretty risky if you do it wrong if you call three two times or zero times or whatever you get a lot of bugs and then there's the garbage collector on the other side where you don't really know when memory is getting freed but you don't have the opportunity to mess it up so what Russ does is to say let's keep this kind of malloc free model but let's put let's put a build on top of it a set of conventions that make sure you're doing it in a reasonable way and we call those ownership and borrowing so I think ownership is pretty analogous to real life in some ways at least a kind of weird version of your life so to help me explain it I'm going to bring in my handy stick figure friend here in his little book right and basically this book it kind of represents a data structure okay so if you think about ownership and a book if I have a book I have it in my bookshelf I own it and other people don't right so basically if they want to read that book they have to come to me first because it's in my bookshelf they can't just have their own copy floating around or if they do it's a separate book well it works the same way with a data structure in rust so if I have like a hash map or something and I'm a stack frame let's say I own that hash map I know that there are no other aliases to it nobody else has that same map right and that has some nice implications for example I know I can just free it anytime I want to because nobody else has a pointer to it so they won't have a problem if it goes away right and in fact I don't even have to do it explicitly I'm the only one that has that map so when I'm finished with it when I quit or return we can just free it right I've always wanted to use that fire transition and I never had a justification but so so that's basically how it works with data structures and memory management but the other thing I can do if I own something is I can give it away and I can transfer it so I might give my book to you and in that case once I've done that it's yours now I don't have it anymore and because it's yours if you are finished with it you can free it right you're the owner now so let's look at some code and see what I mean this is a little bit of rust code and this actually would not compile and we'll see why later or in a minute but let's kind of step through it the first thing it does is it creates a hash map and for those of you who know C++ you'll see the word new there and you'll think memory allocation it's not a keyword in rust it's just the name of a function that by convention returns a new hash map but basically what we're going to wind up with is exactly that same setup yourself in C++ will have the fields on the stack and the data in the heap and now we can call this function take and you see I'm giving the hash map as argument what that does is it transfers ownership so basically I'm going to push a new stack frame and I'm going to copy all the fields from the parent or the caller to the callee and this is where real life and computers kind of diverge because if I didn't do anything else in a computer although I gave ownership to the Kali I still actually have a copy on my stack right that's kind of why DRM has such a hard time but if I want this to work more like real life and rust that's how we want it to work is when you give it away you don't have it anymore so what we do is we just kind of forget about it all right the compiler will enforce this as we'll see but basically you say ok you've given this map away you can't use that data anymore so it's you it's as if you didn't have it on your stack it's been transferred to the caller and now because the function take owns it function take can go and do some stuff to the map and when take returns the map's going to get freed because take is the owner and so will be will be returning now to the call to the original function that the only difference is we don't have the map anymore and this is where the error comes in so if we tried to use it again we would get a compilation error right here a compiler will say no no that variable M you moved it already you can't reference it anymore so that's all good but sometimes you know I have a book and I read it and it was nice I'm not really done with it but I might think my friend might like it so I could give it to them on the agreement that sometime later you know they're going to give it back to me this is called borrowing right kind of a convoluted explanation but it works the same way with data structures if you think about it like maybe you have a hash map and you didn't mean for that function that you gave it to you have some helper function you didn't mean for them to free it they were just supposed to read it for a little while insert some entries take some entries out and then you want it back at the end so we call that the same thing you don't have to give data structures to the caller to the functions you call you can lend them out and the main point that's most important what separates rust from other things is that these temporary references that you use to give temporary access they are a different type from other kinds of pointers and they have a lifetime which is basically the span of time in which they are valid right so then I lend it out to the helper function if the helper function is going to use it in return the lifetime might be the time it takes for that helper function to execute and most importantly the compiler well while me step back if let's go back to real life for a second if I've lent my book to a friend I haven't given it away but there's still a little bit different from not lending it right it's not in my bookshelf so there's some things I can't do like I can't throw it away I can't give it to somebody else not until I get it back well it's the same way with these data structures when I borrow it out if I have a helper function while that helper function is executing there are some restrictions on what I can do I can't trash the map that I lent out to them so let's let's see the code and I think this will make more sense here's a little fragment of code it begins just like the other one it creates a - map but the next thing it does is it takes the address of a local variable so if you know C you'll know the ampersand operator but if you don't what that basically does is it makes a pointer right into the stack right and this is what a borrow is so if that sounded a little abstract before you know more concretely a borrow is taking the address of something basically and the lifetime of this borrow that span of time in which the data is borrowed is going to be from the point where you took the address to the point where you that variable went out of scope the variable B so basically till the end of the block and the compiler is going to check you know it's not it's not legal to but to lend something out for longer than it exists altogether so for example if we tried to borrow this hash map for a span of time that was bigger than this current function that would be an error we'll see that later getting ahead of myself but taking the address noise is one kind of borrow it can also be a little bit more indirect like I told you that in C++ when you fetch something from a map you get a pointer directly into the map well in rust the same thing happens if I call if you look I changed it if you call em get that's going to make a pointer right into the map data right and this is actually a kind of borrow as well it's the same exact thing basically I took the address in the first case I took it over the m variable in this case it took it of some data that the variable m owns but either way we've basically borrowed the map and yeah do I have a little thing what's going on okay anyway so let's let's see now what does it mean so what I said that there's the lifetime of the borrow so the map is considered borrowed until the end of the block what does that mean really that means that there are some things we can't do with the map anymore right kind of like our book so one thing we can't do well this isn't with the map but one thing we can't do is return that pointer that borrowed pointer out to our caller we'll get an error here and the reason is this because that would exceed the lifetime of the borrow we only lent it till the end of the block so you can't just have that pointer go off and escape that would break the whole idea of borrowing when you borrow something you have to give it back basically and this would be not ever giving it back so we'll get a compilation error and that's exactly the bug I showed you with C++ in the beginning right but there are some other things we can't do it it would be bugs like we can't call that function take and give it the map because that would actually if you recall that I'll free the map and then we have this pointer into freed memory and that's bad but that won't be allowed either because that's transferring the map and the map is considered borrowed and we can't transfer something while it's borrowed so we get an error there too so basically the memory management strategy is I mean that about sums it up essentially you have for every data structure and owner it moves from place to place and the owner can free it or they can just keep passing it along and then you can take these temporary references and while something is borrowed you can't free it and you also can't have that reference get used for an indefinite period of time it always has to be blocked by some specific lifespan all right so the next thing I want to talk about is parallelism and we'll see that our approach to parallelism really builds on that ownership all those ideas of ownership that I just talked about but I think everybody kind of knows now that parallelism is important and we can't ignore it anymore and there's some graphs that go like this and blah blah blah and Moore's Law so if we can all agree on that then I can say that we also all know that parallelism is pretty hard right like if you think's getting your memory management stories sound is hard parallelism is even harder and so it'd be really good if we didn't have to worry about some of the nasty bugs that come with it particularly data races and what a day race is for those of you who don't know is let's go basically it's two threads writing to the shared memory it's not the technical definition but it's pretty close so if you imagine I have these two guys and they these two stick figures and they both have the same book you know if they try to write on it at the same time they're just going to get some gibberish and it's going to be a mess and what we want to do then if you have a successful project is you don't allow that to happen and you can do that either by not writing to the book at all just reading it that's pretty good or you can take turns what a lock is for right basically say okay I'm gonna write to it now and the other guy says okay now it's my turn in the lock make sure that those turns everybody plays fair the problem is it's just like memory management that's really easy to say all right that sounds it doesn't sound so hard but in fact if you have 8 million lines of code it's pretty hard once in a while you forget that some memory is shared or you don't realize it's shared at this particular moment in time or whatever and or worse it was fine but then you quit the company and some other buddy comes and he doesn't know what what what Sheridan was not and he makes a mistake so basically we would like to do better right so if we go back to our control and safety if we have shared memory this is the control option right and it's great but there's really no way to avoid these bugs except being really really careful and if we go the other way we have these things like actors which are also really nice when they work and what they basically say is let's avoid data race is the easy way let's just say you don't have shared memory at all voila you know problem solve we can all go home but sometimes that's not enough sometimes you do want shared memory for performance or whatever so what were you saying in rust is let's start with the actor idea let's say most of the time we don't have shared memory because that's actually pretty good and it gets you pretty far but when you do need it we allow shared memory but only if you are these safe mechanisms the guarantee that you're you know taking turns or guarantee that you're only reading and so forth so here is my you know stick figure explanation of how it works and we'll get to the code basically like I just said the default is that you don't share memory so if I'm if there's one thread here and it has two books that it's working with and then another thread starts up and we can transfer some of that memory over right and this is that same notion of ownership that I just talked about so instead we're disabilities giving that thread unique access and similarly we can use this idea of messaging I'll show you in a bit but basically you can create data structures and then send them back and the same works the same way the memory is always transferred nobody ever has the same data at the same time and so let's take a look at some code this is the code to start it starts by creating a hashmap and then it calls spawn and what's spawn that's a little library routine that starts a new thread and it takes as argument this thing called a procedure if you know what a closure is a procedure is kind of like a closure it's a function body bundled together with all the data that that function is going to use the difference is between a standard closure and a procedure is that a procedure really owns that data so nobody else has it and so basically it looks through finds the local variables that appear inside this procedure body and it moves them into the child bed so let's do my favorite graph here just know from a class well it is kind of like a class actually with a single method essentially but like call no it's basically yeah it's like a class with a single method that's another way to look at it so you have here we start out we've created this hash map and then we're going to call spawn and this is the body that's the body of the procedure I showed you just kind of pulled apart because it's going to be a different thread and the point is the child task takes this message m or this hash map and moves it over right and most importantly the parent doesn't have it anymore there's no sharing going on this is an atomic transfer and we can use how much time I have left I'll go through this fast because I'm running a little short on time thought I had a little more but that's alright this is another useful thing that for example or long has that's really handy is this ability to send messages between threads while still maintaining no shared memory and it's basically like a pipe in UNIX right so you create this channel import pair and they're kind of quantumly entangled so that anything that you send to the channel ownership transfers over to the port and you can use this to communicate so let me show you an example I think it'll be pretty clear the parent thread starts out and it creates the port in channel pair and right now the parent thread has both the port and the channel so that's not that useful it could send messages to itself you know could be nice but then it spawns off a child thread and that child thread takes the channel but leaves the port behind right so now this is the magic part the channel in the port are split across the two threads and now when at some point later that child task should execute it can create a message and it can call this send routine which is going to transfer them ownership of the message out of the child into the port and then later very synchronously executing when the receive function is called it'll transfer the message over from the port into the parent so you see that we sent a message we move data around but we never actually had access at the same time so what if we did want access at the same time the trick basically as I said is to take a data structure that is to take that memory and just make sure that we're using it in the right way so we would either like the memory to be immutable so that nobody can be writing to it or to make sure that we have a lock and not just some lock we should get but a lock we have to get so that we know we don't forget and the way that works in rust I'm just going to talk about the immutable case just for time is basically to build on this ownership idea and introduce some library types so we can this is actually an extensible set of things these are the two we have now but you could build other strategies and these library types are called arts which stands for atomically reference counted I kind of like to picture them as like Noah's Ark or something but basically it's a data structure that owns some data and then uses the API to only give access in the way that we want and because the data structure owns because the data is owned nobody else has it right that's what I said in the very beginning so here's an example I'll I'll skip over the introductory part but we can get to this state where we have two threads they each have an arc which is pointing to the same thing that's the kind of yellow box in the middle and inside that arc is a hash map along with a ref count and the ref count is two because there are two of them and you see multiple threads have access okay so the parent thread can can use basically the only method that arc offers is this thing called get and get is going to create a pointer at the data that's inside the arc and it's going to return it as a temporary immutable reference this is borrowing but borrowing the contents of the arc essentially and now because that reference is immutable if I tried to insert into the hash map I'm going to wind up with a type error because I'm trying to mutate something that's immutable but I can fetch things out of the hash map that's just fine so that'll create a pointer right so that's the RUS strategy in the nutshell is that we start out with a basis of no shared memory using ownership to move things from place to place and then when you do need sharing for whatever reason we build up a library of safe essentially containers that encapsulate some protocol like read-only access or acquire a lock and so forth okay so that's all pretty good but sometimes you know it's not enough sometimes we got to get break the rules a little bit we you know for example some of you might have noticed that I said all data has one owner I said that a lot actually and then I showed you this arc with two owners and a reference count and I kind of didn't I kind of papered over that but you know that's you might be wondering how that works well the answer is that the implementation of arc bends the rules it uses these things called unsafe pointers and unsafe blocks and an unsafe block looks kind of like that it's got some code and the word unsafe and what it means is hey hold on I got this you know you don't have to check this code very carefully you can just trust me so basically the compiler will will suspend the rules that will let you do things if it's it's essentially a different syntax for C more or less you know you can copy pointers you can make aliases and the idea is you should do that but you should when you're finished with the unsafe block you should kind of put things back into a state that's safe again so essentially what we're trying to do here is give you the means to build new safe abstractions and by safe I mean even if the caller does some goofy stuff like calls all the methods in all the wrong order it still shouldn't crash it still shouldn't cause data races and so on so something like arc that I showed you that has exactly one method that gives you an immutable reference that's a safe API there's really nothing you can do with that that will break any rules and we use this sometimes because we need better performance so there might be some little method like operating on a vector or something that gets called ten thousand thousand times and we can write it in a more efficient way if we can bend the rules okay that's a good trade-off we can read it very carefully and that's fine or we can build new things like arcs and the task library itself for that matter so that's about it basically in short I guess that as I said the one message I want you to take away is that rust is kind of an opinionated version of C++ you know it's like take all the things that you'd use to do in C++ but do them in a particular way kind of like a strict code reviewer and the thing you get out of this is you get safety but you also don't need to have a runtime so I went over memory management and I went over threading and in particular I went over a little bit about how unsafe code can let you build up new abstractions so if you're interested you can find more information that's our website the IRC channel and the reddit whatever you call that subreddit I guess and thanks very much don't Chris yeah right yeah so the question is basically rust is changing really fast and how can I stay on top of those changes right and that's a good question and I thought the answer is twofold one is we're going to slow down so it's it's been a long long road and I've been working on this for two years now and it's been been a project for longer than that and we've done a lot of iteration but we're kind of happy with what we've got now though we are doing some we're paying off some technical debt kind of like manage pointers doing some changes that we've postponed for a while and saying let's get them done the goal is that this year we should release a stable candidate that has kind of a core language that won't be changing any more and build on that the I think that they're I don't know that there is a good central source of information for for tracking except for the IRC Channel for asking questions and there's like this week in rust but it would be a good thing to create is the truth but hopefully it will be less and less necessary essentially yeah so the question was why don't I just use boost shared pointer and go home right and I think that's a pretty good question I don't think it's an unfair criticism then the less both because there are a lot of code bases out there that don't necessarily use boost for everything and because well things like data races and so forth are much harder to avoid but nonetheless it is true there's some truth to say that C++ has all these tools to build abstractions - and if you are very rigorous and you use those correctly and only those you know then you can still get a lot of the benefits of rust rust is kind of a nicer from my opinion syntax on top of though you know taking note taking those strategies and putting making a language out of them rather than making it a particular way of using C++ the question was can you implement this as a standard C++ compiler like a lint essentially right and I think the answer is you know some of it yes it's kind of the same as before you could but some things are a lot harder I mean aliasing relationships in particular are notoriously hard to track down so I think you'll find that you could do that you won't be able to compile existing C programs with that because they weren't written with that convention in mind but yeah that would be an option I guess theory I guess what I'm saying is I think you could do that but it would be sufficiently different from C has to be a new language anyway all right yeah yeah okay so the question is can I can I intermix different kinds of memory like m map and so forth and the answer is absolutely yes that's one of our big goals is to support essentially we borrowed the term from C++ but kind of smart pointers and these are basically different these pointer types can manage memory in different ways so we have things like an arena for example that allocates a big block of memory and then doles it out and then freeze it all at once you can implement those kind of api's and you can implement them safely for the most part I don't know you know what specific use case you have in mind for calling a map certainly you can call MF and get back some raw pointers making sure that it's safe is a little trickier but I think it would be booble oh well yeah sure to map an input file or something yes that you could certainly do that right I mean I think if you're well I think if you call n map and then you have this pointer that's represents a file you know there's some you'll have to you have to sometimes work a bit to make sure it's safe if you really want that I mean you can take risks yourself it's your project like you could just pass that pointer back and then hope that nobody calls em on map right but you can also do things like have an object with a destructor that calls em on map and to actually get access to the pointer you have to go through that object kind of like arc and that way if you never call em on map directly you're guaranteed that the memory is still valid as long as someone is accessing it so so we have the tools to build that kind of thing um you know get reasonable guarantees yes oh yeah calling c-code is considered unsafe the question was sorry I have to repeat it but when can you call system calls and so forth so I think this guy's how do you stand up a lot so have we what have we built with rust is the question and the answer is first of all the rust compiler itself is self-hosting which means it's written in rust and you just compile each new version with the old version which sometimes makes for a really fun time when you have a bug that you didn't know about for a while but that's a pretty big program however we're also working on that servo project I mentioned earlier which is kind of a rewrite of the browser and then there are a lot of independent projects that I don't even have a full handle on there are even a few people putting it into production which i think is interesting because we're we're still making some changes but they're willing to keep up you know so so that's alright good for them yeah where do I see rust relative to see I mean yeah I mean so the question is where what's the relationship I guess more or less between us do I see them as diverging I think rust is a different take on C and C++ so we aim to you know not to replace C I'm not that ambitious that would be pretty impressive but to give you another option that whenever you might use C or C++ you could use rust and you would get better safety but the languages it's not like the syntax and the semantics I think are sufficiently different that you can't really call them the same language but there they have a lot of similar aspects yeah and then maybe oh that's fine go ahead right that's a good question I'm surprised it took this long actually so I'll start out by saying I think go is an excellent language we're both kind of targeting in some sense similar things but in some sense very different so goes at least initially I don't know if they still do call themselves a systems language and Russ calls itself a systems language I think the systems that we're talking about are kind of different I mean I think go more or less falls on that spectrum that I talked about between control and safety that trade-off somewhere between Java and C++ I would say gives you a lot more control but it also does have things like data races and so forth that there are safety so it gives you more control in Java but still less than C++ and it emits various errors and that's not a bad thing I don't mean when I say you're trading off control and safety I don't mean to criticize all the languages on that line right there's a reason they're all their language design is like the subtle game or everything you change has costs and other benefits and I think that line is kind of a sweet spot in one degree and so but sometimes it's not a sweet spot for some applications and thing does of that tends to be where C++ gets used and that's why we're trying to offer an alternative right question is how much comparison have we done for the performance of rust obviously I made some kind of strong claims about control and efficiency and probably a little stronger than we're warranted by the full set of benchmarks I don't have to show you but but the answer is that I think we we have every time we do some comparison we we usually find that the code is pretty much pretty comparable to C++ although there is often some most micro benchmarks are actually benchmarking some library and our libraries haven't been optimized that much so a lot of times it'll be like I think one particular one I remember was the function that converted numbers to strings was not particularly efficient and there was a benchmark that basically wound up calling this function a whole lot of times in a loop and we look pretty bad until we improved that function but you know in terms of the raw what kind of the LLVM code that we generate I didn't mention it but we build on LOV M it's pretty comparable to C++ and I think there's no reason that with enough tuning we can't have performance that you know is in the same ballpark and we usually do I should say at this point like our hash maps and data structures are pretty fast because they have received a lot of attention now okay oh that's right I'll be here and as I said I have some stickers just burning a hole in my pocket

Channel: Konstantin Bläsi

Views: 30,927

Rating: 4.9251561 out of 5

Keywords:

Id: 9wOzjbgRoNU

Length: 43min 54sec (2634 seconds)

Published: Mon Jan 13 2014