Czytaj książkę: «Go на собеседовании: от новичка до Senior»

Глава 1. Go — это не C++ с другими скобками

Представь себе 2007 год, офис Google. Кен Томпсон, Роб Пайк и Роберт Гриземер ждут сборки очередного C++ сервиса. Сорок пять минут. Это не преувеличение, это реальность того времени. Три человека, создавшие Unix, Plan 9 и Inferno, смотрят на монитор и думают: неужели нельзя сделать язык, который компилируется мгновенно, читается как хороший скрипт и не заставляет разработчика помнить тысячу способов выстрелить себе в ногу.

Так родился Go. И чтобы понять этот язык, недостаточно выучить синтаксис. Нужно понять, какую боль он лечит и от каких инженерных привычек требует отказаться.

Простота как осознанный выбор

Первое, что нужно усвоить: простота в Go — это не ограничение, это философское решение. Создатели языка сознательно отказались от десятков фич, которые есть в C++, Java или Python. Здесь нет классов, нет наследования, нет исключений, нет перегрузки операторов, нет неявного приведения типов, нет аннотаций. Это не потому, что они не умели это делать, а потому, что каждая такая фича рано или поздно начинает работать против читаемости кода в большой команде.

Роб Пайк сформулировал это так: «Go должен помещаться в голове одного разработчика». Когда ты открываешь чужой код на Go, ты не гадаешь, какой магический метод вызовется при передаче аргумента. Ты видишь вызов функции и знаешь, что произойдёт. Всё явно, всё на поверхности. Это неудобно, когда ты пишешь код в одиночку и хочешь выразить мысль покороче. Это спасительно, когда ты в три часа ночи разбираешь чужой баг в продакшене.

Композиция вместо наследования

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

Go предлагает другой путь. Вместо «является» используется «имеет». Ты не говоришь «Service является Logger-ом», ты говоришь «Service имеет Logger внутри». Это называется композицией через встраивание. Ты берёшь маленькие, независимые кусочки поведения и собираешь из них нужную функциональность.

На собеседовании это один из маркерных вопросов. Когда кандидат начинает рассказывать про плюсы наследования, это нормально. Когда он объясняет, почему в Go наследования нет, и почему композиция снижает связность кода — это уже уровень выше.

Ошибки как значения

Ещё один культурный шок для новичка — обработка ошибок. Вместо try-catch-finally, который прячет поток управления за невидимыми прыжками по стеку, Go возвращает ошибку как обычное значение. Функция возвращает результат и ошибку, вызывающий код проверяет ошибку и принимает решение.

Да, это приводит к обилию строк с проверкой «if err != nil». Новички жалуются на это, ветераны пожимают плечами. Потому что явность важнее краткости. Когда ты читаешь код, ты видишь каждое место, где что-то может пойти не так. Ты не гадаешь, вылетит ли исключение из недр библиотеки, которую ты вызвал. Всё честно, всё на виду.

И да, есть способы сделать эту проверку менее назойливой. Можно оборачивать ошибки, добавляя контекст по мере подъёма по стеку вызовов. Можно использовать пакет errors из стандартной библиотеки, чтобы проверять типы ошибок. Но базовый принцип остаётся: ошибка — это значение, и относиться к ней нужно как к значению.

Ортогональность и минимум магии

Есть понятие, которое любят архитекторы: ортогональность. Это когда фичи языка не пересекаются, каждая решает свою задачу и не конфликтует с другими. В Go это проявляется на каждом шагу. Ключевое слово range работает одинаково с массивами, слайсами, мапами и каналами. Тебе не нужно помнить четыре разных синтаксиса. Интерфейсы удовлетворяются неявно: если твой тип реализует все методы интерфейса, он подходит. Не нужно писать длинное объявление о намерениях.

Ещё один пример — zero value. В Go переменная, объявленная без инициализации, всегда получает осмысленное значение по умолчанию. Число — ноль, строка — пустая строка, указатель — nil. Нет неопределённого поведения, нет мусора в памяти. Более того, некоторые типы спроектированы так, что их zero value готово к использованию без вызова конструктора. Ты можешь объявить sync.Mutex и сразу начать его использовать, не вызывая никакой init. Это не случайность, это инженерное решение, продуманное до мелочей.

Дженерики без фанатизма

Долгое время в Go не было дженериков, и это было предметом жарких споров. В 2022 году их наконец добавили, но добавили так, чтобы не сломать философию языка. Дженерики в Go существуют для написания библиотек и обобщённых структур данных, а не для бизнес-логики. Если ты ловишь себя на том, что каждую функцию начинаешь с квадратных скобок и параметра типа — скорее всего, ты пишешь не на Go, а на C++ с синтаксисом Go.

Что хочет услышать интервьюер

На собеседовании вопрос «почему Go» или «что тебе нравится в языке» — это проверка зрелости. Плохой ответ: «там горутины быстрые и синтаксис простой». Хороший ответ — про философию. Про явность вместо магии. Про композицию вместо наследования. Про то, что язык создан для инженеров, которые работают в больших командах над долгоживущими проектами, и каждое решение в дизайне языка подчинено этой цели.

Кстати, вопрос на засыпку, который иногда задают в начале собеседования: что произойдёт, если попытаться записать значение в nil-мапу. Правильный ответ — паника. Но важнее объяснить почему. Zero value для мапы — это nil. Читать из nil-мапы можно, вернётся zero value типа. А писать нельзя, потому что под капотом нет аллоцированной памяти для хеш-таблицы. Это маленький пример того, как философия zero value проявляет себя в реальном коде.

