After writing this comment I noticed it became a bit ranty, sorry for that. Something about this article rubbed a bit in the wrong way.

The relevant section seems to be this:

Browser engines and garbage-collected runtimes are classic examples of code that fights the borrow checker. You’re constantly juggling different memory regions: per-page arenas, shared caches, temporary buffers, objects with complex interdependencies. These patterns don’t map cleanly to Rust’s ownership model. You end up either paying performance costs (using indices instead of pointers, unnecessary clones) or diving into unsafe code where raw pointer ergonomics are poor and Miri becomes your constant companion.

The first half is obviously correct, this kind of data model doesn’t work well for the ownership model rust uses for its borrowchecker. I don’t like the conclusion though. Rust makes you pay the performance costs necessary to make your code safe. You would need to pay similar costs in other languages if you intend on writing safe code.

Sure, if you are fine with potential memory corruption bugs, you don’t need these costs, but that’s not how I would want to code.

The other thing bugging me is how miri being your companion is framed as something bad. Why? Miri is one the best things about rusts unsafe code tooling. It’s like valgrind, or sanitisers but better.

Now, the raw pointer ergonomics could be better, I’ll give them that. But if you dive deep into what rust does with raw pointers, or rather what they are planning to do, is really really cool. Provenance and supporting cheri natively is just not possible for languages that chose the ergonomic of a raw integer over what rust does.

Somewhere an accessibility developer is crying in a corner because of what you just typed

Edit: also, please please please do not use alt text for images to wrongly “tag” images. The alt text important for accessibility! Thanks.

Sorry where does the .deb version store the encryption keys if not in plaintext?