 So, my talk is called Space the Rusty Frontier, or as the program committee like to call it Rust in Space, which I actually like that name a little better. So, this is not gonna be a super technical talk. This is more of the story of the company that I work for and how we have come to use Rust and why we like using Rust in the different places that we use it. So, don't expect any deep technical dives, which honestly is a kudos, I think, to the Rust team in that we didn't have to do any deep technical work with Rust to make it fit into our product as is it was good and it worked. So, this is more of a high level how we got there and what we do with it. So, just a little background on me. I've spent most of my career working on embedded Linux systems, writing some form of C and C++. So, I feel like I spent a lot of time in the wilderness of C trying to find my way out and trying to figure out is there a better way to do this, you know, wrestling with tooling and really weird bugs and all the things that come with that environment. So, using Rust is a breath of fresh air for me, but I spent a lot of time not using Rust and I understand the issues that come up with other languages and other environments. The company that I work for, we are called Cubos and we build software solutions for satellites. So, we operate in what you would call the new space sector, which is, I think, kind of started by SpaceX and this commercialization of space and now you have all of these different startups appearing and we want to position ourselves to really help those companies operate their satellites or their spacecraft really well by providing quality software products that they can use instead of them having to reinvent all this software every time they go about doing a mission. So, our goal is to make space more accessible and we do that by lowering the barriers of entry associated with software in space. Now, what we found is that with a lot of these companies, you know, they're made up mostly by electrical engineers and aerospace engineers, which makes a lot of sense, right? A spacecraft is this complex piece of hardware that you have to be very careful about and it operates in space, so clearly you want a lot of knowledge around those two things, but often the software is kind of left till the end or maybe it's like a poor doubly who doesn't really write a lot of software is now in charge of writing all the software to run their satellite and that's not a really fun position to be in when, let's say, your satellite launches in two months so it's like, go, go, go, get it all done. So, we want to provide tools to empower these people and increase their chances of success with their missions. We have two products that we work on to do that. The first one is called Major Tom and this is just our mission control software. I won't talk about this one too much today because it's not really the focus of this talk. It's a Ruby on Rails back-end with React front-end, pretty standard web app. It's what you'd use on the ground to receive data from your satellite and send commands up to your satellite. I understand there's a pretty big overlap in this community and the Ruby community so I thought it'd be neat to highlight that we do use Ruby on our other product and we are also looking for engineers to help with this product so if this seems interesting to you, please come talk to me after this and we'd be glad to talk to you. The main product that I work on and the thing that will be the focus of this talk is what we call CubeOS. It's a little confusing because the name of our company is Cubos, the name of this product is CubeOS. Part of why we name it that way is because it is the complete flight software system and it's a flight software framework as well. For the systems that we support, we package a custom Linux distribution that supports the hardware and then various pieces of middleware that are custom tailored to satellite-specific needs, drivers that are pre-built for peripherals that satellites will use, and then a framework for our customers to build on top of as they implement the logic for their missions. So we try to provide as much of the software as possible to make it as easy as possible for our customers to get up and going. And this product is also, I would say, like, 95% open source. There are a few bits that are proprietary that hardware vendors don't want us to release because it reveals some details about the hardware, but for the most part, all of this can be found on GitHub, which I love getting to work in an open source product and getting to be here as part of an open source community with this awesome language and using it in an open source product. I think it's a really cool synergy of those two things. So let's talk about how we got to Rust. I think we have to step back a little bit first and recognize that at the base, satellites are all just really fancy embedded systems. They usually have some form of constraint. Now, maybe they operate in a pretty exotic environment like a little different than most of our embedded systems here on Earth. It's just a little, and some of the hardware that's connected to them is a little different, but in the end, when it comes to writing the software, you're essentially working on an embedded device. So in the beginning, when I first started working on this project about two and a half years ago, we were targeting just free RTOS and building an abstraction layer around free RTOS, and what this meant is that everything was written in C because that's what you do if you're writing embedded systems and that's certainly what you do if you're building on top of free RTOS. So writing C abstraction layers and then trying to figure out what is the tooling that we need to deal with our module dependencies for doing testing, for building, all these things, trying to pull this all together and put it under one unified front for our customers to work with because that's not really something that exists in the C world. There are a lot of different tools that do a lot of different things, but not always a lot of unity among those tools and a lot of continuity between them, so we need to build a lot of that. But being a startup, trying to figure out our identity and what our product was and what to do with it, eventually over time, you find that things change and along came Linux and really changed things for us. So we found that as we talked to more hardware vendors, we realized that the flight boards they were offering, they were pretty powerful. They could run Linux and a lot of the customers that we were talking to, they did not have the needs of a real-time operating system. They didn't need those type of constraints or that type of timing, so we started thinking like, well, if we don't need to be doing that and we can run Linux, why wouldn't we just run Linux and have all of our applications run in Linux? It's so much easier to program in Linux. It's so much easier for us to find developers and our customers to find developers to work in a Linux environment and it opens the door for all sorts of other languages to be used. When we were building on Friartos, C was basically the only choice. I've seen some work in building Friartos modules in Rust, which is really cool, but it's pretty rare. For the most part, you're going to be writing in just C, but if you move to Linux and a more Linux-based architecture, you really open the door to other languages and this move for us, which started happening early last year, is really what started opening the door to even consider using Rust. The other thing was just thinking about C and its place in our product and in the industry. At different conferences where we would talk about our software, we would often get very pointed questions about how do you deal with the error rates of C? How do you deal with the dangerous side of C? How do you make this safe for people? There was one person who asked me a lot of questions and his answer was always, well, you should use Ada. Well, it's not exactly that simple to just use Ada, but him asking these questions really got them bouncing around on our head thinking, okay, is this really the best thing for us? Then starting to consider who our customers were and what is the best thing for them? What can deliver the best product for them? When your customers are a bunch of people that, yeah, they can write software, but they are not necessarily professional software developers, so C is easy for them to pick up, but is it really safe for them to pick up? Is it really the right thing for them to be running with? Can they make the best choices with C? Not having a lot of training and a lot of practice writing software and we started to realize that maybe the answer is no, maybe C was not the best choice for us. I think it's good to answer this question, why not Ada at this point? Because in the aerospace industry, Ada is a really popular choice and I think as a language, it actually has a lot of good to it. I spent some time tinkering with Ada as we're wrestling with this question of should we use C, or what's better, what's worse? And as a language, it's cool. The community I found is mainly hidden behind closed source barriers. We could not find a big thriving open source community, which is something that we wanted to be able to align with, but really the killer for us is the licensing situation with Ada. As far as I can tell, there's one company that kind of supports the Ada compiler and the main libraries, so you have two options. You can either purchase their commercial license or use their open source license, and that compiler and all the standard libraries are under the GPL, so then everything you write is then GPLed, which neither of those options really worked that well for us as a company trying to produce a commercial but also open source product. So that really nixed Ada for us. So the thing that really made us jump into Rust was GraphQL. This is probably last fall, last summer. We were really wrestling with this idea of what do we use as an application protocol between the different services on our system. And we really like this idea of GraphQL. There's strongly typed alternative to Rust, which would let us expose a schema of commands and queries, and then really be really selective about what we actually did with it. And we found that in the C world, there was like one or two GraphQL libraries, but there wasn't a GraphQL engine that really worked with the HTTP server, and I really didn't want to write that myself. That just sounded awful when there were so many implementations already in other languages. And we saw that Rust had great support for GraphQL, fit in with the type system that Rust had, worked well with the HTTP server, so did some tinkering with that. It seemed good. We did kind of a bake-off internally between C, Rust, and Python to see what direction we wanted to go in with our core flight software. And in the end, for a variety of reasons, Rust won out. So at this point, I can say pretty confidently that at Cubos, we don't write new C. There are C products that we still maintain. Uboot is the main boot loader we use, which is written in C, and we will not be rewriting Uboot and Rust, because that's not a good idea to try to do that. But when it comes to new software that we're writing, it's all written in Rust, and I am basically a full-time Rust developer now, which I think is just the coolest thing in the world. So now I'm going to talk a little bit about what I call the joy of Rust. There are just different things that we've come to appreciate about Rust. Some of these things were ideas that won us over before we started using Rust, and others were things that we have just discovered as we've gone and now really appreciate. So to start with high-level tools, low-level performance, I find that with Rust, between things like traits, modules, the whole enum system, options, results, the whole standard library, Rust helps me think about software when I write it in a much more natural way than C does. I often found that with C, as I tried to take my thoughts about software and translate them into the language, it's going from high-level design to, okay, how do I organize this around how the computer organizes memory, because that's kind of what C does. That's kind of hard to make that translation, but with Rust, it was always, and has been much easier for me to, I guess, more naturally express myself in the software, which is so cool to be able to do. I think it helps with design so much, but we don't lose on performance, which is even better. So you kind of get the best of both worlds, right? And then that's the point of this. Now, I do want to say real quick that I'm not here to bash C. That is just the context that I come from. That is my history and my background. I'm not boo-hooing C. I think there are places still where it's useful, but I think there are a lot of places where we tend to default to it, and maybe we should question that in the future. So the next great thing about Rust, the compiler protections that we get. And I won't go into this too much, but just the strong typing and the memory management and the way the compiler will protect you and just really yell at you and get on to you if you're doing bad things and just knowing that if I can please the compiler that my code probably isn't going to seg vault, it's probably not going to have some weird pointer errors. That is like such a huge load off of our shoulders. Knowing that if our CI system passes, our code is probably mostly good. It will mostly work. It may not do what we want it to do, but it's not going to do the wrong things in a bad way. And that's just great. Okay, error handling. This is one of our favorite things about Rust. Gosh. We love that we can actually handle errors using Rust. The idea that there is a result type that can return either my data or an error type is so cool that I can propagate those errors back up to the top level through all my call stack. It's even better. And the fact that that can be done with the lowly question mark, it's just genius. It's so great that we can do this. We are patiently watching the error handling story following failure, trying to figure out, okay, where is this going to go using the latest versions? But yeah, we just love that this is a thing that gets so much attention. The core part of the Rust story, and for us, it is a core part of how we write software, is to be able to handle errors gracefully and report them well. Documentation. Documentation is something we take pretty seriously at Cubos. We write a lot of it, and we love that cargo has built in support for Rust doc and building those docs. But even more so, we love that we can embed Rust in our docs and compiler will tell us if those examples are still relevant, if they still work. So it helps us keep our documentation to be a living artifact, a living part of the code. And that's super valuable, especially as a company that is building a product intended for use by other people. The whole point of the product I work on is that I shouldn't have to write code for other people. They should be able to use my code for other things. So documentation, working examples, this is all super important for achieving this goal of empowering other people. And just this ability to compile the examples in our docs seems so small, but really is a big deal for us that we can keep this stuff all in check. And lastly, at least for now, the whole tooling story for Rust has been huge for us. The fact that within the cargo tool through different plugins and through its existing capabilities, you can build, test, cross compile, build your docs, format your code. Gosh, how cool is that? It's all in one tool, and it's all built by the same community. I'm not like going across the other regions of the Internet looking for some random GCC tool chain to do my cross compiling. It's all hidden behind one tool and we didn't even have to write that. That is something that the Rust community is doing and building and maintaining. So, thank you for that. We love it. It's so great. It makes our lives so much easier. And honestly, it's a lot of what we are trying to do previously with our C API, our C SDK. So, seeing it done in Rust in a way that exists already really well and that we can easily extend it through the cargo plugin system is just great. All right. So, let's talk a little bit about where we use Rust, call this Cuboress Corrosion. So, we are slowly, you know, corroding or rustifying our system. So, in this kind of a high level systems diagram of what it will look like with a satellite talking to our ground service. So, on the top we have Major Tom and the Gateway and both of those would sit on the ground, you know, below your radio receiving data. And then this very large gray box that says Flight Software. Those are all the things that run on the satellite. And I think I can say pretty good confidence that most of these are written in Rust at this point. There are a few pieces that aren't written in Rust. We have some Lua floating around in there and some Legacy C and a little bit of Python. But the goal is that everything we write within this diagram will be in Rust. And the goal is that when we deliver this software to our customers that we know we've written it in Rust, we've done our testing, we've looked at it very thoroughly and we've been doing a solid product for them to build on top of. Now, maybe our customers write in Rust, maybe they don't, but the pieces of our software that we have built that they rely on, they are going to be rock solid and part of that is because we've chosen to use Rust to write them. So, speaking of customers, does Rust mix well with our customers? This is an ongoing question. I think one that we will find the answers to over the next few years is we slowly explore this. But what we've decided to do is give our customers the ability to either write in Rust if they want to. And some of them do, and they're very excited about using Rust, which is really encouraging and affirming for our decision to go that way. But for those that are less familiar, we do let them use Python. It runs alongside Rust. And part of how we make that inter-operate is in our architecture all those different boxes are actually different processes. So we create network boundaries between each process, and that means we don't really have to worry about mixing languages. As long as everything speaks the same UDP, GraphQL mixture that we have, we don't care what's talking to our Rust services. We just have everything bounded at the network layer, and then the Rust services are responsible for sanitizing whatever comes in and making sure it's safe. So whatever our customers write, they can't take down their own satellite. We make sure of that. They can screw up their own stuff, but the things that we write that let them control the satellite, they cannot harm, which is great. All right, so kind of the last part of this is some challenges that we have faced as we use Rust and I think some of these challenges also are pretty relevant to the aerospace industry in general and maybe some of the more fringe industries that we want to see Rust get pushed out into. Industries where maybe trust is a little harder to gain or environments are a little weird. So the first one, and this kind of hits us pretty hard is the compiled binary sizes. Is that a debug Rust binary? It's going to be pretty large. Release Rust binary is going to be smaller and you can strip it down to be even smaller, but still we found they tend to be a little bigger than the C binaries and that's something that we have to kind of reckon with on a daily basis as we do development on these satellites. So imagine you have a satellite on your desk and you're working with it but the only way you can talk to it is over a serial link and it's operating like 115200 VPS and you have a one and a half megabyte binary you have to transfer over and that's your only way of doing it. So that's kind of slow. It's going to take a little while to send that over. Now that's like best case scenario. Now imagine we take that satellite and we put it up in space and now it's talking to a radio over that serial link but the radio is actually even slower than the serial link. Let's say half the speed and let's say like you can only talk to it for like three or four minutes every ten minutes. So you've lost a lot of bandwidth at this point and this one and a half megabyte binary suddenly is taking a really long time to transfer over. We don't have a good solution for this one yet. We're still reckoning with this. We may look into the idea of binary diffs or something like that when it comes to updates but this is just a thing for us that we will have to deal with as updating software and satellites is a real need and something that we really want to offer to our customers. User learning curve this comes back to the whole idea of for us it's the customer but really it's any new user of Rust there is certainly a learning curve to getting into the language and I think it'd be easy for someone to argue that C is much easier to learn but is C safer to learn? I don't know about that. I think we pay a lot up front when we learn Rust for the safety that it gives us but sometimes we have to convince people that it's worth doing but I will say we really appreciate the Rust community and the work they've done on the docs, the Rust book has been great. All the different resources for learning Rust are just excellent and have been so helpful for us as a team to get there and I think you know the more we can do to give people those stepping stones to learning Rust the easier it will be to bring in these people. Language maturity. So I haven't run into this as much but I have a feeling that as Rust tries to push more into let's say the traditional aerospace industry or maybe just traditional embedded wherever that lies what you find is that there is a lot of institutional inertia and institutional trust in old things and old tools and new things are not good because they're new but old things are good we know they work and they're old and figuring out how to overcome this is pretty challenging and it can be a hard sell when you're like yeah my language has been around for like half a decade a little more than that you should use it, you should trust it I know your code base has been around for like 15 years but trust me this is okay. It's not a good quick solution to this one I think the best solution though we have to stick with Rust and keep working on it and keep pushing it forward we can't abandon it we have to see the long game of Rust and that in the long term I think it can and will become a very acceptable default for systems languages but we just have to give it that time to age and mature and gain the trust of different industries tool chain maturity this is one that hits a little closer to home when it comes to embedded systems so if you go to the Rust Forge website they have the list of supported platforms and it's actually really cool to see all the different platforms that are supported by Rust in the different tiers but what you'll notice is that the tier one guaranteed to work does not have most of those platforms most of them are in tier two or tier three and I think as we push more into different exotic pieces of hardware and I say exotic exotic could mean like a power pc which to most of us is pretty antiquated but in the aerospace industry is honestly like pretty standard when you get to a bigger mission that needs like a rad hard CPU power pc is pretty common so to say right now like okay yeah you should use Rust it's guaranteed to build like all that stuff it's guaranteed to build it's not guaranteed to work for some people that won't be good enough so we need to continue to push these tool chains in these platforms to have better and better support and the more that we can say are guaranteed to work the better buy-in I think we will get as people try to use Rust in these more exotic or antiquated platforms lastly ecosystem maturity I think this and the tool chain maturity language maturity a lot of these are just things that happen with time but I think this one in particular is the one that's most in the hands of everyone in this community the one thing that we do a lot at Cubos is testing and when looking for a testing framework in Rust it's like okay mock testing in crates.io what do we get out of these six different libraries some of them are unstable some of them are nightly so which one do I pick out of all of these and maybe some appear to be supported really well maybe some got up to a great start but now it's like does someone maintain it I'm not really sure trying to figure out what is the best choice sometimes is tough I think as a community we need to take steps to be better contributors not just users I think the more that we can contribute back to the crates that we want to use and I think a lot of people do this it's not really something I started doing but it's something I really feel like I should do I can't just be up here saying these critical things and not taking steps to fix them I'm part of this community too so the more that we together can contribute and hold up and support these crates I think the quicker the ecosystem as a whole will mature and better and better options will appear for people to use as they build on top of Rust so closing thoughts we at Cubos we really like Rust I don't think it's too much to say that we have taken a decently large gamble on the language and the ecosystem now our product is a framework we have chosen Rust as the primary language for that framework so I think that's a pretty strong statement that we believe in Rust and we believe in its future and we are thankful for Rust and all the different libraries and the people that support it and want to continue working with this community and hopefully growing together so thank you for the great gift of Rust and given to so many people and lastly if you want to check out our flight software it is up here on GitHub so please go out at my Rust tell me I'm a terrible programmer please help me get better give us suggestions that's all thank you