Перейти к основному содержимому

5.10. Сфера применения

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ
Разработчику Архитектору

Сфера применения​

Понимание сферы применения Go невозможно без анализа его архитектурных решений. Язык сочетает статическую типизацию, компиляцию в машинный код, встроенную поддержку горутин и каналов для конкурентного программирования, а также минималистичный синтаксис без наследования и перегрузки операторов. Такой набор свойств определяет возможности языка и его естественную пригодность для определённых классов задач. Go не заменяет C в написании ядра ОС, не претендует на роль Python в научных вычислениях и не стремится к доминированию в интерфейсной разработке, как TypeScript. Вместо этого он создаёт устойчивую нишу, в которой инженерные компромиссы оказываются выгодными: скорость разработки близка к скриптовым языкам, а производительность и предсказуемость — к системным.

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

1. Инфраструктурные системы и сетевые сервисы​

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

Эта модель идеально ложится на типичный паттерн сетевого сервера: приём входящего соединения — выделение обработчика — чтение/запись данных — закрытие соединения. В традиционных языках, таких как Java или C++, для обслуживания тысяч одновременных подключений требуются сложные шаблоны (пулы потоков, реактивные фреймворки, асинхронный ввод-вывод с обратными вызовами). В Go разработчик может писать код в императивном стиле — как будто каждое соединение обрабатывается отдельной «ниткой» — при этом система остаётся эффективной и масштабируемой. Это упрощает проектирование, снижает количество ошибок, связанных с состоянием и синхронизацией, и ускоряет обучение новых инженеров.

Примеры:

  • HTTP-прокси и API-шлюзы (например, Traefik, Envoy в части расширений, Kong Gateway на основе Go-плагинов);
  • Серверы мгновенных сообщений и чат-платформ, где требуется поддержка десятков тысяч долгоживущих соединений (например, Slack в ранних версиях использовал Go для бэкенда, Mattermost частично написан на Go);
  • Сервисы аутентификации и авторизации, такие как OAuth2-провайдеры (ORY Hydra, Keycloak в дополнительных компонентах), где критична предсказуемость задержек и отказоустойчивость;
  • Сетевые инструменты анализа трафика, например, утилиты для работы с DNS (CoreDNS), TLS-инспекции или балансировки нагрузки (Caddy Server использует Go как основной язык).

Важно отметить: Go не «быстрее» C или Rust в чистом смысле тактовой производительности. Однако инженерная производительность — время от идеи до стабильного релиза, стоимость поддержки, вероятность ошибок — в задачах, связанных с сетевым взаимодействием, оказывается выше. Это связано с предсказуемым поведением сборщика мусора (начиная с версии 1.5, он стал конкурирующим и низколатентным), минималистичным системным API и отсутствием глобального интерпретаторского замка (в отличие от CPython).

2. Облачные платформы и микросервисы​

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

Компиляция Go-программы даёт статически слинкованный исполняемый файл, не требующий установки интерпретатора, виртуальной машины или библиотек времени выполнения (за исключением libc в некоторых режимах сборки). Это позволяет создавать контейнерные образы минимального размера — например, на базе scratch-образа, содержащего только один бинарник. Такой подход снижает поверхность атаки, ускоряет развёртывание и упрощает управление версиями.

В среде микросервисов Go получил распространение по следующим причинам:

  • Простота интерфейсов. Стандартная библиотека включает полноценную поддержку HTTP/1.1 и HTTP/2, JSON, TLS, gRPC. Для типичного REST- или gRPC-сервиса часто не требуется сторонних зависимостей.
  • Предсказуемое потребление ресурсов. В отличие от JVM-приложений, Go-сервисы не нуждаются в «прогреве», не проявляют внезапных всплесков потребления памяти из-за сборки мусора (в последних версиях GC настроен на удержание пауз в пределах миллисекунд), и их поведение стабильно при изменении нагрузки.
  • Лёгкость интеграции с инструментами мониторинга. Стандартная библиотека expvar, встроенная поддержка pprof, совместимость с Prometheus (через официальный клиент) и OpenTelemetry позволяют быстро внедрить наблюдаемость без глубокой модификации кода.

