Комментарии 11
Роб Пайк сказал, что простое лучше, чем сложное.
Вроде это из манифеста python третий пункт, он Guido van Rossum :)
Спасибо за статью!
KISS важен :) Не совсем к теме статьи, но добавил бы что можно еще поисследовать репозитории людей которые очень давно пишут на go: пример1, пример2, пример3, пример4, пример5.
Там можно подтянуть конфиги линтеров, посмотреть как пишется документация к функциям, как проекты структурируются. Тоже может быть полезно.
когда по-другому никак
Не только map, но и slice и string будут передаваться "по ссылке".
Но если строки к счастью не получится модифицировать внутри если не "хитрить" например с unsafe указателями, то для слайсов есть нюансы. Например, если внутри функции слайс переаллоцируется, то исходный слайс не меняется, так как на стеке создаётся временный.
Переаллоцирование слайса гарантированно случится если требуется перераспределение памяти при изменении его capacity. Но так же почему-то новый слайс создастся внутри из-за append'а ДАЖЕ если capacity оригинального слайса достаточное.
Категорически не согласен.
Для начала стоит сказать, что "переаллоцирование слайса" не происходит. Слайс - это просто структура, которая под собой содержит len, capacity, и указатель на массив, который содержит элементы слайса. Если и происходит переаллокация, то именно массива, а не слайса.
В функции modifyByAppend на самом деле ничего не переаллоцируется, а пишется значение просто в следующий байт и меняется len на 2, но т.к. значение длины пишется не в тот же самый слайс, по выходу из функции len остается 1. Дальше думаю происходит магия println, который просто не выводит элементы с индексом больше чем len.
Проверить, что значение в modifyByAppend остается в памяти можно через пакет unsafe.
Согласен, с терминологией порой возникает путаница. Сказал переалоцирование слайса, так как append применяется к слайсу и внешне это именно так и воспринимается, а так да, переалоцирование массива на котором построен(?) слайс.
Думаю, что и термин "передаваться по ссылке" не совсем точный, точнее было бы сказать, что когда аргумент - это указатель, то внутрь функции попадает копия этого указателя, до тех пор, пока никто эту копию не изменил, и спокойно меняет память указываемую оригинальным и скопированным указателем, путаницы не возникает, так как указывают они на одну память.
Тут чуть сложнее, не копия указателя, а копия структуры слайса, где хранится указатель на массив на котором построен слайс.
Но как только внутри функции указатель в копии слайса переписали новым значением (что, вероятно, и делает append вызываемый внутри функции при недостатке capacity), память массива оригинального слайса будет отличаться от того, который был скопирован в функцию, и результат будет неожиданным, если на это не обратить внимание.
А про длину нового слайса тоже стало понятнее, спасибо за подсказку. Длина меняется в копии структуры слайса и наружу никак не попадает. И чтобы это случилось, надо передавать указатель на слайс.
Если один метод в структуре изменяет объект, а другой — нет, мы все равно ставим приемник со звездочкой, чтобы это было удобнее читать
Разве это основная мотивация?
У интерфейсов есть нюанс, который оберегает нас от неожиданной модификации аргумента
Это не нюанс интерфейсов, а различие между *Bar и Bar. Bar не включает в себя методы *Bar, а вот обратный вариант уже включает.
Странно, у меня эскейп анализ выкатывал на стек объекты чуть больше 100 байт на раз.. но, в целом .. не жалею что перешёл с но на С++, хотя приходится много чего изучать повторно. Да, правда теперь забываю ставить круглые скобки у if, for.. Но уже оценил выразительность языка в отличии от го.
const char const * const myfunc() имеет свой смысл каждый модификатор.. мелочь, а приятно.
В таком ракурсе - да, но могут быть нюансы в С/С++.. ;) В целом, к тому, что язык позволяет точно указывать что хотел разработчик, а не вот это вот "го..". Автор ещё умолчал о проблемах эскейп-анализа, катастрофически влияющих на производительность кода (всё в кучу, в т.ч. и сам стек, никаких инлайн с деферами, и пр.), оригинальный гарбадж-коллектор, запускающийся по умолчанию через .. 1.5секунды от старта (сколько запросов отработает микросервис за это время?) и прочие дефекты, которые вылезают как плата за скорость написания кода.. ГО - это ни разу не про хайлоад в целом. После ковыряния в потрохах Го, Роб Пайк сильно проиграл в моих глазах .. а ведь было время.. ;)
Это ИМХО, спорить не собираюсь, как это было на собеседовании с автором топика.. хорошо, что не попал.. рад. :)
Простые правила, которые помогают мне писать на Go без побочных эффектов