Глава 2. Указатели и семантика значений

Если первая глава была про мышление, то эта — про механику. Указатели в Go — тема, которая вызывает больше всего споров и ошибок, особенно у тех, кто пришёл из языков без ручного управления памятью. И одновременно это тема, которая позволяет отличить разработчика, действительно понимающего платформу, от того, кто просто пишет работающий код.

Что скрывается за звёздочкой

Начнём с самого простого. Указатель — это не значение, а адрес в памяти, по которому значение лежит. Когда ты создаёшь переменную, компилятор выделяет ей место где-то в оперативной памяти. У этого места есть числовой адрес. Указатель хранит этот адрес. Звёздочка перед указателем означает «пойди по этому адресу и дай мне то, что там лежит». Амперсанд перед переменной означает «дай мне адрес этой переменной».

Важно понимать, что в Go указатели существуют, но они гораздо безопаснее, чем в C или C++. Здесь нет арифметики указателей — ты не можешь прибавить единицу к адресу и получить доступ к соседней ячейке памяти. Нет ручного освобождения памяти — за этим следит сборщик мусора. Указатель в Go — это просто способ сослаться на одно и то же значение из разных мест, не более.

Главный вопрос: значение или указатель

Существует вопрос, который задают почти на каждом собеседовании по Go. Он звучит примерно так: «Вот у тебя есть структура и метод. Ты сделаешь receiver по значению или по указателю? Почему?». И ответ на него не может быть односложным.

Первый критерий — мутабельность. Если метод должен изменить состояние структуры, только указатель. Значение передаётся как копия, любые изменения внутри метода коснутся копии и исчезнут вместе с ней. Это частая ошибка новичков: пишешь метод с value receiver, меняешь поля, а снаружи ничего не происходит.

Второй критерий — размер структуры. Если структура большая, копирование при каждом вызове метода стоит тактов процессора и байт на стеке. Но здесь есть важный нюанс, который упускают многие кандидаты. Копирование значения на стеке — операция быстрая, процессор заточен под линейное чтение памяти. А вот указатель часто означает аллокацию в куче, за которой придёт сборщик мусора. Поэтому для маленьких структур из трёх-пяти полей копирование может быть эффективнее, чем возня с GC. Эмпирическая граница — примерно 64–128 байт, но без бенчмарка это гадание.

Третий критерий — природа типа. Есть типы, которые физически нельзя или бессмысленно копировать. Самый хрестоматийный пример — sync.Mutex. Если ты скопируешь мьютекс, копия будет представлять собой совершенно новый, независимый механизм блокировки. Заблокировал оригинал — копия об этом не знает. Это прямой путь к гонкам данных. Go даже имеет встроенный анализатор go vet, который кричит, если ты копируешь мьютекс. То же самое касается sync.WaitGroup, пулов соединений с базой данных и некоторых других типов, представляющих ресурс или состояние.

Семантика — это контракт

На уровне Senior от тебя ждут уже не просто перечисления критериев, а разговора о семантике. Билл Кеннеди, автор культового курса Ultimate Go, ввёл различение value semantics и pointer semantics. Это два разных контракта, два разных способа думать о данных.

Семантика значений означает, что каждый владеет своей копией данных. Ты передал значение в функцию — функция работает со своей копией, оригинал в безопасности. Это похоже на примитивные типы: когда ты передаёшь число, ты не ожидаешь, что оно изменится снаружи. Это безопасно, предсказуемо и иммутабельно по своей сути.

Семантика указателей означает совместное владение. Ты передал указатель — теперь у тебя и у функции одна и та же память. Изменения видны всем. Это гибко, но требует думать о конкурентном доступе и времени жизни объекта.

Ключевое правило, которое демонстрирует зрелость разработчика: в рамках одного типа нужно придерживаться одной семантики. Не смешивать методы с value receiver и pointer receiver без крайней необходимости. Если тип представляет собой нечто «живое» и изменяемое — соединение с базой, кеш, сессию пользователя — вся работа идёт через указатель. Если тип — просто контейнер для данных вроде координат точки или временной метки — он передаётся по значению.

Интерфейсы и указатели: вечный подвох

Есть одна ситуация, в которую попадаются почти все. Ты определяешь интерфейс, потом определяешь тип с методом и пытаешься присвоить значение этого типа переменной интерфейсного типа. И получаешь ошибку компиляции.

Разгадка в том, на чём именно определён метод. Если метод определён с pointer receiver, то он принадлежит указателю на тип, а не самому типу. Переменная-значение такого типа не имеет этого метода. Поэтому интерфейс удовлетворяет только указатель. И наоборот: если метод на значении, интерфейс удовлетворяют и значение, и указатель. Указатель всегда может разыменоваться до значения, а вот значение не может само стать указателем.

Кстати, Go умеет автоматически брать адрес переменной, если ты вызываешь метод с pointer receiver у переменной-значения. Но это работает только если переменная адресуема — то есть имеет конкретное место в памяти. Результат функции, литерал или константа не адресуемы, и автоматического взятия адреса не произойдёт.

Что остаётся после прочтения

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

На собеседовании не бойся начать ответ с этих слов: «Выбор receiver зависит от семантики типа». Это сразу показывает, что ты не просто выучил правило, а понимаешь, откуда оно взялось.