Многие облачные провайдеры используют Go для внутренних сервисов: например, части AWS (Amazon ECS Agent, AWS CLI v2), Google Cloud (компоненты gVisor, Knative), Cloudflare (части edge-логики и инструментов вроде Wrangler). Это говорит о том, что свойства соответствуют специфике облачной среды: множественность короткоживущих процессов, необходимость изоляции, высокая степень автоматизации развёртывания и диагностики.

3. Командные утилиты и CLI-приложения​

Одним из наиболее последовательных и успешных применений Go стало создание консольных утилит и инструментов командной строки. Эта сфера, казалось бы, традиционно закреплена за скриптовыми языками (Bash, Python, Perl) и системными (C), но Go обеспечил уникальное сочетание простоты разработки, надёжности и удобства распространения, которое оказалось востребованным в условиях роста автоматизации и инфраструктурной сложности.

Стандартная библиотека Go содержит мощные средства для работы с аргументами командной строки (flag, os.Args, а также множество популярных сторонних пакетов вроде spf13/cobra), файловой системой, переменными окружения, сигналами ОС и подпроцессами. При этом утилита, написанная на Go, компилируется в один статически связанный бинарный файл, не требующий установки интерпретатора или зависимостей. Это устраняет целый класс проблем, с которыми сталкивались разработчики на Python: несовместимость версий интерпретатора, отсутствие pip, конфликты виртуальных окружений, зависимости от системных библиотек (например, libssl).

Примеры широко распространённых CLI-инструментов на Go:

  • Docker CLI (вплоть до версии 20.10; последующие версии частично переписаны, но основа осталась);
  • kubectl — клиент для управления Kubernetes-кластерами;
  • Terraform CLI — утилита управления инфраструктурой как кодом (IaC);
  • Helm — менеджер пакетов для Kubernetes;
  • Vagrant — инструмент управления виртуальными окружениями (с версии 2.0 частично переписан на Go);
  • Delve — отладчик для Go-программ;
  • Go itself — компилятор, линтер, форматтер, модульный менеджер — всё это реализовано как набор самодостаточных утилит (go build, go test, gofmt, go mod и т.д.).

Многие из этих утилит используются разработчиками и системными администраторами, SRE, DevOps-инженерами — то есть людьми, чья основная задача — управление, а не написание кода. Для них критична предсказуемость поведения и минимизация внешних зависимостей. Go-утилита может быть скачана в виде одного файла, запущена без установки, и при этом сохранять стабильный интерфейс между версиями. Это выгодно отличает её от, например, Python-скрипта, который может сломаться из-за обновления requests или перехода с Python 3.8 на 3.11.

Кроме того, Go позволяет легко реализовать интерактивные CLI-приложения с прогресс-баром, цветным выводом, подсказками и автодополнением (через интеграцию с bash-completion или zsh). Библиотеки вроде charmbracelet/bubbletea или rivo/tview предоставляют фреймворки для создания TUI (terminal user interface) с минимальными усилиями — что делает Go привлекательным даже для задач, традиционно решавшихся на ncurses/C или Python с curses.

4. DevOps- и SRE-инструментарий​

Следующее естественное расширение — применение Go в инструментах для автоматизации эксплуатации, мониторинга и управления инфраструктурой. Здесь Go стал де-факто стандартом в open-source-экосистеме, особенно в стеке, связанном с облачными нативными технологиями (CNCF — Cloud Native Computing Foundation).

