The Symbiosis Of Rust And Arm: A Conversation With David Wood

Drew: Arm is super well known in the tech world. However, I don't know how many people really understand what Arm actually makes and how the business of Arm works. Can you explain that?

David: Arm is a really interesting company, and I don't think there are many other companies that do what Arm does. Arm designs a processor architecture, ARM or ARM64, which we then design processors for. Arm provides a compute platform that partners license for various applications from small phones, many devices and sensors, up to data center processors and all the clouds that you can think of. There are over 325 billion Arm devices in the world, and that number really makes sense when you understand that they are incredibly fast and power efficient. It's why people pick Arm.

Drew: I remember it was a big deal when Apple switched over to Arm because of the efficiency.

David: Power efficiency is at the core of Arm’s DNA. All major cloud providers build on Arm and provide Arm-based instances, and nearly every smartphone in the world is built on Arm.

Drew: To dig a little deeper on this issue for background, why is there a market for licensing instruction sets?

David: It allows you to be quicker to market with hardware, because you don't have to do that work or have that expertise yourself. If you want to have a processor in your product, you either get all the expertise in-house to do all that yourself, or you work with a team who has the expertise who can provide you with your design. You might also for example use one of our partners who will sell you one of Arm's designs on a system on a chip that you can then use in your product.

Drew: With that foundation in place, let’s talk about what you do. I think you have a very interesting role at Arm. You’re the Rust Team Lead. Can you explain what that involves?

David: An architecture is not much use if you can't write code for it. So, we have lots of teams at Arm that contribute to various open-source projects to make sure that Arm support exists in all the compilers and languages you can think of. My team is specifically responsible for all of Arm's contributions to Rust. We want to make sure that if you're using Rust, you can take full advantage of all the Arm-based hardware, whether that's your phone, your laptop, or in the cloud. I don't want someone to not choose Rust because they're using Arm, or vice-versa. And, obviously, we're very interested in making sure that Arm support is widespread. We want you to be able to take advantage of all the features in your Arm-based hardware to accelerate code and improve security. Concretely, what that looks like is I spend a good amount of time as an individual contributor on upstream projects, things like scalable vectors. I also mentor and work with the people in the team and manage our relationships with our upstream collaborators, making sure everything moves along nicely. I also plan the work we do which is really all about making sure that we're pursuing things that are both important to Arm and impactful in the Rust community. I spend a good amount of time talking to our partners to make sure that the things they really need in terms of their use of Rust on Arm are prioritized. I also spend a lot of my time on my responsibilities as a member of the Rust project.

Drew: I think a lot of people dream of having a job where they could do a lot of open source work, and it's kind of everything that you do, right?

David: Yeah, pretty much. It's the dream job.

Drew: Obviously Arm is a big company. There's a lot going on outside of your team. Are there other areas where Rust is used inside the company that you would point out?

David: There definitely are. Arm is investing more than ever in software, and Rust is part of that. That said, our focus on Rust is slightly different from other companies. A lot of the work we do is contributing to open source projects, which are already written in other languages. So, we can’t really go to these projects and say let's write this in Rust because we like Rust. We just have to work with what's there. Other companies that contribute to Rust are often doing so with an eye to the features and things that are important to their internal users. Our priorities are slightly different. We're more focused on things like general upstream Arm support in Rust and making sure that our partners and their customers can use all the features of their Arm-based hardware with Rust.

David: Even with our focus on architecture enablement, we do end up solving general problems along the way though. And, there are internal projects at Arm related to Rust. For example, there's a project called Parsec, which Arm donated to the Cloud Native Computing Foundation. It's a platform-agnostic API for secure cryptographic services. We also recently announced a rewrite of our firmware for A-class processors in Rust, in collaboration with Google. So, there are teams exploring Rust in things like firmware or trusted execution environments, places where safety and performance matter. But overall, because lots of our work is focused on open source and existing projects, the way that ends up looking is a bit different from other companies that contribute up to Rust.

