Перед вами — известное письмо Линуса Торвальса, где он написал, что если бы единственная причина использовать С, а не С++, была в том, чтобы отпугивать программистов на С++ — это уже была бы весомая причина.

Питон в последнее время завоевал лидирующие позиции в дата саенс и машинном обучении, что меня как разработчика на нём не может не радовать. В данной статье вы узнаете, почему, следуя духу минимализма из указанной цитаты, нужно использовать го в тех областях, где лидерство питона не так очевидно. А в питоне — не заморачиваться с async/await, фреймворками и прочей ерундой.

* * *

Пожалуйста, не подумайте, что мне не нравится питон или мне чего‑то в нём не хватает. Вот я, например, занимаюсь бэкенд‑разработкой. И хотя питон медленный, в 90% случаев веб‑приложение — это тонкая обёртка вокруг базы данных, так что питон в нём — вряд ли бутылочное горлышко. Зато, благодаря эргономичности и общей адекватности — как языка, так и его создателя — питон сейчас широко используется в самых интересных областях.

Что касается async/await — я, на самом деле, тоже доволен. Хотя, за этой реализацией немного прослеживается месседж в духе Линуса Торвальдса: «Дорогие веб‑разработчики, добро пожаловать отсюда в асинхронный питон. Хоть он и не совместим с обычным, зато там можете сделать всё по‑своему». Насчёт несовместимости — я имею в виду «цвета» функций.

Но на практике это оказалось неплохим решением. Потому что библиотекам для дата саенс и машинного обучения асинхронность оказалась не нужна, а веб‑разработчики, судя по всему, не очень и обиделись. К слову, в Ruby разработчики не стали в этот раз идти по стопам питона (наученные горьким опытом, когда они скопировали из питона GIL), и отказались от «разноцветных» функций при реализации Fibers. С технической стороны, мне, конечно, больше нравится реализация в Ruby.

Питон продолжает активно развиваться. В нём появилась версия без GIL, и я не сомневаюсь, что этот язык ждёт светлое будущее. Но эта статья всё‑таки не про него, а про такой феномен как го, или голанг.

По‑моему, го приобрел популярность во время бума девопса — докера и k8s. Это ‑универсальный язык, который годится как для системного программирования (ну почти) и всякого девопса, так и для написания высоконагруженных веб‑сервисов.

Хотя не все разделяют это мнение. Например, Mitchel Hashimoto, один из основателей Terraform — популярного продукта в сфере девопс — высказался о го примерно в таком ключе, что он не знает, для чего бы сейчас стал использовать го: для критичного к производительности кода он не годится из‑за присутствия в нём сборщика мусора, а для веб‑разработки лучше подойдёт «PHP или Rails».

Так‑то — оно так, да не совсем. Лучший язык для личного проекта и лучший язык — в среднем, для коммерческой разработки — не одно и то же. Во‑первых, го — достаточно скучный язык, и если человек его выбрал — это очевидная наклонность в сторону адекватности и практичности. Да и возможностей накосячить меньше. Во‑вторых, он универсален и широко распространён — компании не испытывают сложностей с поиском кадров. То, что он немного, что называется, verbose (многословный) — то эта наименьшая из проблем. Take your time, как говорится, компании готовы потратиться. «Закусывайте, Маргарита Васильевна — всё оплачено!»

Есть ещё одна причина, почему го — это хорошо. Совпадение или нет, но именно во время бума девопса и популярности го стали появляться и приобретать популярность новые системные языки, Rust и Zig. Наверное, из‑за того, что с одним го слишком скучно, и душа просит чего‑то ещё.

Кстати, есть новость: после долгих и безуспешных исканий, автор языка Zig объявил, что наконец понял, как добавить асинхронность в язык Zig. Спойлер: в каждую функцию, которой нужен ввод‑вывод, будет передаваться объект io: IO, реализующий функциональность ввода‑вывода. Наподобие того, как сейчас передаётся аллокатор памяти. Таким образом, Zig, в плане поддержки асинхронности, будет похож на Ruby (в то время как Rust похож на питон). Можно сказать, что Zig будет похож и на го, но в го ввод‑вывод — исключительно асинхронный, в то время как Zig будет в этом плане более гибким.

Так что, мне кажется, что особенности языка го — эргономичность системного языка (то есть, её отсутствие), но наличие сборщика мусора — способствуют росту популярности системных языков и даже постепенному вытеснению го из некоторых областей — как системное программирование, например, или особо критичные к производительности сервисы. И это, на мой взгляд — отличная тенденция: как кто‑то сказал, «system programming is king». И там, выбирайте на свой вкус: развесистый и «кучерявый» Rust или более минималистичный Zig.

Учитывая всё это, очень вероятно, что для своего личного веб‑проекта я бы выбрал го (хотя вероятность появления такого примерно такая же, как встретить динозавра). Но для коммерческих проектов — такое решение оправдано вдвойне. Высокоуровневость и излишняя свобода там часто выходят боком, и в итоге разработчики становятся рабами линтеров, статических анализаторов, паттернов проектирования и Domain Driven Design.

В целом, я почти потерял интерес к высокоуровневым языкам. Например, мне раньше нравился Erlang/Elixir. Это такой функциональный динамический язык — который, кстати, вполне является конкурентом го для создания высоконагруженных сервисов. Он предназначен для асинхронных нагрузок (I/O‑bound) и плохо подходит для вычислительных (CPU‑bound). Для последних там нужно использовать Ports (взаимодействие с другим процессом) или dirty scheduler. В этом смысле, Erlang следует принципу «do one thing and do it well» — в отличие от го, который универсальный.

В Erlang много привлекательных фич. Pattern matching широко используется. Логика строится вокруг данных и вокруг сообщений, которыми обмениваются разные части системы. Из‑за того, что данные при этом чаще всего физически копируются — большой разницы нет, расположены ли эти разные части на одном хосте или нет. Режим кластера очень даже распространён, хоть и не дефолт. Бинарные данные шифруются и передаются между хостами по аналогии с тем, как это делается на одном хосте — нет никакой нужды в gRPC/Protobuf.

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

Выбирайте го — выбирайте простоту!