Matthias: This is Rust in Production, a podcast about companies who use Rust to shape
Matthias: the future of infrastructure.
Matthias: My name is Matthias Endler from corrode, and today we talk to Alexandru Radovici
Matthias: from OxidOS about embedded development and putting Rust back into cars.
Matthias: Hey Alex, welcome to the show. Can you talk a little bit about yourself and
Matthias: about OxidOS, the company that you work for?
Alex: Hi, Matthias. Thank you for the invitation. My name is Alex. I'm the CEO of OxidOS.
Alex: OxidOS wants to provide a new kind of operating system for small ECUs in order
Alex: to make cars safer and the development cycle slower.
Alex: My background is in computer engineering. I have a PhD in computer science and
Alex: have been working in operating systems and compilers for the last 15 years, probably.
Matthias: Maybe for some clarification, what is an ECU?
Alex: An ECU would be an electromechanical component that has a chip on it.
Alex: So it's a small part in a car that is controlled electronically by software.
Alex: The normal device, we would say it's a microcontroller. In the car,
Alex: we would say it's an electronic control unit.
Matthias: Okay, perfect. You say that you have a background in compilers,
Matthias: and i wonder how long is it since you started with rust and started with maybe
Matthias: even low level programming so.
Alex: Low level programming probably in high school
Alex: in the days of windows 90 95 actually
Alex: the days of dos we would do really crazy
Alex: things in dos with rust i'm not
Alex: that old in rust i started it in actually i
Alex: had three attempts to start rust somewhere in 2015 2016
Alex: dropped it because complicated syntax
Alex: tried two years later but didn't have time and finally i did have time during
Alex: the pandemic the pandemic hit us in 2020 i was teaching at university we started
Alex: teaching online which reduced significantly the time that i had to spend the
Alex: university and i started contributing to Doc OS,
Alex: which is an operating system written in Rust. That's how I learned Rust.
Alex: I needed a project, and this one seemed really nice.
Matthias: It's kind of funny that you say that, because not many people have that depth
Matthias: of experience then, and also maybe drop the language in between.
Matthias: So I do wonder, has the syntax changed significantly since your first attempt?
Alex: Yes, it did. Lifetime elision rules were added, and I think the manual was better.
Alex: But most probably I dropped it because I didn't have enough time.
Alex: It was a really, really small side project, which required more time than I could afford.
Matthias: And what did you use before Rust? Probably some C, C++ assembly?
Alex: Not really. I started with Pascal and doing stuff in NASM and Pascal.
Alex: I used Delphi afterwards.
Alex: I did learn C by writing some Linux software. I never learned C++.
Alex: I don't like it. I think it's a nice playground and it was super necessary, but I'm not a fan of C++.
Alex: And knowing compilers, I can have several reasons why not.
Alex: And then I used, surprisingly, Node.js as soon as it came out.
Alex: My previous business was performing remote updates and controlling boards with
Alex: everything written in node.js.
Matthias: And what was so great about node.js that you jumped on it immediately i.
Alex: Was very similar in syntax with c i didn't have to do mandatory indents and
Alex: getting errors that they don't fit like in python i'm not saying python is not
Alex: great it is it just it was not
Alex: easy to fix indent problems and i
Alex: don't know node.js was running everywhere it was running in
Alex: the browser it was running on the computer it was
Alex: really easy and fast to program so we started the previous business with controlling
Alex: boards with writing a client in c and it took us about a month and a half to
Alex: be able to start sending messages on the protocols that we needed in In Node.js, it took us half a day.
Alex: Probably the Node.js ecosystem exploded and you would find modules for everything.
Alex: Some were good, some were bad, but it just worked really nice.
Matthias: Are there any similarities between Node.js and Rust?
Alex: I think there's a lot of them in syntax. If you think of structures,
Alex: if you think of TypeScript and the type system, but this is more or less normal.
Alex: Somehow it was the same foundation or company behind them.
Alex: So they borrowed many things. In the functional part from Node.js, they borrowed it.
Alex: I think so. Of course, they have different purposes.
Matthias: Well, yeah, that's true. But at the same time, when you said Node.js runs on
Matthias: the backend and the frontend in every environment, I was reminded of Rust somehow,
Matthias: because Rust is kind of similar there.
Matthias: You have backend applications, and you can write things all the way to embed
Matthias: it, which is what we talk about today, right?
Alex: Yes, that's why we actually migrated to Rust. So we tried using Go for the previous
Alex: company, and it didn't work very well for several reasons.
Alex: And then when we found Rust, after the pandemic, we said, okay,
Alex: this is something that we want to use.
Alex: And now we have the code base more or less in Rust, and everything fits nicely together.
Matthias: What were some reasons why you dropped Go?
Alex: Package management was really bad. We are talking about 2015 to 2017.
Alex: Package management was bad. they had several package managers none of them worked
Alex: you had a global go variable the project structure was very fixed you needed
Alex: to have a fixed folder in your home directory so there were several reasons
Alex: of project organization i think yeah.
Matthias: These things are mostly fixed by now so i wonder would you go and give go another
Matthias: chance today or would you not but obviously Obviously, you know more about Rust nowadays,
Matthias: but I do wonder if you had a team and you started out fresh without really any
Matthias: Rust background, would you still try with Go or would you nowadays start with Rust right away?
Alex: Uh, that's a difficult question. Probably I'd look at it.
Alex: The idea that you have a garbage collector can be good and bad.
Alex: I mean, it's bad if you have a constraint system, but if you don't have a lot
Alex: of constraints and you can consume a decent amount of memory,
Alex: the garbage collection collector will be way more efficient because it will
Alex: delete memory when it has time, not when it It doesn't have time.
Alex: The second thing in Go, the fact that you don't have to explicitly start threads is not that bad.
Alex: So probably for concurrent programming, I would give Go a try.
Alex: But in the case, if the case were that I wouldn't know Rust and I wouldn't have
Alex: a team that has experience in Rust,
Alex: today I wouldn't choose Go because I have the team that knows Rust and it would
Alex: not be economically wise to do this.
Matthias: How is the support for embedded devices in Go?
Alex: I know there's tiny Go. I saw this at FOSDEM in 2020, but I didn't follow it.
Alex: My understanding is that it's basically some kind of VR TOS modified to be a Go runtime.
Alex: But I might be saying something that's not true anymore. I didn't follow this.
Matthias: Yeah, the two things I learned lately was that they really improved there.
Matthias: Garbage collector times this is one huge thing because that was a blocker back in the day,
Matthias: and then i do think that they need
Matthias: some sort of runtime for an embedded environment there's no other way that i
Matthias: see because of go routines and so on i do wonder though if the runtime itself
Matthias: is limited or if you can write the same go code that you can write in a backend
Matthias: application for example?
Alex: I don't know. I don't know what to say. I know the runtime that they were using
Alex: in 2020 was something based on VRTOS talking to the maintainer at FOSDEM.
Alex: But I wouldn't know more than that.
Alex: What I do know and what I'm really happy is that they use finally something different than C.
Alex: Don't get me wrong, C is a really useful language, but it's really old and has a lot of problems.
Alex: So if you can avoid it in a way or another, that's really good.
Matthias: Can you list some of the problems, especially in an embedded context?
Alex: Memory allocation will be always a problem. So if on big computers you have
Alex: paging, and if you do something that's not just right, You might get a segmentation
Alex: fault because the operating system protects you.
Alex: In many cases in embedded, this is not happening. So you can do a lot of memory
Alex: overflows or incorrect memory usages, and you will just not get away,
Alex: but go to undefined behavior.
Alex: And for beginners, and I am teaching embedded systems for some time,
Alex: doing small lab projects is fine in C.
Alex: But as soon as the project becomes a little bit more complicated,
Alex: it becomes increasingly hard for students.
Alex: They will fight with C syntax and pointers instead of focusing on what they need to do on the app.
Alex: Another problem is there is no package management.
Alex: So you are fully responsible in making the packages compatible.
Alex: And the third problem is no interfaces. I mean, you have the H files,
Alex: but that's not enough for an interface.
Matthias: I can certainly relate to that. I didn't write any embedded code in C,
Matthias: but it was always frustrating just to get past the compiler.
Matthias: And even if you did get past the compiler, it doesn't mean it runs.
Matthias: It just means it compiles. But runtime is another thing.
Matthias: There definitely were segfaults.
Matthias: And maybe you want to avoid that in an embedded environment.
Alex: In an embedded environment, there's no segfault. It just does something different,
Alex: which Rust calls undefined behavior for a good reason.
Matthias: Right. So does that mean that the code that runs in my car also is prone to undefined behavior?
Alex: More or less. I mean, they use C for cars, but if the car manufacturer respects
Alex: good practices, they will require software to comply with the ACIL standard,
Alex: A, B, C, D, depending on what that software does.
Alex: Because technically what they do is they write the software and then have a
Alex: lot of static analysis with very expensive tools, which do what the Rust compiler does out of the box.
Alex: Try to find undefined behavior and ask the developer to fix it.
Alex: And to some extent that works fairly well, but it takes a lot of time and it is very expensive.
Matthias: And now suddenly we got rust and all of these problems go away quote unquote
Matthias: but i do wonder does it save companies time to start with rust because maybe
Matthias: they don't run into a lot of these problems.
Alex: It depends which company so car manufacturers would not write software directly
Alex: until recent years they would buy the part like they would buy the headlight
Alex: they would buy the brake system, the ABS system from a tire one.
Alex: The tire one would actually write the software, choose the microcontroller,
Alex: make the ECU, and make all these checks.
Alex: I think, and we actually think at OxidOS, on an educated guess,
Alex: that it will save some time because the Rust compiler forces you to write software in the right way.
Alex: Somehow, the community that wrote Rust just got inspired from this functional
Alex: safety and good practices of writing code.
Alex: It's one to write the whole code,
Alex: then go through static analysis and then retrofit. It's another one when your
Alex: code does not compile at the beginning.
Alex: So in Rust, it will simply not compile. So you will be forced to think a little bit different.
Alex: And this is where we think they will save some time.
Alex: And probably due to the nature of the language and the expressivity of the language,
Alex: it will be easier to read the source code.
Matthias: The Rust compiler itself got recently approved or it got certified for those
Matthias: critical embedded environments like automotive.
Matthias: And I do wonder, as a Rust developer, how much work do you have to do on top
Matthias: of what is already certified or qualified?
Matthias: Do you also have to qualify your code even if you run it in Rust? I assume so.
Alex: Yes, and that is still an ongoing issue.
Alex: So the compiler is certified. What is not certified yet is the core library.
Alex: And the compiler, it's not like the C compiler where the compiler is completely standalone.
Alex: In Rust, the compiler needs a subset of the core library, the language features.
Alex: And I think several companies are working to certify that as well.
Alex: We, as a software provider, need to certify the software as well.
Alex: So we need to do what is called ACLD out-of-context certification.
Alex: So we need to prove that the software does what it says it does.
Alex: Out of context, because we have no hardware that we run on, the client that
Alex: buys the operating system from us is providing the hardware.
Alex: The client is the final step in the certification because he needs to take the
Alex: software together with hardware, respect some parameters and guidelines and certify the whole ECU.
Alex: We as a software provider need to provide a lot of documentation for the software.
Alex: There's a V model where we need to provide specific requirements.
Alex: Requirements, we need to provide the architecture, and we need to provide the
Alex: detailed design up to almost every variable that we use.
Alex: And then we need to provide tests for everything in the inverse direction,
Alex: testing the small components, functional testing, and then testing that the requirements are met.
Alex: In the Rust ecosystem is really rich and moving really fast,
Alex: but we are still missing some tools. For instance, we need to prove that our
Alex: tests do full coverage of the code, and this will be available in LLVM 18.
Alex: I'm saying will be because Rust doesn't use LLVM 18 yet. It's in progress.
Alex: And we are also missing some tools that can do some kind of static analysis
Alex: that compiler doesn't do.
Alex: But it's in the works. I mean, the Rust ecosystem is really good at doing things fast.
Matthias: Just yesterday, I used a tool called llvm-cov or something like this,
Matthias: which allows you to print the coverage of my rust code.
Matthias: But I assume that what you mean is it's not available for your environment for your context.
Matthias: Is that correct? Or is it the same software, essentially?
Alex: I think it's the same software. My colleagues were looking at it a month ago, so it wasn't available.
Alex: This is really, really new because they included this in LLBM 18,
Alex: and I know the Rust compiler is working towards having support.
Alex: And I know that the team that does certification says that what we currently
Alex: have is not enough, but it's very, very close to what we need, and it will be done.
Alex: Talking to some compiler vendors, Rust compiler vendors, my understanding is
Alex: that they are working to integrate this fully in the compiler.
Matthias: Yeah what i learned yesterday was that i needed to pass in one additional flag
Matthias: which was not stable yet there was a config flag i can't remember but the rest
Matthias: was in fact running on stable rust which is kind of that's the problem.
Alex: I think that's the problem that my colleagues had.
Matthias: Okay well coming back to the architecture of OxidOS and also the software that
Matthias: you need to certify i do wonder if you have to go down to a function level and
Matthias: even sometimes a variable level does it make,
Matthias: redesigning the architecture super hard i imagine that you need to be extremely
Matthias: conservative about what you put in and how you move things around because you
Matthias: know that it will mean you will have to update all these documents and maybe
Matthias: trigger another round of certification.
Alex: Yes that is correct. So how the system was designed, and this was designed in the
Alex: 90s, is you are building specific requirements,
Alex: you are building the architecture, you are building the detailed design up to
Alex: the function and almost variable level.
Alex: And this is the point where you start writing the software.
Alex: Which is very interesting because in our case, we use an open source operating
Alex: system, which we professionalize.
Alex: And we have the software already, but we need to retrofit the document.
Alex: So this is the challenge that we have. The second is we are working very hard
Alex: to make this architecture changes easy.
Alex: Because imagine it's an open source software. It moves online.
Alex: It changes. It gets new features. It gets redesigned from time to time.
Alex: We need to have a really fast way in bringing in those changes,
Alex: at least the changes that are security related, and be able to update the documentation.
Alex: And this is a process that my colleagues are working very hard to do.
Matthias: If I understand you correctly, TockOS existed before this process started.
Matthias: So now you are in a situation where you have this ongoing open source project
Matthias: and you somehow need to retrofit it into the certification process. Is that correct?
Alex: Exactly. Yes, that is correct.
Matthias: And then whenever you get a pull request from an external contributor,
Matthias: you need to somehow see if that fits into the bigger equation.
Alex: Exactly.
Matthias: Okay, how long is that feedback loop if you look at it from a open source maintainers perspective?
Matthias: Hours, days, weeks, months?
Alex: For the open source project, it's fast. For certification, we are still assessing
Alex: this, but probably it's weeks in our case.
Alex: In a standard certification process, it would be months.
Alex: But we are trying to shrink this to weeks. We can't follow the upstream to the
Alex: letter because we will provide a stable operating system with a certain set of features.
Alex: What we need to pull in from upstream is security
Alex: patches and changing the architecture will be the case only if this impacts
Alex: seriously security and from time to time we'll pull another version of Tock
Alex: and certify that one so this is the process that we are following.
Matthias: OxidOS is a fork of Tock and you maintain your mirror of it. Is that correct?
Alex: It is a fork which is very close to upstream.
Alex: So we are trying to avoid things that different companies did,
Alex: forking an operating system, forking some software, having a downstream version,
Alex: and then having thousands out of upstream patches.
Alex: So we are following Tock really, really close.
Alex: Half of our team is our contributors, our steady contributors to Tock.
Alex: And we're trying to update as soon as possible and ship back code as soon as possible.
Matthias: And how are you planning to reduce feedback cycle for the official certification?
Matthias: Do the certifiers, the qualifiers, do they get access to a repository?
Matthias: Do you have to send them a CD with all the code or an email or a fax?
Matthias: And also on the other side,
Matthias: Are they used to checking Rust code?
Matthias: What is the process there? Do they also have to upscale and learn new technologies?
Alex: Certification is a bureaucratic process. So assessors verify documents.
Alex: And for instance, they start asking questions to the teams. Who is responsible for this?
Alex: Okay, where can you show me that this was tested? And you need to show the test.
Alex: Where can you show me you see this function?
Alex: Excellent. Which requirement does it fulfill? fill and then you need to quickly show the requirement.
Alex: So it's more or less a bureaucratic process, not a process of verifying code.
Alex: The assessor is very much interested in the fact that you as a company have
Alex: a clear process, what happens if and what needs to be done when something happens.
Alex: He needs to see that everybody knows the process, knows how to find and to track down something.
Alex: For instance, if some ECU misbehaves and they determine it's the operating system,
Alex: we need to be able to very, very quickly track it down to the line of code.
Alex: The language is not important here, but we have the responsibility to actually prove that,
Alex: hey, this line actually covered this requirement and this could not have happened
Alex: or this happened, but not because of a faulty process or a faulty code submit,
Alex: but because nobody ever thought of this corner case.
Alex: Basically avoiding the XZ problem.
Alex: So we're an open source, but we need to prove that we did everything possible
Alex: to avoid a problem such XZ.
Alex: So if XZ would have been certified, what that contributor did would have been
Alex: impossible because that testing framework would have had some requirements and
Alex: they would have had to prove that everything in a test framework has a requirement
Alex: and there's no additional code to that.
Matthias: From what I heard, and correct me if I'm wrong here, the entire process is sensical.
Matthias: It does make sense because they don't really look at the code itself,
Matthias: they look at the process,
Matthias: they look at a high-level documentation, documentation they look at whatever
Matthias: else you need but they don't really tell you how to write the code they just
Matthias: tell you what you need to guarantee or what are things to look out for. Do you agree with this?
Alex: Exactly actually you are telling
Alex: yourself how to write the code because the detailed design document shows you
Alex: sequence diagrams and exactly how do you need to write the code well and what
Alex: they check is the sequence diagram the code respects the sequence diagram And
Alex: there's no additional code except the stat sequence diagram.
Alex: There's no additional significant code.
Matthias: Okay. Significant means?
Alex: You have an auxiliary variable, that's fine. But calling additional functions
Alex: or having the function way more complex or having a branch of a match that's
Alex: not covered in the detail design.
Alex: It is down to a process, to a very efficient, hopefully, and well-documented
Alex: process where a team knows exactly what it needs to do.
Matthias: Is it something that can be exciting and also rewarding in a sense that you
Matthias: learn more about software development and best practices? Or is it something that needs to be done?
Alex: It's half and half. It depends how you apply it. I mean, if you apply it correctly,
Alex: and if you're changing, and that's what we are doing.
Alex: If you're trying to change a little bit the process to be more modern than in
Alex: the 90s, then yes, it's very rewarding.
Alex: And the team is very efficient. If you follow the process that was described
Alex: in the 90s to the line, you will have to send documents over email for approval.
Alex: This is not something that we want to do. So we use a repository.
Alex: The documents are marked down files.
Alex: Of course, digitally signed, that's fine. But bringing this process to the modern
Alex: era is one of our biggest concerns.
Matthias: Amazing.
Alex: And we are talking to assessors to allow us to do this because you can do deviations
Alex: from the process as long as you can prove it makes sense.
Matthias: That sounds like a way more modern development environment that I envisioned.
Alex: We're struggling with this. So we are not there yet. We are working actively
Alex: in doing this, but sadly, it's a very costly process.
Matthias: Does it also depend on who will verify your code, the agency that will do it in the end?
Matthias: Or is it more or less normative and people are always using the same process?
Alex: The process standard is ASPICE. Now, every manufacturer uses a different version,
Alex: which he or she adapted for its purpose.
Alex: We are trying to modernize it and adapt it for open source. because in the automotive
Alex: industry, open source was not a thing until a few years ago.
Alex: And in the safety critical parts of automotives are not connected to the internet,
Alex: in the engine or brake control, open source still does not exist.
Alex: And adapting this and making the industry understand what open source means
Alex: and that they need to change a little bit the process takes time.
Matthias: I saw a talk by Pietro Albini at Rust Nation UK lately, and they used a Google
Matthias: document to document or maybe to start to qualify the Rust compiler.
Matthias: And they had one huge document, even with different color schemes for different
Matthias: areas or for different sections, I guess.
Matthias: And it felt like such a monstrous process to me.
Matthias: What you described is way more manageable. I do hope that you can do it your way.
Alex: Don't get me wrong. We still have documents, but they're in the form of markdown
Alex: files. But there's a lot of documents.
Alex: What we're trying to do is to use open standards. So there's a lot of software
Alex: that allows you to do the documentation.
Alex: But the problem is, it's not that it's costly. That would be fine.
Alex: The problem is the format is closed.
Alex: So we are trying to build all the documents and everything in open formats so
Alex: we can share it with customers and export it into the platform that they use.
Alex: This is another challenge. But it's getting there.
Matthias: Right. But once you're there, that means your customers don't have to go through
Matthias: the same process, which is kind of great.
Alex: Exactly.
Matthias: I wanted to touch on the customers a bit. Who would be your ideal customers?
Matthias: Would it be big automotive companies, anyone else in the safety space?
Matthias: Or might it also be hobbyists, people that are makers and want to try new ways
Matthias: of building safe environments?
Matthias: Can you talk about the ideal customer a little bit?
Alex: It ideally it would be the big
Alex: automotive customers and aerospace and
Alex: big functional safety like medical or let's
Alex: say heavy industrial customers but that's
Alex: this is our hope that in 10 years this will happen today we are hoping to get
Alex: to customers which are smaller oems customers that build let's say electrical
Alex: bikes or electrical scooters because as we are talking They can sell them without certification,
Alex: but in a few years, probably,
Alex: they won't be able to do this because of European regulation.
Alex: So we are trying to get a system for them where they can use it to build these
Alex: kind of small micromobility devices.
Alex: And our second target is also smaller OEMs that build these smaller,
Alex: usually electric cars that will probably take over the city.
Alex: I mean, I doubt that in five to 10 years, you will have a big SUV running around in a city.
Matthias: Visit me in Dusseldorf, then I might convince you of the opposite.
Matthias: SUVs are very much a thing here.
Alex: Yes, but for instance, Paris, I think, has double or triple parking fees for SUVs.
Alex: I read some news somewhere. I don't know if it's actually true, but probably.
Alex: So that they can create more space for smaller vehicles.
Alex: But in the long run, I really think people will have a small electric car,
Alex: which they will use in the city.
Alex: I don't want to say names, but we all know smaller electric cars.
Alex: And then for going, let's say, on vacation, they will have a bigger SUV.
Matthias: Yeah.
Alex: Because literally you don't need it in the city. I mean, you can get around
Alex: in a city with a small car and park easier.
Matthias: Yeah, yeah, totally. And I also like that you think long-term here because not
Matthias: many companies, especially startups, have a 10-year window or they think about
Matthias: what happens in 10 years from now.
Matthias: And it feels like this is part of the equation as well.
Matthias: Can you talk a little bit about this? Why do you think in such long time spans?
Alex: Because we have no other choice. That's how the automotive industry works.
Alex: I mean, the long selling cycles and cars, so software that is being written
Alex: today will be in cars in three to four years.
Alex: So we really have no option than we think on the long run.
Alex: And even with Rust, they are looking at Rust, but they don't fully understand it.
Alex: Most of the car companies want to use it, but don't know how.
Alex: So we are trying to figure this out.
Matthias: Are there any important or big automotive companies that are ahead of the curve
Matthias: here that understand it better than other companies.
Alex: Yes, they are, but I can't and I don't want to name them because we work with some of them.
Alex: It might be NDA, but if you search online, you will see there's a couple of
Alex: companies that have invested in rust.
Alex: And there are some companies that have rust in cars already,
Alex: not in safety critical systems.
Alex: But as a better example, every car manufacturer that will use Android Automotive,
Alex: which is Android's version for the infotainment of the car, for now at least,
Alex: will use Rust because Google is rewriting Binder in Rust.
Alex: Binder is the communication mechanism for driver for Android applications.
Alex: So as soon as Google will ship this, everybody will have it in the car.
Alex: And usually car manufacturers are modifying this android because they adapt
Alex: it to themselves and they will have no choice than use rust it's.
Matthias: Kind of funny that in the 90s we tried to move away from rust in cars and now
Matthias: it's back if you allow me that pun.
Alex: I've heard this i have heard this a lot i was talking to people that are not
Alex: in the technical space and when they heard rust Rust in cars,
Alex: they said, oh, this is bad.
Alex: I mean, how can I do marketing for you when you're telling me that I need to
Alex: put rust in the car? Oh, yeah, what can I do?
Matthias: We can oxidize it. We can call it off.
Alex: Exactly.
Matthias: I watched a few things in that space. One was also a talk by Renault at Rust Nation UK.
Matthias: They talk openly about rust usage, so it's not a trade secret. I know that mercedes had a prototype internally
Matthias: that was a leak that came out
Matthias: where they had a rust repository but it was not for a safety
Matthias: critical environment i also know that
Matthias: volvo builds volvo os or something
Matthias: like this and it apparently was based on rust but i'm not sure if it still is
Matthias: or if they even developed that anymore and also a german manufacturer vw which
Matthias: at least experimented with it there were a few companies that i know of yeah.
Alex: I want to refrain from saying names because we work with car companies and
Alex: i don't want to infer anything there.
Matthias: And how does a conversation like this usually go when you go in and you say
Matthias: you should definitely have rust in your car apart from the obvious pun they
Matthias: might also have questions about
Matthias: why this is a necessary step and what do you tell them then well.
Alex: It's not about rust because no car manufacturer will actually
Alex: take rust because it's rust and it's a new language they don't care and they
Alex: shouldn't care they saw cars and what we tell them is hey you know we can shorten
Alex: the selling cycle we can be faster in the time to market anyway your developers
Alex: need to learn. Car companies are,
Alex: internalizing a lot. They took the model of Tesla and just internalize everything,
Alex: but they need to train the teams because they're not big tech companies.
Alex: And we're telling them, Hey, anyway, you need to train your people.
Alex: Why not train them directly in rust? It's more expressive. You can do it faster.
Alex: That's one. The second one is we tell them, Hey, you know, you will have a safety
Alex: issue because one, you need to respect the European regulations.
Alex: Second, you will have to respect the White House and the NSA's guidelines.
Alex: And at some point, you will not be able to get away with C and C++ because these
Alex: languages were specifically named in those papers.
Alex: So it's a good idea to start with this. What we are trying to tell them now
Alex: is let's make a POC, proof of concept.
Alex: So I'm not expecting you to change your whole operating system.
Alex: Them let's take something small and make a proof of concept and evaluate how
Alex: fast this is working for you and if we can prove that hey this was way faster
Alex: than writing it in c or in legacy things then maybe you would consider working
Alex: with us and this is the selling point that we have.
Matthias: And then you come and you have some skeleton of their application that they
Matthias: want to build you You build the proof of concept for them on top of OxidOS and you demonstrate it.
Alex: Exactly. Many of them want to run OxidOS alongside something else.
Alex: And that is also possible.
Alex: I mean, if you have a beefier chip, you can always hypervise OxidOS. Many want to do this.
Matthias: OxidOS is just a good guest in this case. And it runs on a host and it has its
Matthias: own little runtime, which actually we maybe should touch on soon.
Matthias: But then you can embed it into another bigger system.
Alex: Exactly. I mean, it's an operating system that works on small chips,
Alex: Cortex-M-like or RISC-V, IAMC.
Alex: So anything that respects these can run OxidOS.
Alex: And this is interesting because for RISC-V, there are very few operating systems
Alex: that actually work in this small chip space.
Alex: And OxidOS works perfectly on RISC-V.
Matthias: Is that the hardware that the automotive companies use.
Alex: Not yet mostly most companies use PowerPCs and arms yes PowerPCs the old ones
Alex: they never changed the chips but probably in the future they will shift towards
Alex: risk 5 for several reasons okay.
Matthias: Let's talk about TockOS itself of the components that it consists of the architecture,
Matthias: the high level picture of the entire thing.
Alex: All right, so TockOS is different from other operating systems in its class.
Alex: Mostly because it's an embedded operating system for small chips,
Alex: but behaves like a normal operating system for computers in the sense that the
Alex: kernel of the operating system is completely separated from the apps and is
Alex: getting compiled separately.
Alex: That's a piece written fully in Rust. There is actually no C line of code.
Alex: So yes, we do have some assembly, but most
Alex: of the the rest of the kernel not most of the kernel is
Alex: written fully in rust it has zero external
Alex: dependencies i mean everything is contained into the repository we do not allow
Alex: external dependencies except for crypto libraries or things that are super well
Alex: vetted but at the moment there's no external dependency applications are compiled
Alex: separately from the kernel so
Alex: completely separately into their own binaries.
Alex: You could write an application in C and D, in Rust, in C++, or anything that
Alex: compiles for the target.
Alex: As long as you can produce a static relocatable binary, which is a star for
Alex: Rust, because Rust still can't produce this on ARM, you can run it on top of
Alex: OxidOS and on top of Tock, actually.
Alex: So right now, applications are exactly like Linux applications.
Alex: They're their own binaries. they're not dependent on the kernel.
Alex: Whenever you flash the operating system, you are flashing only the kernel,
Alex: and then you can flash separately the apps, which is not the case for other
Alex: operating systems in its class.
Alex: Secondly, we do require memory protection, and applications are sandboxed.
Alex: So applications run in user mode, exactly like a Linux application.
Alex: Applications can never touch hardware. Absolutely never touch hardware.
Alex: So you cannot have the case that you have an application that configures a dma
Alex: differently than another application and then everything breaks which is the case of FreeRTOS.
Matthias: If they can't touch hardware how do they get any work done.
Alex: Through divers the kernel provides drivers so in the top kernel we have two
Alex: types of drivers one is low level drivers which control hardware and export
Alex: a set of traits, a set of standard traits,
Alex: these drivers do have some unsafe code because we need to do memory input outputs, MMIO.
Alex: But other than that, unsafe code is completely avoided.
Alex: And then you have upper level drivers, which are called capsules.
Alex: These ones are forbidden in having unsafe code.
Alex: So they can only use safe rust, which means a driver even though it runs with
Alex: full privileges on the computer on the processor,
Alex: cannot interfere with other drivers and applications because the compiler has
Alex: checked this at compile time.
Alex: Of course, as long as the binary stays the same of the kernel,
Alex: but you can always digitally sign the kernel.
Alex: But as soon as the driver compiles, you know for a fact that it can't interfere
Alex: with another driver or another application, even though it runs in full privileges.
Alex: And this allows us to guarantee safety with zero runtime penalty.
Matthias: Well, you have this really magical compile time system but at the same time you run
Matthias: applications that are compiled independently and they run on this small runtime
Matthias: so technically if i could find an exploit i could still try to access the hardware directly no.
Alex: No because you run in an mpu sandbox
Alex: mpu is memory protection so the application
Alex: can access only its small part of memory
Alex: none of the peripherals are ever mapped or
Alex: not mapped but allowed to be
Alex: accessed by the application so as long as hardware doesn't misbehave you are
Alex: not able to touch the peripherals because it will fault the processor should
Alex: fault of course if the processor doesn't support memory protection then there's
Alex: nothing that we can do applications can't always access peripherals can.
Matthias: You restart applications at runtime can you.
Alex: Of course.
Matthias: Okay. That means you can also update them if you want to.
Alex: Of course i mean we do need some support from hardware because some flash systems
Alex: on some microcontrollers behave in a really strange way but for instance for
Alex: nordic semiconductors it works very well for STMs it works very well i mean
Alex: you can update just the application the application can fault.
Alex: It's the equivalent of a stack fault. It can be restarted, it can be stopped.
Alex: You can do with an application the same things that you would do with a Linux
Alex: application, just that the number of applications is significantly reduced.
Matthias: I can imagine that this is a really nice demonstration for vehicle manufacturers as well,
Matthias: when they for the first time see that you can safely restart or even update
Matthias: an application that might enable them to do more in the future.
Alex: Yes, this is one of the selling points. But as I said, we have three to four applications per chip.
Alex: And yes, but don't expect it to be like in Linux. You have thousands of applications
Alex: now, three to four applications usually.
Matthias: And what do these applications do?
Alex: It's the business logic of your device. So anything that is not related to hardware
Alex: is done in an application, including networking.
Alex: I mean, we have a running networking stack written in C, which runs in an application.
Alex: So if your networking stack misbehaves, you just shoot it down and restart it.
Matthias: That's pretty incredible.
Alex: I mean, the operating system provides the layer two of the networking,
Alex: but anything else goes into the application.
Matthias: It's kind of cool that you can do that in application space, in user space,
Matthias: quote unquote, quote because in traditional operating systems that will be a
Matthias: core part of the operating system but for you it's just another application
Matthias: that runs just next to the others and is there some sort of communication between
Matthias: those apps then can they send messages to one another because,
Matthias: if you want to use that application and make a network request you have to reach it somehow.
Alex: Yes, so that's what we do. We have an IPC system that sends messages between applications.
Alex: We would love if hardware will help us more in this sense, but it doesn't.
Alex: So many, many times it results into copying buffers because we have no other way.
Alex: We have a way of sharing memory, but due to the way hardware is constructed,
Alex: this is super limited.
Matthias: Shout out to James Munns who worked on or is still working on postcard which is a
Matthias: message format i wondered do you use your own message format for this ipc bus
Matthias: or do you use something out there that already exists.
Alex: We transfer buffers applications use whatever they want okay.
Matthias: So you deal with it on a memory level and you say this is the blob that got
Matthias: sent to you deal with it and then you need to interpret it.
Alex: so out of the box that's
Alex: what the operating system does of course
Alex: you can always add a driver a capsule to
Alex: the operating system that is let's say content aware of the message and does
Alex: more but this is something that goes from user to user so we ship the operating
Alex: system with a generic set of
Alex: capsules and it's you the user who decides if if you want to add or not,
Alex: something like this. But in a generic way, we passed the buffer.
Matthias: If I was a manufacturer, I would ask, isn't that a security risk?
Matthias: Because you give me a blob of memory and I might interpret it in a certain way.
Matthias: For example, try to parse it as a struct that I can understand.
Matthias: There might be issues with the parsing process and maybe this could be an exploit.
Matthias: What would you answer there?
Alex: In the application, you mean? Well, the application needs to parse the,
Alex: I mean, in automotive, they use it a little bit different.
Alex: They won't pass buffers. They have something that is called the RTE,
Alex: real time environment. I think real time environment.
Alex: I'm not the automotive expert in the company. I'm the operating system expert in the company.
Alex: Where they have a set of connections. So every application gets its values.
Alex: So more or less automotive applications work like PLCs.
Alex: They have a running cycle, and at every cycle, they just read some values.
Alex: So what we do there, we just hand over to the application the values.
Alex: We have a specialized capsule, which provides these values to the application.
Alex: Let's say an application wants to know the RPM of the engine,
Alex: the temperature of the engine, something like that.
Alex: And then the application does something based on this. So yes,
Alex: in the automotive space, we do have semantic passing of buffers.
Matthias: But even if you didn't, it wouldn't matter because that's in the application
Matthias: space and that is inherently sandboxed.
Alex: Exactly. I mean, if the application tries to access anything outside its world of memory, it just falls.
Alex: Of course, an application could generate some networking signals or CAN signals
Alex: based on something that it receives. But then the application had the right to do that.
Alex: An interesting thing that Tock provides and inherently OxidOS also provides
Alex: is we are able to digitally sign applications, actually add credentials to applications.
Alex: It doesn't matter if it's a digital signature, it's a hash, it's just a credential field.
Alex: And we can check those credentials and have firewall I called this,
Alex: of what system calls an application is allowed to do.
Alex: So, for instance, if you have an application that just needs to crunch some
Alex: numbers but should never be able to access CAN, CAN is the communication bus,
Alex: the credential that the application will receive will forbid it to access the CAN.
Alex: Any system call to the CAN driver will just fail.
Alex: The application won't even know that there is a CAN capability on the device.
Alex: Because the operating system will reject it immediately.
Matthias: Right. Because that's another huge advantage there.
Matthias: If I understand you correctly, that means that you don't have to run all of
Matthias: this on real hardware to be able to test it. You can have your own little test environment.
Matthias: If you work against these trades, if you work against these capsules as you
Matthias: described them, that means you can test all your code even with unit tests locally
Matthias: and then deploy it once and be moderately sure that it will just work?
Alex: We actually do this. So we have an OxidOS simulator, which is publicly available
Alex: in the cloud, where you can run OxidOS and real applications.
Alex: So that means the real binary of the application compiled for ARM.
Alex: In this case, on top of OxidOS, which is compiled to WASM.
Alex: So OxidOS runs as a Wasm device, not Wasm device, it's compiled to Wasm.
Alex: And applications are just to run and do system calls.
Alex: And incidentally, applications don't, system calls in Tock and OxidOS are not
Alex: function calls, are real ABI calls.
Alex: So they do real system calls with sending data in registers,
Alex: which is perfect for core WASM because that's what we can ship.
Alex: So system calls are translated into really WASM simple function calls.
Alex: But you can test the exact same binary in a test environment.
Alex: And you can do this today accessing our platform.
Matthias: Yeah, makes for a great demo. Just for some context, WASM means Web Assembly.
Matthias: That's the runtime that gets built and can run not only on the web,
Matthias: and it's also not assembly.
Matthias: It's a format that is kind of specified in the open that allows you to have
Matthias: a very conservative set of inputs, mostly integers and floats.
Matthias: And a blob of memory that you can manipulate however you want.
Matthias: And it seems like TockOS maps very nicely into this model.
Matthias: And I guess others that came before TockOS that are used by current manufacturers,
Matthias: they don't really map to that model right away.
Matthias: It's probably very, very hard to run any existing system on WebAssembly.
Alex: They don't have the separation. So we were lucky in the sense that Tock and
Alex: Oxid allowed us to compile the kernel in WebAssembly and then provide functions
Alex: like networking or CAN in a simulated way,
Alex: and then run the binary applications directly on top of it.
Alex: We're just interpreting ARM assembly and making system calls.
Alex: And this was fairly easy to do for us. And this is what you can see on our website.
Alex: And we're hoping to have a nice day-long workshop at Oxidize about this.
Matthias: Amazing. Really looking forward to that. And can you run async code as well?
Alex: Actually, thank you for the question. Tock's kernel and OxidOS as well is fully asynchronous.
Alex: So we are not allowed in the kernel to do any synchronous action.
Alex: So every capsule and driver is a state machine.
Alex: This reduces, makes the kernel more predictable.
Alex: On the user space technically everything
Alex: is asynchronous even in c even in rust you'd have to do asynchronous things
Alex: we need to struggle to make it synchronous i mean make a call wait for an answer
Alex: filter all the other answers out the rust library for Tock was initially asynchronous,
Alex: now we have one that is synchronous and we at Oxid are trying to write a new
Alex: library that uses a weight and a sink, and we're experimenting if we can use
Alex: the embassies API for that.
Alex: Embassy RS is a library for embedded systems, and it seems that people are starting to use it,
Alex: and we are looking into if we could port embassy as an application for OxidOS.
Alex: Because the kernel actually helps us a lot in this.
Matthias: If you don't use Embassy right now, does it mean you have your own executor at the moment?
Alex: The first Rust library had its own executor, but it wasn't great.
Alex: The second one is fully synchronous for several reasons that were discussed in the Tock meetings.
Matthias: Okay. And what's so great about Embassy, other than maybe that it's a standard?
Matthias: Well, actually, that's probably the greatest benefit of it, to have something
Matthias: that works cross-platform, cross-application, cross-use case?
Alex: I'm not an embassy expert. I just teach an embedded class at the university which uses embassy.
Alex: Why did we choose embassy? Because it works. We use the Raspberry Pi Pico for
Alex: this and embassy actually works on the Raspberry Pi Pico with Wi-Fi.
Alex: So this is clearly the point why we chose embassy.
Alex: When it comes to embassy, I don't know if embassy is standard,
Alex: but it does provide the standard Rust-embedded async hull.
Alex: So the Rust-embedded group provided standard traits and Embassy just used them,
Alex: which is great because it actually doesn't matter if you use Embassy or some
Alex: other framework, you will have the same API, more or less.
Alex: That's why we are trying to port Embassy over. I mean, Embassy has a really
Alex: nice asynchronous executor. It seems to work well and is of decent size.
Alex: And we think it could be very useful in our applications.
Alex: But more than that, I'm not an embassy expert. So I'm just learning as I teach the class.
Matthias: When you teach embassy to students in the class, do they get it?
Matthias: Do they struggle with this new environment? Or maybe to rephrase it,
Matthias: do they struggle more with embassy and async execution or Rust and its syntax and the borrow checker?
Alex: I think none of them. They struggle with not being able to see the panic.
Alex: So a problem that we have is we have Raspberry Pi Picos, but we don't have a
Alex: debugger for them. So everything goes through USB.
Alex: And what the embassy is still not able to do is, if you get a panic, shoot it out over USB.
Alex: So if students get a panic, the port doesn't work, maybe blinks an LED.
Alex: But shooting out the panic over USB is the problem that we are having with embassy.
Alex: Understanding Rust, yes, maybe in the first labs, but we did some intros and
Alex: they have some boilerplate code,
Alex: understanding how to
Alex: use the framework that's really easy i mean examples are fairly good you have
Alex: some tutorials and the lab team did a great job in writing additional tutorials
Alex: actually the class is free you can see it online if anybody wants to use it
Alex: feel free to use it that's.
Matthias: Amazing and is anyone working on this panic handler a way to see the panic somewhere
Matthias: else other than the blinking light.
Alex: No i don't i none that i
Alex: know of we as the team for the class and
Alex: not OxidOS is looking into this because in
Alex: Tock we can do this we have a few chips that only have usb and we can shoot
Alex: out the panic over the usb and we are looking if we can contribute this back
Alex: to embassy to may do the same thing but it's very different from Tock because
Alex: it needs to touch embassies internals on this okay.
Matthias: And what other tools do you use other than embassy and a raspberry pi do you use probe rs in class.
Alex: Yes of course of course well.
Matthias: Not everyone knows what probe rs is maybe you can explain what it does what it provides to you.
Alex: On a bird's eye view probe rs is a really nice tool that allows you to flash
Alex: embedded devices from a computer.
Alex: And the really nice thing about it is that it knows a lot of boards.
Alex: Technically, when you buy a board, you need to take a specific software that would flash the board.
Alex: With Probe RS, they somehow collected a lot of open source code and they have
Alex: written a lot of open source code in Rust, which makes flashing a board really easy.
Alex: It's like a Swiss army knife for connecting and flashing software to boards.
Alex: And yes, we use Probe RS. We use it for flashing and for displaying the USB
Alex: messages, the console messages.
Matthias: Nice that means you have a
Matthias: very productive development environment mostly except for maybe this blinking
Matthias: panic handler but how do students feel about this and especially about rust
Matthias: are they excited about the language can they even compare it with something
Matthias: else that existed before like c or do you start right away with rust how do
Matthias: they feel about this environment and about the language.
Alex: My students are a special case they started in the their second year of
Alex: university and during the first year they studied java only
Alex: java so it was interesting because it was easy to
Alex: relate to because java has interfaces rust has traits they're not exactly the
Alex: same thing but they can relate to this java has classes rust has structs but
Alex: java has methods and rust does have methods so at least for me from a teaching
Alex: point of view and from the students it was easy to relate to Java.
Alex: And then they understood this rather easily.
Alex: If they like it or not, we will find out at the end of the class because every
Alex: student has to build a project.
Alex: We'll see the project and the feedback that we get from the students.
Alex: But so far, we think it's okay so far.
Alex: It's the first time that we do it. I mean, it's a completely brand new class.
Matthias: Once the students graduate and they are trying to look for jobs what are you
Matthias: looking for when someone applies to OxidOS what are the skills that are required
Matthias: to hire embedded rust engineers?
Alex: I will say something that people might not really resonate with i like students
Alex: that are really good in doing educated guesses,
Alex: so i ask him something i'm super happy if he doesn't know it because it's something
Alex: specific specific, but I'm really, really happy when he tries to figure out
Alex: how to tackle the problem and does some really good educated guesses.
Alex: This means that the candidate uses his brain a lot and is able to understand
Alex: complex problems and find an engineering solution.
Alex: So I care less about the fact that he doesn't know the Rust language. Fair enough.
Alex: If you know programming and understand the concepts, you will learn Rust in two days.
Alex: And we've seen this before. So we have employees which knew nothing,
Alex: literally nothing about Rust when we employed them.
Alex: And now they are super proficient in Rust and solving difficult problems because
Alex: it's not about Rust, it's about solving the problem.
Matthias: What are some great resources to learn more about embedded Rust development?
Matthias: You mentioned the course already, which is open.
Matthias: I hope that we can link that in the show notes. But is there anything else,
Matthias: any project ideas or any great resources that come to mind?
Alex: That's difficult. I think the ecosystem is lacking here. So I know the Rust
Alex: embedded books that the Rust website has.
Alex: I don't think they are really pedagogical. For me, it was hard to understand what they do.
Alex: And I struggled with this. Good resources.
Alex: I might not know every resource. So my problem is I don't know the resources
Alex: because I did my training myself.
Alex: And I did my training myself a few years ago, reading the embedded books,
Alex: contributing to Tock, and mostly seeing what others did in Tock.
Alex: So asking other contributors, looking at what they did, reverse engineering. That's how I learned.
Alex: So good resources, yes, start with the books. It's still better than a few years
Alex: ago because they used the microbit. They had another obscure board that they
Alex: were using for a demo, which at least for me was really difficult to get.
Alex: Now they use the micro bit, which is nice, and you can get it really easy,
Alex: and it has a debugger, but they still need to work on how to do embedding.
Alex: If I would recommend somebody to start with an embedded, I would say read the Embassy tutorials.
Alex: It works really easy, it's understandable, and at least it's a good starting point.
Alex: But it's nowhere close to arduino i'm sorry it's really nowhere close to arduino,
Alex: but we can i mean we can contribute to this ecosystem that's why we made the
Alex: class open source i'm not saying we have a really good resource i'm saying we
Alex: have a resource and we made it open source and we we gladly accept contributions
Alex: and feedback i mean we would love to have contributions and feedback yeah.
Matthias: A few things that come to mind from my side is I do work very well on a project-based environment.
Matthias: So I take a challenge and then I try to fix it or solve the problem.
Matthias: So focusing more on the project itself and not necessarily on the language or
Matthias: environment or the libraries, that is one thing.
Matthias: The other thing is open source maintenance or contributing to open source can
Matthias: really help you get better at understanding how other people work and think better,
Matthias: Where do you see Rust heading? What will be the future of Rust in 5 to 10 to 15 years?
Alex: I think it will do what Java and .NET did in 95 for the enterprise business.
Alex: They completely wiped out C++ there. Some people still use COBOL,
Alex: but that's like isolated cases.
Alex: But I think for the embedded systems and for basic applications or command line
Alex: applications, this will be the case. I don't think people will start new projects
Alex: in C and C++. They will start them in Rust.
Alex: It's going to take a few years. Still, it's going to take a few years,
Alex: but you can already see sudo has been rewritten in Rust. The time server has been rewritten in Rust.
Alex: And you see more and more projects that are being rewritten.
Alex: So the ecosystem has exploded. It's moving nicely.
Alex: And I think Rust, or this is my personal opinion,
Alex: A language that applies the same principles of Rust will take over the command
Alex: line and embedded systems in the next 10 years.
Alex: This is like Java and C#. They did Java, but C is probably used on a wider scale.
Matthias: What would that mean to the state of critical infrastructure if it was rewritten in Rust?
Alex: I think it's going to be
Alex: at least safer from the
Alex: undefined behavior point of view I mean
Alex: a lot of critical infrastructure has been written in c and c plus plus for a
Alex: good reason don't get me wrong they had no other choice I mean when they started
Alex: writing that critical infrastructure they had no choice they had constrained
Alex: systems but I think it's going to become safer because undefined behavior is less likely to occur.
Alex: I mean, we can still have undefined behavior and the compiler bug that we had
Alex: like half a year ago proved that you can segfault a Rust program.
Alex: And I think there's still things that, there's still ways to write the code
Alex: that will segfault the Rust, not the compiler, but the program written in Rust because it happens.
Alex: But at least on a general on scale, it's less likely to happen.
Alex: It's not that programmers are not good. Programmers are really good,
Alex: but eventually you make a mistake.
Alex: Eventually you forget to verify that a pointer is not.
Alex: Rust helps you in this. I think they would have written critical infrastructure
Alex: in Java or C Sharp if they could. But they couldn't.
Matthias: Yeah, because those environments were not supported by the runtime.
Alex: It was not possible. I mean, simply not possible.
Alex: We work also with a software services company, and we have in production Rust.
Alex: I have Rust in industrial systems, and I have Rust in kiosks,
Alex: and it works really nice.
Matthias: This is kind of a surprising thing to me, because I met you at Embedded World,
Matthias: and there were other companies there as well, which didn't really advertise
Matthias: Rust, but they used it. And for them, it was just a tool.
Matthias: And there were people that used it for their environments, for really solving customer problems.
Matthias: And that made me aware that we are making progress here, even in highly regulated environments.
Matthias: And also, people are generally excited about it, but they don't really see it
Matthias: as a language in and of itself, just a piece of the puzzle that just fits in well and makes sense.
Matthias: It's the right tool for the job and this was kind of eye-opening we.
Alex: Shipped three years ago an industrial system that works today in industry and
Alex: before OxidOS long before OxidOS we shipped Rust software into the industry
Alex: and we chose Rust not because it was fancy because we,
Alex: The client allowed us to rewrite the project because they liked it.
Alex: And we said we had a lot of problems in C.
Alex: Let's try it in Rust. We had one issue.
Alex: Never heard about the client again. I mean, never heard about the client.
Alex: No news is good news. I mean, it works.
Alex: And that was more than three years ago when we shipped it.
Matthias: When he said never heard about the client again, I wondered about why that was
Matthias: the case. But yeah, I guess in this context...
Alex: No, no news is good news. I mean, it works. The system works the client
Alex: is happy they don't need patches to it because it works it didn't fail.
Matthias: Yeah, I guess the one - of the biggest compliments for any programming language
Matthias: or tool is if it becomes boring to use where you don't really you're not really
Matthias: worried that you will run into any huge issues or you will need to have long
Matthias: patch cycles and so on it just works and from what you tell me this is the experience
Matthias: that you had with this project.
Alex: Yes it just worked and imagine it was the same team building both of them and
Alex: on the first iteration which was in c we had a lot of problems and not because
Alex: programmers were not good because of like no pointer which misbehaved or something
Alex: that we didn't catch or a concurrency problem or
Alex: deadlock in a mutex, or something like that,
Alex: which, yeah, Rust made it easier.
Alex: I mean, eventually, with the older project, we realized, because everybody knew
Alex: Rust in the team, but the client wanted C.
Alex: We basically built Rust structures in C, and we said, hey, why are we doing this? Let's use Rust.
Matthias: Awesome. It has become sort of a tradition around here to ask this one final question.
Matthias: What would be your message to the Rust community? You can say literally anything,
Matthias: it can be technical or non-technical, but if you wanted to address the Rust
Matthias: community as a whole, what would you say? The stage is yours.
Alex: I would say use Rust if it is the right tool for the right job.
Alex: Use it when it's really necessary.
Alex: And don't try to use Rust where it's not necessary or where something else works better.
Alex: That would be my message. And this will make Rust a success.
Alex: If you're trying to push Rust everywhere,
Alex: even if it doesn't fit really well, there will be a backlash.
Alex: So for the community, the message will be, use it as the right tool.
Matthias: Awesome and i guess that wraps it up pretty well,
Matthias: unless you have any questions we are
Matthias: done with our interview and i thank you
Matthias: very much for taking the time and i
Matthias: hope to give OxidOS and TockOs a try in the future i you definitely put it
Matthias: on the map for me and if anyone out there is listening where can they learn
Matthias: more about OxidOS how can they get started what will be the first step also
Matthias: including Tock of course so.
Alex: For Tock just go to the Tock repository and look at the Tock operating system
Alex: start reading the documentation pick a board because Tock is really explicit
Alex: about boards pick a board that you have and just run it on the board that would
Alex: be my message this is the message that we send that to everyone one.
Alex: For OxidOS, oxidos.io, go to our developer platform, sign up and you can use
Alex: OxidOS in a simulated environment.
Alex: Don't expect something super, super flashy. It's at the beginning.
Alex: But we are trying to build the manuals and everything for OxidOS so you can
Alex: see how to use it in automotive.
Matthias: Alex, thank you so much for all the insights and for being a guest.
Alex: Thank you for inviting me. Happy to talk to you and happy to talk about Rust.
Matthias: Thank you! Ciao
Alex: Bye
Matthias: Rust in Production is a podcast by corrode, it is hosted by me Matthias Endler and produced
Matthias: by Simon Brüggen. For show notes transcripts and to learn more about how we can
Matthias: help your company make the most of Rust visit corrode.dev. Thanks for listening to Rust in Production.