Kieran Kunhya

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 a David or x264, right?

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 C part 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?

So which is compile time, check the assembly, which is similar to the check assembly projects that we're doing on David and x364 with Videoland.

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.

Oh, that was cool.

In the community, I want to speak about two people who are wizards of assembly, right?

The two of them are actually working, living in North of Europe, Sweden and Finland.

And Henrik Gramner knows so much about