Основные причины:

  • Совместимость с системными вызовами и низкоуровневыми API. Go предоставляет прямой доступ к syscall, netlink, cgroups, namespaces, seccomp, что позволяет писать утилиты для управления контейнерами, изоляции процессов и сбора метрик на уровне ядра. Пример: runc (реализация OCI runtime), containerd (контейнерный рантайм), crun (альтернатива на C, но containerd остаётся на Go).
  • Лёгкость интеграции с REST/gRPC/HTTP API. Большинство современных систем управления (Kubernetes API, Prometheus, Elasticsearch, Grafana, Vault) предоставляют HTTP-интерфейсы. Go отлично подходит для написания адаптеров, экспортеров, webhook-обработчиков.
  • Надёжность при длительном выполнении. Многие DevOps-инструменты работают в фоне — как демоны, sidecar-контейнеры или агенты. Go обеспечивает стабильность памяти и управляемость ресурсов, что критично для сервисов, которые должны работать месяцами без перезапуска.

Конкретные примеры:

Мониторинг и сбор метрик​

  • Prometheus — система мониторинга и сбора временных рядов, написанная целиком на Go. Её клиентская библиотека (prometheus/client_golang) стала стандартом для экспорта метрик из Go-приложений.
  • Grafana Agent — лёгкий агент сбора логов и метрик, заменяющий связку Prometheus + Loki + Tempo в некоторых сценариях.
  • Telegraf (часть TICK-stack от InfluxData) — collector метрик, частично переписанный на Go для улучшения переносимости.

Управление конфигурацией и секретами​

  • HashiCorp Vault — система управления секретами, написанная на Go. Выбор языка обусловлен необходимостью работы с TLS, аудитом, плагинами и отказоустойчивыми кластерами.
  • etcd — распределённое key-value-хранилище, используемое Kubernetes для хранения состояния кластера. Реализует алгоритм Raft для консенсуса и написан на Go для обеспечения предсказуемой задержки и стабильности.

Инфраструктура как код (IaC)​

  • Terraform — один из самых влиятельных проектов на Go. Его архитектура основана на провайдерах — плагинах, реализующих взаимодействие с облачными API. Плагины компилируются в отдельные бинарники и запускаются как дочерние процессы, обмениваясь данными через gRPC. Такой подход позволил создать экосистему из сотен провайдеров (AWS, Azure, Yandex.Cloud, VK Cloud и др.) без жёсткой привязки к основному коду. Это стало возможным благодаря стабильности ABI в Go (через гранулярные интерфейсы и gRPC) и простоте сборки кроссплатформенных бинарников.

CI/CD и автоматизация сборки​

  • Drone CI — система непрерывной интеграции, написанная на Go и работающая в Kubernetes.
  • Buildkite Agent — лёгкий агент для распределённого выполнения задач CI.
  • ko — утилита для сборки и развёртывания Go-приложений в Kubernetes без Dockerfile (компилирует, упаковывает в образ на лету).

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

5. Системы хранения данных и базы данных​

Go нашёл широкое применение в разработке специализированных систем хранения данных, особенно там, где важны простота развёртывания, отказоустойчивость, горизонтальное масштабирование и интеграция в облачные среды. При этом Go редко используется для реализации ядер СУБД в классическом понимании (например, для управления буферным пулом, WAL, блокировками на уровне страниц), где доминируют C/C++ из-за требований к предсказуемому поведению памяти и прямому контролю над диском. Однако Go активно задействуется в построении координаторов, прокси, мета-сервисов, адаптеров и легковесных СУБД, ориентированных на конкретные рабочие нагрузки.

Ключевые факторы, делающие Go привлекательным в этой области:

  • Встроенная поддержка сетевых протоколов — возможность быстро реализовать MySQL-, PostgreSQL-, Redis- или gRPC-совместимые интерфейсы;
  • Простота реализации распределённых алгоритмов, таких как Raft или Paxos, за счёт встроенной конкурентности и отсутствия сложных состояний;
  • Лёгкость интеграции с существующими СУБД через драйверы (например, pgx, go-sql-driver/mysql), что позволяет создавать middleware-слои (шардинг, кэширование, репликация);
  • Минимальный runtime, что критично для sidecar-контейнеров и embedded-БД.

