Rust vs C vs Assembly programming languages - FFmpeg developer explains | Lex Fridman Podcast - https://www.youtube.com/watch?v=k92DumKjoqs

What do you think about the Rust programming language? Because that's a bit of a meme. We have very different opinions with Kiran. I think it's valuable what they're doing in terms of memory safety as a concept. Can it achieve some of the speed up that assembly achieves? Not assembly by hand? No. I think that that's a given C potentially, but I see it very. It has a very big Esperanto vibe about it. It's like we're going to solve this and we're doing this in a particular way. Meaning it's a bit too utopian. There's a lot of focus on the self importance rather than solving real world problems. It reminds me of the Sinclair C5. Sir Clive Sinclair of Sinclair Computers built a car and he said, oh, everyone will be traveling around in one of these electric cars. And it was Frost reminds me of that. Where I think the community doesn't quite understand that in order to get people to move, you have to build something that's as good as, if not better than what you have now. Yes, people are doing Rust rewrites, but if they only do 85, 90% of the feature set of what we need, like things like Core utils that last 1% takes 99% of the time to use Elon's famous quote, prototypes are easy, like this kind of stuff is easy. But this, to get a real electric car, you have to make a car as good as, if not better than what we have now. And Rust isn't in that stage yet. I think we. I don't think anyone would object to seeing rust code in FFmpeg, but it needs to work as well and support the same unit testing as everything else. It needs to be flawless. It can't just randomly break. They can't just randomly break ABI when they want to. It needs to. It needs to have, I think more. I think it still has only one compiler implementation. Yes. So it's got to be as good as, if not better. And saying, hey, here's my utopia of memory safety isn't enough. Even though we probably all agree that that's the goal. So I've done a ton of Rust and the two major topics I had was adding Rust modules inside vlc. One of the reasons VLC got popular and which was one of the main architecture decision is that VLC is a very small core and a ton of modules. Right. And so you can write modules in, in C, in Objective C and anything that is basically interoperable with C. And so we did some Rust modules And so I have experience on that and I wrote some of it. And also my new startup called Kyber, is an open source project mainly done in Rust. Rust is extremely good in the sense that it's a better C that cares about memory and allows you to do things about memory ownership that no one else can do. So far, however, it's great when you start a new project from scratch and you do everything in Rust, but it's very not good when you interrupt with existing part. And some part of the Rust community believes that they need to rewrite everything and everything will be better with Rust. And the answer is like, no, like I'm almost always. And all my years of being engineer, manager, CTO of startup and so on, don't rewrite, right? That's the initial instinct for a lot of people when they show up to a code base, probably before LLMs, is like, probably because they don't understand the wisdom of the way things have been done in the past. They say, well, we need to rewrite it, hence why there's a thousand JavaScript frameworks. But the reason is that the following, and this is very important to understand, it is an order of magnitude easier to write code than read code. And you see that also with LLM they can write code. Analyzing is a lot more difficult. And so when you arrive, and when you arrive to a very complex piece of code, right, you don't understand it, right? Because it's so much more effort to understand the code from someone else because you don't have the thought process. And often I joke about some languages, mostly Perl, for example, which has very complex syntax. And imagine I am at my maximum intellectual efficiency in programming, right? And I write the best code ever. I will not be able to understand myself six months later, right? Because reading code is more difficult. So very often you arrive, you don't understand all the wisdom, all the business logic, the reasons that were done that is maybe not documented. And you say, well, I'm going to write it. And the thing is, no you don't, right? Because that's, as Kiran said, I'm going to reroute coreutils in Rust. And then of course you arrive very quickly at 80%, then 90% takes a bit more time and then you got the last ones right on the other side, right? So for new projects it's great. Everything related to parsing files, networking, because of the memory checker, borrower, checker, it's amazing. And there is nothing else to answer. A bit differently for us, imagine I take a piece of software like David or X264 which has a ton of runtime in assembly, right? I rewrite the C part in Rust, right? So it's more secure. Yes but then you arrive into the assembly and you can jump anywhere in the memory because we are doing handwritten assembly. So even if I rewrite the CPOT in Rust for security reason you break all the security when you write handwritten assembly because we can jump anywhere. So in my opinion we need to do something that is secure assembly, right which is compile time check the assembly which is similar to the check assembly project that we're doing on David and x364 with Videolan is to start instrumenting your assembly at compile time to check that it's not jumping anywhere in the memory because else you might rewrite a part of C in Rust but if you want to have the same performances you're going to have inline assembly and so you destroy your whole security model. So that's a bit what I think about Rust.