Drew: That makes sense. It's a very different perspective. It's sort of like you're facilitating the growth of the ecosystem rather than building a specific product for a specific user.

David: Yeah, we want to make sure that if you use Arm, Rust has full support for the Arm architecture.

Drew: Do you see Arm investing a lot more in Rust in the future? If so, what would be driving that?

David: As Rust is used more across the industry and by our partners, I expect our investment to grow with it. As Rust adoption broadens, we will make sure our team has everything it needs to reliably make impactful contributions.

Drew: I'm going to ask a potentially stupid question, but I realized I don’t know the answer to this… One of the ways that I've seen Rust growing a lot in the last year or two is in embedded robotics, automotive, that kind of domain. Is Arm used a lot there?

David: Of course. There are parts of the company that focus strictly on different parts of the technology industry. So, there are people who focus only on working with our automotive partners or our IoT partners about how they are deploying Rust in cars and things like that. NVIDIA recently released Jetson Thor for robotics and industrial systems, which brings Arm compute into humanoid robots and physical AI. So, Arm's quite widespread in those areas. It really is everywhere you can think of. 

David: So, we work with those parts of the business to make sure that we can satisfy the needs they are hearing from those partners. We collaborate with companies like Ferrous Systems to advance safety critical development with Rust on Arm.

Drew: You didn’t mention this earlier though you alluded to it, but you are also the Rust compiler team co-lead. Is there anything unique about juggling working for Arm and working as the compiler team co-lead?

David: Not really. The two things complement each other quite nicely. Arm is very supportive of the fact that I have those upstream responsibilities, and it’s part of the reason why they brought me on board. They make sure I have time to dedicate to that work and encourage me to be very active. My experience and familiarity with the Rust project has been really useful in helping us navigate the project when we're making our contributions. It helps when we’re trying to make sure that the things we propose and the work we're doing have a better chance of success. So, it's a mutual benefit. I get supported to do that work and Rust benefits from that, and Arm benefits from having that experience on our team. For the project in general, I think it's quite good for there to be contributors with varied affiliations so that we're not all just paid by one company. We need people from different backgrounds and different interests that are being supported to perpetuate the project.

Drew: I agree that it's very good for the health of the project to have lots of different companies with different interests all supporting it in different ways. What are some of the interesting things you've worked on with the compiler in terms of problems you've been able to solve or features you've added?

David: There's a lot of really interesting things, especially some of the stuff we've been doing recently. At the moment, one of our main projects is scalable vectors. That's given me an opportunity to learn about parts of the compiler I never really understood before. Scalable vectors are this interesting extension to the Arm architecture. They're similar to existing fixed-length SIMD instructions. Those are where you have a single instruction operate on multiple values at once. It basically just improves performance. The scalable vectors are similar, except that all the intrinsics are length-agnostic. So, instead of having to rewrite your code every single time a new vector length is added to the architecture, you write it once and then the instructions are all length-agnostic. You benefit from the larger vectors and faster performance as a result.

David: So, those are really interesting because they don't really jive with some aspects of the Rust language. Rust's existing notions of sizedness expects that the size of a type can be known at compile time. With these scalable vectors, that’s not the case because it's the hardware that decides that. At the same time, they are just registers on the system and they should act like value types. For example, you should be able to copy them. To square that circle will be really interesting. This will involve writing RFCs, working with the language team and the compiler team, and doing some complicated implementation. It's fun for me to take on big challenges like this. It's just very different from stuff I've done before, and it's quite challenging. Also, by doing this kind of work, we often end up unblocking other features that have been blocked for quite a while.

David: For example, there's a feature called extern types, which helps interop with C. If you say forward-declare a type in C, there's no real way of representing that type in your bindings to C today. Extern types have been blocked for a long time in Rust, and our work on extending Rust's notions of sizedness is helping unblock that. So, that's just something that we've managed to do along the way that improves Rust for everyone. Extern types are not even related to Arm, but we’re hoping to fix that problem alongside the changes we're making to support scalable vectors.

