Florian Gilcher, co-founder of Ferrous Systems and the Rust Foundation, speaks with host Giovanni Asproni about the application of Rust in mission- and safety-critical systems. The discussion starts with a brief overview of such systems, and an introduction to Rust, emphasizing aspects that make it well-suited for critical environments.
Florian and Giovanni then discuss how Rust compares to C and C++ — two widely used languages in this sector. They proceed to outline important factors that companies should consider when assessing whether to move from C or other languages to Rust. The episode also touches on Ferrocene, an open-source Rust toolchain qualified for safety- and mission-critical systems, which was developed and supported by Ferrous Systems. The conversation ends with some reflections on the future of Rust for mission- and safety-critical applications.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
- SE Radio 644: Tim McNamara on Error Handling in Rust
- SE Radio 490: Tim McNamara on Rust 2021 Edition
- SE Radio 279: Florian Gilcher on Rust
- SE Radio 152: MISRA with Johan Bezem
Articles and Resources
- Safety-critical system definition
- Rust language official site
- Ferrocene open-source Rust toolchain for safety-critical systems
- MISRA-C addendum for Rust
- Tock OS operating system
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Giovanni Asproni 00:00:18 Welcome to Software Engineering Radio. I’m your host, Giovanni Asproni and today I will be discussing Rust for mission and safety critical systems with Florian Gilcher. Florian is the managing director and co-founder of Ferrous Systems. He has worked with the Rust programming language since 2013 and he co-founded the Rust Foundation. His company is the creator of Ferrocene, an open-source Rust compiler tool chain, qualified for safety and mission critical applications. Florian, welcome to Software Engineering Radio. Is there anything I missed that you’d like to add?
Florian Gilcher 00:00:49 Oh, I think that’s been perfect. Thank you, Giovanni.
Giovanni Asproni 00:00:52 You are not even new to the Radio because I see that you were a guest in Episode 279 about Rust. In fact, it was quite some time ago.
Florian Gilcher 00:01:00 Exactly. That was actually before forming Ferrous Systems when was I was the lead of the community team in the Rust Project. So I was more representing the project there.
Giovanni Asproni 00:01:09 And in fact, there are some episodes that are related to this one that is the
- Episode 644 with Tim McNamara on Error Handling in Rust,
- Episode 490 with Tim McNamara on Rust 2021 Edition.
- Florian Episode 279 on Rust. So it’s a bit of an old episode, but I think is being about the language, I mean the basic ideas should be the same pretty much maybe the language evolved, but the core ideas.
Florian Gilcher 00:01:34 Yeah, and I hope my understanding is refined, that’s a very new language back then.
Giovanni Asproni 00:01:39 Yes. And then also there is Episode 152. This is quite an old one, is about MISRA with Johan Bezem and all of them will be linked in the show notes. Now ready to start Florian?
Florian Gilcher 00:01:54 Of course. Let’s go.
Giovanni Asproni 00:01:56 Okay, so let’s set some context. Let’s start from the very basics. What is a mission-critical system?
Florian Gilcher 00:02:02 I mean the punchy one-liner is anything that if it fails, it hurts you. Particularly mission critical is usually it hurts you fiscally. We’re talking about safety critical, we’re talking about systems where people could be harmed. All lives are at stake.
Giovanni Asproni 00:02:16 Okay, there are distinctions between mission and safety critical. What is the difference there?
Florian Gilcher 00:02:22 It is something like you’re running a major web service, you’re major running a major data center. It is critical that your base systems never fail. If they fail, the whole data center is down. None of your clients can work. That can have repercussions in, for example, a whole hospital system may go down like this is often called mission critical. But because something like for example, an AWS data center is nowadays so part of everything in our lives, this can have repercussions down the line where safety critical systems fail because they haven’t anticipated that case and people could actually be harmed. So the distinction is actually, from my perspective, getting harder and harder, the perspective that I’m taking is there’s a new found desire in software correctness for multiple reasons coming out of different directions. Rust as a programming language that says safe and correct code directly in its claim comes out of a web browser company. It was originally designed at Mozilla and not just because someone wanted to build such a language just for fun in Mozilla research, but because they had legitimate need for that. So that’s pretty interesting that a language that we’re currently talking about or like is this the new language in safety critical comes out of a space that is pretty far from safety critical, but mindset wise is pretty close.
Giovanni Asproni 00:03:46 Yeah. And I think that sometimes we realize that the systems are safety critical when something bad happens. You know, like cloud providers that have some kind of loss of service for whatever reason, or I think something ago happened even to Google, I think Gmail issues things. So and all of a sudden entire business cannot really work anymore.
Florian Gilcher 00:04:06 Yeah. And that was a memory safety issue. It was another point of the reference that they actually actively ran into the retro about that is quite clear about this.
Giovanni Asproni 00:04:14 So yeah, you are smiling because this is like, it wouldn’t have happened with Rust I guess, joking.
Florian Gilcher 00:04:23 In a way, yes, there’s other bugs of that scale that you can build on Rust, but Rust is there to help with that. So I think one of the things that legitimizes, I don’t need to legitimize Rust, but that is interesting about this whole move is Rust is not alone in being a new memory safe systems programming language. For example, Apple has developed Swift, which is pretty much in the same generation of programming languages. So it’s not just Rust coming up and saying, you all bad here. We know it better. It is much more a generation of new software development that also then invests into new base tooling, because it has new needs.
Giovanni Asproni 00:04:58 Yeah, yeah. Can I ask you, what are the criteria to say that a mission or a safety critical system is actually good enough for its purpose?
Florian Gilcher 00:05:08 This is one of the things where the safety critical community has an edge because it has standards and documents and aside from these documents, forums where this is constantly being discussed and that is something that we don’t really see in, for example, like before I had Ferrous Systems, I was actually in data center operations. So I have quite a bit of insight there. So while there are background groups that talk about these issues, there’s nothing as structured as here is an industry consortium that wants to fix these and these issues and talk about how our programming practice looks like. So it’s things like MISRA, things like all the standards bodies in the ISO that decide about the IAC 61508 for industry or the ISO 26262 for automotives. Like all these forms or the DO178 for avionics where you have written down standard engineering practice of what is expected and what is recommended that just doesn’t exist in that mission critical space. So I think a little bit there, the label helps if it’s safety critical as something where one of those standards is in play.
Giovanni Asproni 00:06:11 So can you give us an example, you know, or a few things, you know, some of these criteria or some examples of what these documents specify? Just a small one to give people an idea of what we look at.
Florian Gilcher 00:06:21 The one I love is that the ISO 2662 for example says practice on all levels of safety. So it has these SO A,B,C,D for different levels of toughness. Essentially it says if available use a statically type programming language. That is one of the criteria and it’s actually highly recommended in all levels, which I sometimes use as a joke when people ask like, should we use Rust in automotive? And I say, yes, if you’re standard says so, but there’s other things like for example, practice restricted use of pointers is don’t just hand pointers around everywhere. If you can pass things by value, pass them by value because that’s easier. That’s one of those things that could be in a standard or even on certain levels to assess the quality of your test suite, please use code coverage of different kinds of forms. Like for example, please use statement coverage is for example, the one that the automotive standard says for SLB.
Florian Gilcher 00:07:19 So roughly mid-level while it says for a SLB, use multiple condition and decision coverage MCDC. So those are things that it mandates. So it mandates and recommends activities. One important thing is that all of those activities can be argued at a level where you say, I do this activity, I don’t do activity A, but I don’t do activity B because I can give you an argument while in my software it actually doesn’t improve quality that much and will actually focus on making the first one really thorough. That is a debate you then have to have with your assessor. And this is the other practice where I would differentiate safety critical for mission critical where this practice of your software is being assessed by an independent party is much more structured while a mission critical, particularly in cybersecurity, it is just, I’m doing air quotes here, good practice, but it’s also, so for example, we do work on cryptographic code. We have worked for example, on Rust TMS, which means we will never assess this code. We will never claim that this code is good. That is for a third party to assess. And I think this is good practice. This interplay between the implementer is not the validator I think is, and that’s completely dependent on programming languages.
Giovanni Asproni 00:08:33 So do I understand correctly that is basically a set of recommendations at various levels, even to the nitty gritty details of everyday coding up to that. And then any decisions that are taken maybe outside the recommendations, what to do are actually explicitly undocumented decisions. So it’s not by random chance that things happen.
Florian Gilcher 00:08:53 Exactly. And it’s totally fine to do things that are outside of the standard. You can still go and say we have an activity that is not covered in the standard, but we still think it increases software quality. In that case, that’s a longer argument to make because you have to say it is of utility. That’s often like the standards are not prescriptive. They’re not saying that you should do this. The good thing I find about the safety standards is that they say this is a very good recommendation of what you should do. If you’re diverging from it, we need to have a conversation and someone needs to trust that your divergence is good and makes sense.
Giovanni Asproni 00:09:28 And then how do decide what to apply not apply. So I give you an example. So in a safety critical system of course means that lives might be at risk. How do you decide it could be acceptable to risk some lives in some circumstances? So, or how is this, you know, the criteria. So it’s just try to understand, you know, when people go there and say, okay, according to what you have done, this is a good system because of course you cannot really eliminate the risk entirely.
Florian Gilcher 00:09:56 Yeah. This is a little bit out of my depth because I am very much on the front of the chain in providing the tools for this. I’ve never been in the position where I would have to argue that. I know that these assessments are being made. And I know that for example, the avionic standards are so strict because disaster is usually pretty big. While if you’re talking about a car that that level, I can speak like that, just the system and the system complexity is just a completely different category. If a plane falls from the sky, it’s a massive, massive disaster. Automotive has the problem that billions and billions of cars drive every day and they want to drive numbers down and accidents happen daily. That’s a fact of life. But nowadays, we’re talking in Germany about thousands of accidents a year. They were times where we were talking about 10,000 of accidents a year. So bringing that number down and further and further and further and making sure that through also mechanical and ways, and it’s not just about the software, it’s also how the car is built.
Giovanni Asproni 00:10:58 It’s about the system, the entire system.
Florian Gilcher 00:11:00 You can’t escape the system. I had a very nice conversation at the safety critical club the last time I was there where someone said safety in the end is about dealing with what’s real. Like you can’t escape reality and you usually have a physical system in place and the reality is car accidents exist, but there’s a lot of people out there both on the software side and the hardware side to make sure that people don’t get harmed in them.
Giovanni Asproni 00:11:25 Yeah. Now why do the tool chains for the critical systems need to be certified? What is the reason for that?
Florian Gilcher 00:11:31 So the general term is they’re being qualified because the tool chain doesn’t end up like your compiler doesn’t run on an engine. The compiler runs in your build system quite simply because compiler box can immediately lead to program misbehavior. So they’re in the direct chain of the coder. I write something into my text editor, and this is the program that runs and a lot of bugs are pretty much immediately obvious. That’s the good ones. I run my tests, this is buggy, that’s fine. And then the program never gets deployed. The problem is compilers have the power to generate our code and that also means any bugs in the code generation can lead too hard to trace stone bug that come down the line that may be triggered later on. And this is why we assess tool chains. So the joking summary, if I have to explain Ferrocene and the whole subject of compiler qualification to people in the Rust project who are away from safety critical is they’re saying like, what are you doing?
Florian Gilcher 00:12:31 The Rust compiler is already high quality. And I’m saying like, yeah, but what’s your argument that it is high quality? Is it we haven’t found bugs for a couple of weeks? Or is it we are sure that for example, this feature has an appropriate number of tests, that we are reasonably sure that it is well tested. And that’s basically the qualification work. You say the tool has the following feature, for example, it compiles a main function and if you put in printed out Hello, the output is a certain kind of binary program on a certain kind of architecture that outputs Hello World, a trivial example. But we make sure that this compilation process works well all over time.
Giovanni Asproni 00:13:12 And so when you have this qualification process, is it done for a specific version of the compiler on a specific operating system, on a specific architecture? Are all versions kind of locked down for the qualification process or there is a bit of flexibility there?
Florian Gilcher 00:13:28 So, we generally release every three months. So every quarter and we release an appropriate Rust compiler version that is currently new. We take a few one to two months to further validate the compiler downstream. That means validating it on, as you say, we need to validate it on all the targets that are supported that the main Rust project does not support. So we are running the tests there. We are seeing if exactly that thing is like we have for the whole 13 project. We have written a language specification for the Rust language so that we can say this is a feature of the language, these are the tests for it. This specification, by the way, has recently been accepted of the Rust Project as the Rust specification. Which means the argument Rust doesn’t have a specification now goes away. That was a decade long argument that we had.
Florian Gilcher 00:14:20 Rust now has a specification. So a major chunk of that work is making sure that every piece in that specification is well tested. That’s about one half. And the reason why we do this is to make sure that engineers that use the tool and they see a tool behavior, they can go to the specification and say, does this behave like it’s written down? And then they look at this tool behavior and maybe they say, okay, okay, this is how the tool should behave. That’s fine. Or they see okay, something’s off. And there’s sometimes the discussion that people make is like, okay, so who’s right? Who’s wrong? Is the spec right? Is the compiler wrong? That’s actually not the interesting bit. If those two things disagree, you should look at what actually happens there. And then this is more the starting point for further research because you probably found something. So coming back to my communication piece, there is always what we do is we take the gut feeling that the Rusts compiler is good quality and give you an actual argument and evidence that the Rusts compiler is good quality because things can feel as good as I want. I don’t want to be in a car where someone said it feels good, the brake feels good, it hopefully works.
Florian Gilcher 00:15:36 No, the brake has to work.
Giovanni Asproni 00:15:38 Okay. And what are the limitations of this certification or qualification process? Because I guess cannot guarantee a hundred percent safety. So there must be some limitations so. . .
Florian Gilcher 00:15:49 Quite a few. Can I just add in one more thing to the activities? Yeah, please. And then answer that question. The other thing is the Rust compiler has quite a lot of features that, for example, may lead to mis-compilation. So for example, it has a developer convenience feature that is called incremental compilation. So it compiles parts of the code and then if you recompile it does only recompile the things that’s been changed. This one is generally solid, but if you’re using that, it may in very rare cases because there’s a very complex system introduce bug. So what we also do is inform our customers on the final build on the final software, please don’t use this feature. It’s generally okay, but please not on safety critical software because even the off chance that this triggers a bug something. So it’s also a lot of customer information of writing down information that is running around the community. So a lot of experienced Rust programmers know that the problem is our customers don’t always employ people who build the compiler, more often than not, you know what I mean? So that is also like this.
Giovanni Asproni 00:16:55 This is also interesting because it’s not a feature of the language itself, but this is about the tool chains available and how we use them pretty much. And so this is one of the recommendations of using the tool chains in a particular way to be safer, I guess.
Florian Gilcher 00:17:10 Exactly. Only your question about limits.
Giovanni Asproni 00:17:12 Yeah, the limitations.
Florian Gilcher 00:17:13 So we have qualified, that was Ferrocene was a bit of a research project for a customer. On the customer request. We have actually qualified the whole language. So this from the tool perspective, you can use all of Rust with the tool. The problem is, Rust has for example features. It has a specific thing called procedural macros, which are tiny annotations. You can put them on top of structures and then this is actually allowed to pick this up, the structure up and generate additional code. And the way this works is these procedural macros are actually code libraries. You can well either download from the internet or write yourself. And this is where it gets a little bit ironic where people say it’s like, can we use proc macros in our project? And I’m like, yes. For me as a tool vendor, I can tell you our proc macro interface works. It’s pretty simple, it’s tested, but you need to validate that code generator that you plug in and that you write yourself that it does actually correctly generate pretty much invisible code. So it’s often around these subtleties. It’s less the tool in itself is problematic or we won’t catch a buck. Like these problems exist. We can talk a little bit more about quality measures of the Rust project.
Giovanni Asproni 00:18:33 Yeah. But this one in terms of limitation of the process is interesting. Like yeah, use the language, use the tool chain, but then there are some kind of escape patches that allow you to do something yourself. And you have to be careful there and you probably need to certify that bit independently if you want to use those in these particular systems.
Florian Gilcher 00:18:51 Yes. And then we end up in a situation where we’re more in an advisory position where we’re saying this is a way how you build a solid proc macro that is actually easy to validate and should pass certification. We never claim that it does pass certification because that’s on someone else’s, right? But yeah, all of these things, programming languages are complex, and you can’t combine them infinitively complex. So what we are teaching when we are dealing with safety critical customers is a simple and understandable Rust, even though you could heavily lean into the feature. So there’s a little bit of a cultural bit there.
Giovanni Asproni 00:19:25 Okay. And before you mention also, I think security, but I was looking around this seems that the differences between safety critical and security critical systems are kind of blurring nowadays. What do you think? Is that correct assessment?
Florian Gilcher 00:19:42 It’s very glaring coming out of space. As I said, data center operations where time to update is really the thing that counts. It’s like you see a zero-day attack somewhere and it’s how fast do you react and how fast do you have all your service patched that collides with this very slow minded, let’s keep the system stable, let’s keep all tools stable, let’s validate for months and years to make sure that this tool really, really works or this piece of machinery. And the problem is now that we are starting to connect all these things to the internet, so you could frame this as a collision. I see this much more as there’s two groups coming back together. There’s certainly some conflict coming in. But I think the interesting thing coming back to what I said before, suddenly you have very correctness minded engineers working at the hyperscalers at large companies that also they have the problem the other way around. They suddenly have the issue that they need to patch fast, but their systems are so complex that they need to have high assurance that if they patch it, it behaves the same as before, minus that bug and doesn’t bring a whole data center down. So suddenly we have these two groups coming back together. So you see, you actually see people from hyperscalers now at safety critical software club.
Giovanni Asproni 00:20:59 I can imagine also situations like, you know, in automotive now the cars are connected to the internet all time. And that is obviously safety critical, the software in the car. But there is also the chance of hackers hacking to the car. And so security and safety there can be at some point come together because a hacker can hack into the car of somebody and take control and kill the person, you know, provoke an accident. So it seems to be a strong relationship now that it’s becoming stronger.
Florian Gilcher 00:21:29 You have that and you also have a very tangible example that you have is, for example, you need to update the car and the update needs 10 minutes. But the other thing is this also people rely on their car being ready out in the front yard, for example, if they need to rush someone out to the hospital. Imagine running out and your car says, I spent nine minutes on patching. So it’s also a situation where the safety critical industries have it harder. They can’t just use the approaches. And then there’s a regular conflict. Where people come from out of the, the space that I’m from and say like, oh this is so simple, why don’t you just have an update demon and you’re done. And they’re like, yeah.
Giovanni Asproni 00:22:13 Or I mean a bug in the procedure breaks, the car cannot start anymore because the software now is ruined that.
Florian Gilcher 00:22:22 Exactly. Though on the other hand, bricking a server nowadays is also a problem because all of the data centers nowadays run human less. So if the server doesn’t start, again coming back to that thinking, it’s mission critical, that costs you a lot because you need to send someone out. And it’s probably because you’re deploying these things on mass. You’re not bringing down one server, you’re bringing down a hundred. But yeah, so there’s a curious time currently where these two groups intermingle and that’s why I find it very interesting at the moment where this is growing back together. But as you say, it breeds conflict also because of I think base assumptions.
Giovanni Asproni 00:22:57 Yeah. And now let’s move into more detail about Rust itself. So first of all, maybe a very brief overview of Rust with a focus on what you think makes it suitable for mission and safety critical systems.
Florian Gilcher 00:23:12 Okay. So Rust is a new systems programming language that as its hallmark feature is memory safe and memory safe in the face of concurrency, that’s, its two big strong points. It comes out of the language family of the ML families for those that are interested in those bits. But it looks a lot like a standard general standard systems programming language comes, as I said, out of Mozilla research and it was an approach to do better than C++ that which they were currently using and fix a lot of the issues they were seeing on the Firefox code base. Though the best comment I ever heard about that was, if Rust is a criticism of C++, it comes from a place of love. So it’s built by people who are very pragmatic programmers. So it has a lot of features around that.
Florian Gilcher 00:23:58 It comes with two very big concepts to ensure that the concept of memory ownership, it is always clear in a Rust program, which part of the program currently owns a resource, generally memory, but also sometimes for example a lock or something else. And then on top of that it has a feature that is called borrowing, which makes it safe to refer to other items in memory, usually through references. And these references carry what people often sometimes heard about this idea of lifetime. So the Rust compiler very much tracks when data enters your program, when it exits the program. And then it tries to make sure that every reference that’s given out to that data is always legal and always referenceable. That’s very short in a nutshell, the core ethos of Rust without showing source code.
Giovanni Asproni 00:24:49 Okay. Yeah. And then Rust also in general is if you are called compiles, you are a long way into having something that actually runs, I guess. Because of all these checks and what makes it as suitable for mission and safety critical systems. You mentioned memory, you mentioned concurrency. There are other aspects as well?
Florian Gilcher 00:25:08 It’s first of all that correctness and also, it’s a pretty strict language. And there’s pretty often like its rules are actually, if you don’t it pretty simple. You have that ownership thing; you have that borrowing thing and otherwise it boils down to what I usually call a data structures and functions language similar to C. So Rust has two big primitives, data structures that you put in memory, functions you call on them. So in the end it becomes very traceable what actually happens in runtime. The other thing is all of those checks happen at compile time. That means the Rust programming language does not have a runtime, it just executes code on the processor, which makes it really feasible to be a language that is put on other things with active behavior saying operating system or something like that. So you don’t have this situation where you have a, okay, I have the kernel, which is essentially a runtime system. And then I have, for example, if I take a language let Go, Go has this whole thing with an event reactor and an IO system on top of it and I need to validate all that before I come to the programming language. While a simple Rust program that just has a main function and prints out something is equivalent to like in its runtime components to a C program that just calls the main function and prints out something. So there’s nothing going on the side of that.
Giovanni Asproni 00:26:28 So in short, the compiler does a lot of the hard work to guarantee that the program runs correctly. And so the need for the runtime is much less than in other languages on other platforms?
Florian Gilcher 00:26:39 Yes. Yes.
Giovanni Asproni 00:26:40 Okay. And how does it compare to other languages that that is for safety critical systems say, you know, C, C++.
Florian Gilcher 00:26:48 To C it’s mainly the bits with memory safety and the whole managed concurrent these things. So it’s threat safe. While Rust can also easily call into C, so as I said, it’s actually a language that’s pretty close to C in its evaluation model. So on top of C it does away with a lot of the problems that C introduces. To C++, Rust compares more like another take on a similar concept. So Rust is a generic programming language. So it has generics, it doesn’t have templates like in C++, but it has generics and a lot of the compilation behavior, for example, if I’m giving a class to C++ people, a lot of the compilation behavior is pretty intuitive. The thing that C++ does and it codes this idea. So if you’re used to that C++ pattern of resource acquisition is in sterilization, RAII, this is basically Rusts ownership.
Florian Gilcher 00:27:44 So Rust can be seen as a language that enforces that pattern everywhere and makes it compile time checked. So this is how it compares to C++. To ADA, I only have superficial ADA knowledge. I know that Rust is quite a bit ADA inspired in ethos around that whole correctness thing. ADA has a little bit of an edge on Rust, particularly in places where, for example, you can say this is an integer from 50 to 120. So these constraint integer types and things like that. Though I know there’s currently an initiative to actually fill a few of those gaps on the Rusts compiler where we can actually do that, let’s see, next year.
Giovanni Asproni 00:28:24 And in terms of the safety critical environment, so what are the advantages and disadvantages of Rust compared to C and picking one of them?
Florian Gilcher 00:28:35 The advantage is obviously less checking needed. A lot of the things that you would check using an expensive external tool, you don’t need to buy a tool for proving memory safety on Rust because the compiler already does it. And it’s so broadly deployed that we have not only tangible evidence out of the test suite that this works, but also industry-wide tangible evidence that this is a solid system. That’s one of the advantage, if I had to pick a disadvantage is, Rust in safety critical is still new, which means gaps may be found. So if you’re deploying, so we’re working with a number of tool vendors for further validation and in general Rust’s strategy that the compiler tries to be as boring as possible at the back end. It generates binary code, it debugs using 12, like the 12 annotations, like the metadata format and all of these things.
Florian Gilcher 00:29:29 So it’s very boring in the backend, which means most tools can pick up a Rust binary and just read it like it. Where a C binary or a C++ binary and figure things out. Thing is sometimes there’s still gaps. So do we expect that on your very first Rust project you will be in a conversation with your tool vendor about, oh, we’re seeing this, we are seeing that maybe you can fix this. Most of the people we’re working with just, well all of the people we’re doing this are actually fixing this with a couple of days turnaround.
Giovanni Asproni 00:29:57 So can you give us one example of these things?
Florian Gilcher 00:30:00 Yeah, sure. The Rust compiler currently does not annotate B tables with the jump targets. So virtual function tables a way to dispatch to do dynamic dispatch. So you get this function table handed and there’s basically a point or two data in memory and the point to a virtual function table that are functions that you can call on this object and the Rust compiler does not currently properly encode all possible jump targets, which is clang for example does. Because even though this is a dynamic call, you can actually during compilation say these are all the possible jump targets. This is something that people want for cybersecurity but also for safety because then they can analyze all the possible calls that can happen here and can make a performance assessment. And because that item is currently not emitted by the compiler tools will say like, okay, and they, the usual stance of the tool vendor is, will fix it if it becomes an actual problem to a big customer. And most customers are currently like, okay, we can work around this because the program is so tiny we just say this, this and this is the jump target by code reading and say to yes as a, we’ve done it manually.
Giovanni Asproni 00:31:08 But it is interesting that it is not even a language level thing. It’s more the compiler. So it’s really some of the tool and the tool chain and what happens in the small details that really matters sometimes in these are.
Florian Gilcher 00:31:18 Yes, you say it exactly. It’s like the biggest broker for adoption I think is we need someone to sweep through all the tiny details at some point. And that isn’t quite there. This is something where, for example, there’s a safety critical consortium at the Rust Foundation where these things are being collected and given as an advice to the Rust project to actually fix them.
Giovanni Asproni 00:31:39 And what about availability of tools, libraries and frameworks because C has been used in this space for a long time, so there must be plenty of tools and things. What about Rust?
Florian Gilcher 00:31:50 So for safety critical, many people use the tools that are available in the mission critical space. So for example, two of our certification projects rely on a tool that is called Arctic real-time interrupt-controlled concurrency. It’s a tiny tool that generates an interrupt-based scheduler on a microcontroller safely comes out of a university. So it will make sure that as a compile time proof that interrupts of a lower priority do not interrupt interrupts of a higher priority on a microcontroller. But the thing is this is solid that has been deployed for years, but now customers do trust it in us that they think they can go through certification. We’ll see by the end of the year, we’re pretty convinced that it works. We have actually one operating system that is completely built in Rust, same story. So there’s an operating system called Tock OS and that is actually used by Google in a number of tools. You can see that. And it is invented at the university, Princeton I think. And that one is an, is an open-source project that has been around for I think 10 years now or something like that. And that is currently being certified by a company in Romania. So there’s Rust based operating systems for tools. There’s a number of vendors that have formal or informal Rust support. Most of them are public about it.
Giovanni Asproni 00:33:15 That is a lot of movement in this space then around Rust…
Florian Gilcher 00:33:19 Movement, movement is the right word for it. It’s a lot of people are moving into that space, expect that the space is new, but people are currently in their certification projects.
Giovanni Asproni 00:33:29 Okay. So that’s the stage.
Giovanni Asproni 00:33:30 Can you give us one example from a real project who are moving to Rust, maybe from C or C++ actually made a positive difference?
Florian Gilcher 00:33:39 So the general, I mean there’s, there’s always,
Giovanni Asproni 00:33:43 If you’ve got an example you can share, you know, it’s like
Florian Gilcher 00:33:46 We have ported sudo — like, the classic Unix program — to Rust together with another Rust company in the Netherlands called Tweed Golf. So we had a number of very good experience in that not only on the coding side made the code much, much smaller and a lot more reliable. It also allowed us to actually cut all features. So the code is now faster, easier to read. And the additional thing is because we ported the C code base, we also learned a lot about C. So the suds classic project actually also got a lot of information out of that. We found suds bugs while porting it to Rust. But that’s obviously, so from the productivity side we are Rust experts so of course our productivity Rust is, but also
Giovanni Asproni 00:34:27 But also you got anything also maybe from the safety critical system and movement. If you can share something?
Florian Gilcher 00:34:34 From the porting side, I sadly can’t share any. So our customers are usually people who do not port over their actually new developments completely in Rust. So I couldn’t say anything about the productivity gain their way. I have tangible data. These projects go rather fast. We currently have a medical device that has been implemented in the better part of a month through all requirements and is currently in assessment.
Giovanni Asproni 00:35:01 And, we got any data in terms of bugs, the facts that something like, well we’ve done this in Rust and it seems to be better than whatever in C or than an equivalency system. I donít know if you have any data around that.
Florian Gilcher 00:35:17 So defect rates are lower. The problem is for having tangible data around that you need a much larger org. But you may have this talk at Rust Nation, the keynote from Las Bergstrom who is the responsible person at Google for Rust. And they claim across the whole Android code base a two times productivity increase across their group of developers and they’ve measured a couple of thousands. It is interesting to see that talk particularly because he also argues it’s not the development speed. The development speed is about as fast as in C and C++. The problem comes later, it takes less time in code review. People generally feel more confident because the language finds more bugs during compilation time. So it’s mainly later. And then the missing cycles because of if you have fewer bugs, fewer things need to go back into develop. That’s Rust claim he makes.
Florian Gilcher 00:36:09 The case C mix, there’s another talk that was given at the big Rust conference in the Netherlands Rust Week by Volvo. They actually claim a 2-4 time productivity increase. And there I have to say this is mainly my conjecture. I would really like to have a look at the data and where that comes from. I think it’s precisely because that bug back to developer cycle is longer in automotive than it probably is on automotive. But this is purely my off the cuff conjecture, having seen this conference talk and not the underlying data. Both of them claim that they have done structured research in their organizations, but I can’t go to Google and ask them to please, please give me all the exit sheets.
Giovanni Asproni 00:36:48 That’s good. Well now, now let’s talk about something it may be a bit closer to you. So about Ferrocene. The open-source Rust compiler tool chain that your company maintains. Now Ferrocene is said, is a fork of the standard version of Rust. How do you keep it updated without invalidating the certification for safety critical systems? So what kind of process? Of course, you know, whatever you can reveal. I’m not asking for any secret sauce here. If there is any.
Florian Gilcher 00:37:19 There’s literally a repository that’s called secret sauce somewhere on our infrastructure. But no, the whole process is actually, you can actually see it out in the open on GitHub. I think we’re the only completely open-source safety compiler and also the only one where you can actually follow the process out in the public. So first of all, we don’t fork the Rust compiler, we call it downstream. So what we do is every night we directly take the changes down and make sure that our validation elements on top of that, which is the test traceability precisely that spec to test. So we look at for example, have there been tests added? What are these tests? Therefore are they documented, are they written down? We are fixing the documentation if they aren’t. Or for example, if we see a test missing, there’s a language feature being added on the right side in the specification, but they’re lacking tests, then we fix that. We run test runners for all of our targets. We are the only ones out in the open that actually run microcontroller tests like the, the Rust project itself does not run tests, for example on court exam microcontrollers or on the arm cortex are these things. We also done some work together with the Rust Foundation around risk five. So we can easily run these things and then we are also implementing support for autos like for example, QNX71.
Giovanni Asproni 00:38:41 And do you feedback what you find any discrepancies with tests or bug or anything back to the Rust Foundation to fix those? Or how do you do that?
Florian Gilcher 00:38:52 As a co-founder of the Rust Foundation, I would need to be very clear here, feed the back into the project. The project is independent from the foundation. So we feed the back into the Rust compiler. Given that thinking that are laid out very much in the beginning, it’s like Rust comes out of a correctness mindset. I think the Rust compiler should be very correct. So if we find any kind of bugs or if we think the test suite is lacking, we’ll upstream that. We’re currently upstreaming a major change to the test suite for the test suite being more resilient against the certain compiler features. So yes, we are very much committed to our upstream there and we have a very good experience in that. It’s like particularly, and this is why I’m so, I can’t go and say I want a safety critical patch in the Rust compiler.
Florian Gilcher 00:39:33 So that’s why I’m saying I want a correctness patch in the Rust compiler and people will very much accept that. It’s also compiler validation nowadays is quite a different game from what the open-source projects did about 20 years ago. So yes, we are downstreaming that. So we are always keeping our things fresh and we also make sure that as early as possible, if there’s a change in the upstream that for example fails on any one of those orthroses, we can say, oh by the way, we found a bug and we have our communication path back where we actually just patching the thing. So if we can we just patch the thing in the main Rust compiler and then one day later it falls into our system.
Giovanni Asproni 00:40:12 Okay. So you contribute directly to the Rust compiler itself as well when you patch? Yes. And so is it correct if I say that what you give is pretty much the same thing as the standard compiler plus let’s say the confidence that actually is usable for safety critical systems?
Florian Gilcher 00:40:31 This is exactly what to do.
Giovanni Asproni 00:40:31 So there aren’t any major differences. I mean the differences can be temporary due to things that you found that will be fixed at some point.
Florian Gilcher 00:40:39 The most important thing is if you for example, have to, so we also do long-term support for that compiler for over years. And the Rust project itself currently only gives support for the last compiler they released, and they release every six weeks. So basically, you’ve got a six-week support window. So if a bug comes up in a new compiler, we do the work of figuring out, okay, which of our compilers are currently in support? Does this bug also affect that? And then give advice to our customers. Yeah. It’s like how do you deal with that bug? So we are always keeping our things fresh and we also make sure that as early as possible, if there’s a change in the upstream that for example fails on any one of those orthroses, we can say, oh by the way, but the decision making there is what is our assessment for the patch doesn’t break. Other things, if it’s a 3000-line patch, no one’s going to patch an 80-year-old compiler that we’d rather go to the customer and say, this is how you find if you even triggered that bug. Otherwise we don’t test the tool. So all of these complexities are not really something for an open-source project
Giovanni Asproni 00:41:36 For your company really. Maybe where the most hard work, is actually in maintaining this what is in production pretty much and the versions that you guarantee to your customers to support.
Florian Gilcher 00:41:47 Exactly, yes.
Giovanni Asproni 00:41:48 And also I would imagine you have to guarantee support for a number of years for a specific version that is out there. It’s like, it’s not three months or six months can be several years.
Florian Gilcher 00:41:58 As long as the customer wants.
Giovanni Asproni 00:41:59 As long as the customer wants. Yeah. And so does this mean that the open-source version of Ferrocene is actually itself certified for safety critical systems or is kind of or 12 the word certified one is the paid for one. So how does it work in this respect?
Florian Gilcher 00:42:19 So always vagueness of terms is a big problem in our industry. So the source code isn’t a state that you can immediately qualify. The problem is if you go to an SS4 tool qualification, they will not only look at the source code, but they will also go and look at your organization and say, are they capable of actually responding to issues in a certain time and in timely manner.
Giovanni Asproni 00:42:41 Okay. So it’s basically the same compiler that you sell, but the commercial one as the company support, that is actually a necessary thing for the qualification itself. Because there are requirements around fixing issues in a timely manner and all in some other aspects.
Florian Gilcher 00:43:01 Yeah, in safety critical, there’s pretty often liability involved. So you take on a certain amount of liability, which an open-source project strictly can’t. When I was part of the core team, I was always saying like the most important thing if you’re working with volunteers is that volunteers are never liable for anything.
Giovanni Asproni 00:43:17 Yeah.
Florian Gilcher 00:43:18 And that’s the only way you can do that. And I sometimes just open source, uh, the open source licenses have this, this comes without warranty and ferin comes with warranty.
Giovanni Asproni 00:43:29 Yeah, yeah. No, it makes sense. It’s trying to understand. But also, I guess that having it open source will give companies actually the possibility to try it in their own systems with the confidence that if it works, they can say, okay, you know what? We’ll buy the qualified version, so we know that’ll work for our case. So they don’t necessarily need to buy something beforehand.
Florian Gilcher 00:43:51 And we support them in that activity because there are companies that nowadays for example, want to rebuild the whole tool chains from source. And we are a place where they can acquire the source pre-vetted and we then go and say, okay, we help you, for example, building your own compilers in your data center.
Giovanni Asproni 00:44:08 Yeah. I think this is an important thing to know for people that going to try Ferrocene. So there is an open-source version, they can do whatever they like with it, but if they really need something that is officially qualified, the open-source version is not qualified because it’s simply not possible due to the requirement of the qualification process.
Florian Gilcher 00:44:29 Yeah, is that exactly? Yeah. And our biggest customers are software factories in that sense, possessive for that reason.
Giovanni Asproni 00:44:35 Okay, now yeah, let’s go to moving to Rust, you know? Let’s say that there is a company that producing safety or safety critical systems. And they decide, you know what? We are using C, we’d like to move to Rust. Now what are the criteria to make such a decision? Are there any specific criteria they should look into?
Florian Gilcher 00:44:55 It’s always, first of all, do you have any pain? Like if you don’t do a technology switch because you’re not experiencing any pain. So it sounds so simple, but that is a mistake that I’ve seen over the last decade where people would just go, we need to do new, new hype thing. Because for example, new employees but no further thinking like, I’m not joking here. I’ve spoken to people that had no further thinking in this and the project has completely failed. So itís a standard engineering process nowadays. Identify a need particularly on these metrics. Do we think that Rust will increase productivity or increase us addressing the wish, for example, from nation states nowadays to put memory safety out there? It’s like memory safety has been a word in the US Senate appropriation bill at some point, it’s like, so people need to address that, and people now expect a memory safety story from their vendors.
Florian Gilcher 00:45:49 Do I have the engineers available? And the most important thing is do I have a project available? So in generally I recommend a good starter for starting to use Rust is you have a good team that you trust, you have something that you have the requirements written down for. And it’s not necessarily super timing critical so that you can, for example, it’s a new technology. Say like, okay, this was two wasted weeks, let’s oh it’s not wasted. You figure it out, you should do it differently. So it needs some breathing room. This is how we see Rust growing into organizations. It’s much more this, you start with a very small project and then that is successful. Then you try something more and then you try something more.
Giovanni Asproni 00:46:29 So it seems to be a process of basically learning, having the time to learn the new thing while creating the system in production pretty much. So having sufficient time. When you say not time critical, basically you don’t want kind of hard deadlines potentially for something that if doesn’t go well, you lose, and the company loses a lot of money or anything like that
Florian Gilcher 00:46:50 And you have no alternative.
Giovanni Asproni 00:46:51 And they have no alternative. Yeah.
Florian Gilcher 00:46:53 They are actually counterintuitively rewrites are actually good. Although people say never rewrite because the good thing with rewriting a small component in Rust is if that thing fails or doesn’t hit a ship date, you can still use the C version that you have on the shelf, for example. So the other thing we experience is there’s a new generation of managers, like I’ve also been a little bit into bringing Rust here, making it popular into in Germany, Ruby, sorry, not Rust. Both languages with RU. And I think that experience with the introduction and the growth of JavaScript Ruby that we had about, well now two decades ago, all of those people who have been part of that are slowly now in management. So it’s a much more repeatable thing. It’s programming like in this generation of programming languages, what I experienced is that managers are much more equipped for introducing fundamental technology than they were before. Which I think is a really, really good thing
Giovanni Asproni 00:47:48 Because they themselves experienced these kinds of changes in their own previous life as developers.
Florian Gilcher 00:47:54 Yes. And there’s much more a conversation about how this is a job and there’s certain standards and how you can apply this. So my biggest recommendation is don’t start too big, start small, start maybe on a system that you already know. Don’t switch your operating system right next to switching to a new programming language and things like that. So keep it isolated.
Giovanni Asproni 00:48:15 And you said also before that Rust has very good support for C libraries as well. So if they have their own libraries, frameworks, maybe with some important IP that the company, they can still use those from their last program.
Florian Gilcher 00:48:29 Yeah, and that comes a little bit out of the history of Rust. It was deployed in tools like for example, Firefox or in applications where, for example, the binding generator that Mozilla has written, which is still maintained by the Rust project called Rust BiGen is still an extremely solid piece that where every, basically every binding to a C library nowadays is mainly tool generated for C++. There’s also quite a lot of tooling that exists. And also there’s a C++ integration initiative that the Rust Foundation is running. And yeah, it exists. There’s a whole service market existing around that, not just Ferrous. There’s a lot of companies now outside, so we already have a mature service market where there’s, for example, already companies that specialize in advice on how to do particularly these kinds of integrations. And if you have a solid C++ code base, again, if you’re not in pain, like a rewrite of 1 million liner C++ into a new programming language, the programming language isn’t the issue, at least not the biggest issue. It’s like how much knowledge is in those 1 million lines of code that we have maybe lost, or someone just can’t write down. So that’s an issue
Giovanni Asproni 00:49:40 Actually, does Rust allow for say, incremental introduction in a system in a C or C++ system? Say we start writing parts in Rust bit by bit and remove the C or C++ one piece at a time?
Florian Gilcher 00:49:54 That is actually done. There’s a very good blog post series out there that the GNO team has written how they incrementally moved their SVG implementation. So scalable electro graphics into Rust. And they’ve done it function by function. So basically, they use that facility that Rust can call into C and C can call into Rust transparently by literally doing that function by function.
Giovanni Asproni 00:50:17 Okay. And how does this affect the qualification process or kind of for the system? When you say we are rewriting these bits and parts and Rust for the C system, how does that affect their Ö
Florian Gilcher 00:50:28 For the certification I would at least make sure that my library is either Rust or C. It doesn’t affect it a lot. Like mixed language systems in qualification are kind of normal. It’s just like Rust on top of a C based kernel is kind of new. But you have all of the other languages we certify systems that do Java.
Giovanni Asproni 00:50:51 Okay. So it’s feasible because it’s already something that has been done with other languages anyway. And there is no reason for not doing it in Rust.
Florian Gilcher 00:50:59 But you have this break where you need to talk about to your SSO, like this is the way we get data over from C into Rust and from Rust into C. That will definitely be something that needs to be addressed, but it’s, it is a standard procedure that people have done before.
Giovanni Asproni 00:51:14 So it is not, doesn’t require any new invention of procedures?
Florian Gilcher 00:51:18 No.
Giovanni Asproni 00:51:18 Or processes?
Florian Gilcher 00:51:20 No.
Giovanni Asproni 00:51:20 Okay. And also, so you said, you know, giving people the time to learn Rust, but an interesting aspect of what people say about Rust is that the learning curve can be quite steep. So are there any tradeoffs in terms of cost benefits here for learning the language and moving to it?
Florian Gilcher 00:51:39 Oh, I need to give a little bit of a longer answer to that. The learning curve of Rust used to be super steep for two reasons. These two concepts, ownership and borrowing were first of all very new. And that’s a problem that persists today is you can’t escape the two base concepts of Rust and there’s no other language that has them, which means you will need your two to three weeks to actually get at ease with them. What flattened that curve is, first of all, the Rust compiler was always known for its good diagnostics. But I can tell you I recently used Rust 1.0, oh, just for fun for the 10-year anniversary that we recently had. I would not want to use the diagnostics of Rust 1.0. So the diagnostics got way better. So the compiler tells people you should do it like this.
Florian Gilcher 00:52:25 This is broken. So that is the one thing. The second thing is Rust has very much a teaching culture, and second, because of these ideas becoming much more widespread, that already lowers the curve because you have far more people around you with a relatively deep understanding of what the language does. And that’s often underappreciated. As someone, I’m giving Rust training since 2015 and 2018, and I have to say my mental model around these things together with all the other trainers out there is something we had to solidify for three years on how do we explain this? And just like the community that teaches Rust is also getting better of like, okay, this is exactly how we teach, and this is how we do it. This lowered that barrier. So nowadays a lot of companies already have someone around who is at the level where they can competently explain and assess whether that’s correct use of those language features and all of that flattens that bit. It’s still, because of what I said, these two properties of the language hit you immediately, still means that bump is there. It’s very much in the beginning and you need to get over it.
Giovanni Asproni 00:53:30 Okay. But if I am understanding correctly, years ago the learning curve was much steeper. Now because of maybe familiarity, more people using the language, better teaching methods or learning have simplified this to an extent.
Florian Gilcher 00:53:44 And better tooling.
Giovanni Asproni 00:53:45 And better tooling as well.
Florian Gilcher 00:53:46 Better tooling addressing that. Yeah.
Giovanni Asproni 00:53:48 Yeah. Okay. And when somebody say some of these safety critical developers, more from C to Rust. You know, could be C, could be C++, let’s say from another language to Rust, how much of their technical expertise with the tools and things they had, they have to just give up?
Florian Gilcher 00:54:05 Thanks for that question. Not a lot. The thing I observe in programming language teaching is there’s also an amount where especially people who have been doing one programming language for their whole life and maybe go from C to C++, like as their main language often conflate about their programming skill as just their programming language, mentally. While in a lot of safety critical systems, we will use very specific micro controllers, very specific architectures, very specific ways on how to assemble a system. How two of these talks together, that stays all the same in Rust. So the language doesn’t have a lot of impact there. It is a different way on how we do the software development, but it’s not on the program or by firmware level. It is not a new thing, on the micro controller is still the same. And lo and behold, in one of our projects, just this one day we found a hardware bug. You can throw as much Rust as you want on a hardware bug or as much C as you want on a hardware bug. It stays a hardware bug.
Giovanni Asproni 00:55:05 Yeah.
Florian Gilcher 00:55:06 And if you are someone who has worked with hardware for a long time and looks at these things and says, this is off, this is a skill you can immediately transfer over to Rust.
Giovanni Asproni 00:55:16 I see. So basically, apart from learning a new language, pretty much everything else or most of the rest of the technical knowledge, expertise stays the same. So there is no real loss of expertise there. It’s more acquiring a new language than losing something. Am I correct?
Florian Gilcher 00:55:33 Exactly. Exactly. And I would even put that up to about 60 to 70% of what an engineer can do. And coming back to that question about the introduction, the engineers who are solid about those assessments are the best ones to introduce that new tool in your organization. Because what you want is an experience engineer that tells you, okay, these 70% we haven’t solved, but we got way better on the software side. And depending how much of their work is like, that may differ. We also have a lot of people that work mostly on the software side. So that calculation is a little bit different.
Giovanni Asproni 00:56:05 Okay. And another question that is both maybe interesting for companies, but also the developers themselves, you know, how big is the job market for Rust developers in this safety critical domain? Because I guess for a company it’s important because of course they want to have skills available if they need to help people. And for developers is important because yeah, well you know, see I find a lot of jobs. I really like Rust, I want to move to Rust. But you know, if the market is not big enough could be a problem to find a new job.
Florian Gilcher 00:56:37 It is growing and contracting. Like sometimes there’s just a lot of people that want to start doing Rust nowadays and then some companies grab them up and so on so forth. But in general, so the Rust market, first of all, it’s a little bit hard to assess because it’s a new market and there’s not a lot of tracking. There’s Rust jobs available at all major safety critical companies nowadays. I’ve seen them very often in the Q&M departments, like just the quality management side, because that’s usually where they start. But they have an interest in moving in. I’ve seen quite a few people leave their job taking a pay cut and going somewhere else just so that they could do Rust. So it’s also a thing that experienced engineers see that as their next career step. And that’s a way you can snatch them up if you have a project to offer. That’s something that we’ve seen. The biggest mistake that we’ve seen is in hiring, is a quite trivial one, is expecting too much Rust experience of potential hires. Because I know people in the Rust community who are extremely knowledgeable in the language, extremely knowledgeable in putting in off projects, but who have never worked Rust on a job because they’re C++ developer somewhere.
Giovanni Asproni 00:57:47 Yeah, okay.
Florian Gilcher 00:57:48 And they often fall through screening because it says not five years of professional Rust experience, but they have 30 years of professional systems programming experience not in Rust.
Giovanni Asproni 00:57:57 I think these is unfortunate things with all development jobs. Often companies look for specific language stuff when in fact experience programmers can pick up the specific skills very, very quickly.
Florian Gilcher 00:58:11 But the job market I think is mature. And my indicators for a mature market is people move jobs. Like people move away from Rust jobs into Rust jobs. I think that’s my most important indicator. There’s employee mobility. Thereís specialized recruiters actually just doing Rust recruiting, which also speaks a little bit to maturity. And most companies that I know that postage drops at the right places report. Yeah. We’re finding about 10 to 20 good applicants. The other thing is usually Rust jobs, and that’s something they hear from a lot of people that are hiring and also seeing in our own hiring data is the medium level of quality of the people who actually apply is pretty high. And who’s complaining about I have 10 to 20 pretty good pre-screened candidates rather than I have 200 with spot.
Giovanni Asproni 00:59:00 So actually, so if they have to screen fewer candidates, but they have a better chance to actually hire someone because the average level is higher anyway.
Florian Gilcher 00:59:08 Yes.
Giovanni Asproni 00:59:09 Okay. And so my last question is about the future. How do you envision the future of Rust in the safety critical domain?
Florian Gilcher 00:59:17 Okay. I envisioned itís pretty big. I honestly think Rust will become the next standard language for those areas. And the reason for that is memory safety will become a mandate in a lot of projects. And we are already seeing that. We’re seeing requests for quotations being handed around that say do only implement in a memory safe programming language. So that’s the one thing. So when we’re seeing like the buying side is far more interested in, you need to have a memory safety story and we’ll enter a space where, okay, I use a programming language where I need additional tooling, additional skilled engineers and so on, so forth. Or I could just take one that actually fits that bill right away. That is the one thing. The other thing I see though is there’s a very good interchange between all of those languages and C++ is still in the game to be completely fair there.
Florian Gilcher 01:00:11 And they say, it’s like competition is business. So that also applies to programming languages. So it is very important that a Swift and C++ are around because that also makes sure that the Rust team is not lazy. And I know for example, we have very good relationship with the C++ committee or some, I wouldn’t say like I can’t claim an official relationship with the C++ Committee, but we’ve been talking for years about things and I know everything that is done in the C++ site. They will also look at what Rust does. And we obviously look at what C++ does. LLVM has just announced last week that they want to have a committee in which they do safety information on the client compiler. And to put that open-source very similar to how we do it.
Giovanni Asproni 01:00:55 There is a good cross pollination between the world community.
Florian Gilcher 01:00:58 Yeah. As they say in Germany, there’s music in it. And this is much more the space where I want to be, where people go and meet and say like, okay, we have three technologies here and let’s figure out how we make it better and better.
Giovanni Asproni 01:01:10 Sounds a situation where there is a healthy competition in terms of trying to improve all these values, languages, and technologies.
Florian Gilcher 01:01:18 Yeah, exactly. And it’s important. Like we have literally millions and millions of lines of C and C++ code out there. It would be bad if we ended up saying, okay, this is done. No one cares about this. Like we, this is just structurally impossible. But it also means for a language like Rust going in and saying, okay, C is now how much from the sixties, like one of the oldest languages we still use in broad use C++ is a little bit younger. It would also be like, as engineers, we also need to say there’s probably a lot of learning that we can take from all these years. And not recommit those mistakes and put that into a new product. And Rust is just to be clear, there’s a debate that we very often have. Rust is an open-source project that sees itself as a product. So this is something that needs to go into the hands of users and needs to be designed with that mindset. And I actually think is one of the big factors in its success. Like aside from all of the details that mindset is of the most important thing is the user. And this is something where we have quite a lot of good exchange and I think we’re in a good space in terms of programming languages. If we love programming languages, we are in a great space.
Giovanni Asproni 01:02:32 Okay. Thanks Florian. So now we have come close to the end of the episode. Is there anything that we missed that you’d like to add?
Florian Gilcher 01:02:39 No, I think we talked about how all programming languages are great in the end. I think that’s a good ending.
Giovanni Asproni 01:02:47 Okay. So thank you Florian for coming to the show. It’s been a real pleasure. And this is Giovanni Asproni for Software Engineering Radio. Thank you for listening.
Florian Gilcher 01:02:56 Thank you and goodbye.
[End of Audio]
