I think the thing to be very aware of is that all data, ALL data, in Erlang/Elixir is immutable. This is not just a language feature but implemented/enforced all the way down in the BEAM. This means that when mutating a structure and rebuilding “on the way up” you never have to make copies of the unchanged parts of the structure only the actual path down to the new parts. No one else can change them so you are always safe. So yes when appending a new element to the end of a list you need to rebuild the list cells but there is no need to copy the actual elements in the list.

This means that there is actually no copy instruction/call in the machine. Well, there is one for binaries but that exists for one special purpose.

Writing NIFs for accessing parts of deep structures would be fine but I am not certain that they would be very much faster than writing code instead.

I’m not sure if I understand you correctly, but given a list [1, 2, 3], you want to alter the second element that the list looks like [1, -2, 3] and change the pointer from the first element to the second as well?

Such that we get this:

old = 1 --->  2 ---> 3 ---> []

garbage =     2
new = 1 ---> -2 ---> 3 ---> []

This would brake my assumption, that I were able to use old as it was before. Also it would brake assumptions of the garbage collector about the structure of the heap (old items never reference newer ones).

If though I got you wron, can you please elaborate?

I’m not sure I get what you’re suggesting, but newer data can’t point to older data in Erlang, it would break the GC. So you can’t have a child node keep a reference to a parent.

https://www.erlang-solutions.com/blog/erlang-garbage-collector.html