> 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.
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.
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.
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.
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.