Язык Gleam — типобезопасный новичок на арене серьёзных языков

WhatsApp обслуживает два миллиарда пользователей силами небольшой инженерной команды. Телефонные сети Ericsson работают с надёжностью 99,9999999% — девять девяток. За обоими стоит одна и та же виртуальная машина — BEAM, созданная в 1980-х для телекома и с тех пор не знающая конкурентов в задачах, где система не имеет права падать. У BEAM был один давний недостаток: языки на ней — Erlang и Elixir — динамически типизированы, и ошибки типов обнаруживаются только в рантайме, уже в работающей системе. Gleam появился как ответ: тот же BEAM, но со статической типизацией, без null, с проверкой всех типов до запуска. В 2024 году вышла версия 1.0, а год спустя в опросе Stack Overflow 70% разработчиков, попробовавших Gleam, захотели продолжать — второе место после Rust.

В 2024 году язык вышел в версии 1.0. Год спустя, в опросе Stack Overflow 2025, 70% разработчиков, попробовавших его, захотели продолжать — второе место после Rust с его 72%. Для языка, которому нет и двух лет в стабильной версии это достижение.

Давайте посмотрим, что Gleam умеет на самом деле и где он уступает зрелым конкурентам.

Компиляция: один язык — два мира

Gleam компилируется в два совершенно разных targets: Erlang-байткод для виртуальной машины BEAM и чистый JavaScript для браузера или Node.js. Это значит, что один и тот же код можно запустить на бэкенде с отказоустойчивостью уровня телекома — и на фронтенде.

Go компилируется в нативный бинарь под конкретную платформу: один go build — один исполняемый файл без зависимостей. Это предельно просто и предсказуемо, но выбор сделан навсегда: Go-сервер не станет фронтендом.

Производительность

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

C# и Java на современных JIT-компиляторах (RyuJIT и HotSpot) в долгоживущих серверных процессах показывают производительность, сопоставимую с Go и иногда превосходящую его — ценой медленного старта и более высокого потребления памяти.

Gleam работает на BEAM — виртуальной машине Erlang, которая была создана не для максимальной скорости вычислений, а для максимальной надёжности под нагрузкой. В задачах с интенсивными вычислениями Gleam заметно уступает Go. Зато там, где нужно обрабатывать миллионы одновременных соединений с изоляцией каждого — BEAM не знает равных.

Параллельность: разные модели мышления

Gleam наследует модель акторов от Erlang: каждый процесс — это изолированная песочница с собственной памятью. Процессы общаются только через сообщения, никакого общего состояния. BEAM создаёт миллионы таких процессов без усилий; если один упал — остальные продолжают работать.

В Go параллельность строится на горутинах и каналах. Горутины дешевле системных потоков в тысячи раз, а go перед функцией запускает её асинхронно — проще некуда. Но общая память никуда не делась: race condition вполне возможен, и детектор гонок (go run -race) — привычный инструмент Go-разработчика.

В C# и Java параллельность прошла долгий путь: от сырых Thread через ExecutorService до async/await в C# и виртуальных потоков в Java 21+. Это мощно, но с историческим багажом. Модель Gleam проще концептуально: если вы не можете передать данные через сообщение — вы не можете их разделить. Компилятор заставляет думать именно так.

Отказоустойчивость: «пусть упадёт»

Философия BEAM звучит нарочито контринтуитивно: let it crash — пусть упадёт. Вместо того чтобы защищать каждый участок кода от ошибок, вы строите дерево супервизоров: специальных процессов, которые перезапускают упавшие дочерние процессы по заданной стратегии. Система продолжает работать, даже когда внутри что-то ломается.

Go предпочитает явную обработку ошибок: if err != nil — это не шутка, это буквально каждая вторая строчка в реальном Go-коде. Ошибки видны, предсказуемы, но вся ответственность на разработчике. Встроенного механизма перезапуска нет — нужны внешние инструменты вроде systemd или Kubernetes.

C# и Java используют исключения: try/catch и иерархии наследников Exception. Это удобно для локальной обработки ошибок, но для распределённых систем с тысячами соединений такая модель требует аккуратной архитектуры. OTP-супервизоры Gleam/Erlang — это готовая архитектура, встроенная в платформу.

Простота: маленький язык, большие возможности

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

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

C# и Java — богатые языки с десятилетиями накопленных фич: generics, LINQ, records, sealed classes, pattern matching в C# 12, virtual threads в Java 21, записи и switch expressions. Мощно, но войти в кодовую базу на C# 12 без опыта — значит читать документацию параллельно с кодом.

Масштабируемость: где Gleam выигрывает

