I agree that not having to reason about lifetimes can lower the cost of software development. However, GC is a very well-developed field, both in research and i

I agree that not having to reason about lifetimes can lower the cost of software development. However, GC is a very well-developed field, both in research and in practice, and I don't expect any game-changing breakthroughs there in the forseeable future. All GCs impose significant performance tradeoffs --- forcing you to take a hit on at least one of (worst-case) latency, throughput, and memory overhead. Apart from pure reference-counting, they require some sort of runtime support and make it difficult to write code that can be used as a library by non-cooperative applications (e.g. C programs). (Hardware support for GC can be interesting but then you have the problem that there's no one-size-fits-all GC that works well for all languages and workloads.) I agree that for some applications the overheads of GC are fine and wrangling lifetimes is tricky enough you should use a GC-based language, not Rust (and probably not Swift either, since it's easy to write Swift-style reference counting in Rust). However --- Rust lifetimes are about more than just memory safety and performance. They also enable data race freedom and strong control over aliasing, which prevent other kinds of bugs and can enable higher degrees of optimization. They enable affine types, which let you write APIs with very nice static guarantees, e.g. that a Nonce value is only used once. I don't think we're fully exploiting Rust lifetimes yet. It's also important to remember that for many applications Rust lifetimes are hardly any burden at all. For lots of code I write --- serial, synchronous code manipulating off-the-shelf data structures where the overall shape of the heap is tree-ish, or DAG-ish and reference counting is acceptable --- I hardly have to think about them at all.