❓ Почему модули пришли на смену GOPATH

Главная проблема GOPATH заключалась в отсутствии контроля версий зависимостей.При использовании GOPATH система собирала проект из тех пакетов, которые уже находились на локальной машине.

Из-за этого разные разработчики могли получать различные версии зависимостей при сборке одного и того же проекта.

Go модули решили эту проблему, введя строгое версионирование. Они фиксируют точные версии всех зависимостей и используют файл go.sum для проверки их целостности.

Благодаря этому любой разработчик получает идентичный набор зависимостей при клонировании проекта.

🐸 Библиотека Go для собеса

❓ Объясните, почему в Go интерфейсы реализованы через внутренний кортеж (type, value)

Такой подход позволяет интерфейсу быть универсальным контейнером для любых типов, которые реализуют его методы. Благодаря этому Go может вызывать методы интерфейса динамически, независимо от конкретного типа объекта, который хранится внутри интерфейса.

В реализации это выглядит как структура с указателем на таблицу методов и указателем на конкретные данные.

Такое представление интерфейсов позволяет эффективно реализовать полиморфизм, динамический вызов методов и хранение различных типов в одном интерфейсе без потери информации о типе. При этом Go гарантирует безопасность типов на этапе компиляции и одновременно предоставляет гибкость работы с динамическими объектами во время выполнения.

🐸 Библиотека Go для собеса

❓ Объясните, чем отличается конкретный тип от типизированного интерфейса с точки зрения компилятора и рантайма

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

В рантайме конкретный тип представлен как обычная структура в памяти, и Go не хранит дополнительной информации о динамическом типе — всё известно заранее.

Типизированный интерфейс — это абстракция, которая описывает набор методов, но не фиксирует конкретный тип объекта. На этапе компиляции компилятор проверяет, что присваиваемый объект реализует все методы интерфейса, но сам конкретный тип известен только частично — как «реализует интерфейс».

В рантайме интерфейс хранит две вещи: динамический тип объекта (type) и динамическое значение (value). Это позволяет Go вызывать методы интерфейса динамически, независимо от конкретного типа объекта, который был присвоен интерфейсу.

Разница в том, что конкретный тип — это статическая, полностью известная структура, а интерфейс — динамическая обёртка, которая хранит тип и значение для полиморфного вызова методов.

🐸 Библиотека Go для собеса

❓ Как в Go сделать readonly коллекцию

В Go нет встроенного механизма readonly, как в C# или Java, поэтому неизменяемости достигают через инкапсуляцию и интерфейсы.

Например, если нужно сделать слайс доступным только для чтения, можно спрятать сам слайс в структуру, а наружу отдать интерфейс только с методами чтения.

type ReadonlySlice[T any] interface {
    Len() int
    Get(i int) T
}

type sliceWrapper[T any] struct {
    data []T
}

func (s *sliceWrapper[T]) Len() int    { return len(s.data) }
func (s *sliceWrapper[T]) Get(i int) T { return s.data[i] }

func NewReadonlySlice[T any](src []T) ReadonlySlice[T] {
    copyData := make([]T, len(src))
    copy(copyData, src)
    return &sliceWrapper[T]{data: copyData}
}

🐸 Библиотека Go для собеса

❓ Расскажите, что такое паттерн фабрика и в каких случаях его целесообразно использовать

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

Использовать фабрику стоит, когда:

• Нужна централизованная логика создания объектов;
• Требуется полиморфизм, чтобы клиент не знал конкретный тип;
• Планируется расширение системы новыми типами без изменения клиентского кода;
• Необходимо упростить тестирование через замену объектов на моки.

🐸 Библиотека Go для собеса

❓ Где Go хранит загруженные зависимости локально

Зависимости хранятся в GOPATH/pkg/mod (модульный кэш), а не в папке проекта. Это позволяет повторно использовать одну и ту же версию пакета в нескольких проектах.

🐸 Библиотека Go для собеса

❓ Как проверить, что контекст был отменён или достиг дедлайна

Каждый контекст, который может быть отменён (WithCancel, WithTimeout, WithDeadline), содержит канал Done(), который закрывается, когда контекст отменяется или истекает дедлайн.

select {
case <-ctx.Done():
    fmt.Println("Context cancelled or deadline exceeded:", ctx.Err())
default:
    // Продолжаем работу
}

Метод Err() позволяет получить конкретную причину, по которой контекст завершился.

ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()

time.Sleep(2 * time.Second) // превышаем таймаут

if err := ctx.Err(); err != nil {
    fmt.Println("Context error:", err) // выведет: DeadlineExceeded
}

🐸 Библиотека Go для собеса

❓Какие типы горутин есть в Go

