Often you don't need to care about the extra allocations and can just deserialize to owned types.
The code for owned deserialization certainly ends up looking more elegant.
I want to say that seems like a valid concern but in practice I've seen it come up only rarely.
Eg cloning a string leads to an extra allocation and a memcopy.
If you want to get a similar performance profile to GC languages, you have to stick your types behind a `Rc<T>>/Arc<T>` or `Rc<RefCell<T>> / Arc<Mutex<T>>` if you need mutability.
But modern allocators hold up pretty well to a GC, which amortizes the allocations. The extra memcopying can be less detrimental than one might think.
const obj1 = { a: 32, b: 42 };
function foo(ref) { ref.a = 0; }
foo(obj1);
console.log(obj1);
Basically all I was saying is one can not approach writing Rust with a Java/JavaScript mindset. (That a variable is just a bucket holding a value). Care needs to be taken when referencing a variable as it may need to be moved, copied/cloned or referenced. In the case of copying, another memory allocation is done. So if someone approaches Rust from the standpoint of "this word represents a value, and I'm going to use it all over the place", they can find themselves blindly allocating memory.