Yeah, everyone expected Go to never implement any optimization if it is not in v1.0.
If they could have simply use LLVM they would be stuck with slow compilation that Rust folks are very fond of telling. And they would not be able to use segmented stack which was differentiating factor for language.
No, jesus christ, not every bad take is gaslighting.
IIRC, they were artificially capped at 1GB a few years ago since it was decided that stacks larger than that usually indicate an obvious bug, and if infinite recursion causes a goroutine stack to consume all memory on a machine, the OOM killer would make this harder to diagnose than a reproducible panic with a backtrace.
which one?
We didn't pay for it, so I'm not going to drag anyone personally for something that's a cultural issue. If you're worried because you might use it, you'll see it in your benchmarks just like we did. If you don't have benchmarks, it's the least of your performance concerns.
In which case I'd recommend jerf's post at http://www.jerf.org/iri/post/2955, or my comments at https://news.ycombinator.com/item?id=30804253, or even just reasoning a bit from first principles about how intermediate slices would perform given Go's memory/execution model.