Если вы строите систему реального времени — чат, торговую платформу, IoT-хаб, игровой сервер — BEAM создавался именно для этого. WhatsApp обслуживал миллиард пользователей силами нескольких десятков инженеров во многом благодаря Erlang. Discord использует Elixir (сосед Gleam по BEAM) для обработки миллионов сообщений в секунду.

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

C# и Java горизонтально масштабируются так же хорошо, как Go. В облачных сценариях разница минимальна. Но старт JVM-процесса занимает секунды — это делает их менее удобными для serverless и edge-вычислений, где Go и Gleam (в JavaScript-режиме) чувствуют себя лучше.

Сферы применения: кто для чего

Gleam сегодня живёт в нишах: real-time бэкенды, распределённые системы, стартапы, которые хотят надёжности BEAM с типобезопасностью.

Go — язык инфраструктуры. Docker, Kubernetes, Terraform, Prometheus, etcd — весь современный DevOps написан на Go. Если вы пишете CLI-инструмент, прокси, сервис с REST/gRPC API или что угодно, что должно работать в контейнере — Go выбор по умолчанию.

C# и Java доминируют в корпоративном секторе: банки, страховые, ERP-системы, enterprise-сервисы. Огромная экосистема библиотек, зрелые фреймворки (Spring, ASP.NET), десятилетия найма и поддержки. Там, где важна интеграция с Oracle, SAP или Windows Active Directory — Go и Gleam почти не встречаются.

Перспективы: повторит ли Gleam путь Rust

В 2015 году Rust вышел в 1.0 с высочайшим рейтингом — и пять лет оставался нишевым. К 2020-му его начали использовать в production Microsoft, Google, Amazon, Mozilla. Сейчас почти половина компаний применяет Rust в production.

У Gleam похожий профиль старта: интерес есть, production — пока нет. Всего около 8% пользователей языка развернули его в боевой среде. Главный тормоз — незрелая экосистема: нет фреймворка уровня Phoenix (который есть у Elixir), нет зрелого ORM, мало готовых решений.

Go и C#/Java этой проблемы не имеют: экосистемы огромные, вакансий тысячи. Если вам нужен язык для работы прямо сейчас — выбор очевиден. Если вы хотите строить системы, для которых BEAM создан идеально, — Gleam стоит изучить сегодня.

Переписывать ли существующий код на Gleam

Коротко — нет, по крайней мере не в 2026 году. Gleam не тот язык, на который переносят легаси — экосистема просто не готова. Нет зрелого ORM — придётся писать запросы вручную или тянуть Erlang-библиотеки с неидиоматичным API. Нет фреймворка уровня Spring Boot или ASP.NET: обработка HTTP-запросов, middleware, авторизация, валидация — всё собирается из отдельных небольших пакетов, часть которых поддерживается одним человеком. Нет готовых коннекторов к корпоративным системам: SAP, Oracle, Active Directory — за пределами Gleam. Переписать Java-сервис на Go — это несколько недель работы с предсказуемым результатом. Переписать на Gleam — значит на каждом шагу упираться в отсутствие библиотеки и решать: писать самому, оборачивать Erlang-код или отказываться от фичи.

Gleam имеет смысл для новых проектов, где с первого дня важна отказоустойчивость и высокая конкурентность: чаты, стриминг, IoT-платформы, игровые серверы. Там, где Go взял бы внешний оркестратор для управления сбоями, Gleam решает это на уровне языка и платформы.

Итоги

Критерий	Gleam	Go	C# / Java
Скорость компиляции	Быстро	Очень быстро	Медленно
Скорость выполнения	Средняя (BEAM)	Высокая	Высокая (JIT)
Параллельность	Акторы, миллионы процессов	Горутины + каналы	async/await, virtual threads
Отказоустойчивость	Встроена в платформу	Ручная	Ручная
Простота обучения	Высокая (маленький язык)	Высокая	Низкая (сложные языки)
Система типов	Строгая, без null	Статическая, есть nil	Статическая
Экосистема	Молодая	Зрелая	Очень зрелая
Рынок труда	Минимальный	Большой	Огромный
Лучшее применение	Real-time, распределённые системы	Инфраструктура, DevOps, API	Enterprise, корпоративный сектор

• Gleam — это не «следующий Go» и не «замена Java». Это другой инструмент для другой задачи.
• Если вы строите систему, где миллионы соединений и отказ одного компонента не должен роняла всё — смотрите на Gleam.
• Если вам нужен надёжный, простой и повсеместно поддерживаемый язык — Go.
• Если вы в корпоративной среде с легаси и требованиями к интеграции — C# или Java.