GoLang: Жарт, що зайшов занадто далеко

Поява GoLang стала неочікуваною подією у світі мов програмування. Запропонована розробниками Google — Робертом Пайком та Кеном Томпсоном (розробниками мови C та операційної системи Unix), мова Go (також відома як GoLang) претендувала на просте розв’язання проблем, що переповнювали сучасні мови програмування. Але що, якщо це був лише добре спланований жарт?

GoLang нібито забезпечує легкість і простоту програмування. На перший погляд, відсутність генериків, мінімалістичний синтаксис та однозначність у поведінці можуть здаватися привабливими рішеннями. Але для тих, хто знайомий зі складністю сучасних проектів, ці «простоти» виглядають не як зручність, а як навмисний пародійний жест.

Одним із найяскравіших прикладів цього є відсутність генериків на ранніх етапах розробки GoLang. Замість універсальних шаблонів програмісти змушені вручну писати функції для кожного типу даних. Це повертає нас до часів C++, коли для кожної реалізації вимагалася окрема функція, що значно знижує ефективність розробки та підтримки коду.

GoLang також відмовився від класичної об’єктно-орієнтованої моделі, яка дозволяє будувати більш складні й логічно структуровані ієрархії. Замість цього розробники змушені копіювати та вставляти код, що нагадує практики 90-х років, незважаючи на всі технічні досягнення сучасності. Ще однією проблемою є практика «покращення» існуючих типів у непов’язаних модулях, через що важко зрозуміти, де саме реалізований певний метод. Це значно ускладнює процес діагностики, перетворюючи його на пошук голки в копиці сіна.

Відмова від винятків і структурованої обробки помилок також підкреслює прагнення до спрощення, що, втім, має свою ціну — зменшення стабільності та передбачуваності. Відсутність концепції Null або None у GoLang робить роботу з відсутніми значеннями додатково ускладненою, що може призводити до непередбачуваних ситуацій. Використання оператора ’after’ замість класичного блоку ’finally’ створює додаткову складність і робить код менш інтуїтивним для підтримки.

Канали, що використовуються для передачі даних між горутинами, на перший погляд здаються зручним механізмом, проте вони мають свої недоліки. Це нагадує спробу створити поштову систему без адрес, сподіваючись, що повідомлення якось знайде свого отримувача. Використання каналів ускладнює відстеження потоку даних та може призводити до блокувань, якщо горутина неочікувано не зчитує дані з каналу.

Ще одним аспектом є заміна класичної багатозадачності на горутини. Горутини реалізують модель кооперативної багатозадачності, де кожна горутина продовжує виконання, поки явно не передасть керування. Це робиться, наприклад, при взаємодії через канали або інших точках синхронізації. На відміну від примусової багатозадачності, яка використовує планувальник ОС для перемикання контексту між потоками, кооперативна модель покладається на добровільну передачу керування. Це означає, що неправильно написана горутина може заблокувати весь процес, оскільки немає автоматичного механізму примусового переривання. Така модель вимагає від програміста більше уваги до координації, що збільшує ризик виникнення помилок синхронізації та блокувань.

Як продовження цієї історії, був винайдений формат protobuf разом з окремою мовою для опису структур даних та компілятором для генерування коду, що покликаний подолати обмеження GoLang. Згодом інші мови програмування змушені були адаптувати protobuf, часто всупереч своїм власним парадигмам, оскільки код, який генерував для них protoc, був зовсім не схожий на звичний код цих мов. Також протягом часу protobuf був змушений додати типи обгортки, щоб забезпечити семантику відсутнього значення, яка раніше не існувала та інші «звичні» можливості.

Отже, якщо ви задумалися, чи можливо вся історія з GoLang — це просто спланований жарт для тих, хто не побачив її справжньої мети, то ви не самотні. У GoLang є щось безперечно відмінне від інших мов — але чи там, де це потрібно? Недостатня простота та відсутність деяких важливих інструментів перетворилася на чисту пародію, яку сприйняли як серйозне рішення серйозних проблем.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті