> That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past.
1. Many embedded applications do not use dynamic memory at all.
2. The runtime cost of a tracing garbage collector is largely a red herring. In a well-designed imperative program, all the cost involved with GC should not typically exceed 10% or so and manual memory management can only avoid part of that. On top of that, Rust's fallback option for shared ownership (Rc<T> and Arc<T>) are very expensive and can be worse than tracing GC. As I noted elsewhere, Rust is a very poor option when you have to deal with shared ownership (such as with persistent data structures).
3. Tracing GC does raise genuine issues in other situations (stack scanning in a multi-language environment, for example), but it's not the only established automatic memory management technique. There's no reason why you can't have a compiler switch to change to a different implementation.
4. Conversely, tracing GC can also have advantages, such as avoiding fragmentation for long-running processes (assuming the GC supports compaction).
> I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it.
There's nothing hackish about Swift's ARC. It's basically bog-standard reference counting, which has very well understood semantics, and then the compiler optimizes away reference count updates that aren't needed. The primary downside of the approach is that it can't handle cycles automatically, but then, neither can Rust. Other than that, it ticks off pretty much all the boxes that Rust does.
> I don't think I count techniques that aren't available in any language less obscure than Cyclone.
I'm not sure why, nor why you would tie it to languages. After all, MLKit is Standard ML, hardly a language more obscure than Cyclone; deferred reference counting was first implemented for Java (lots of memory management techniques have actually used Java as a testbed).
> You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is.
If you want to go into a more detailed discussion of Rust with respect to software engineering, then we'll also have to discuss the software engineering costs that Rust creates, and that becomes a fairly large topic.