David: Another thing that's interesting about the work at Arm is that previously I really only focused on the compiler. That's where my background in the project is, and that's what I've worked on for the seven or eight years I’ve been working on Rust. At Arm, we're focusing on more than just the compiler. We pay attention to the whole project, the whole Rust ecosystem. For example, we've got projects in Cargo like build-std, which is a very long-standing request from the community. It provides the ability to rebuild the standard library with different configurations or for different targets. That's a completely different type of project than I've ever worked on before. So, I'm learning a lot along the way. And, I’ve been able to work with people in the project that I have not had many opportunities to work with before. That work will be really exciting when it’s done because it unblocks a huge amount of stuff. There's lots of compiler flags that are blocked on build-std. There's lots of embedded users for example who need this. It'll be really useful for a lot of people. I wasn't sure at first how impactful some of our work would be, because it looked to be quite architecture-specific. But, it ends up being both really interesting, impactful, and enabling for a huge amount of other things. It's been really satisfying.

Drew: The scalable vectors sound kind of mind-bending to work on. Is that ongoing work?

David: Yeah, we're still working on that. It will be a multi-year project because we have to extend Rust's notion of sizedness as I mentioned. We have to do that work and stabilize that work. That'll take a lot of time, a lot of discussions, and a lot of meetings. Then we also need to build the stuff on top of that that actually does the scalable vectors. We're working on those in parallel. Then, we’ll get it stabilized after that as well. This is sort of the nature of all the work that happens in the language and compiler. The timelines are really long. We want to make sure we get things right. And, we want to make sure we don't break anybody’s code or introduce anything unsound. So, it's slow. It's arduous. It's a lot of politics in a good sense and a necessary sense. We have to get consensus and come up with decisions. That's what the project's built around. So, not many things happen quickly.

Drew: I want to make sure I understood this right. The benefit of this is really a performance benefit, right?

David: Yeah. There are certain algorithms that you can express using these vector extensions–think of stuff like video codecs, where you're performing the same operation multiple times on different bits of data. You can put all that data in one vector and do the operation across the whole vector all at once. Vector extensions are built for doing this kind of thing really well. The scalable vectors take what we already have with NEON, which is fixed-length vectors, and make the next step that will allow you to do that in a way which is scalable. So, you write it once, then as hardware gets larger vectors over time, you'll benefit from that speedup. Further down the line, we'll start supporting three-dimensional vectors and matrices. That'll be for AI and for those types of operations.

Drew: That's super cool. Speaking of performance, a lot of people complain about compile times. I'm sure that's something you know a lot about. How much opportunity is there to speed up compile times? Or is it kind of as fast as it can be right now?

David: I'm sure there'll be ways we can make things faster. We're always working on that. There are teams of other people in the Rust project whose sole focus is making sure the compiler is fast. For example, Nicholas Nethercote is well known for doing this. He writes a lot of blog posts about how he's improving the speed of the compiler. He's actually currently looking for opportunities to do that professionally again. So, there's lots of people whose sole focus is this. Rust compiler speeds have gotten faster in the last couple of years. A lot of the low hanging fruit has already been taken. Those are efforts like trying to improve our incremental compilation or using different linkers or using parallel linkers. Actually, there is work going on to parallelize the compiler itself. Obviously, there’s plenty of opportunity to improve compile times when you've got lots of cores. Some of it's just the nature of Rust as a language and the fact that we have these quite large crates that we compile all at once. But, that kind of has to be the way we do things for the language to work the way it does. So, it makes for a hard problem to solve. That's also quite different from how other languages which use LLVM are compiled. So, the types of languages that LLVM has historically been optimised for are quite different from Rust.

Drew: To me it seems almost like the trade-off that you make. To have a fast language that has all these safety guarantees from the compiler, the compiler needs a little bit more time to do its job. What do you think will be the most impactful change in the compiler in the next year or two?

