> Like Rust but without the need for Rc and Arc boxes. Rust gets us 80% of the way there. I think you're qualifying Rc/Arc as kludges to get around the type sy

> Like Rust but without the need for Rc and Arc boxes. Rust gets us 80% of the way there. I think you're qualifying Rc/Arc as kludges to get around the type system. They may end up being used like that sometimes but when well used they are actually encoding extra semantics, just like &Type and &mut Type. A simple example is a cache get() method: pub fn get(&self, key: &K) -> Option<Arc<V>> https://docs.rs/multicache/0.5.0/multicache/struct.MultiCache.html#method.get https://docs.rs/multicache/0.5.0/multicache/struct.MultiCach... This allows you to get and use a cache value across your program and depending on outside input the value can disappear first in the cache by eviction or in the consumer. So Arc<V> is already expressing to the compiler the exact semantics. It just so happens that the actual lifetime is runtime defined from outside input so it must be managed dynamically. I don't see a general way around that without copying but maybe a lot more can be inferred automatically so you get similar ergonomics to a GC language by introducing Rc/Arc/etc automatically at compile time. I don't think that's a good fit for a system programming language like Rust though where you don't pay extra costs without asking for them explicitly. But maybe there's space for a higher level language that does all that magic and doesn't use a GC. Someone trademark Rustscript.