Формально они не делятся на типы, но по применению можно выделить обычные (для асинхронных задач), для параллелизма (с sync.WaitGroup или каналами), для обработки событий (например, в серверах), в пуле воркеров (для управления нагрузкой) и фоновые (для длительных задач).

Их поведение определяется контекстом и механизмами синхронизации, такими как каналы или мьютексы.

🐸 Библиотека Go для собеса

❓ Можно ли использовать один контекст для нескольких горутин

Да, один контекст в Go можно использовать в нескольких горутинах одновременно.

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

Например, если создать контекст с таймаутом, несколько воркеров могут одновременно подписаться на ctx.Done(). Как только таймаут срабатывает или вызывается cancel(), канал закрывается, и все горутины получают сигнал и корректно завершают работу.

🐸 Библиотека Go для собеса

❓ Как работает исключающее или

XOR (исключающее ИЛИ) — это логическая и побитовая операция, которая возвращает 1, если входные биты различны, и 0, если они одинаковы.

Результат для двух битов:
0 XOR 0 = 0
0 XOR 1 = 1
1 XOR 0 = 1
1 XOR 1 = 0

🐸 Библиотека Go для собеса

❓ Зачем нужен пустой интерфейс

Пустой интерфейс — это универсальный контейнер, который может хранить значение любого типа. Он нужен, когда заранее неизвестен тип данных, с которыми будет работать функция или структура.

Примеры использования:

Коллекции разных типов

items := []interface{}{1, "hello", 3.14}

Функции с параметрами любых типов

func PrintValue(v interface{}) {
    fmt.Println(v)
}

Передача метаданных или контекста
Пустой интерфейс используется для хранения идентификаторов, параметров или значений в структурах типа map[string]interface{}.

🐸 Библиотека Go для собеса

❓ Какие библиотеки для логгирования вы знаете

log — стандартный пакет.

slog — стандартный пакет в Go 1.25+.

logrus — популярная библиотека, поддерживает уровни логов, хуки и форматирование (JSON, текст).

zap — высокопроизводительное структурированное логирование, оптимально для микросервисов.

zerolog — минимальная и быстрая библиотека с нулевыми аллокациями, подходит для высоких нагрузок.

🐸 Библиотека Go для собеса

❓ Что такое зомби-процесс в линукс

Зомби-процесс — это завершившийся процесс, который всё ещё числится в таблице процессов, потому что его родитель не вызвал wait() для чтения кода завершения. Такой процесс не использует память или CPU, но его PID и запись в таблице остаются.

По сути, это механизм ОС для передачи информации о завершении от дочернего процесса к родительскому. Если родитель забывает забрать статус, зомби остаётся висеть. Один-два зомби не страшны, но их накопление может переполнить таблицу процессов и блокировать запуск новых.

🐸 Библиотека Go для собеса

❓ Какие знаете бест практис по использованию интерфейсов

1. Чем меньше методов в интерфейсе — тем лучше. Классический пример — io.Reader и io.Writer. Один метод, зато супер универсально.

type Stringer interface {
    String() string
}

2. Принимать интерфейсы, а возвращать конкретные типы.

Это удобно и для тестов, и для читаемости. Функция, которая что-то использует, пусть принимает интерфейс, а фабрика или конструктор возвращает конкретный тип.

func Process(r io.Reader) error { ... }       // принимаем интерфейс
func NewBuffer() *bytes.Buffer { ... }       // возвращаем структуру

3. Не создавать интерфейсы на будущее. Если абстракция сейчас не нужна — лучше оставить конкретный тип, иначе код будет сложнее без пользы.

4. Переиспользовать стандартные интерфейсы, если они подходят. В стандартной библиотеке уже много хороших примеров — error, fmt.Stringer, context.Context.

5. Осторожно с interface{}. Это, по сути, отключение типизации. Если нужен универсальный контейнер — ок, но в остальном лучше обойтись конкретными интерфейсами или дженериками.

🐸 Библиотека Go для собеса

❓ Почему индексация начинается с нуля

Индексация с нуля исторически связана с тем, как данные хранятся в памяти.

Массив — это непрерывный участок памяти. Индекс элемента фактически является смещением от начала этого участка. Если первый элемент имеет индекс 0, то его адрес равен base_address + 0 * size. Для второго элемента — base_address + 1 * size и так далее.

Кроме того, нулевая индексация упрощает работу с циклами и диапазонами. Например, цикл for i := 0; i < len(arr); i++ интуитивно проходит весь массив без лишних корректировок. Если бы индексация начиналась с единицы, пришлось бы постоянно делать «−1» или «+1» в выражениях.

🐸 Библиотека Go для собеса