Читать книгу Full stack Developer - Группа авторов - Страница 5

Go (или Golang) часто выбирают люди, которые любят, когда всё просто, предсказуемо и быстро. Это язык, который создавали с идеей:

«давайте писать серверы и утилиты так, чтобы их легко было собирать, деплоить и поддерживать».

Go редко восхищает «красотой абстракций», но часто восхищает тем, что:

– сервис собирается в один бинарник,

– работает стабильно,

– жрёт мало,

– и не просит от вас философии на тему DI-контейнеров.

4.1. Что обычно значит «Go-бэкенд»

Типичный Go-сервис:

– Go 1.21+ (или близко к актуальному).

– HTTP API на стандартной библиотеке `net/http` или на роутерах/фреймворках (их много, но часто берут минимум).

– Работа с БД через драйвер + тонкий слой репозитория.

– JSON, gRPC, очереди – всё по ситуации.

– Лёгкий контейнер/деплой: один бинарник + конфиг.

Go-сервисы часто выглядят «прямолинейно». И это не недостаток: это стиль.

4.2. Что поставить для работы

Минимально:

– Go (официальный дистрибутив).

– Редактор:

– VS Code + Go-плагин,

– или GoLand (если хотите «как в Java мире, но для Go»).

– Docker (БД, Redis, брокеры).

– Утилиты:

– `golangci-lint` (сборный линтер),

– `go test` (встроенные тесты),

– `pprof` (профилирование),

– `delve` (отладчик).

Go хорош тем, что «поставил Go – и почти всё уже есть». Это очень приятное чувство после миров, где нужно собрать пазл из 12 инструментов.

4.3. Плюсы Go

Плюс 1. Простота языка и предсказуемость

Go специально ограничивали по фичам, чтобы:

– код читался одинаково в разных командах,

– стиль был более-менее единым,

– поведение было понятным без «магии».

Поначалу кажется: «а где мои любимые фишки?»

Потом начинаешь ценить: «о, тут сложно написать слишком хитро».

Практический эффект:

– проще ревьюить код,

– проще онбордить людей,

– меньше «архитектурных религий» внутри команды.

Go как будто говорит: «давайте решим задачу, а не устроим конкурс абстракций».

Плюс 2. Быстрые бинарники и низкое потребление ресурсов

Go компилируется в один бинарник. Это даёт:

– простой деплой (особенно в контейнерах),

– меньше проблем с окружением,

– быстрый старт сервиса,

– хорошую эффективность по памяти и CPU (обычно).

Для платформенных команд это почти музыка:

– один файл,

– понятная конфигурация,

– легко катать в Kubernetes,

– быстро поднимать новые инстансы.

Если у вас много микросервисов, это ощущается особенно сильно: меньше инфраструктурной «возни».

Плюс 3. Отличная конкурентность: goroutines и каналы

Go создавался с мыслью, что сетевой сервер – это история про параллельность.

goroutines – очень лёгкие «зелёные потоки», которые Go runtime планирует сам.

В итоге вы можете:

– держать много одновременных соединений,

– параллелить I/O операции,

– строить пайплайны обработки.

Это не означает, что багов конкурентности не будет. Будут, конечно. Но модель проще, чем ручная работа с потоками во многих языках.

Часто Go выбирают именно за эту «естественность» конкурентного кода: сделал `go func()` – и задача поехала параллельно.

Плюс 4. Идеален для сетевых сервисов, инфраструктуры, high-load API

Go отлично показывает себя там, где нужно:

– много сетевых запросов,

– простая и быстрая обработка,

– низкие задержки,

– предсказуемость,

– эффективность на сервере.

Поэтому Go часто встречается:

– в API-шлюзах,

– в сервисах авторизации,

– в обработке событий,

– в инфраструктурных компонентах,

– в высоконагруженных микросервисах.

4.4. Минусы Go

Минус 1. Меньше «встроенной выразительности» для доменной логики (чем в Java)

Если доменная область сложная: много правил, много сущностей, много вариаций поведения – Java с её объектной моделью и типами иногда выражает такие вещи удобнее.

Go чаще тянет к стилю:

– простые структуры,

– явные функции,

– минимум «магии».

Это хорошо для инфраструктуры, но в сложной доменной логике вы можете столкнуться с тем, что:

– код начинает расползаться по функциям,

– появляются самодельные паттерны,

– хочется более богатой типовой системы «из коробки».

Это не «Go плох», это просто другой стиль. Но этот стиль подходит не всем доменам.

Минус 2. ORM/генерации/валидации – нужно выбирать аккуратно

В Go есть инструменты для:

– ORM,

– миграций,

– валидации,

– генерации клиентов/серверов.

Но важный нюанс: в Go-экосистеме есть много подходов, и не все одинаково зрелые и совместимые друг с другом. Можно легко собрать «зоопарк».

Что часто происходит:

– один пакет для роутинга,

– другой – для валидации,

– третий – для генерации,

– четвёртый – для БД,

– и всё это по-разному считает ошибки, контексты и структуру проекта.

Это лечится выбором «консервативного» набора инструментов и стандартов. Но новичку можно запутаться.

Минус 3. Дженерики есть, но экосистема ещё догоняет удобства Java/TS

В Go появились дженерики, и это полезно. Но:

– многие библиотеки и команды ещё адаптируются,

– часть паттернов в Go всё равно остаётся «ручной работой»,

– типовая система Go не пытается стать Java или TypeScript – она остаётся проще.

Если вы привыкли к богатому миру типовых абстракций, Go может казаться «немного деревянным». Иногда это плюс. Иногда – раздражает.

4.5. Когда выбирать Go

Сценарий 1. Высокая нагрузка, микросервисы, platform/infrastructure

Go – отличный выбор, если вы строите:

– много небольших сервисов,

– инфраструктурные компоненты,

– прокси, gateway, обработчики событий,

– high-load API с понятной логикой.

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

Сценарий 2. Когда важны простые деплои и эффективность

Если вам важно:

– быстро собирать и доставлять сервисы,

– легко масштабироваться,

– иметь минимальные зависимости,

– экономить ресурсы,

то Go очень часто выигрывает.

Сценарий 3. Когда команда ценит простоту и единый стиль

Если у вас команда, которая хочет:

– понятный код,

– минимум магии,

– предсказуемую сборку,

Go хорошо поддерживает этот стиль на уровне языка.

4.6. Вывод по Go

Go – это выбор, когда вам нужно:

– быстро,

– просто,

– эффективно,

– легко деплоить,

– хорошо работать под конкуренцией и нагрузкой.

Он может быть менее удобен для «богатой» доменной модели, зато очень хорош как рабочая лошадь для сетевых сервисов и инфраструктуры.