WEBVTT 00:03.360 --> 00:06.440 What do you think about the Rust programming language? Because that's a bit of a 00:06.940 --> 00:10.400 meme. We have very different opinions with Kiran. I think it's valuable 00:10.900 --> 00:14.200 what they're doing in terms of memory safety as a concept. Can it 00:14.700 --> 00:17.840 achieve some of the speed up that assembly achieves? 00:18.080 --> 00:21.840 Not assembly by hand? No. I think that that's a given C potentially, 00:22.340 --> 00:26.000 but I see it very. It has a very big Esperanto vibe about 00:26.500 --> 00:29.600 it. It's like we're going to solve this and we're doing this in a particular 00:29.760 --> 00:33.360 way. Meaning it's a bit too utopian. There's a lot of focus 00:33.860 --> 00:37.440 on the self importance rather than solving real world problems. It reminds me of 00:37.940 --> 00:41.400 the Sinclair C5. Sir Clive Sinclair of Sinclair Computers built 00:41.900 --> 00:45.200 a car and he said, oh, everyone will be traveling around in one 00:45.700 --> 00:49.200 of these electric cars. And it was Frost reminds 00:49.700 --> 00:53.440 me of that. Where I think the community doesn't quite 00:53.940 --> 00:57.080 understand that in order to get people to move, you have to build 00:57.580 --> 01:00.240 something that's as good as, if not better than what you have now. 01:01.040 --> 01:05.840 Yes, people are doing Rust rewrites, but if 01:06.340 --> 01:10.439 they only do 85, 90% of the feature set of what 01:10.939 --> 01:14.760 we need, like things like Core utils that last 1% takes 99% 01:15.260 --> 01:18.800 of the time to use Elon's famous quote, prototypes are easy, like this kind 01:19.300 --> 01:21.960 of stuff is easy. But this, to get a real electric car, you have to 01:22.460 --> 01:24.480 make a car as good as, if not better than what we have now. 01:24.980 --> 01:28.320 And Rust isn't in that stage yet. I think we. I don't think anyone 01:28.820 --> 01:32.200 would object to seeing rust code in FFmpeg, 01:32.440 --> 01:35.720 but it needs to work as well and support the same unit testing 01:36.220 --> 01:39.480 as everything else. It needs to be flawless. It can't just randomly break. 01:39.980 --> 01:42.600 They can't just randomly break ABI when they want to. It needs to. 01:43.400 --> 01:46.160 It needs to have, I think more. I think it still has only one compiler 01:46.660 --> 01:50.290 implementation. Yes. So it's got 01:50.790 --> 01:54.210 to be as good as, if not better. And saying, hey, here's my utopia 01:54.710 --> 01:58.530 of memory safety isn't enough. Even though we probably all agree that 01:59.030 --> 02:02.770 that's the goal. So I've done a ton 02:03.270 --> 02:07.330 of Rust and the two major topics I had was adding Rust modules inside 02:07.830 --> 02:11.290 vlc. One of the reasons VLC got popular and which was 02:11.790 --> 02:15.050 one of the main architecture decision is that VLC is a very 02:15.550 --> 02:18.810 small core and a ton of modules. Right. And so you can write modules 02:19.310 --> 02:23.470 in, in C, in Objective C and 02:23.970 --> 02:25.950 anything that is basically interoperable with C. 02:26.910 --> 02:30.630 And so we did some Rust modules And so I have 02:31.130 --> 02:34.670 experience on that and I wrote some of it. And also my new startup 02:35.170 --> 02:38.670 called Kyber, is an open source project mainly done in Rust. 02:40.670 --> 02:45.640 Rust is extremely good in the sense that it's 02:46.140 --> 02:49.480 a better C that cares about memory and allows you to do 02:49.980 --> 02:53.480 things about memory ownership that no one else can do. 02:53.640 --> 02:57.320 So far, however, it's great when you start 02:57.820 --> 03:01.800 a new project from scratch and you do everything in Rust, but it's 03:02.300 --> 03:05.600 very not good when you interrupt with existing part. 03:06.100 --> 03:09.880 And some part of the Rust community believes that they need to rewrite everything and 03:10.380 --> 03:13.760 everything will be better with Rust. And the answer is like, no, 03:14.260 --> 03:18.000 like I'm almost always. And all my years of 03:18.500 --> 03:21.680 being engineer, manager, CTO of startup and so on, 03:21.840 --> 03:23.520 don't rewrite, right? 03:24.960 --> 03:28.200 That's the initial instinct for a lot of people when they show up to a 03:28.700 --> 03:31.520 code base, probably before LLMs, is like, 03:32.400 --> 03:36.120 probably because they don't understand the 03:36.620 --> 03:38.600 wisdom of the way things have been done in the past. They say, well, 03:39.100 --> 03:42.520 we need to rewrite it, hence why there's a thousand JavaScript frameworks. 03:43.020 --> 03:46.200 But the reason is that the following, and this is very important to 03:46.700 --> 03:49.880 understand, it is an order of magnitude easier to 03:50.380 --> 03:54.280 write code than read code. And you see that also with LLM 03:54.780 --> 03:58.000 they can write code. Analyzing is a lot 03:58.480 --> 04:01.360 more difficult. And so when you arrive, 04:01.760 --> 04:04.920 and when you arrive to a very complex piece of code, 04:05.420 --> 04:08.680 right, you don't understand it, right? Because it's so 04:09.180 --> 04:12.360 much more effort to understand the code from someone else because you don't have the 04:12.860 --> 04:17.500 thought process. And often I joke about some 04:18.000 --> 04:21.460 languages, mostly Perl, for example, which has 04:21.960 --> 04:25.420 very complex syntax. And imagine I am at my maximum 04:25.660 --> 04:28.300 intellectual efficiency in programming, right? 04:28.860 --> 04:32.460 And I write the best code ever. I will not be able to understand 04:32.780 --> 04:36.260 myself six months later, right? Because reading code is 04:36.760 --> 04:40.260 more difficult. So very often you arrive, you don't understand all 04:40.760 --> 04:44.700 the wisdom, all the business logic, the reasons that were done that is maybe not 04:45.200 --> 04:48.600 documented. And you say, well, I'm going to write it. And the thing is, 04:48.760 --> 04:52.200 no you don't, right? Because that's, as Kiran said, I'm going to 04:52.700 --> 04:56.760 reroute coreutils in Rust. And then of course you arrive very quickly at 80%, 04:57.880 --> 05:01.480 then 90% takes a bit more time and then you got the last 05:01.720 --> 05:05.480 ones right on the other side, right? So for 05:05.980 --> 05:08.600 new projects it's great. Everything related to parsing files, 05:09.240 --> 05:12.480 networking, because of the memory checker, 05:12.980 --> 05:16.620 borrower, checker, it's amazing. And there is nothing else to answer. 05:17.120 --> 05:19.060 A bit differently for us, 05:20.180 --> 05:24.140 imagine I take a piece of software like David or 05:24.640 --> 05:28.180 X264 which has a ton of runtime in assembly, right? 05:29.220 --> 05:32.260 I rewrite the C part in Rust, right? So it's more secure. 05:32.420 --> 05:35.820 Yes but then you arrive into the assembly and you 05:36.320 --> 05:39.380 can jump anywhere in the memory because we are doing handwritten assembly. 05:39.940 --> 05:43.850 So even if I rewrite the CPOT in Rust for 05:44.350 --> 05:48.250 security reason you break all the security when 05:48.570 --> 05:51.690 you write handwritten assembly because we can jump anywhere. 05:52.250 --> 05:56.890 So in my opinion we need to do something that is secure 05:57.390 --> 06:01.170 assembly, right which is compile time check the assembly which 06:01.670 --> 06:04.970 is similar to the check assembly project that we're doing on 06:05.470 --> 06:10.980 David and x364 with Videolan is to start instrumenting 06:11.480 --> 06:14.780 your assembly at compile time to check that it's not jumping anywhere in 06:15.280 --> 06:19.020 the memory because else you might rewrite a part of C in Rust but 06:19.520 --> 06:21.980 if you want to have the same performances you're going to have inline assembly and 06:22.480 --> 06:25.980 so you destroy your whole security model. So that's a bit what 06:26.480 --> 06:26.900 I think about Rust.