Welcome to Rust in Production, a podcast about companies who use Rust to shape the future of infrastructure. I'm your host, Matthias Endler, and today we talk to Dylan Brown from Rising Academies about bringing Rust to schools in Africa. Dylan, thanks so much for being on the show today. Please say a few words about yourself. Hi, Matthias. Thanks. My name is Dylan Brown. I'm a South African developer. I've been working primarily with C# for over 10 years. A lot of work in .NET, a lot of work building chatbots in particular over the last eight or so years, primarily in spaces like fintech. And then in the last two years, I suppose, I've been working more heavily with Rust at the organization that I'm at now. Which is? That's Rising Academies. So Rising Academies is an educational organization, so not a tech company first. Rising started in 2014 in Sierra Leone, which is in West Africa. And we spent over a decade developing and refining an approach that improves classroom practice and student learning. As I said, it's not a tech company, so most of the company is not from a tech background. A couple of years ago, we added more education technology or edtech. Into our offerings to support our mission of impacting the learning of one and a half million students across Africa. So we've been trying to take everything we've learned from having physical schools on the ground across West Africa through crises like Ebola, COVID, all of that, and to try and take that and see what we can, build that actually helps education all across Africa. So these days, we're also partnering with governments across the continent and building out these edtech products. And that's where I come in. So I'm the senior engineering manager for Rori and Tari. So Rori is a math chatbot, which is delivered to students in schools through WhatsApp. It's operating in schools across seven countries, primarily in Western East Africa. And then Tari is a teacher-facing chatbot, which aims to use a lot of our learnings, about teacher training to help with teacher professional development across the whole continent. So being used a lot, very widely across the continent. So explain to me how that part works. You said that students use it via WhatsApp, but what is the typical workflow? Sure. So Rori, we found the most success with in terms of student learning by having Rori deployed in schools. So usually classes will cycle between some phones that are shared. So you might have a school of 250 students and maybe 50 phones, and they will have maybe one session a week with Rori. And those sessions with Rori are focused on practicing their math skills. So the main key loop in Rori is students getting math questions, answering them, having those evaluated by our systems on our side, and returning back to the user, either if they've got it correct, moving on to the next one, giving them hints if they've got it wrong, basically helping them do that math practice, which, students don't typically get a lot of in a typical kind of call and response classroom. Where a teacher is just standing there. And, you know, the occasional student gets to come up and write on the blackboard the answer, right? So one of the key things with Rori has been that ability for students to actually practice their math skills. Anecdotally, we hear a lot from students about their growing confidence in maths and kind of overcoming those barriers in terms of fear of mathematics. So that's a lot about how the kind of key loop of Rori works and how it works in schools. The key other observation from Rori is that it's really about trying to get students to the right level. So once again, the difference with a classroom is you have to be teaching the same content to everyone in the class. And with Rori, because individuals are practicing themselves, they can be practicing at all different levels. So you can see a class where you have students practicing everything from grade two to grade nine in level of maths skills that they're practicing as well. So, yeah, those are the two key benefits with Rori in an African context in schools. It's getting students to practice that maths and actually practice the skills and making sure that they're practicing it at the right level. Now, of course, an obvious question might be, why don't you use laptops for that? Why phones and why a chatbot via WhatsApp? Yeah, I think from like a traditional ed tech that we've seen in like the Western world or in Europe, you might expect it to be laptops or tablets. But practically, when you're coming into a space where a lot of schools in Africa don't have computers at all or they have no real computers, tech devices a phone is often the easiest way to get these kind of technologies into these schools right and it's mechanism that's easy for kids to, learn to use we've seen kids who have said they've not really had any experience to phones being able to quite easily learn to use whatsapp right and learn to interact with Rori and i think also once again, in terms of the technology you see across africa mobile phones are by far the most ubiquitous form of technology and whatsapp is by far the biggest, chat platform so when it comes to like the teachers being familiar with whatsapp, and just everyone having more context for what it is it makes it a lot easier, for us to overcome any of those kind of barriers and those learnings in the schools as well. What's your Rust production story? So a couple of years ago, we wanted to build out a service in order to enable us to better scale the use of Rori in schools, right? I mentioned earlier that, you will have students switching phones. So we needed a way to store a lot of the student information off the platforms that we were using. And so we needed to build out effectively a student service. And so that's where we decided to build out a service in Rust that we call the user service. That's more broadly because it also stores teacher data for Tari. There's nothing particularly special about it. It's a relatively straightforward API service using axum and SQLX. But the key thing that it enabled for us is this ability for students to share phones. So in order to have 200 students at a school using Rori, we no longer have to have 200 phones in that school, which can be quite expensive, we can do that with now 50 phones or 20 phones, depending on how the scheduling works in the school. Someone might listen to that and think, well, you could do that with any other technology. You could use Python, for example, or TypeScript. So I think my question would be, why Rust? True. There is nothing special about our use case that makes it explicit for Rust. I think for us, when we're thinking about the choice to use Rust, we're thinking a lot about what is it about our context that's actually the most relevant thing, right? I think a phrase that comes to mind a lot for me is education is a long game. We want to be building something that is sustainable, that is going to stick around and be with these kids for their learning in the long run. And I think another thing is that at Rising, we have the rising way, we call it, our principles that we live by. And one of those is we do more than anyone thought possible with less than anyone thought possible. And I think the key thing for people to understand is that this speaks to the. To working with limited resources in Africa, right? Especially in education, unfortunately. And it shouldn't be like this. Obviously, we would love for there to be a lot more resourcing for education, but that is not entirely within our control, right? So what we can control is what we can do with what we have. And I think that's a principle broader within Rising, not just specifically to our choice for Rust, but it does lean us in that direction, right? We want to make sure we're making a long-term impact with a relatively small team. And importantly, we also want to make sure we're controlling costs in a reasonable way, right? So when it comes to compute costs for a service, for example, the user service, I did a calculation the other day, was about 25 times cheaper than a comparably active service that we have that's been built with Python and Django. So those costs really rack up over the long run in order to make sure that we can keep having more and more students using Rori. So I think that side of things really matters. And I think another thing for me that's very important is the impact of the work that we do on the environment as well, right? So I think Rust in terms of. Compute, it helps you have your cloud services cost less, but that's also because they're using less electricity, you're using less resources. And Africa is unfortunately a continent that is going to be bearing the brunt of a lot of the environmental change that we see as a result of climate change. So I think inspired by a talk from Rust Lab a couple of years ago, I think a big reason for us is also making sure that we are doing something, that is not only helping the students with their education, but also with the communities that they live in. And I think being smart about the resources that we use for what we build is an important aspect of that. What went into that cost calculation between the Django app and the Rust application? So that cost calculation is primarily just the hosting costs on GCP for the API service that I was comparing there, I think, you know, there are other costs that we want to be aware of, right? When we're building out these services, there's obviously costs in terms of team salaries and the time that we spend, therefore, on these services that we're building out, right? What we also want to do is make sure that we're using the time of the team efficiently, right? And a key to that is making sure that we can be building new features and not, you know, firefighting production issues. And I think Rust has some clear benefits for that, right? In terms of making us able to trust that what we ship is solid, as well as in terms of being solid for student experience, right? I mentioned earlier the scenario where you have maybe 50 phones and 250 students. So if one student has their Rori session once a week, if Rori is down for half an hour and it happens to coincide with that student's session, then they've missed out on a whole week of their learning, right? And the education calendar is already very packed. So missing out on a week of any kind of education can be very impactful to students. So we also need to make sure that it's solid in terms of stability for making sure that that, you know, the cost of everything for the impact it makes on the students' learning is also taken into consideration. What does Rust mean for you in an engineering leadership role? Yeah, I think that's one of the other things that informed my decision to push for our use of Rust. I think for me, as an engineering leader, in other languages like Python or C#, I find myself a lot of the time being like, kind of annoying person on the code review who's like, okay, what happens when we return this null at the call site, right? And I think Rust makes it a lot easier for me to just focus on the business logic, to focus on what really matters when I'm doing a code review and not have to worry about like, have we caught this exception everywhere that this function is called when we add an exception here? Or like, have we handled the null? Because I know that the compiler does those things for me. So I think being able to almost create those kind of, systems within the code itself that the compiler enforces, right, using the type system in particular really makes it such that my, technical contributions get enforced in a way that doesn't just have to be me on a code review, and I can focus on the more substantive things. If I remember correctly, your background is in C#, Now, if you look at it from this perspective, you come from maybe C# and then you transition to Rust. How does that change your perception of what robustness means and what were your experiences when using Rust from that background? I think for me, a lot of it was about what I didn't have to worry so much about. So I think I also had learned some C++ and those kind of languages in university. So I had some understanding of like memory management and pointers and things like this from C++. But primarily I found in C# a lot of the time what you're worrying about, is memory leaks in production or you're worrying about null references or is this exception being handled. I think a lot of the challenge sometimes with C# is it does provide you a lot of groundwork to build a lot of really solid applications. But there's a lot of those edges that you kind of have to keep in your mind all the time that Rust allows you to, basically let go of and not worry so much about because the compiler is stricter and enforces a lot of these things, right? The memory safety is more a function of, Not having to be in my working memory than having to worry too much about the actual impact of memory leaks, for me at least. And what would you say about the tooling story comparing C# and Rust? I think C#, there's a lot of, especially in the .NET environment, there's a lot of tooling that is just very much built for enterprise software out of the box, right? That's like really the environment that most C# devs are working in. And I think that's the reason C# has been as prolific as it has, especially in areas like fintech. I think Rust does make you sometimes do more of that yourself. But I think if you know where you're going, that can be a lot easier, right? So I think some of the challenges we had in C# was trying to work against some of these frameworks and these tooling that we were using. Whereas in Rust, we are having to be more explicit about those decisions ourselves. And so we're a lot more in control of that rather than having to, you know, fight against that ecosystem, so to speak. I think one of the challenges sometimes with the Rust tooling for somebody coming from another language is maybe not having all that stuff immediately obvious to you. So for example, you know, we had a lot of success using X tasks for things that would normally be like scripted things you would write Python scripts for, So you might think, okay, I'm moving into this language, or I can't do these things that I do in Python that are really easy. But often there are ways to do these things. And sometimes the challenge is just figuring that out and figuring out how to do that, because you won't find as many YouTube videos or podcasts about Rust as you will about Python or other languages. Rust has a famously steep learning curve. I would like to pick your brain on this. Is it really that hard for a new team to get started with Rust? Yeah, I think it was something that was a bit intimidating at first and has been a bit intimidating for some folks in the team. But I think what I've really come to realize is that learning Rust isn't about learning all the details of the borrow checker or learning all the details about how lifetimes work. At least for our case learning rust is a lot more about the mindset right that goes into writing rust code so i think that's something that i've learned, is probably the better way to approach learning rust in a way that's less scary than having to, learn all these hard concepts up up front more learning about why why would i want to write this in rust right and those are things like, the type system, obviously, that can give you a lot of safety in what it is that you're writing. If you are used to writing code in a way where you care about types, like using something like Pydantic and Python, then it becomes much easier to transfer that mindset into Rust, right? Where you don't really have a choice but to care about types most of the time. So I think it's those kind of mindsets that are best for somebody who's learning Rust, right? I would focus more on. I would focus more on those elements of their mindset towards programming rather than the specifics of this is how a borrow checker works. This is the difference between the stack and the heap or any of these more in-detail, technical facts, right? I don't know much about C#, but certainly that was a problem with Python for me is that types are optional and you can switch them off and you can forget about them. And has gotten a lot better in recent years. But yeah, the part about Pydantic, resonates with me. You have to bring additional tooling like static analysis tooling, linters and so on to get a fraction of the power that you can have with Rust. But then again, I don't want to put words into your mouth. Do you agree with that? Yeah, I think that for me, when I look at a Python project that doesn't have some of that tooling that I like, like Pydantic, for example, it just becomes a bit more frustrating, right? Like it becomes more frustrating to work with. It becomes easier to just make errors as a team, right? Easier to be in a situation where you're now having to firefight issues in production. So I think that makes a big difference to me. I think it's also a case of having those types. It's also a case of having the type system allows you to build code that is also more resilient to change right it makes refactoring easier it also makes it a lot clearer about how your code changes over time so, being able to map from one type in a previous model to a new type in another model is a lot more straightforward with the type system than if you're dealing with like stringy types or you're dealing with like json you know raw json. You also said that you have some c++ background, How much did that help you getting up to speed with Rust? I think the C++ background was more just about concepts like pointers and references not being very alien to me. It was kind of like, oh, right, I kind of remember this from a while ago. But at that point, it was like 10 years ago that I'd written any C++ code. So I don't know that it made a huge impact. I think it's probably easier for somebody who's working more actively in C++. But I think even when I'm looking at hiring for somebody that's going to be working with Rust, having had them work with C++ at some point, even if it's just in university, I think makes a difference because you're having to deal with some of those things. You're having to be more aware of memory allocation. You're more aware of pointers, and these slightly lower level things than you have to deal with in languages like Python or Java. First time I hear about the Rust mindset you need, can you elaborate on that a bit more? I think one big thing for folks that I was working with is... Helping them to also understand that you can work with the compiler. You're not working against it. It's not like an enemy you have to defeat. And I think that's also a pitfall that I see a lot of AI tooling tend towards is just trying to get past the compiler error, not seeing the compiler as something that you're co-building with. I think when you have that mindset about the compiler, you start to realize where the explicitness is actually valuable. So like i'm not a big fan of like underscore match arms and unwrap generally i mean they have their place of course and, there's nothing wrong with using them if you know what you're doing but i think a lot of the times they also become like crutch for, bad design so i think a lot of the times it's seeing developers who favor that explicitness so you have an enum that you're returning or you have an option. It forces that explicitness of okay but what am i going to deal with what am I going to do when it's a none, right? You don't have these like hidden null refs where maybe sometimes you return null and you don't actually remember to deal with it at the call site, right? So I think the explicitness there is also valuable. So if I see somebody writing some Python code or C# code, and they're being explicit about those actions, right? Making sure that they are, if they're returning null from something, that they're doing it for a good reason, that they're making sure that the call site handles it, these kind of things where explicitness really matters and Rust forces that of you. So if you have that mindset that you want it to be like that already, it makes it a lot easier to work with Rust. If I understand the match arms part correctly, what you mean is that if you have... A type with three variants, foo, bar, and bass, and bar and bass would evaluate to the same return value, you would still write them as separate cases. Is that correct? Yeah, I think so. In a lot of cases, I would prefer that because to me, it's about, sure, you might have foo, bar, and bass now, but you might want to add another variant, right? And if you put an underscore match arm to handle foo and bar, and then you add Bess instead, you're going to end up handling Bess in the same way as foo and bar when you actually maybe wanted to handle it more like Bess. So I think it's a lot about that explicitness being valuable for how code changes over time as well. That's the real thing that I find can be a bit of a trap with underscore match arms and these things that are a little bit more implicit in a way. Yeah, because if you add another case and you had an underscore in your match arm, then nothing would warn you about that new case. You might forget about it. Yeah, exactly. And also what I like about that approach is that every case is one line in your diff. You can clearly see when you add a new case in the diff, it's not munched together into one. Yeah, and I think it means when you do have an underscore match on, you really need to ask yourself, like, is it true that for any variants I add to this in the future, I also definitely am going to want them handled in this way, right? So it makes you have to think a lot more about that rather than just, you know, getting the compiler to stop complaining because you've missed some variant in your match. Any other recommendations for more robust Rust? I think one of the things I've found working with Rust is making use of the new type. So not carrying around types that are just like I16s or strings, even where they could just be. Having new type wrappers around them makes it a lot easier when making changes to the code to not make errors. It helps you reduce the kind of engineering side errors that are a result of maybe mixing up two strings, like a first name and a surname, right? And you have these logical errors that you're not really letting the compiler help you in catching. So I think new type wrappers around these types, sometimes they can feel a bit painful. We now have to name a whole bunch more types, and everyone loves naming. But I think that it can really help with the long-term stability as well as avoiding some of these logical bugs that can be quite easy to make quite easy errors. So, for example, instead of using a number like a U32, you could use a phone number type, for example. Yeah, I think it's a good way to be explicit also about the way that you expect the types to be used going forward, right? It's like a form of documentation for the next developer to come along, even if that's only you in six months' time. Correct. Also helps you with narrowing down the type, which is a thing that many people often forget. A string is a very wide type with many valid inputs, whereas a message might not be. Where does validation belong? Yeah, I think that's a good point. It does also make it easier to move validation into your types, right? One thing that I've really liked is in other languages like C# or a typical, domain-driven design approach, you might have some models and you need to validate them at the different layers in your domain, right? But in Rust, you can kind of attach the validation a lot more to the actual types themselves. And then because of the assurances you get from type safety, you can be a lot more confident that when you're using the type at any point in your domain, that it has valid values, right? You don't have to recheck these things more frequently. So that's something I've found that's a bit different compared to other languages where you might have a view model and a repo model, etc. You know, different models for each level of your domain. In Rust, sometimes there is benefit to, using the model as much as possible across your domain because you keep that same validation, the same logic that ensured you constructed a valid type in the first place. You parsed it once and you don't have to validate it over and over again. Yeah, it creates that trust that you want as a developer, right? It allows you to not have to think about, oh, is this value valid here within my type? And when you built out a user service, how much did the compiler influence your architecture? I think that building out the user service, It was also a really good first project for us in Rust. It's taught me a lot that has made it easier, I think, to try and write more, idiomatic Rust, or at least idiomatic in my opinion, after the work we've done there. I think having a project that is quite similar to something you might experience in a lot of other languages, this API that stores user information, is really a good way to learn. So I think that it's been very beneficial there. And I think a lot of these lessons about the new types, you know, not fighting against the compiler, I think a lot of this has come from our experience of working with Rust in the user service. What came before the Rust user service? Was there a service in production that did the thing? Before Rust? No, not exactly. We have a platform that we use and still use for other parts of the stack where a lot of the student data was effectively associated to the phone number that they were using on WhatsApp. And so that meant there was sort of a tight coupling between phone and student. And it also meant that when, let's say, a lesson is starting, it's not that, you know, Dylan can just grab any phone and go with Rori. It means Dylan's got to get Dylan's phone if he wants to continue from where Dylan was working and Matthias needs to get Matthias's phone right so I think, a big thing as well with the like flexibility of the phones beyond just being able to scale the impact is also making the implementation on the ground easier right and that's one thing I've really, enjoyed working at Rising is seeing a lot more of that actually what's going on on the ground and being more aware of that because we have because we have the benefit of being able to visit our schools, speak to people who are working in these schools, working with the teachers, doing the implementations for Rori and a lot of the other projects that Rising works with. Are there other things you've learned before that you've brought to Rust? Yeah, I think one of the things that I learned in the first job that I was working in, where we were building an API platform for public transport data, was around API testing and building really solid APIs. And I think that also helped me a lot with the work that we were doing on the user service. I think one of the things we did there was we used Postman a lot for writing the kind of like end-to-end integration tests. And thankfully, since then, I found the project called Bruno, which is a kind of open source version of a lot of what Postman are doing. And it allows us to write really nice tests in a very readable format for end-to-end testing of the API. So I think that's been really nice for integrating into CI. As well as sometimes even just using with like these AI coding tools, because quite frankly, a lot of it does end up being a bit of like copy paste some boilerplate stuff to go make this Bruno test, you know, call the API, but with some different details for the user, right? When you're wanting to create them. And so I think those Bruno tests have been really nice to help us with confirming things work in the way that we want from an end to end side. So one thing that Rust doesn't give us is if we change things about the type that, let's say, causes the API response to change, Rust is not really going to tell us that the API response has changed. But the way that our stack works is that the service that interacts with the user service is a lot more dependent on the JSON structures not changing. So Bruno gives us a way to confirm that the JSON responses and requests conform to what is expected it gives us that extra safety on top of all the safety we have from within the Rust ecosystem. Even though the compiler is very strong it's not enough you need to have that additional security or maybe safety net. I like that approach. And let's talk about the wider context. How is the user service integrated into the entire flow? Do you talk directly to it from WhatsApp? Is there anything in between? So Rori was first built with the Turn.io platform. So at the moment, that's handling a lot of our conversational logic. And it's kind of the hub of the whole system, right? So from that platform, we call various different services. So we have CMS that stores a lot of the content that students work their way through, right? We have an answers API that can help with classification of if a student's answer is correct or incorrect, obviously very important for their practice. And then we have the user service, which has grown from what we first built it for, which was helping to identify students. And I think one of the interesting things about identifying students is you can't really just use like a username password, especially over something like WhatsApp, right? And there's also kids, kids don't, aren't going to remember a password. And nobody wants to deal with having to reset the passwords for 20 kids every time. And if you don't do it fast enough, well, they've lost out on their whole Rori session. So we had to build a way to identify them based on things that they will remember about themselves, right? So once again, having teams that could go, into the field, speak to kids, do some research and figure out what it is that we want to ask them about themselves that they can use to identify themselves in their subsequent sessions was also really important. So students can identify themselves with their first name, surname and a bunch of other information that they usually know about themselves, right? So the user service helps us match the students because their answers are usually not always the same exactly over time. And then it helps us track their activity, what they're doing within the content that I referred to, to enable us to both resume where they were before, as well as to help us do analytics on both our content and Rori's approach generally to see how students are progressing over time. Which is also a very important thing for us, as a lot of our work also involves putting out research about the work that we're doing and what actual impact we're making on the student's education. What was your experience deploying the user service to production? I think for most part, the user service deployment and running it in production has been pretty smooth. We haven't really encountered any major crashes. The service has always been very performant, both in terms of cost and latency for responses. But I think one of the challenges we had is that we were not being permissive enough with the barrier between other services and Rust, right? So going back to the validation and the types, we were being a bit too strict in our validation. And if something goes wrong on the client side for the API, then you might reject something from the server side, which you don't actually want to reject. Because if, in our case, if students are doing activity, we kind of want to always store that, right? So we were missing some activity because we were being a bit too strict with our validation. It was useful in a sense that it helped us find the bug on the client side and, things like Sentry logs shouting at us for 400s was very useful. And you might think, well, you don't really need to log 400s on the server side. But the challenge we had is we couldn't really log those on the client side. So we had to do a little bit of finagling with our Sentry implementation to get it to let us know about those things. So that was useful. But it was also kind of a challenge. And it's where you have to think a little bit more about how the strictness of the Rust side integrates with the wider tech stack as well. So I think that even though you can be confident about the safeties and guarantees that Rust provides you, a lot of the most difficult parts are at the boundaries. Whether that's interacting with the clients that are dealing with your API or the database structures that you have to deal with mapping between maybe the Rust enum types and types that you can store in the database. What's next for Rust at Rising? So we're definitely pursuing more Rust at Rising. We're building out new parts of the tech stack that we've wanted to improve for a while with Rust. And we're also considering porting over other parts of the tech stack to Rust. I think that going back to my earlier point, Rust has some unique benefits for us in the African context. And that's like a big part of what I would like to see, right? We deal with a lot of unique challenges in Africa, one of which, for example, is in a lot of the schools that we work with, internet connection can be very inconsistent. So one thing that's a personal dream of mine would be to be able to build something like Rori that can actually be completely offline, right? So running on a device that other devices can connect to, right? It's a kind of Wi-Fi, internal Wi-Fi that doesn't require internet connection. So I think for me, being able to build more of our tech stack in Rust, makes it more possible for us to pursue that at some point in the future because Rust is well-suited to these kind of embedded systems and to running on low-resource devices. Yeah, that sounds pretty clever because that's precisely where Rust shines. You want the stability, you want the robustness because... Potentially, you don't have that many chances to do any updates on those devices once they get deployed. Yeah. And I think, you know, we see Rust used in a lot of interesting and niche ways. A lot of folks that you've spoken to on the podcast, they've been really interesting to learn about how they're using Rust. But for me, I think there's a lot of these unique challenges that we face in Africa that are really well suited to using Rust and what we can actually build with Rust. Can you elaborate on that? Where do you see Rust in Africa? I think increasingly a lot of places are talking about tech sovereignty, both in Europe and in Africa, right? And I think that if we want to be hosting tech in Africa and building for an African context, I think Rust is really well suited to that because it doesn't require us to be spending as much money, you know, on the actual resources to run these projects, right? The raw compute power required is less. And that enables us to be better aligned with the impact on the climate, the impact on communities where you have these data centers that would be needed to run these kind of projects that are running in the cloud, as well as, as I mentioned, the ability for us to run more offline in places where we can actually provide technology where the infrastructure for like internet connection is not quite there yet. How easy would it be to recruit for rust development in Africa? I think at Rising, we generally favor hiring folks on the continent who have that context for the unique challenges in Africa. It isn't really the case that there's like big established communities of Rustaceans for us to necessarily hire from in Africa. There is a lot of folks doing some interesting work trying to grow those communities. But I think for me, it's less about hiring somebody who already has Rust experience and more trying to hire thinking about that mindset that I was talking about. So it might not be that they have experience with C++ or some of these technologies as well, because you're going to find a lot more Python developers, for example. But looking at how they go about that work, like what the mindset is that they have towards the code that they ship, those are really the things that I look out for in the hiring process. Seems like there's a lot of momentum. What if someone's listening right now and thinks, oh, I would like to help? I think for us, we're always looking for ways to reach our North Star goal, right? Of impacting the education of one and a half million students across Africa. One of the effective ways for us to scale our impacted rising is partnering with governments and philanthropic funders in order to help projects like Rori, and Tari reach more people, right? So I think we're always interested in anyone who can be involved in those kinds of things. Like we have a very small pilot happening in The Gambia that's just one school, but a really great person has been working with Rising to run and getting the government there really excited. So... Particularly to folks in Africa, you never know if you can help spread what we're doing and help improve the educational outcomes for kids on the continent. I hope that more people will rise to the occasion. We talked about Rust in Africa, and that's a nice segue into the traditional last question of the episode, which is, what's your wider message to the Rust community? I think for me, the key thing is that we should be expanding our vision for where we see Rust being used, right? What we're doing at Rising is not the most unique case of using Rust. It's not a typical systems programming use case or something like that. It's, you know, a relatively standard API service. I think what we should be doing as the Rust community is spreading the use of Rust by being more inclusive, by including more wider uses of Rust beyond just making the argument for, oh, this is a systems programming language and it does systems programming things really well. Well, actually, what it does really well can be impactful for a lot of cases, right? Exactly what we're talking about, the sustainability, not only in terms of the cost and compute and the environment, but also just in terms of the developer work, right? But I think what we need to do as a Rust community is be more inclusive about where we use Rust to position it as a tool for building reliable, sustainable, maintainable systems for years to come, right? Education is a long game, and this is a great example of where we can use Rust in a very valuable way. Perfect. Thanks for the interview, Dylan. Thanks. Rust in Production is a podcast by corrode. It is hosted by me, Matthias Endler, and produced by Simon Brüggen. For show notes, transcripts, and to learn more about how we can help your company make the most of Rust, visit corrode.dev. Thanks for listening to Rust in Production.