WEBVTT 00:00:01.930 --> 00:00:06.550 Welcome to Rust in Production, a podcast about companies who use Rust to shape 00:00:06.550 --> 00:00:07.870 the future of infrastructure. 00:00:08.140 --> 00:00:12.470 I'm your host, Matthias Endler, and today we talk to Dylan Brown from Rising 00:00:12.470 --> 00:00:16.300 Academies about bringing Rust to schools in Africa. 00:00:19.560 --> 00:00:25.090 Dylan, thanks so much for being on the show today. Please say a few words about yourself. 00:00:26.070 --> 00:00:30.220 Hi, Matthias. Thanks. My name is Dylan Brown. I'm a South African developer. 00:00:30.220 --> 00:00:33.810 I've been working primarily with C# for over 10 years. 00:00:34.080 --> 00:00:38.720 A lot of work in .NET, a lot of work building chatbots in particular over the 00:00:38.720 --> 00:00:43.040 last eight or so years, primarily in spaces like fintech. 00:00:43.420 --> 00:00:47.900 And then in the last two years, I suppose, I've been working more heavily with 00:00:47.900 --> 00:00:50.160 Rust at the organization that I'm at now. 00:00:50.710 --> 00:00:51.370 Which is? 00:00:52.220 --> 00:00:58.580 That's Rising Academies. So Rising Academies is an educational organization, 00:00:58.580 --> 00:01:04.350 so not a tech company first. Rising started in 2014 in Sierra Leone, which is in West Africa. 00:01:04.990 --> 00:01:08.860 And we spent over a decade developing and refining an approach that improves 00:01:09.280 --> 00:01:10.910 classroom practice and student learning. 00:01:11.770 --> 00:01:17.440 As I said, it's not a tech company, so most of the company is not from a tech background. 00:01:17.640 --> 00:01:22.110 A couple of years ago, we added more education technology or edtech. 00:01:22.340 --> 00:01:26.890 Into our offerings to support our mission of impacting the learning of one and 00:01:26.890 --> 00:01:28.580 a half million students across Africa. 00:01:28.850 --> 00:01:33.160 So we've been trying to take everything we've learned from having physical schools 00:01:33.160 --> 00:01:37.470 on the ground across West Africa through crises like Ebola, COVID, 00:01:37.890 --> 00:01:42.390 all of that, and to try and take that and see what we can, 00:01:43.050 --> 00:01:45.960 build that actually helps education all across Africa. 00:01:45.960 --> 00:01:50.570 So these days, we're also partnering with governments across the continent and 00:01:50.570 --> 00:01:52.850 building out these edtech products. 00:01:53.350 --> 00:01:58.430 And that's where I come in. So I'm the senior engineering manager for Rori and Tari. 00:01:59.210 --> 00:02:05.010 So Rori is a math chatbot, which is delivered to students in schools through WhatsApp. 00:02:05.610 --> 00:02:11.030 It's operating in schools across seven countries, primarily in Western East Africa. 00:02:11.510 --> 00:02:17.670 And then Tari is a teacher-facing chatbot, which aims to use a lot of our learnings, 00:02:17.670 --> 00:02:21.700 about teacher training to help with teacher professional development across 00:02:21.700 --> 00:02:26.020 the whole continent. So being used a lot, very widely across the continent. 00:02:26.400 --> 00:02:32.590 So explain to me how that part works. You said that students use it via WhatsApp, 00:02:32.990 --> 00:02:35.990 but what is the typical workflow? 00:02:36.810 --> 00:02:41.400 Sure. So Rori, we found the most success with in terms of student learning by 00:02:41.750 --> 00:02:44.400 having Rori deployed in schools. 00:02:44.540 --> 00:02:50.400 So usually classes will cycle between some phones that are shared. 00:02:50.880 --> 00:02:55.120 So you might have a school of 250 students and maybe 50 phones, 00:02:55.660 --> 00:02:58.590 and they will have maybe one session a week with Rori. 00:02:59.060 --> 00:03:03.330 And those sessions with Rori are focused on practicing their math skills. 00:03:03.330 --> 00:03:08.940 So the main key loop in Rori is students getting math questions, answering them, 00:03:09.420 --> 00:03:14.270 having those evaluated by our systems on our side, and returning back to the 00:03:14.270 --> 00:03:17.100 user, either if they've got it correct, moving on to the next one, 00:03:17.540 --> 00:03:21.520 giving them hints if they've got it wrong, basically helping them do that math practice, which, 00:03:22.040 --> 00:03:27.700 students don't typically get a lot of in a typical kind of call and response classroom. 00:03:28.620 --> 00:03:30.540 Where a teacher is just standing there. 00:03:30.540 --> 00:03:35.300 And, you know, the occasional student gets to come up and write on the blackboard the answer, right? 00:03:35.450 --> 00:03:39.220 So one of the key things with Rori has been that ability for students to actually 00:03:39.220 --> 00:03:40.520 practice their math skills. 00:03:41.130 --> 00:03:45.190 Anecdotally, we hear a lot from students about their growing confidence in maths 00:03:45.190 --> 00:03:49.560 and kind of overcoming those barriers in terms of fear of mathematics. 00:03:50.120 --> 00:03:55.450 So that's a lot about how the kind of key loop of Rori works and how it works in schools. 00:03:56.030 --> 00:04:00.890 The key other observation from Rori is that it's really about trying to get 00:04:00.890 --> 00:04:02.280 students to the right level. 00:04:02.760 --> 00:04:07.630 So once again, the difference with a classroom is you have to be teaching the 00:04:07.630 --> 00:04:09.180 same content to everyone in the class. 00:04:09.680 --> 00:04:13.040 And with Rori, because individuals are practicing themselves, 00:04:13.420 --> 00:04:15.530 they can be practicing at all different levels. 00:04:15.530 --> 00:04:19.380 So you can see a class where you have students practicing everything from grade 00:04:19.380 --> 00:04:25.370 two to grade nine in level of maths skills that they're practicing as well. 00:04:25.370 --> 00:04:30.720 So, yeah, those are the two key benefits with Rori in an African context in schools. 00:04:31.240 --> 00:04:35.940 It's getting students to practice that maths and actually practice the skills 00:04:36.380 --> 00:04:38.340 and making sure that they're practicing it at the right level. 00:04:38.870 --> 00:04:43.680 Now, of course, an obvious question might be, why don't you use laptops for that? 00:04:44.080 --> 00:04:47.670 Why phones and why a chatbot via WhatsApp? 00:04:48.310 --> 00:04:53.830 Yeah, I think from like a traditional ed tech that we've seen in like the Western 00:04:53.830 --> 00:04:59.780 world or in Europe, you might expect it to be laptops or tablets. 00:05:00.460 --> 00:05:05.400 But practically, when you're coming into a space where a lot of schools in Africa 00:05:05.400 --> 00:05:09.440 don't have computers at all or they have no real computers, 00:05:10.360 --> 00:05:16.240 tech devices a phone is often the easiest way to get these kind of technologies 00:05:16.240 --> 00:05:20.020 into these schools right and it's mechanism that's easy for kids to, 00:05:20.940 --> 00:05:26.470 learn to use we've seen kids who have said they've not really had any experience 00:05:26.470 --> 00:05:31.980 to phones being able to quite easily learn to use whatsapp right and learn to 00:05:31.980 --> 00:05:35.220 interact with Rori and i think also once again, 00:05:35.960 --> 00:05:41.780 in terms of the technology you see across africa mobile phones are by far the 00:05:41.780 --> 00:05:47.020 most ubiquitous form of technology and whatsapp is by far the biggest, 00:05:47.600 --> 00:05:51.580 chat platform so when it comes to like the teachers being familiar with whatsapp, 00:05:52.160 --> 00:05:56.760 and just everyone having more context for what it is it makes it a lot easier, 00:05:57.500 --> 00:06:02.110 for us to overcome any of those kind of barriers and those learnings in the schools as well. 00:06:02.600 --> 00:06:04.050 What's your Rust production story? 00:06:04.530 --> 00:06:10.580 So a couple of years ago, we wanted to build out a service in order to enable 00:06:10.580 --> 00:06:14.980 us to better scale the use of Rori in schools, right? I mentioned earlier that, 00:06:15.460 --> 00:06:17.660 you will have students switching phones. 00:06:18.100 --> 00:06:23.400 So we needed a way to store a lot of the student information off the platforms that we were using. 00:06:24.000 --> 00:06:28.050 And so we needed to build out effectively a student service. 00:06:28.050 --> 00:06:31.390 And so that's where we decided to build out a service in Rust that we call the 00:06:31.390 --> 00:06:35.780 user service. That's more broadly because it also stores teacher data for Tari. 00:06:36.580 --> 00:06:41.270 There's nothing particularly special about it. It's a relatively straightforward 00:06:41.270 --> 00:06:43.880 API service using axum and SQLX. 00:06:44.580 --> 00:06:50.740 But the key thing that it enabled for us is this ability for students to share phones. 00:06:50.740 --> 00:06:55.670 So in order to have 200 students at a school using Rori, we no longer have to 00:06:55.670 --> 00:06:58.180 have 200 phones in that school, which can be quite expensive, 00:06:58.560 --> 00:07:03.920 we can do that with now 50 phones or 20 phones, depending on how the scheduling works in the school. 00:07:04.440 --> 00:07:08.530 Someone might listen to that and think, well, you could do that with any other 00:07:08.530 --> 00:07:12.490 technology. You could use Python, for example, or TypeScript. 00:07:12.900 --> 00:07:15.130 So I think my question would be, why Rust? 00:07:15.780 --> 00:07:21.230 True. There is nothing special about our use case that makes it explicit for Rust. 00:07:21.230 --> 00:07:25.870 I think for us, when we're thinking about the choice to use Rust, 00:07:25.870 --> 00:07:30.570 we're thinking a lot about what is it about our context that's actually the 00:07:30.570 --> 00:07:33.390 most relevant thing, right? I think a phrase that comes to mind a lot for me 00:07:33.390 --> 00:07:34.760 is education is a long game. 00:07:35.080 --> 00:07:37.880 We want to be building something that is sustainable, that is going to stick 00:07:37.880 --> 00:07:41.740 around and be with these kids for their learning in the long run. 00:07:42.560 --> 00:07:46.560 And I think another thing is that at Rising, we have the rising way, 00:07:46.560 --> 00:07:48.800 we call it, our principles that we live by. 00:07:49.340 --> 00:07:54.550 And one of those is we do more than anyone thought possible with less than anyone thought possible. 00:07:54.740 --> 00:08:00.340 And I think the key thing for people to understand is that this speaks to the. 00:08:01.180 --> 00:08:06.080 To working with limited resources in Africa, right? Especially in education, unfortunately. 00:08:06.740 --> 00:08:10.810 And it shouldn't be like this. Obviously, we would love for there to be a lot 00:08:10.810 --> 00:08:14.960 more resourcing for education, but that is not entirely within our control, 00:08:14.960 --> 00:08:18.580 right? So what we can control is what we can do with what we have. 00:08:18.920 --> 00:08:23.970 And I think that's a principle broader within Rising, not just specifically 00:08:23.970 --> 00:08:27.320 to our choice for Rust, but it does lean us in that direction, 00:08:27.320 --> 00:08:31.780 right? We want to make sure we're making a long-term impact with a relatively small team. 00:08:32.420 --> 00:08:37.000 And importantly, we also want to make sure we're controlling costs in a reasonable way, right? 00:08:37.500 --> 00:08:41.970 So when it comes to compute costs for a service, for example, 00:08:41.970 --> 00:08:46.360 the user service, I did a calculation the other day, was about 25 times cheaper 00:08:46.360 --> 00:08:52.290 than a comparably active service that we have that's been built with Python and Django. 00:08:52.720 --> 00:08:58.290 So those costs really rack up over the long run in order to make sure that we 00:08:58.290 --> 00:09:00.760 can keep having more and more students using Rori. 00:09:01.180 --> 00:09:03.480 So I think that side of things really matters. 00:09:03.920 --> 00:09:09.830 And I think another thing for me that's very important is the impact of the 00:09:09.830 --> 00:09:14.320 work that we do on the environment as well, right? So I think Rust in terms of. 00:09:15.320 --> 00:09:21.140 Compute, it helps you have your cloud services cost less, but that's also because 00:09:21.140 --> 00:09:24.510 they're using less electricity, you're using less resources. 00:09:25.070 --> 00:09:30.120 And Africa is unfortunately a continent that is going to be bearing the brunt 00:09:30.120 --> 00:09:35.040 of a lot of the environmental change that we see as a result of climate change. 00:09:35.040 --> 00:09:40.050 So I think inspired by a talk from Rust Lab a couple of years ago, 00:09:40.730 --> 00:09:44.550 I think a big reason for us is also making sure that we are doing something, 00:09:45.050 --> 00:09:50.110 that is not only helping the students with their education, but also with the 00:09:50.110 --> 00:09:51.250 communities that they live in. 00:09:51.870 --> 00:09:56.940 And I think being smart about the resources that we use for what we build is 00:09:56.940 --> 00:09:58.050 an important aspect of that. 00:09:58.630 --> 00:10:04.300 What went into that cost calculation between the Django app and the Rust application? 00:10:04.970 --> 00:10:09.540 So that cost calculation is primarily just the hosting costs on GCP for the 00:10:09.540 --> 00:10:14.090 API service that I was comparing there, I think, you know, there are other costs 00:10:14.430 --> 00:10:16.850 that we want to be aware of, right? 00:10:17.770 --> 00:10:21.580 When we're building out these services, there's obviously costs in terms of 00:10:21.580 --> 00:10:26.430 team salaries and the time that we spend, therefore, on these services that 00:10:26.430 --> 00:10:27.530 we're building out, right? 00:10:28.550 --> 00:10:34.580 What we also want to do is make sure that we're using the time of the team efficiently, right? 00:10:34.760 --> 00:10:39.430 And a key to that is making sure that we can be building new features and not, 00:10:39.430 --> 00:10:41.600 you know, firefighting production issues. 00:10:41.600 --> 00:10:45.150 And I think Rust has some clear benefits for that, right? 00:10:45.150 --> 00:10:49.060 In terms of making us able to trust that what we ship is solid, 00:10:49.880 --> 00:10:54.150 as well as in terms of being solid for student experience, right? 00:10:54.150 --> 00:10:59.370 I mentioned earlier the scenario where you have maybe 50 phones and 250 students. 00:10:59.370 --> 00:11:04.460 So if one student has their Rori session once a week, if Rori is down for half 00:11:04.460 --> 00:11:07.280 an hour and it happens to coincide with that student's session, 00:11:07.280 --> 00:11:09.720 then they've missed out on a whole week of their learning, right? 00:11:10.260 --> 00:11:13.240 And the education calendar is already very packed. 00:11:13.740 --> 00:11:18.560 So missing out on a week of any kind of education can be very impactful to students. 00:11:18.560 --> 00:11:23.690 So we also need to make sure that it's solid in terms of stability for making 00:11:23.690 --> 00:11:29.490 sure that that, you know, the cost of everything for the impact it makes on 00:11:29.490 --> 00:11:32.550 the students' learning is also taken into consideration. 00:11:33.270 --> 00:11:36.560 What does Rust mean for you in an engineering leadership role? 00:11:36.850 --> 00:11:41.450 Yeah, I think that's one of the other things that informed my decision to push for our use of Rust. 00:11:41.810 --> 00:11:46.540 I think for me, as an engineering leader, in other languages like Python or 00:11:46.540 --> 00:11:48.550 C#, I find myself a lot of the time being like, 00:11:49.280 --> 00:11:51.840 kind of annoying person on the code review who's like, okay, 00:11:51.840 --> 00:11:55.540 what happens when we return this null at the call site, right? 00:11:55.980 --> 00:12:01.350 And I think Rust makes it a lot easier for me to just focus on the business 00:12:01.350 --> 00:12:04.620 logic, to focus on what really matters when I'm doing a code review and not 00:12:04.620 --> 00:12:08.400 have to worry about like, have we caught this exception everywhere that this 00:12:08.400 --> 00:12:10.650 function is called when we add an exception here? 00:12:10.650 --> 00:12:12.950 Or like, have we handled the null? 00:12:13.410 --> 00:12:15.690 Because I know that the compiler does those things for me. 00:12:16.290 --> 00:12:21.070 So I think being able to almost create those kind of, 00:12:21.690 --> 00:12:25.090 systems within the code itself that the compiler enforces, right, 00:12:25.090 --> 00:12:29.270 using the type system in particular really makes it such that my, 00:12:29.810 --> 00:12:34.520 technical contributions get enforced in a way that doesn't just have to be me 00:12:34.520 --> 00:12:38.150 on a code review, and I can focus on the more substantive things. 00:12:38.740 --> 00:12:42.220 If I remember correctly, your background is in C#, 00:12:42.920 --> 00:12:48.320 Now, if you look at it from this perspective, you come from maybe C# and 00:12:48.320 --> 00:12:50.100 then you transition to Rust. 00:12:50.100 --> 00:12:56.390 How does that change your perception of what robustness means and what were 00:12:56.390 --> 00:12:59.890 your experiences when using Rust from that background? 00:13:00.380 --> 00:13:05.180 I think for me, a lot of it was about what I didn't have to worry so much about. 00:13:05.820 --> 00:13:11.680 So I think I also had learned some C++ and those kind of languages in university. 00:13:11.680 --> 00:13:17.730 So I had some understanding of like memory management and pointers and things like this from C++. 00:13:18.910 --> 00:13:22.910 But primarily I found in C# a lot of the time what you're worrying about, 00:13:23.490 --> 00:13:28.170 is memory leaks in production or you're worrying about null references or is 00:13:28.170 --> 00:13:29.610 this exception being handled. 00:13:30.770 --> 00:13:33.960 I think a lot of the challenge sometimes with C# is it does provide you 00:13:33.960 --> 00:13:37.830 a lot of groundwork to build a lot of really solid applications. 00:13:38.170 --> 00:13:42.790 But there's a lot of those edges that you kind of have to keep in your mind 00:13:42.790 --> 00:13:44.970 all the time that Rust allows you to, 00:13:45.590 --> 00:13:50.940 basically let go of and not worry so much about because the compiler is stricter 00:13:50.940 --> 00:13:55.170 and enforces a lot of these things, right? The memory safety is more a function of, 00:13:55.800 --> 00:13:59.570 Not having to be in my working memory than having to worry too much about the 00:13:59.570 --> 00:14:02.180 actual impact of memory leaks, for me at least. 00:14:02.540 --> 00:14:06.610 And what would you say about the tooling story comparing C# and Rust? 00:14:07.070 --> 00:14:12.540 I think C#, there's a lot of, especially in the .NET environment, 00:14:12.540 --> 00:14:19.760 there's a lot of tooling that is just very much built for enterprise software out of the box, right? 00:14:19.760 --> 00:14:24.090 That's like really the environment that most C# devs are working in. 00:14:24.090 --> 00:14:28.990 And I think that's the reason C# has been as prolific as it has, 00:14:28.990 --> 00:14:31.030 especially in areas like fintech. 00:14:31.530 --> 00:14:36.570 I think Rust does make you sometimes do more of that yourself. 00:14:37.070 --> 00:14:41.640 But I think if you know where you're going, that can be a lot easier, 00:14:41.640 --> 00:14:46.790 right? So I think some of the challenges we had in C# was trying to work 00:14:46.790 --> 00:14:50.130 against some of these frameworks and these tooling that we were using. 00:14:50.730 --> 00:14:55.650 Whereas in Rust, we are having to be more explicit about those decisions ourselves. 00:14:56.230 --> 00:15:00.300 And so we're a lot more in control of that rather than having to, 00:15:00.570 --> 00:15:03.800 you know, fight against that ecosystem, so to speak. 00:15:04.390 --> 00:15:09.240 I think one of the challenges sometimes with the Rust tooling for somebody coming 00:15:09.240 --> 00:15:14.590 from another language is maybe not having all that stuff immediately obvious to you. 00:15:14.920 --> 00:15:19.760 So for example, you know, we had a lot of success using X tasks for things that 00:15:19.760 --> 00:15:23.390 would normally be like scripted things you would write Python scripts for, 00:15:23.390 --> 00:15:27.680 So you might think, okay, I'm moving into this language, or I can't do these 00:15:27.680 --> 00:15:29.400 things that I do in Python that are really easy. 00:15:29.400 --> 00:15:33.190 But often there are ways to do these things. And sometimes the challenge is 00:15:33.190 --> 00:15:37.410 just figuring that out and figuring out how to do that, because you won't find 00:15:37.410 --> 00:15:44.060 as many YouTube videos or podcasts about Rust as you will about Python or other languages. 00:15:44.470 --> 00:15:48.520 Rust has a famously steep learning curve. I would like to pick your brain on this. 00:15:49.140 --> 00:15:53.520 Is it really that hard for a new team to get started with Rust? 00:15:53.790 --> 00:15:58.460 Yeah, I think it was something that was a bit intimidating at first and has 00:15:58.460 --> 00:16:01.670 been a bit intimidating for some folks in the team. 00:16:02.100 --> 00:16:06.620 But I think what I've really come to realize is that learning Rust isn't about 00:16:06.620 --> 00:16:08.600 learning all the details of 00:16:08.600 --> 00:16:12.440 the borrow checker or learning all the details about how lifetimes work. 00:16:12.930 --> 00:16:17.970 At least for our case learning rust is a lot more about the mindset right that 00:16:17.970 --> 00:16:21.770 goes into writing rust code so i think that's something that i've learned, 00:16:22.370 --> 00:16:28.390 is probably the better way to approach learning rust in a way that's less scary than having to, 00:16:29.050 --> 00:16:34.280 learn all these hard concepts up up front more learning about why why would 00:16:34.280 --> 00:16:37.470 i want to write this in rust right and those are things like, 00:16:38.250 --> 00:16:40.010 the type system, obviously, 00:16:40.550 --> 00:16:45.310 that can give you a lot of safety in what it is that you're writing. 00:16:46.210 --> 00:16:51.130 If you are used to writing code in a way where you care about types, 00:16:51.530 --> 00:16:55.880 like using something like Pydantic and Python, then it becomes much easier to 00:16:55.880 --> 00:16:58.130 transfer that mindset into Rust, right? 00:16:58.130 --> 00:17:01.330 Where you don't really have a choice but to care about types most of the time. 00:17:01.810 --> 00:17:10.060 So I think it's those kind of mindsets that are best for somebody who's learning 00:17:10.060 --> 00:17:12.410 Rust, right? I would focus more on. 00:17:15.080 --> 00:17:19.740 I would focus more on those elements of their mindset towards programming rather 00:17:19.740 --> 00:17:23.570 than the specifics of this is how a borrow checker works. 00:17:23.570 --> 00:17:27.790 This is the difference between the stack and the heap or any of these more in-detail, 00:17:28.690 --> 00:17:30.220 technical facts, right? 00:17:30.690 --> 00:17:35.260 I don't know much about C#, but certainly that was a problem with Python 00:17:35.260 --> 00:17:40.610 for me is that types are optional and you can switch them off and you can forget about them. 00:17:40.610 --> 00:17:46.460 And has gotten a lot better in recent years. But yeah, the part about Pydantic, 00:17:48.900 --> 00:17:53.890 resonates with me. You have to bring additional tooling like static analysis 00:17:53.890 --> 00:17:58.300 tooling, linters and so on to get a fraction of the power that you can have 00:17:58.410 --> 00:18:03.290 with Rust. But then again, I don't want to put words into your mouth. Do you agree with that? 00:18:03.890 --> 00:18:08.270 Yeah, I think that for me, when I look at a Python project that doesn't have 00:18:08.270 --> 00:18:11.500 some of that tooling that I like, like Pydantic, for example, 00:18:12.040 --> 00:18:15.160 it just becomes a bit more frustrating, right? 00:18:15.620 --> 00:18:21.410 Like it becomes more frustrating to work with. It becomes easier to just make errors as a team, right? 00:18:21.530 --> 00:18:26.220 Easier to be in a situation where you're now having to firefight issues in production. 00:18:26.640 --> 00:18:33.690 So I think that makes a big difference to me. I think it's also a case of having those types. 00:18:35.000 --> 00:18:38.630 It's also a case of having the type system allows you to build code that is 00:18:38.630 --> 00:18:44.130 also more resilient to change right it makes refactoring easier it also makes 00:18:44.130 --> 00:18:48.220 it a lot clearer about how your code changes over time so, 00:18:49.020 --> 00:18:53.740 being able to map from one type in a previous model to a new type in another 00:18:53.740 --> 00:18:57.320 model is a lot more straightforward with the type system than if you're dealing 00:18:57.320 --> 00:19:01.850 with like stringy types or you're dealing with like json you know raw json. 00:19:01.990 --> 00:19:05.180 You also said that you have some c++ background, 00:19:05.750 --> 00:19:10.540 How much did that help you getting up to speed with Rust? 00:19:11.050 --> 00:19:19.790 I think the C++ background was more just about concepts like pointers and references 00:19:20.090 --> 00:19:22.410 not being very alien to me. 00:19:22.730 --> 00:19:26.150 It was kind of like, oh, right, I kind of remember this from a while ago. 00:19:26.890 --> 00:19:31.450 But at that point, it was like 10 years ago that I'd written any C++ code. 00:19:31.450 --> 00:19:36.490 So I don't know that it made a huge impact. I think it's probably easier for 00:19:36.490 --> 00:19:38.810 somebody who's working more actively in C++. 00:19:39.450 --> 00:19:44.550 But I think even when I'm looking at hiring for somebody that's going to be working with Rust, 00:19:45.310 --> 00:19:50.010 having had them work with C++ at some point, even if it's just in university, 00:19:50.010 --> 00:19:54.470 I think makes a difference because you're having to deal with some of those things. 00:19:56.070 --> 00:19:59.770 You're having to be more aware of memory allocation. You're more aware of pointers, 00:20:00.250 --> 00:20:05.900 and these slightly lower level things than you have to deal with in languages like Python or Java. 00:20:06.390 --> 00:20:12.250 First time I hear about the Rust mindset you need, can you elaborate on that a bit more? 00:20:12.810 --> 00:20:18.110 I think one big thing for folks that I was working with is... 00:20:18.910 --> 00:20:23.190 Helping them to also understand that you can work with the compiler. 00:20:23.190 --> 00:20:26.460 You're not working against it. It's not like an enemy you have to defeat. 00:20:26.910 --> 00:20:31.140 And I think that's also a pitfall that I see a lot of AI tooling tend towards 00:20:31.580 --> 00:20:35.810 is just trying to get past the compiler error, not seeing the compiler as something 00:20:35.810 --> 00:20:37.000 that you're co-building with. 00:20:37.540 --> 00:20:41.920 I think when you have that mindset about the compiler, you start to realize 00:20:41.920 --> 00:20:44.360 where the explicitness is actually valuable. 00:20:44.860 --> 00:20:49.370 So like i'm not a big fan of like underscore match arms and unwrap generally 00:20:49.370 --> 00:20:51.820 i mean they have their place of course and, 00:20:52.500 --> 00:20:55.380 there's nothing wrong with using them if you know what you're doing but i think 00:20:55.380 --> 00:20:58.800 a lot of the times they also become like crutch for, 00:20:59.370 --> 00:21:04.770 bad design so i think a lot of the times it's seeing developers who favor that 00:21:04.770 --> 00:21:09.760 explicitness so you have an enum that you're returning or you have an option. 00:21:10.460 --> 00:21:13.580 It forces that explicitness of okay but what am i going to deal with what am 00:21:13.580 --> 00:21:15.260 I going to do when it's a none, right? 00:21:15.700 --> 00:21:19.780 You don't have these like hidden null refs where maybe sometimes you return 00:21:19.780 --> 00:21:23.830 null and you don't actually remember to deal with it at the call site, right? 00:21:23.830 --> 00:21:28.000 So I think the explicitness there is also valuable. 00:21:28.000 --> 00:21:33.140 So if I see somebody writing some Python code or C# code, 00:21:33.580 --> 00:21:38.560 and they're being explicit about those actions, right? 00:21:38.560 --> 00:21:42.920 Making sure that they are, if they're returning null from something, 00:21:43.200 --> 00:21:46.190 that they're doing it for a good reason, that they're making sure that the call 00:21:46.190 --> 00:21:53.350 site handles it, these kind of things where explicitness really matters and Rust forces that of you. 00:21:53.350 --> 00:21:56.240 So if you have that mindset that you want it to be like that already, 00:21:56.700 --> 00:21:58.450 it makes it a lot easier to work with Rust. 00:21:58.780 --> 00:22:03.380 If I understand the match arms part correctly, what you mean is that if you have... 00:22:04.860 --> 00:22:10.350 A type with three variants, foo, bar, and bass, and bar and bass would evaluate 00:22:10.350 --> 00:22:16.170 to the same return value, you would still write them as separate cases. Is that correct? 00:22:16.610 --> 00:22:21.180 Yeah, I think so. In a lot of cases, I would prefer that because to me, 00:22:21.180 --> 00:22:25.610 it's about, sure, you might have foo, bar, and bass now, but you might want 00:22:25.610 --> 00:22:27.220 to add another variant, right? 00:22:27.580 --> 00:22:31.160 And if you put an underscore match arm to handle foo and bar, 00:22:31.860 --> 00:22:36.630 and then you add Bess instead, you're going to end up handling Bess in the same 00:22:36.630 --> 00:22:40.630 way as foo and bar when you actually maybe wanted to handle it more like Bess. 00:22:40.840 --> 00:22:46.340 So I think it's a lot about that explicitness being valuable for how code changes over time as well. 00:22:46.480 --> 00:22:52.060 That's the real thing that I find can be a bit of a trap with underscore match 00:22:52.060 --> 00:22:55.470 arms and these things that are a little bit more implicit in a way. 00:22:55.830 --> 00:23:02.000 Yeah, because if you add another case and you had an underscore in your match 00:23:02.000 --> 00:23:07.990 arm, then nothing would warn you about that new case. You might forget about it. 00:23:08.470 --> 00:23:09.120 Yeah, exactly. 00:23:09.600 --> 00:23:15.950 And also what I like about that approach is that every case is one line in your diff. 00:23:16.380 --> 00:23:22.770 You can clearly see when you add a new case in the diff, it's not munched together into one. 00:23:23.570 --> 00:23:26.530 Yeah, and I think it means when you do have an underscore match on, 00:23:26.890 --> 00:23:31.070 you really need to ask yourself, like, is it true that for any variants I add 00:23:31.070 --> 00:23:34.910 to this in the future, I also definitely am going to want them handled in this way, right? 00:23:35.510 --> 00:23:40.820 So it makes you have to think a lot more about that rather than just, 00:23:41.150 --> 00:23:45.390 you know, getting the compiler to stop complaining because you've missed some variant in your match. 00:23:45.850 --> 00:23:49.290 Any other recommendations for more robust Rust? 00:23:49.880 --> 00:23:54.410 I think one of the things I've found working with Rust is making use of the new type. 00:23:55.050 --> 00:23:59.250 So not carrying around types that are just like I16s or strings, 00:23:59.770 --> 00:24:01.330 even where they could just be. 00:24:01.910 --> 00:24:08.430 Having new type wrappers around them makes it a lot easier when making changes 00:24:08.430 --> 00:24:11.370 to the code to not make errors. 00:24:15.160 --> 00:24:19.600 It helps you reduce the kind of engineering side errors that are a result of 00:24:19.790 --> 00:24:22.890 maybe mixing up two strings, like a first name and a surname, right? 00:24:23.350 --> 00:24:28.010 And you have these logical errors that you're not really letting the compiler help you in catching. 00:24:28.470 --> 00:24:35.550 So I think new type wrappers around these types, sometimes they can feel a bit painful. 00:24:36.230 --> 00:24:39.410 We now have to name a whole bunch more types, and everyone loves naming. 00:24:40.160 --> 00:24:46.160 But I think that it can really help with the long-term stability as well as 00:24:46.160 --> 00:24:51.060 avoiding some of these logical bugs that can be quite easy to make quite easy errors. 00:24:51.700 --> 00:24:58.640 So, for example, instead of using a number like a U32, you could use a phone 00:24:58.640 --> 00:25:00.720 number type, for example. 00:25:01.180 --> 00:25:05.640 Yeah, I think it's a good way to be explicit also about the way that you expect 00:25:05.640 --> 00:25:07.690 the types to be used going forward, right? 00:25:07.990 --> 00:25:11.740 It's like a form of documentation for the next developer to come along, 00:25:11.740 --> 00:25:14.100 even if that's only you in six months' time. 00:25:14.660 --> 00:25:19.240 Correct. Also helps you with narrowing down the type, which is a thing that 00:25:19.480 --> 00:25:20.750 many people often forget. 00:25:21.280 --> 00:25:28.050 A string is a very wide type with many valid inputs, whereas a message might not be. 00:25:28.750 --> 00:25:30.420 Where does validation belong? 00:25:30.910 --> 00:25:31.990 Yeah, I think that's a good point. 00:25:31.990 --> 00:25:37.720 It does also make it easier to move validation into your types, right? 00:25:38.020 --> 00:25:43.500 One thing that I've really liked is in other languages like C# or a typical, 00:25:43.960 --> 00:25:48.910 domain-driven design approach, you might have some models and you need to validate 00:25:48.910 --> 00:25:51.600 them at the different layers in your domain, right? 00:25:52.180 --> 00:25:57.360 But in Rust, you can kind of attach the validation a lot more to the actual types themselves. 00:25:57.780 --> 00:26:00.420 And then because of the assurances you get from type safety, 00:26:00.740 --> 00:26:05.510 you can be a lot more confident that when you're using the type at any point 00:26:05.510 --> 00:26:08.030 in your domain, that it has valid values, right? 00:26:08.030 --> 00:26:12.150 You don't have to recheck these things more frequently. So that's something 00:26:12.150 --> 00:26:16.690 I've found that's a bit different compared to other languages where you might 00:26:16.690 --> 00:26:20.260 have a view model and a repo model, etc. 00:26:21.060 --> 00:26:24.580 You know, different models for each level of your domain. In Rust, 00:26:24.580 --> 00:26:25.940 sometimes there is benefit to, 00:26:26.820 --> 00:26:31.500 using the model as much as possible across your domain because you keep that 00:26:31.500 --> 00:26:37.260 same validation, the same logic that ensured you constructed a valid type in the first place. 00:26:37.660 --> 00:26:41.640 You parsed it once and you don't have to validate it over and over again. 00:26:42.200 --> 00:26:46.630 Yeah, it creates that trust that you want as a developer, right? 00:26:47.360 --> 00:26:53.320 It allows you to not have to think about, oh, is this value valid here within my type? 00:26:53.940 --> 00:26:59.280 And when you built out a user service, how much did the compiler influence your architecture? 00:27:00.200 --> 00:27:01.970 I think that building out the user service, 00:27:03.030 --> 00:27:06.200 It was also a really good first project for us in Rust. 00:27:06.640 --> 00:27:14.120 It's taught me a lot that has made it easier, I think, to try and write more, 00:27:14.590 --> 00:27:17.270 idiomatic Rust, or at least idiomatic in my opinion, 00:27:19.080 --> 00:27:22.020 after the work we've done there. 00:27:22.020 --> 00:27:26.950 I think having a project that is quite similar to something you might experience 00:27:26.950 --> 00:27:31.080 in a lot of other languages, this API that stores user information, 00:27:31.680 --> 00:27:34.340 is really a good way to learn. 00:27:34.860 --> 00:27:37.860 So I think that it's been very beneficial there. And I think a lot of these 00:27:37.860 --> 00:27:42.400 lessons about the new types, you know, not fighting against the compiler, 00:27:42.400 --> 00:27:47.940 I think a lot of this has come from our experience of working with Rust in the user service. 00:27:48.470 --> 00:27:53.950 What came before the Rust user service? Was there a service in production that did the thing? 00:27:54.510 --> 00:27:55.480 Before Rust? 00:27:56.220 --> 00:28:01.520 No, not exactly. We have a platform that we use and still use for other parts 00:28:01.520 --> 00:28:07.420 of the stack where a lot of the student data was effectively associated to the 00:28:07.420 --> 00:28:09.360 phone number that they were using on WhatsApp. 00:28:09.890 --> 00:28:13.700 And so that meant there was sort of a tight coupling between phone and student. 00:28:14.160 --> 00:28:17.700 And it also meant that when, let's say, a lesson is starting, 00:28:18.160 --> 00:28:21.670 it's not that, you know, Dylan can just grab any phone and go with Rori. 00:28:21.670 --> 00:28:25.230 It means Dylan's got to get Dylan's phone if he wants to continue from where 00:28:25.230 --> 00:28:29.580 Dylan was working and Matthias needs to get Matthias's phone right so I think, 00:28:30.470 --> 00:28:33.970 a big thing as well with the like flexibility of the phones beyond just being 00:28:33.970 --> 00:28:39.650 able to scale the impact is also making the implementation on the ground easier 00:28:39.650 --> 00:28:40.920 right and that's one thing I've really, 00:28:41.480 --> 00:28:45.960 enjoyed working at Rising is seeing a lot more of that actually what's going 00:28:45.960 --> 00:28:51.460 on on the ground and being more aware of that because we have because we have 00:28:51.460 --> 00:28:54.650 the benefit of being able to visit our schools, speak to people who are 00:28:54.950 --> 00:28:58.830 working in these schools, working with the teachers, doing the implementations 00:28:58.830 --> 00:29:01.730 for Rori and a lot of the other projects that Rising works with. 00:29:02.100 --> 00:29:05.450 Are there other things you've learned before that you've brought to Rust? 00:29:05.770 --> 00:29:10.010 Yeah, I think one of the things that I learned in the first job that I was working 00:29:10.010 --> 00:29:13.970 in, where we were building an API platform for public transport data, 00:29:14.090 --> 00:29:17.730 was around API testing and building really solid APIs. 00:29:17.730 --> 00:29:21.310 And I think that also helped me a lot with the work that we were doing on the user service. 00:29:21.760 --> 00:29:27.010 I think one of the things we did there was we used Postman a lot for writing 00:29:27.010 --> 00:29:29.350 the kind of like end-to-end integration tests. 00:29:29.630 --> 00:29:32.300 And thankfully, since then, I found the project called Bruno, 00:29:32.480 --> 00:29:36.460 which is a kind of open source version of a lot of what Postman are doing. 00:29:36.460 --> 00:29:44.210 And it allows us to write really nice tests in a very readable format for end-to-end testing of the API. 00:29:44.510 --> 00:29:47.850 So I think that's been really nice for integrating into CI. 00:29:48.370 --> 00:29:52.240 As well as sometimes even just using with like these AI coding tools, 00:29:52.240 --> 00:29:56.240 because quite frankly, a lot of it does end up being a bit of like copy paste 00:29:56.240 --> 00:30:00.010 some boilerplate stuff to go make this Bruno test, you know, 00:30:00.510 --> 00:30:03.860 call the API, but with some different details for the user, right? 00:30:03.860 --> 00:30:04.850 When you're wanting to create them. 00:30:05.350 --> 00:30:11.940 And so I think those Bruno tests have been really nice to help us with confirming 00:30:11.940 --> 00:30:14.570 things work in the way that we want from an end to end side. 00:30:14.570 --> 00:30:20.650 So one thing that Rust doesn't give us is if we change things about the type 00:30:20.650 --> 00:30:24.990 that, let's say, causes the API response to change, Rust is not really going 00:30:24.990 --> 00:30:27.020 to tell us that the API response has changed. 00:30:27.020 --> 00:30:33.100 But the way that our stack works is that the service that interacts with the 00:30:33.100 --> 00:30:38.330 user service is a lot more dependent on the JSON structures not changing. 00:30:38.790 --> 00:30:45.910 So Bruno gives us a way to confirm that the JSON responses and requests conform 00:30:45.910 --> 00:30:51.740 to what is expected it gives us that extra safety on top of all the safety we 00:30:51.740 --> 00:30:53.380 have from within the Rust ecosystem. 00:30:53.920 --> 00:30:57.510 Even though the compiler is very strong it's not enough you need to have that 00:30:57.910 --> 00:31:01.180 additional security or maybe safety net. 00:31:02.550 --> 00:31:03.490 I like that approach. 00:31:04.170 --> 00:31:09.720 And let's talk about the wider context. How is the user service integrated into 00:31:09.720 --> 00:31:15.090 the entire flow? Do you talk directly to it from WhatsApp? Is there anything in between? 00:31:15.940 --> 00:31:20.340 So Rori was first built with the Turn.io platform. 00:31:20.550 --> 00:31:24.330 So at the moment, that's handling a lot of our conversational logic. 00:31:24.770 --> 00:31:28.390 And it's kind of the hub of the whole system, right? 00:31:28.570 --> 00:31:33.580 So from that platform, we call various different services. So we have CMS that 00:31:33.910 --> 00:31:37.270 stores a lot of the content that students work their way through, right? 00:31:37.810 --> 00:31:43.750 We have an answers API that can help with classification of if a student's answer 00:31:43.750 --> 00:31:47.320 is correct or incorrect, obviously very important for their practice. 00:31:47.460 --> 00:31:49.990 And then we have the user service, which has grown from what we first built 00:31:49.990 --> 00:31:53.630 it for, which was helping to identify students. 00:31:54.170 --> 00:31:58.610 And I think one of the interesting things about identifying students is you 00:31:58.610 --> 00:32:03.310 can't really just use like a username password, especially over something like WhatsApp, right? 00:32:03.310 --> 00:32:06.770 And there's also kids, kids don't, aren't going to remember a password. 00:32:06.770 --> 00:32:10.970 And nobody wants to deal with having to reset the passwords for 20 kids every 00:32:10.970 --> 00:32:14.240 time. And if you don't do it fast enough, well, they've lost out on their whole Rori session. 00:32:14.640 --> 00:32:18.410 So we had to build a way to identify them based on things that they will remember 00:32:18.410 --> 00:32:19.570 about themselves, right? 00:32:19.570 --> 00:32:22.490 So once again, having teams that could go, 00:32:22.970 --> 00:32:26.920 into the field, speak to kids, do some research and figure out what it is that 00:32:26.920 --> 00:32:31.570 we want to ask them about themselves that they can use to identify themselves 00:32:31.570 --> 00:32:34.670 in their subsequent sessions was also really important. 00:32:34.670 --> 00:32:38.840 So students can identify themselves with their first name, surname and a bunch 00:32:38.840 --> 00:32:42.430 of other information that they usually know about themselves, right? 00:32:42.930 --> 00:32:48.370 So the user service helps us match the students because their answers are usually 00:32:48.370 --> 00:32:50.990 not always the same exactly over time. 00:32:51.550 --> 00:32:56.790 And then it helps us track their activity, what they're doing within the content that I referred to, 00:32:57.270 --> 00:33:02.600 to enable us to both resume where they were before, as well as to help us do 00:33:02.600 --> 00:33:07.130 analytics on both our content and Rori's approach generally to see how students 00:33:07.130 --> 00:33:08.350 are progressing over time. 00:33:08.630 --> 00:33:12.330 Which is also a very important thing for us, as a lot of our work also involves 00:33:12.650 --> 00:33:16.930 putting out research about the work that we're doing and what actual impact 00:33:16.930 --> 00:33:19.220 we're making on the student's education. 00:33:19.470 --> 00:33:22.570 What was your experience deploying the user service to production? 00:33:23.250 --> 00:33:25.630 I think for most part, the user 00:33:25.630 --> 00:33:28.790 service deployment and running it in production has been pretty smooth. 00:33:29.270 --> 00:33:33.630 We haven't really encountered any major crashes. 00:33:34.000 --> 00:33:40.870 The service has always been very performant, both in terms of cost and latency for responses. 00:33:41.340 --> 00:33:46.770 But I think one of the challenges we had is that we were not being permissive 00:33:46.770 --> 00:33:51.210 enough with the barrier between other services and Rust, right? 00:33:51.690 --> 00:33:57.380 So going back to the validation and the types, we were being a bit too strict in our validation. 00:33:57.380 --> 00:34:02.850 And if something goes wrong on the client side for the API, then you might reject 00:34:02.850 --> 00:34:07.290 something from the server side, which you don't actually want to reject. 00:34:07.810 --> 00:34:12.740 Because if, in our case, if students are doing activity, we kind of want to 00:34:12.740 --> 00:34:13.930 always store that, right? 00:34:14.310 --> 00:34:20.790 So we were missing some activity because we were being a bit too strict with our validation. 00:34:21.570 --> 00:34:26.890 It was useful in a sense that it helped us find the bug on the client side and, 00:34:27.510 --> 00:34:33.710 things like Sentry logs shouting at us for 400s was very useful. 00:34:34.030 --> 00:34:38.990 And you might think, well, you don't really need to log 400s on the server side. 00:34:39.710 --> 00:34:43.270 But the challenge we had is we couldn't really log those on the client side. 00:34:43.270 --> 00:34:47.570 So we had to do a little bit of finagling with our Sentry implementation to 00:34:47.570 --> 00:34:50.730 get it to let us know about those things. So that was useful. 00:34:51.330 --> 00:34:56.070 But it was also kind of a challenge. And it's where you have to think a little 00:34:56.070 --> 00:35:03.690 bit more about how the strictness of the Rust side integrates with the wider tech stack as well. 00:35:04.230 --> 00:35:08.840 So I think that even though you can be confident about the safeties and guarantees 00:35:08.840 --> 00:35:12.880 that Rust provides you, a lot of the most difficult parts are at the boundaries. 00:35:12.880 --> 00:35:17.170 Whether that's interacting with the clients that are dealing with your API or 00:35:17.550 --> 00:35:21.540 the database structures that you have to deal with mapping between maybe the 00:35:21.540 --> 00:35:25.060 Rust enum types and types that you can store in the database. 00:35:25.610 --> 00:35:27.330 What's next for Rust at Rising? 00:35:27.450 --> 00:35:33.460 So we're definitely pursuing more Rust at Rising. We're building out new parts 00:35:33.460 --> 00:35:39.150 of the tech stack that we've wanted to improve for a while with Rust. 00:35:39.770 --> 00:35:43.770 And we're also considering porting over other parts of the tech stack to Rust. 00:35:44.490 --> 00:35:51.280 I think that going back to my earlier point, Rust has some unique benefits for 00:35:51.280 --> 00:35:53.100 us in the African context. 00:35:53.100 --> 00:35:56.340 And that's like a big part of what I would like to see, right? 00:35:56.340 --> 00:35:59.770 We deal with a lot of unique challenges in Africa, one of which, 00:35:59.770 --> 00:36:04.430 for example, is in a lot of the schools that we work with, internet connection 00:36:04.430 --> 00:36:06.310 can be very inconsistent. 00:36:06.770 --> 00:36:11.270 So one thing that's a personal dream of mine would be to be able to build something 00:36:11.270 --> 00:36:14.980 like Rori that can actually be completely offline, right? 00:36:15.160 --> 00:36:19.650 So running on a device that other devices can connect to, right? 00:36:19.650 --> 00:36:24.780 It's a kind of Wi-Fi, internal Wi-Fi that doesn't require internet connection. 00:36:24.780 --> 00:36:28.650 So I think for me, being able to build more of our tech stack in Rust, 00:36:29.310 --> 00:36:34.850 makes it more possible for us to pursue that at some point in the future because 00:36:34.850 --> 00:36:41.060 Rust is well-suited to these kind of embedded systems and to running on low-resource devices. 00:36:41.370 --> 00:36:45.990 Yeah, that sounds pretty clever because that's precisely where Rust shines. 00:36:46.200 --> 00:36:49.120 You want the stability, you want the robustness because... 00:36:49.850 --> 00:36:51.760 Potentially, you don't have that 00:36:51.760 --> 00:36:55.880 many chances to do any updates on those devices once they get deployed. 00:36:56.380 --> 00:37:01.560 Yeah. And I think, you know, we see Rust used in a lot of interesting and niche ways. 00:37:01.560 --> 00:37:04.730 A lot of folks that you've spoken to on the podcast, they've been really interesting 00:37:05.110 --> 00:37:07.330 to learn about how they're using Rust. 00:37:07.330 --> 00:37:11.260 But for me, I think there's a lot of these unique challenges that we face in 00:37:11.260 --> 00:37:16.880 Africa that are really well suited to using Rust and what we can actually build with Rust. 00:37:17.180 --> 00:37:21.030 Can you elaborate on that? Where do you see Rust in Africa? 00:37:21.290 --> 00:37:24.830 I think increasingly a lot of places are talking about tech sovereignty, 00:37:25.130 --> 00:37:27.720 both in Europe and in Africa, right? 00:37:27.720 --> 00:37:33.870 And I think that if we want to be hosting tech in Africa and building for an 00:37:33.870 --> 00:37:38.000 African context, I think Rust is really well suited to that because it doesn't 00:37:38.000 --> 00:37:41.730 require us to be spending as much money, 00:37:42.370 --> 00:37:45.700 you know, on the actual resources to run these projects, right? 00:37:45.700 --> 00:37:47.910 The raw compute power required is less. 00:37:48.390 --> 00:37:52.310 And that enables us to be better aligned with the impact on the climate, 00:37:52.310 --> 00:37:56.880 the impact on communities where you have these data centers that would be needed 00:37:56.880 --> 00:38:00.990 to run these kind of projects that are running in the cloud, as well as, 00:38:01.550 --> 00:38:06.630 as I mentioned, the ability for us to run more offline in places where we can 00:38:06.630 --> 00:38:09.410 actually provide technology where 00:38:09.850 --> 00:38:12.880 the infrastructure for like internet connection is not quite there yet. 00:38:13.200 --> 00:38:17.130 How easy would it be to recruit for rust development in Africa? 00:38:17.680 --> 00:38:21.470 I think at Rising, we generally favor hiring folks on the continent who have 00:38:21.470 --> 00:38:24.500 that context for the unique challenges in Africa. 00:38:26.290 --> 00:38:31.920 It isn't really the case that there's like big established communities of Rustaceans 00:38:31.920 --> 00:38:33.810 for us to necessarily hire from in Africa. 00:38:34.270 --> 00:38:38.530 There is a lot of folks doing some interesting work trying to grow those communities. 00:38:38.530 --> 00:38:43.340 But I think for me, it's less about hiring somebody who already has Rust experience 00:38:43.340 --> 00:38:47.230 and more trying to hire thinking about that mindset that I was talking about. 00:38:47.710 --> 00:38:52.850 So it might not be that they have experience with C++ or some of these technologies 00:38:52.850 --> 00:38:57.330 as well, because you're going to find a lot more Python developers, for example. 00:38:57.690 --> 00:39:02.410 But looking at how they go about that work, like what the mindset is that they 00:39:02.410 --> 00:39:07.530 have towards the code that they ship, those are really the things that I look 00:39:07.530 --> 00:39:09.950 out for in the hiring process. 00:39:10.500 --> 00:39:14.740 Seems like there's a lot of momentum. What if someone's listening right now 00:39:14.740 --> 00:39:16.790 and thinks, oh, I would like to help? 00:39:17.230 --> 00:39:22.410 I think for us, we're always looking for ways to reach our North Star goal, 00:39:22.410 --> 00:39:27.720 right? Of impacting the education of one and a half million students across Africa. 00:39:27.940 --> 00:39:31.690 One of the effective ways for us to scale our impacted rising is partnering 00:39:31.690 --> 00:39:37.110 with governments and philanthropic funders in order to help projects like Rori, 00:39:37.810 --> 00:39:39.910 and Tari reach more people, right? 00:39:39.910 --> 00:39:45.420 So I think we're always interested in anyone who can be involved in those kinds of things. 00:39:45.420 --> 00:39:48.830 Like we have a very small pilot happening in The Gambia that's just one school, 00:39:49.310 --> 00:39:53.180 but a really great person has been working with Rising to run and getting the 00:39:53.180 --> 00:39:55.020 government there really excited. So... 00:39:55.690 --> 00:40:01.450 Particularly to folks in Africa, you never know if you can help spread what 00:40:01.450 --> 00:40:07.120 we're doing and help improve the educational outcomes for kids on the continent. 00:40:07.410 --> 00:40:12.110 I hope that more people will rise to the occasion. We talked about Rust in Africa, 00:40:12.700 --> 00:40:18.180 and that's a nice segue into the traditional last question of the episode, 00:40:18.510 --> 00:40:22.430 which is, what's your wider message to the Rust community? 00:40:22.820 --> 00:40:26.430 I think for me, the key thing is that we should be expanding our vision for 00:40:26.430 --> 00:40:28.240 where we see Rust being used, right? 00:40:28.360 --> 00:40:31.880 What we're doing at Rising is not the most unique case of using Rust. 00:40:31.880 --> 00:40:35.940 It's not a typical systems programming use case or something like that. 00:40:35.940 --> 00:40:40.450 It's, you know, a relatively standard API service. 00:40:40.830 --> 00:40:44.280 I think what we should be doing as the Rust community is spreading the use of 00:40:44.280 --> 00:40:50.610 Rust by being more inclusive, by including more wider uses of Rust beyond just 00:40:50.610 --> 00:40:51.730 making the argument for, 00:40:52.250 --> 00:40:56.310 oh, this is a systems programming language and it does systems programming things really well. 00:40:56.690 --> 00:41:01.450 Well, actually, what it does really well can be impactful for a lot of cases, 00:41:01.450 --> 00:41:04.930 right? Exactly what we're talking about, the sustainability, 00:41:05.270 --> 00:41:08.700 not only in terms of the cost and compute and the environment, 00:41:08.700 --> 00:41:11.670 but also just in terms of the developer work, right? 00:41:11.880 --> 00:41:15.260 But I think what we need to do as a Rust community is be more inclusive about 00:41:15.260 --> 00:41:19.560 where we use Rust to position it as a tool for building reliable, 00:41:19.560 --> 00:41:22.910 sustainable, maintainable systems for years to come, right? 00:41:23.230 --> 00:41:25.000 Education is a long game, and 00:41:25.000 --> 00:41:29.120 this is a great example of where we can use Rust in a very valuable way. 00:41:29.570 --> 00:41:32.010 Perfect. Thanks for the interview, Dylan. 00:41:32.730 --> 00:41:33.080 Thanks. 00:41:33.800 --> 00:41:37.390 Rust in Production is a podcast by corrode. It is hosted by me, 00:41:37.770 --> 00:41:40.670 Matthias Endler, and produced by Simon Brüggen. 00:41:40.880 --> 00:41:45.110 For show notes, transcripts, and to learn more about how we can help your company 00:41:45.110 --> 00:41:48.080 make the most of Rust, visit corrode.dev. 00:41:48.240 --> 00:41:50.790 Thanks for listening to Rust in Production.