> Also: Don't use linked lists, they are slow. They are, but they have the nice property of retaining the underlying memory as you add to the container, unlike a seq on a realloc due to exceeding capacity.
But of course, for this property, it would be better to opt a container similar to `std::dequeue` in C++-land (["In addition, insertion and deletion at either end of a deque never invalidates pointers or references to the rest of the elements."](https://en.cppreference.com/w/cpp/container/deque)) - it appears that nim's [std/deque doesn't seem to have](https://github.com/nim-lang/Nim/blob/version-2-0/lib/pure/collections/deques.nim#L246-L252) \- I don't think there is a container in the stdlib with this property? Correct me if I am wrong here. Here is an example scenario where this property is useful: * write into a container on thread 1 (only append/add data e.g. I/O loop) * iterate (read) over the container in thread 2 (e.g. UI thread) With a seq, you must set the capacity and ensure you don't exceed it as you write; if you go over capacity you can cause a realloc which will potentially be a SEGFAULT on thread 2 due to reading deallocated memory. With a std::dequeue or list it is fine. Even if the length changes during iteration, the code is still correct as we will never touch memory we have not assigned & is not free'd back.
