Hacker News new | ask | show | jobs
by int_19h 810 days ago
They knew it all along, since it's well-documented. But they don't seem to care about it until they get burned. Which first happened on macOS, so that was switched; then OpenBSD.

This was previously discussed at length here: https://news.ycombinator.com/item?id=25999623
2 comments
akira2501 810 days ago
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."

link
int_19h 809 days ago
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.

link
pjmlp 810 days ago
Like many other decisions, and as it happens with other technologies, reaching for it is a decision that outweights my preferences, given how it has managed to become unavoidable in many CNCF and DevOps products.
link