[akira2501]

Ironically the libc itself fails to document how large of a stack you should have before you call into it. Which is why go, having goroutines, tried to avoid it in the first place.

They didn't "get burned" they were "trying to provide a nice feature that wasn't as broadly compatible as they had hoped."

[int_19h]

When Go first shipped, it was already well-documented that the only stable ABI on some platforms was via dynamic libraries (such as libc) provided by said platforms. Go knowingly and deliberately ignored this on the assumption that they can get away with it. And then this happened:

https://github.com/golang/go/issues/16606

If that's not "getting burned", I don't know what is. "Trying to provide a nice feature" is an excuse, and it can be argued that it is a valid and justifiable one, but nevertheless they knew that they were using an unstable ABI that could be pulled out from under them at any moment, and decided that it's worth the risk. I don't see what that has to do with "not being as broadly compatible as they had hoped", since it was all known well in advance.