Again, all this confusion is due to not being clear about virtual and physical memory. Every OS thread in linux does have a fixed virtual memory size (it is claimed when a thread is created, but this claim is on the virtual memory. This value is fixed at creation time). As you grow your program's conceptual stack in this virtual memory area, you would soon hit new pages of virtual memory, leading to page faults and linux allocating physical memory for you.

From a virtual memory standpoint, every thread would appear to have a fixed size which can be set when you create it. [0]

From a physical memory standpoint, every thread would appear to have a dynamic size (but bounded by the virtual memory size of course).

[0] http://man7.org/linux/man-pages/man3/pthread_create.3.html

The article makes a number of authoritative claims without providing much in the way of references to other more scholarly work. One might characterize it as an opinion piece masquerading as serious analysis. Nevertheless, I found it thought-provoking and I'm learning a lot by reading the comments here.

One error I spotted is that at 4kb each, 1GB only gets you 250,000 goroutines (i.e. article is wrong by an order of magnitude). Easy mistake to make, but bad in a comparison article.

FTA: "With 4KB per stack, you can put 2.5 million goroutines in a gigabyte of RAM – a huge improvement over Java’s 1MB per thread"