[netbioserror]

Dynamic data structures by their nature have to be allocated to the heap. What I mean by "prefers the stack" is that you don't have to make a managed ref and dereference a managed pointer type. You just make a `seq[int]`, use it as a `seq[int]`, and pass it as a `seq[int]`, just like stack data. Behind the scenes, it has a unique scoped pointer with no mental overhead.

[jitl]

Sounds like a vector/array/list in any other language after C++, like Go slice, Java ArrayList, Javascript array, Python list, Rust vec. Is there something I'm missing?

[gcoakes]

I think they're discussing the lifetime of that heap data, not whether the data is heap allocated.

[chc]

I don't see them drawing any distinctions from C++ or Rust there either. It really sounds to me like most of their low-level experience is in C, where the contrasts they appear to be drawing really do apply.

[kragen]

it depends on what you mean by 'dynamic' and 'stack'; certainly, outside of nim, you can allocate a list of, say, integers entirely on a stack in any of the following cases:

- the size of the list is known when you create a stack frame, as in c:

    int xs[n] = {0};

- when the list grows, it grows in that subroutine and not some callee, for example using alloca();

- the list is built on a stack that isn't the one you have to pop your return address off of; examples include perl's data stack, ada's secondary stack, forth's operand stack, forth's dictionary, or an mlkit region. in these cases you can even return the dynamically built structure to a caller;

- each new callee adds some fixed number of items to a linked list, such as, in c

    void with_fill(color *c, 
        env *e, 
        void (*cb)(void*, env*), 
        void *userdata)
    {
      env ne = {
        .prop = PROP_FILL_COLOR,
        .val = c,
        .parent = e };
      cb(userdata, &ne);
    }

look ma, no heap