Примеры:​

  • CockroachDB — распределённая SQL-СУБД, совместимая с PostgreSQL, написанная целиком на Go. Архитектура основана на Raft для репликации, MVCC для контроля параллелизма и распределённом выполнении запросов. Go позволил команде сосредоточиться на логике распределения, а не на управлении памятью или портабельности. CockroachDB демонстрирует, что Go способен поддерживать СУБД класса enterprise — при условии, что критические пути (например, сериализация данных, работа с диском) написаны с учётом особенностей GC и оптимизированы под профилировщики (pprof, trace).

  • TiDB — гибридная система: SQL-слой (TiDB-сервер) написан на Go, а движок хранения (TiKV) — на Rust. Такое разделение отражает философию: Go — для координации, сетевого стека, оптимизатора запросов; Rust — для управления диском и транзакциями на нижнем уровне. Это показывает, что Go рассматривается как язык оркестрации в гетерогенных системах.

  • etcd (упомянут ранее) — хотя формально это key-value хранилище, оно часто используется как координатор для СУБД (например, в Vitess — системе шардинга для MySQL) или как репозиторий метаданных для распределённых систем. Его API прост, задержки предсказуемы, а надёжность обеспечивается Raft — всё это реализовано с использованием стандартных средств Go без внешних зависимостей.

  • InfluxDB (версии 1.x) — временная БД, изначально написанная на Go. В последующих версиях часть критичных компонентов была переписана на Rust для повышения производительности, но основной серверный код, API и плагины остались на Go. Это типичный путь эволюции: старт на Go для скорости разработки, затем частичная оптимизация «узких мест».

  • VictoriaMetrics — высокопроизводительная альтернатива Prometheus, написанная на Go. Демонстрирует, что при грамотном проектировании (избегание аллокаций в hot path, использование sync.Pool, []byte вместо string) Go способен обрабатывать десятки миллионов метрик в секунду на одном узле.

Go не используется для написания универсальных OLTP-СУБД, таких как PostgreSQL или Oracle. Его ниша — специализированные, распределённые, облачно-нативные хранилища, где приоритет отдаётся операционной простоте, отказоустойчивости и интеграции с Kubernetes, а не абсолютной производительности на одном узле.

6. Блокчейн и децентрализованные системы​

Ещё одна область, где Go получил значительное распространение, — блокчейн-платформы и криптографические протоколы. Здесь важны те же качества: предсказуемость, безопасность (в смысле отсутствия неопределённого поведения), простота аудита кода и кроссплатформенность.

