> But of course, the paper says nothing of the sort; it makes an aside about how an earlier design of the Go runtime was less scalable than the current one, and

> But of course, the paper says nothing of the sort; it makes an aside about how an earlier design of the Go runtime was less scalable than the current one, and that's it. The paper makes two references to Go: one to talk about split stacks, and one to reference the FFI (specifically, cgo). Cgo absolutely still has large overhead. That was true when the paper is written, and it's true today. It's inherent to the M:N small-stack design that your FFI calls that require big stacks require switching from a small stack to a big stack. You cannot get that overhead down to zero; it's a fundamental tradeoff of the design. Go's solution here is to try to minimize the amount of FFI usage. As the paper points out, that may work for Go, but will absolutely not work for many other use cases.