Go

Чому блокування тут безкоштовне

Горутина — не потік. Вона стартує зі стеком на пару кілобайтів, що росте за потреби, тож створити сто тисяч горутин — це звичайно, а не безрозсудно. Середовище виконання Go розкладає їх на невелику кількість справжніх потоків операційної системи — типово стільки, скільки у вас ядер, — і планує їх саме.

Наслідок і є тим, що варто забрати з собою. Коли горутина робить блокуючий виклик — запит до бази, HTTP-запит, читання файлу, — середовище паркує її й передає її чергу виконання іншому потоку, тож ніщо не зупиняється. Ви отримуєте масштабованість асинхронного сервера, пишучи код, що читається згори вниз, без колбеків, без ланцюгів промісів, без «кольорових» функцій і зі стектрейсами, які означають те, що кажуть. Node розв’язав ту саму задачу, зробивши асинхронним усе; Java прийшла до відповіді Go на два десятиліття пізніше — з віртуальними потоками.

Горутини спілкуються через канали: типізовану трубу, де надсилання блокується, доки не готовий отримувач, і навпаки. Це блокування і є синхронізацією: передача значення через канал передає й відповідальність за нього — саме це на практиці означає спільнотне гасло «діліться пам’яттю, спілкуючись». select чекає на кілька каналів одразу, а в парі з context це той спосіб, яким запит скасовує розпочату роботу, коли клієнт пішов.

Канали — не відповідь на все, і новачки в Go ними зловживають. Коли кільком горутинам просто треба читати й писати одну спільну структуру, sync.Mutex зрозуміліший, швидший і легший для міркування, ніж протокол на каналах. Беріть канали, щоб передавати роботу й сигналізувати; беріть м’ютекс, щоб захищати стан. І запускайте тести з -race, бо Go спокійно дозволить двом горутинам писати в одну мапу, а скаже вам про це лише детектор гонок.

Помилки — це значення

У Go немає винятків. Функція, здатна зазнати невдачі, повертає помилку поруч із результатом, а викликач її перевіряє. Це те архітектурне рішення, про яке сперечаються найбільше, і суперечка проминає, що воно дає: кожне місце, де може статися збій, видно в коді на тому самому рядку, і немає невидимого шляху, яким керування покидає вашу функцію. Забути врахувати помилку не вийде, бо компілятор не дозволить проігнорувати оголошену для неї змінну.

Ціна — повторюваність: та сама перевірка на три рядки скрізь. Сучасний Go її пом’якшує: обгортання помилки через fmt.Errorf і %w будує ланцюг, який несе контекст угору, не втрачаючи оригіналу, а errors.Is та errors.As досліджують цей ланцюг нагорі, де й місце рішенню. Взірець, до якого варто прагнути: низькорівневий код додає контекст і повертає, а рівно один шар біля межі вирішує, що робити — залогувати, повторити чи перетворити на код статусу.

Свідомо мала

Go лишає поза бортом можливості, які інші мови вважають необхідними, і ці пропуски — задум, а не недогляд. Немає спадкування: типи вбудовують інші типи й задовольняють інтерфейси неявно, не оголошуючи цього. Немає конструкторів, перевантаження операторів, аргументів за замовчуванням, а донедавна не було й дженериків. Сенс усього цього в тому, що Go-код, написаний незнайомцем, схожий на Go-код, написаний вами, — і саме це робить робочою велику команду на великій кодовій базі.

Ще дві речі визначають щоденну роботу. gofmt завершує будь-яку дискусію про форматування, роблячи його непредметом обговорення: розкладка одна, і застосовує її інструмент. А стандартна бібліотека незвично повна для бекенда: HTTP-сервер, JSON, TLS, шаблони, тестування й профілювання — усе в ній, тож робочий сервіс справді може майже не мати сторонніх залежностей. Дженерики прийшли в Go 1.18 і корисні для контейнерів та допоміжних функцій; це не запрошення відбудовувати механіку рівня типів іншої мови.

Як це виявляється в реальній поставці

Операційна історія й пояснює, чому Go забрав собі інфраструктуру. Збірка дає один статично злінкований виконуваний файл без середовища, яке треба доставляти: образ контейнера в мегабайтах, старт у мілісекундах і розгортання, що є копіюванням файлу. Docker, Kubernetes, Terraform і Prometheus написані на Go, і це не збіг: це саме ті програми, де малий, швидкий і без залежностей бінарник є вимогою.

Збирач сміття Go налаштований на затримку, а не на пропускну здатність: паузи зазвичай значно менші за мілісекунду, і досягає він цього тим, що більше працює паралельно й витрачає більше CPU, ніж витрачав би збирач, орієнтований на пропускну здатність. Для сервісу це правильна угода. Інструменти, щоб побачити, що ваша програма робить насправді, постачаються з нею: pprof для профілів CPU, пам’яті та горутин і детектор гонок під go test -race, який має бути частиною CI, а не тим, що ви пам’ятаєте запустити.

Де це вироджується

• Горутини, запущені без способу зупинити їх, течуть весь час життя процесу й ростуть разом із трафіком.
• Помилки, повернені без обгортання: збій десятьма шарами нижче приходить як «connection refused» без контексту.
• panic і recover у ролі механізму винятків для звичайних, очікуваних збоїв.
• Канали там, де простішим інструментом був м’ютекс, — виходить протокол, за яким ніхто не встежить.
• Спільні мапи, у які пишуть кілька горутин без блокування, — це спіймав би детектор гонок.
• Шаруваті абстракції, перенесені з Java чи C#, воюють із мовою замість того, щоб нею користуватися.
• context, прийнятий параметром і потім проігнорований: скасування ніколи не доходить до роботи.

Коли це застосовувати

Пов’язані сторінки

• РозробкаJavaJava вже тридцять років є типовою мовою великих бекенд-систем і досі та, яку бачиш, коли банк, авіакомпанія чи телеком відкриває своє дерево коду. Java робить собою не так синтаксис, як машина, на якій вона працює: байт-код замість машинного коду, компілятор, що оптимізує під час роботи програми, і збирач сміття, який налаштовують, а не замінюють. На цій сторінці — JVM, система типів, Spring, паралельність і те, що змінили віртуальні потоки.
• РозробкаNode.jsNode.js — це JavaScript на сервері й середовище, яке зробило звичним «один процес, тисячі з’єднань». Досягає воно цього тим, що ніколи ні на що не чекає само: ввід-вивід передано операційній системі або невеликому пулу потоків, а ваш код виконується між цим рівно в одному потоці. У цьому його сила для API — і його жорстка межа для будь-яких обчислень. На цій сторінці — модель вводу-виводу, масштабування, поділ модулів і помилки, що з’являються лише під навантаженням.
• РозробкаМікросервісиМікросервіси — це архітектура, у якій систему будують як набір сервісів, кожен з яких можна деплоїти окремо. Визначальна властивість — незалежна деплойність, а не розмір: сервіс правильного розміру тоді, коли одна команда володіє ним від початку до кінця. Усе добре в цьому стилі випливає з тієї незалежності, а все складне — з того, що виклики між сервісами тепер ідуть через мережу.