[edude03]

> just because it's not in your favorite language.

Kind of a strawman argument though. The question is, is the 5% difference (today) worth the memory safety guaranties? IE, would you be OK if your browser used 5% more power displaying video, if it meant you couldn't be hacked via a memory safety bug.

[mvanbaak]

No, it wouldn't

Because it also means your battery drains 5% faster, it gets hotter, you will need to upgrade your media player device etc etc etc.

Seen on the scale of the actual deployment, this is HUGE.

[viraptor]

And yet we collectively got a bigger hit across the board with the speculative exploit mitigations. We made that choice and we'll make it again.

[imtringued]

I would take the hit. It's irrelevant. I personally am forced to work with security placebo software that causes a 20x slow down for basic things. Something that should take seconds takes minutes and nobody is arguing about even making it 1% faster.

[astrange]

It can't cause that kind of slowdown in realtime operations or you wouldn't be able to use any kind of audio at all.

[Ragnarork]

I can agree on the strawman but parent I responded to was mentioning "silly reasons" for not choosing a Rust implementation over a C one. A 5% performance difference in that space is anything but a silly reason.

Also glancing over the implementation of rav1d, it seems to have some C dependencies, but also unsafe code in some places. This to me makes banging the drum of memory safety - as it is often done whenever a Rust option is discussed, for obvious reasons since it's one of the main selling point of the language - a bit moot here.

[viraptor]

You're saying pushing the memory safety improvements is moot because they have only reduced the unsafe code of the whole library to 10 or so cases where the reason is documented next to the block? (There are open PRs for reducing that too) Not worth banging the drum of memory safety until they reach 100%? That's literally letting the perfection get in the way of huge improvements.