10 ms·
I think this is a trade-off, between configurability/expressiveness and simplicity. Historically, the Go team has favored simplicity. My impression is that the
by gen220 8y ago
I think this is a trade-off, between configurability/expressiveness and simplicity. Historically, the Go team has favored simplicity. My impression is that the Go team would believe that exposing such a runtime config isn't a good idea. Personally, I agree with you it'd be nice to pre-alloc. But I also think that exposing such an option would probably create more bugs than it would solve.
I believe they'd prefer to improve the runtime's internal stack allocation algorithm, while keeping it opaque to the average developer. The proposal mentioned elsewhere in this thread, to re-use allocated routines "under the covers" is an example in that direction.
Until they implement something like that (essentially, routine-pooling) in the runtime, these apps will just have to use routine pooling at the application level – which I suppose isn't that bad, after all?