История изменений

Сборщик мусора поколениями не имеет смысла в Go, поскольку Go не сует локальные объекты в кучу. Весь смысл сборки поколениями ведь заключается в том, что в ЯП кучу объектов создается локально и локально же уничтожается. В Go всё это тупо происходит в стэке вызова функции, ни до какой кчи и сборщика мусора оно не доходит, там оказываются либо большие объекты, либо уже не локальные.

Я go не знаю, но как же аллоцируются объекты которые должны вернуться из функции? Как например в factory method.

Работет механизм похожий на RVO в cpp? Когда аллокация в стеке происходит до вызова функции сразу под возвращаемое значение? Я так понимаю никакого динамического связывания интерфейсов и имплементаций в го нет, во многих случаях размеры необходимой области можно найти в compile time, но если вернуть коллекцию то без аллокация в куче не обойтись, размер ведь заранее нельзя угадать.

Сборщик мусора поколениями не имеет смысла в Go, поскольку Go не сует локальные объекты в кучу. Весь смысл сборки поколениями ведь заключается в том, что в ЯП кучу объектов создается локально и локально же уничтожается. В Go всё это тупо происходит в стэке вызова функции, ни до какой кчи и сборщика мусора оно не доходит, там оказываются либо большие объекты, либо уже не локальные.

Я go не знаю, но как же аллоцируются объекты которые должны вернуться из функции? Как например в factory method.

Работет механизм похожий на RVO в cpp? Когда аллокация в стеке происходит до вызова функции сразу под возвращаемое значение? Я так понимаю никакого динамического связывания интерфейсов и имплементаций в го нет, но если вернуть коллекцию то без аллокация в куче не обойтись, размер ведь заранее нельзя угадать.

Сборщик мусора поколениями не имеет смысла в Go, поскольку Go не сует локальные объекты в кучу. Весь смысл сборки поколениями ведь заключается в том, что в ЯП кучу объектов создается локально и локально же уничтожается. В Go всё это тупо происходит в стэке вызова функции, ни до какой кчи и сборщика мусора оно не доходит, там оказываются либо большие объекты, либо уже не локальные.

Я go не знаю, но как же аллоцируются объекты которые должны вернуться из функции? как пример в factory method.

Механизм похожий RVO в cpp? Когда аллокация в стеке происходит до вызова функции сразу под возвращаемое значение? Я так понимаю никакого динмаического связывания интерфейсов и имплементаций в го нет, но если вернуть коллекцию то без аллокация в куче не обойтись, размер ведь заранее нельзя угадать.