Once all the backwards-compatible work is done, say in Go 1.20, then we can make the backwards-incompatible changes in Go 2.0. If there turn out to be no backwards-incompatible changes, maybe we just declare that Go 1.20 is Go 2.0. Either way, at that point we will transition from working on the Go 1.X release sequence to working on the Go 2.X sequence, perhaps with an extended support window for the final Go 1.X release.

https://blog.golang.org/toward-go2

var cmd *exec.Cmd
 cmd = exec.CommandContext(ctx,pass7z,"e",path,"-o"+dest)
 cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true}
 return cmd
}

Ну там один нормальный способ, новая структура с эмбеддингом интерфейса.
Рефлект тут странно использовать.

Механизм тот же но поверх очень много кода в рефлекте. Не редко неоптимизированного.

Так это крохи должны быть.
Да и нет существенной разницы между хипом и стеком, если значение лежит в кеше

Это статья 17 года.

А еще нет существенной разницы между хипом и стеком, если значение один раз аллоцировалось и переиспользуется, логично.

Только потом в итоге на практике оно срет в хип на каждый запрос, т.к. это редкость.

Привет, есть вообще комьюнити gokit ?

Ну gc - это параллельная история

А есть новее, где сказано, что го 2 не будет?

хип обходится GC а стек нет. обход GC затратен (правда редко, но все же)

Могу рассказать как аллоцировать без печали gc ;)

давай

слинковать jemalloc

Аллоцировать силами cgo/mmap

Ну да.

А я думал тут ща будет трюк вида "на старте выделить огромный массив и его не трогать"

Можно выделить и использовать объекты из него, да

* тут должен быть мем про тролейбус из буханки хлеба