> Plus D is adding Rust's ownership and borrowing Saying that "@live" feature is "adding Rust's ownership and borrowing" is technically accurate, but in realit

> Plus D is adding Rust's ownership and borrowing Saying that "@live" feature is "adding Rust's ownership and borrowing" is technically accurate, but in reality I'd be surprised if it were used in production in major systems in the next 5 years. The @live feature has multiple problems: - The author wants it to be implementable incrementally (eg some code uses @live, some doesn't), but doing so isn't really feasible in safe code. From the moment you disable GC, you either need your entire program to respect some strict memory model (in which case you basically have a new programming language, and no incrementality), or your program won't be any safer than C++. This is not hyperbole: Rust-with-unsafe and D-with-@system is safer than C++, because you only need to audit an annotated subset of your codebase. D-with-@live (or more accurately, D-with-@trusted-@live) is not safer, because a memory error can come from anywhere in your program. - Speaking of a memory model, D doesn't have one. Rust has Stacked Borrows, which gives library developers a framework to know whether their unsafe code might lead to undefined behavior. D doesn't seem to have nailed down semantics as to how @live might create/affect undefined behavior (which means the semantics will probably be "whatever the DMD/LLVM/GCC backend wants"). - Rust has Non-Lexical-Lifetimes (and soon Polonius). D's documentation is very sparse about how lifetimes in @live will be determined, but I think it's safe to assume that it will be scope-based at first. This means that, eventually, when @live ships, it will be roughly equivalent to Rust as it was in 2015. Not great. And, finally, saying that Rust will decline because another language will add OB misses what makes Rust great. The strength of Rust is that things work by default. A quick search through D's forums will raise dozens of instances of people complaining about edge cases in the language, things that don't work exactly as expected or produce undefined behavior (autodecoding and uninitialized variables come to mind). Rust has very few problems like that. If your Rust code compiles, it will work. You will never have a bug that happens on a coworker's machine but not on yours, or a crash that happens because you used two niche features that weren't designed to be used together. If your code crashes, it will be in a predictable, reproducible way, with an error message and a stack trace to tell you what to fix. Rust isn't perfect, but it's infinitely less fragile over time than D.