Примеры:​

  • Ethereum (geth) — официальная реализация клиента Ethereum на Go (Go Ethereum). Является одной из трёх основных реализаций (наряду с Nethermind на C# и Besu на Java). geth поддерживает полные ноды, лёгкие клиенты, майнеры и инструменты разработки (clef, bootnode, rlps). Выбор Go обусловлен необходимостью работы с P2P-сетью, криптографией (secp256k1), хранением состояния (LevelDB, а позже — Pebble и собственные решения), и при этом — требованием к стабильности в условиях высокой нагрузки (например, при синхронизации блокчейна).

  • Cosmos SDK — фреймворк для построения Proof-of-Stake блокчейнов. Написан на Go и позволяет разработчикам создавать собственные chains (например, Terra, Osmosis, Juno), сосредоточившись на бизнес-логике (модулях), в то время как консенсус (Tendermint Core — также на Go), P2P и криптография предоставляются «из коробки». Это демонстрирует силу Go в создании модульных, расширяемых фреймворков.

  • IPFS (go-ipfs) — реализация протокола InterPlanetary File System. Включает компоненты для DHT, Bitswap, libp2p — всё на Go. libp2p, в свою очередь, стал независимым проектом и используется в IPFS, Ethereum 2.0, Polkadot, Filecoin.

Особенность блокчейн-разработки — необходимость полной детерминированности. Любая неопределённость (например, порядок итерации по map в Go до версии 1.0) может привести к расхождению состояния нод. Go-команда осознанно ввела детерминированную итерацию по хеш-таблицам, что сделало язык пригодным для таких задач. Также важна поддержка критических библиотек криптографии: crypto/ecdsa, crypto/ed25519, golang.org/x/crypto — все они проходят независимые аудиты и входят в стандартный стек.

7. Встраиваемые системы и IoT​

Применение Go во встраиваемых системах и IoT остаётся ограниченным, но постепенно расширяется благодаря улучшениям в компиляторе и runtime.

Традиционные ограничения:

  • Отсутствие поддержки голого железа (no-std) — Go требует минимального runtime (планировщик, GC, системные вызовы);
  • Относительно большой размер бинарника (даже «hello world» занимает ~2 МБ);
  • Непредсказуемость сборщика мусора в условиях жёстких временных ограничений (hard real-time).

Однако в мягких IoT-сценариях (например, шлюзы, edge-устройства на базе Linux, Raspberry Pi, ESP32 с поддержкой Linux-подобных ОС) Go становится всё более конкурентоспособным.

Достижения:​

  • Сборка без libc (CGO_ENABLED=0, GOOS=linux, GOARCH=arm64) позволяет создавать статические бинарники для ARM-устройств.
  • Экспериментальная поддержка WASI — компиляция Go-кода в WebAssembly для запуска в изолированных средах (например, в edge-роутерах с поддержкой WASM).
  • TinyGo — альтернативный компилятор, ориентированный на микроконтроллеры (AVR, ARM Cortex-M, ESP32). Поддерживает подмножество языка и стандартной библиотеки, но позволяет писать firmware на Go с доступом к GPIO, UART, I2C. Проект активно развивается, хотя и не достиг уровня зрелости Rust или C для критичных задач.

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

  • Edge-шлюзы для промышленного IoT, где Go обрабатывает данные с датчиков, агрегирует их, отправляет в облако и предоставляет локальный HTTP API для диагностики.
  • Сетевые устройства на базе OpenWrt, где Go-утилиты управляют маршрутизацией, QoS, сертификатами.
  • Устройства с Linux-ядром и достаточным объёмом RAM (≥64 МБ) — например, умные камеры, медиаплееры, роботы.

Go здесь выступает как язык среднего уровня абстракции: выше C по удобству, ниже Python по требованиям к ресурсам. Это особенно ценно, когда устройство должно одновременно выполнять сетевые, криптографические и бизнес-логические задачи.

8. Ограничения и неподходящие сценарии​

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

8.1. Высокопроизводительные вычисления и HPC​

Задачи, требующие максимальной тактовой производительности — численное моделирование, линейная алгебра, обработка сигналов, физические симуляции — остаются прерогативой C, C++, Fortran и, всё чаще, Rust. Причины:

  • Сборщик мусора (GC), несмотря на улучшения (конкурирующий, стоп-мир паузы < 1 мс в типичных сценариях), всё ещё вносит непредсказуемую задержку. В HPC-кодах часто требуется гарантированное время выполнения операции (hard real-time), что невозможно при наличии фонового GC, даже если он работает в отдельном потоке.
  • Отсутствие контроля над layout памяти. В Go невозможно точно указать выравнивание структур, размещение данных в кэше процессора или использование SIMD-инструкций без ассемблерных вставок (что нарушает портируемость). В C/C++ это достигается через __attribute__((aligned)), #pragma pack, intrinsics (_mm256_add_ps и т.д.).
  • Высокая стоимость абстракций. Горутины удобны для I/O-bound задач, но для CPU-bound вычислений они не дают преимущества перед нативными потоками, а накладные расходы на переключение контекста в runtime могут быть выше, чем при ручном управлении через OpenMP или pthreads.

Пример: библиотека BLAS (Basic Linear Algebra Subprograms) реализована на оптимизированном ассемблере под конкретные архитектуры (Intel MKL, OpenBLAS). Попытка переписать её на Go приведёт к падению производительности на порядки — даже при использовании unsafe и cgo для вызова нативных функций, сама обёртка и управление памятью будут «тормозить».

8.2. Десктопные и мобильные пользовательские интерфейсы​

Хотя существуют фреймворки для GUI на Go (Fyne, Wails, Gio, Webview), они не обеспечивают того уровня зрелости, производительности и нативного внешнего вида, который ожидается в коммерческих приложениях.

  • Отсутствие официальной поддержки нативных виджетов. Большинство Go-GUI-библиотек либо рисуют интерфейс самостоятельно (OpenGL/WebGL), либо встраивают WebView, что приводит к увеличению размера приложения и отставанию от системных стандартов (темизация, accessibility, drag-and-drop).
  • Сложность интеграции с системными API. Для полноценного desktop-приложения нужны уведомления, интеграция с системным трееем, работа с clipboard, файловыми диалогами, шорткатами, меню — всё это требует cgo и ручной привязки к Win32, Cocoa или GTK, что аннулирует преимущество «чистого Go».
  • Медленная итерация дизайна. В отличие от декларативных UI-фреймворков (React, SwiftUI, Jetpack Compose), где разметка отделена от логики, Go-решения часто вынуждают смешивать отрисовку и бизнес-код, что затрудняет поддержку.

Исключение — внутренние инструменты с простым интерфейсом (например, настройка демона, мониторинг локального сервиса), где достаточно базового окна и нескольких полей ввода. Но для продуктового ПО выбор Go в качестве основного языка UI — рискованное решение.

8.3. Машинное обучение и data science​

Экосистема ML в Go находится на уровне экспериментов. Библиотеки вроде goml, gorgonia, onnx-go существуют, но не конкурируют с Python-стеком (PyTorch, TensorFlow, scikit-learn) ни по функциональности, ни по сообществу, ни по документации.

  • Отсутствие поддержки автоматического дифференцирования «из коробки». В PyTorch это встроено на уровне тензорных операций; в Go приходится реализовывать вручную или полагаться на символьные вычисления, что медленно и ненадёжно.
  • Недостаток предобученных моделей и датасетов. Python-сообщество накопило десятки тысяч моделей в Hugging Face, TensorFlow Hub, Model Zoo. В Go — единицы.
  • Сложность взаимодействия с GPU. Хотя есть привязки к CUDA (gocv, cuda-go), они нестабильны, требуют cgo, и не поддерживают современные фичи (Tensor Cores, mixed precision). Запуск модели на GPU из Go означает, по сути, вызов Python-скрипта или REST-сервера на другом языке.

Практически единственный разумный сценарий — серверная инференс-часть: Go принимает запрос, валидирует данные, передаёт тензоры в ONNX Runtime (через cgo или gRPC) и возвращает результат. Сама же модель разрабатывается и обучается на Python.

8.4. Системное программирование низкого уровня​

Go не подходит для написания:

  • ядер операционных систем,
  • драйверов устройств,
  • загрузчиков,
  • firmware без RTOS,
  • гипервизоров.

Причины:

  • Зависимость от runtime. Даже минимальная программа требует инициализации планировщика, GC, стека. Это невозможно в среде без виртуальной памяти и системных вызовов.
  • Невозможность отключения GC полностью. Флаг -tags=netgo или GOGC=off лишь откладывает сборку, но не устраняет необходимость в runtime.
  • Ограниченный доступ к inline-ассемблеру. Go поддерживает ассемблер, но только в отдельных .s-файлах, без встраивания в Go-код, и только для архитектур, поддерживаемых компилятором. Это затрудняет написание критичных по времени участков.

Для этих задач предпочтительны C, Rust или специализированные языки (Ada, SPARK).

8.5. Приложения с жёсткими требованиями к размеру бинарника​

Хотя Go позволяет создавать статические бинарники, их минимальный размер — ~1.5–2 МБ (даже для package main; func main() {} после upx --best). Это неприемлемо для:

  • микроконтроллеров с flash < 1 МБ,
  • bootloaders,
  • сетевых фильтров в ядре (eBPF-программы),
  • ultra-lightweight container images, где критичен каждый килобайт.

Для сравнения: аналогичная программа на C компилируется в ~8 КБ с -Os -s, а на Rust — в ~300 КБ (но с возможностью сжатия до 50 КБ при использовании xargo и no_std). Go здесь проигрывает по компактности.