> At the very least: the cost of rewriting, re-testing, and re-deploying systems in a memory-safe language.
True. In most cases, this is completely outweighed by the benefit of not having these kinds of security vulnerabilities, as well as the other benefits that come with safety.
> The cost of realizing half-way through adoption that there are things that you need to do, used to be able to do, but cannot do in the new language.
Memory safety costs 10% in execution speed and takes 50% more effort to develop, a fair trade-off anyone can take on behalf of their customers. Shortcomings of C are offset by many eyeballs law and the security life-cycle processes so much so that we can afford to safely abandon most organized auditing as well as any defensive coding.
> Memory safety costs 10% in execution speed and takes 50% more effort to develop, a fair trade-off anyone can take on behalf of their customers.
That doesn't match my experience. Source?
> Shortcomings of C are offset by many eyeballs law and the security life-cycle processes so much so that we can afford to safely abandon most organized auditing as well as any defensive coding.
In effect, you're saying we shouldn't care about security vulnerabilities, because they'll be patched. That may be true for your projects. It's not true for many organizations.
No source. There's always a price to pay. Rust is zero-cost, but only on a subset of algorithms that are valid in idiomatic Rust. If you translate Rust to C you won't gain on speed, but if you translate C to Rust you might have to reorganize it and that will cost you. If your subset involved mostly increments and decrements of data and address registers then language called brainfuck would be zero-cost. Correct me if I'm wrong, but I'm led to believe at least some problems that would be most naturally expressed with graph structures will require reference counting when rewritten in safe Rust. Then again there are trade-offs in Rust that I might not be aware of, Singularity exceeded raw C in some instances by replacing overhead and functionality of MMU with static checking in compiler.
> In effect, you're saying we shouldn't care about security vulnerabilities
Cue a rant from spengler/deraadt. I was being sarcastic. We should rewrite most of our software in Rust 20 years ago. ;)
> If you translate Rust to C you won't gain on speed
Mostly this is the case, but we do give better aliasing info than C in many cases right now, and that can help optimizations. It depends a lot on your use case.
> Correct me if I'm wrong, but I'm led to believe at least some problems that would be most naturally expressed with graph structures will require reference counting when rewritten in safe Rust.
Most people use petgraph nowadays for graphs, which doesn't use RC; instead it uses indices, which are roughly the same cost as individual heap allocations. They have more computation for lookups, but the computation is usually folded into the addressing mode, and you get better cache behavior.
or use an arena (or backing store of handles, or graph of indices, or ...); which is basically the same situation as doing it in C unsafely with more or less the same cost.
> but only on a subset of algorithms that are valid in idiomatic Rust
IME almost all algorithms can be implemented in safe Rust, just that it takes some work to make it safe (e.g. using an arena, or shuffling some code around). The "limitations" of the borrow checker, for example (where it might be considered overzealous) can always be worked around by twiddling a few lines of code.
If it really comes to that (it shouldn't), you can always make your algorithm work with a few lines of unsafe Rust, and verify that locally. Still better than the entire thing being unsafe.
Regarding the 50% more effort to develop, we've gotten consistent feedback that the effort involved in writing Rust code is not more than any other typed language once you internalize some of its rules (which takes some time, but not too much).
Can you elaborate, in detail, what the costs of memory safety are?