Often it's infeasible to justify rewriting a lot of existing code, but my point is that these days this concern shouldn't really be an obstacle to integrating a new codec.

It should certainly lower the bar of adopting a new codec if the implementation is in a memory-safe language.

Even so, it is more code, and somewhat more risk. Lack of safety elsewhere might end up using code that is otherwise safe in order to build an exploit (by sending it something invalid that breaks an invariant, or building gadgets out of it, etc.).

Adding something in rust into a browser means you now need to bundle all of the needed crates and that your browser now also needs rustc to build… at a minimum.

You also need potentially to audit all the crates and keep them up to date and so on… without crates you can't do so much.

I can see that for components heavily interfacing with high surface area things like encryption, hardware interfacing etc., but why would that be true for a relatively “pure” computational problem like an image codec? Bytes in, bytes out.