David: There's a compiler subteam in the project called the types team; they’re focused on the type system, which is a notoriously complicated part of the compiler. They've been doing really great work rewriting that part of the compiler in the last two or three years. That will be a really, really significant development. It may not be something that users notice immediately, but it will mean that we have a much better understanding and a much better foundation to build on for one of the really core parts of the compiler and the language. That will end up enabling a lot more features to happen on an achievable timeline in the years to come. For example the ability to make your traits const. That will be a really interesting feature because it will enable a lot more use of our existing compile-time evaluation, but it will need the new trait solver to work. That’s just one example of a feature that will be enabled by this work.

Drew: With everything you've described about working at Arm and how much you get to work on growing the Rust ecosystem, I would imagine that a lot of people after reading this will be very interested in trying to work at Arm. If you were one of those people, how would you go about trying to make that happen? Are there specific teams or projects within Arm that you would try to find roles with?

David: That's a tricky question. My team probably does the most Rust. And, we're really looking for people who are very experienced in the Rust project, are contributors, and know their way around the compiler really well. That's a very niche skill set. That's one option though for those who fit that criteria. You can go and contribute to Rust, and maybe one day that will give you an opportunity on my team. As far as other teams at Arm go, I think the best way to think about it is not necessarily in terms of working with Rust at Arm. Instead, there are lots of teams that will be looking for people with expertise in things like firmware, codecs, or confidential computing. There are a number of things like that that Arm does quite a lot with. So, I would learn one of those domains that sounds interesting. And, I would think, “Would Rust make sense in this context?” If you think of something like a video codec, it's perfect for Rust. We’re seeing that these areas are focused on memory safety, and the governments are urging people to make their software memory safe. So, Rust will move into the domains where it naturally fits.

David: So, find the area you think is interesting, irrespective of whether Rust is commonly used there now. If Rust makes sense in that domain, my feeling is it probably will get adopted eventually. I'm optimistic that Rust is going to see broader adoption. Much broader than it already has, which is already huge. Having some Rust experience and having domain-specific knowledge will put you in a perfect place for that type of role. And, I imagine it could be really cool to start working in one of those fields before Rust is being used and then be on the forefront of helping that transition happen.

Drew: That seems like sound advice to me. I wanted to ask a follow-up on one of the things you said about your team, which is that you look for people who are pretty mature contributors to the compiler and ecosystem already. So if you're someone who wants to get into contributing, what advice would you have?

David: The most important thing is to start doing it. It's simple, but it’s the best advice. There's never a perfect time to start contributing. I kind of wish I had started earlier, but now after eight years, I know there are people who started last year who wish they started prior to that. So just dive right in. The Rust project is really friendly. There's lots of documentation, and there's always something that needs doing. We've got lots of work to do. Even small projects and small contributions can teach you a lot and help you feel quite connected to the project. There's lots of things like improving diagnostics that can be quite approachable and could be a good way to get started. That's how I started. I think as long as you show up and are eager, friendly, and interested in making a good contribution, then there are lots of people in the project who are interested in supporting that.

Drew: I've heard from a few people that have contributed that the people in the Rust project are actually quite good at helping new people ramp up.

David: It's important that we do that. We have to make sure that we always have a good group of maintainers. We have to scale with Rust’s growth. So, absolutely, as many people who want to get involved as possible, please do come and help. We need the help.

Drew: Is there anything else that you wish we'd had the chance to talk about or that you'd want to leave people with?

David: No, thank you for having me in this interview. It's been really great. I've enjoyed the other interviews you've done as well. If anyone's interested in the stuff that I've mentioned like build-std, scalable vectors, or making improvements to Rust's performance tracking infrastructure, feel free to reach out to me. I'm quite easy to find online, “davidtwco” on GitHub is probably easiest. Also, if you're interested in Rust on Arm or compilers or systems programming, just reach out.

Drew: Awesome. Well, thank you so much, David!