Отцы и дети. Java и Go

Данная статья содержит размышления о сильных и слабых сторонах обоих языков. Кода нет, смысла не так чтобы много — чистое словоблудие и мнение рядового разработчика. Если интересно, велком под кат.

В данной статье много воды, отражены мысли и опыт воспалённого мозга, потому заранее предупреждаю: вы можете просто зря потерять своё время. Данную и любую статью нужно читать с включённым критическим мышлением и вообще понимать, что автор — «профессор лука».

Идея статьи родилась в связи с повсеместной попыткой написать очень многое на Golang, и автор начал ловить флэшбэки похожих событий.

TL;DR

Автор рассуждает о том, что языки программирования — лишь инструменты выражения мыслей и абстракций, а проблемы кода чаще связаны с непониманием предметной области, а не с самим языком. Golang упрощает мышление и помогает средним разработчикам писать стабильный и производительный код, но плохо подходит для сложных доменов. Java, наоборот, более выразительна и подходит для богатых предметных областей, но требует глубокого понимания JVM и легко порождает сложность. Главный вывод: нет «лучших» языков — есть подходящие и неподходящие, а мода на один стек со временем повторяет старые ошибки.

Любой язык, кроме Java

Мой старший сын выбрал быть программистом (хоть я и старался отговорить). Когда он начинал входить в тему разработки, я ему посоветовал выбрать любой язык, кроме Java! Сейчас он пишет на Golang и спит спокойно. В целом, по мне, Java, возможно, слишком усложнена своей экосистемой, но в то же время это отличный инструмент для решения большого спектра задач. Golang тоже отличный инструмент — как мне кажется, для решения другого рода задач.

На каком языке вы думаете?

Давайте попробуем ответить на один вопрос: на каком языке вы думаете? Русский, английский, Java, Golang… По моему мнению, мы, люди, вообще не думаем на каком-то языке, а манипулируем образами в нашей голове, при выражении которых каким-либо образом получаем кальку этих образов, то есть очень неточные проекции, слабо отражающие суть этого самого образа. Замечали когда-либо, как в голове всё структурно, логично и красиво, но при выражении этих мыслей через язык, визуализацию, звуки или запахи эта структурность и логичность начинает тускнеть?

А что нам даёт язык, точнее языки в целом? Мне кажется, они дают возможность выразить эти образы, на которых мы думаем, с целью передачи их другому человеку. В момент передачи этих образов начинают активно использоваться абстракции в виде метафор, идиом и прочего, но я заметил, что бывает очень сложно подобрать именно то, что отражает внутренний образ так, чтобы он одинаково понимался несколькими людьми. Особенно сложно, если принимающая сторона — пассивный слушатель. Вероятно, при таком раскладе большая часть оральной работы (когда работают ртом) приносит больше проблем, чем пользы (бесконечные встречи, на которых одна голова говорит, остальные спят).

Есть ещё момент: с одной стороны, чем больше язык может вмещать в себя метафоричных абстракций, тем он более лаконичен и более точен для выражения этих самых образов; с другой стороны, чем лучше человек владеет языком, тем лучше он выражает свои образы (тут и про уровень образованности, и про эрудицию, и про уровень интеллекта, и про развитость в какой-то определённой сфере).

Код как сочинение

Теперь переходим к разработке. Вероятно, программирование (современное) ближе к написанию сочинений, эссе, книг и прочего. Иногда встречается многословный код с запутанным смыслом, выглядящий как сочинение ученика 4-го класса; иногда код выглядит как книга, достойная Пулитцеровской премии, в которой могут быть глубоко заложены смыслы между строк и для понимания которой приходится 10 раз её перечитывать в разных состояниях. Почти все варианты написания кода можно читать только под припев из трека «Пироман 17» (Хаски), но, вероятно, по одной причине — мы его не поняли. Возможно, чистый код, который мы хотим называть чистым, — это бестселлер: в нём всё очевидно, абстракции понятны и не текут, всё пишется в едином стиле, понятно, как проверить, то есть код доступен многим читателям, которые могут легко стать соавторами.

Если продолжить аналогию, то иногда использование сторонних библиотек или фреймворков становится затруднительным ввиду отсутствия осознания абстракций, заложенных в этих кусках стороннего кода. Также, думаю, вы видели (я участвовал, и не раз), как исправляют чужой код, где ты уже 10-й автор в условных 100 строках и код читается как письмо дяди Фёдора из Простоквашино. В такие моменты возникает желание «всё переписать», «всё сделано не так», «срочно нужно писать вторую версию», «да я всё напишу проще и лучше». А может, проблема в том, что мы не поняли предпосылок в виде абстракций, истории развития решения, бэкграунда разработчиков, которые писали код? Через время замечаем, что образы просачиваются в наше сознание и мы уже отлично ориентируемся в предметной области того, над чем работаем или что используем. Как следствие, не всегда остаётся желание что-то написать самому или переписать (но да, если играет «Пироман 17» на репите, то это, вероятно, знак).

Выразительность: Golang и Java

Попробуем теперь сравнить Golang и Java с точки зрения выразительности. Golang очень хорошо усмиряет пыл разработчика написать «абстрактные фабрики абстрактных фабрик» или накидать абстракций с дженериками, с контравариантностью и ковариантностью в контрактах, как это иногда любят в Java. С другой стороны, тот же Golang не даёт возможности создать абстракции более высокого порядка, которые даёт Java. Подходит это или нет — всё зависит от модели предметной области. Не будем уходить в сторону DDD и прочего, подумаем просто на поверхности: когда приходит новый разработчик и ему требуется очень продолжительное время, чтобы вникнуть в проект, то, возможно, либо предметная область очень сложна, либо код написан так, что чёрт ногу сломит; не будем учитывать факторы, относящиеся к конкретному специалисту, ввиду презумпции интеллекта. Естественно, тут нет вины самого языка или его специфики, в первую очередь вопрос к варианту его использования. То есть мы видели замечательные и понятные программы (системы), написанные на Golang, и отвратительно написанные на Java (коих, вероятно, больше), но мы смотрим с точки зрения возможности выразить абстракции, ввести понятия предметной области, которыми удобно пользоваться и которые удобно поддерживать на протяжении всего времени жизни проекта. Мне кажется, Golang позволяет это сделать менее удобно, чем Java. Да, код будет понятен, но только если модель предметной области несложная или пока несложная, как в стартапах: предметная область зачастую не осознана до конца, образы ещё примитивны, абстракции лёгкие. Правда, когда мы пытаемся использовать выразительность Golang при написании условного банка, особенно где предметная область очень богата и изучена достаточно хорошо, то, вероятно, на выходе мы получим проект, который очень сложно поддерживать и осознать. Как следствие, такие проекты сами порождают техдолг и несут высокую когнитивную нагрузку.

100%, что где-то сейчас плачут несколько Golang-разработчиков, предлагающих уже Java, C#, Haskell, душу дьяволу — лишь бы не писать больше бизнес-логику их проекта на Golang ввиду сложности её выражения.

А микросервисы спасут?

А как насчёт микросервисов, призванных снизить когнитивную нагрузку и упростить построение комплексных систем? О да, я думаю, на этот счёт уже написано статей, пройдено холиваров, и вообще даже обсуждать особо нечего. Один момент всё же стоит упомянуть: в более-менее приемлемом подходе один сервис — один контекст, который содержит агрегат, ну или атомарную единицу предметной области (в рамках транзакционной согласованности). Если это разделить, то получается high coupling и, как следствие, distributed monolith. Ну а если эта атомарная единица сложна, то в ряде языков она будет очень сложно помещаться в голову разработчиков.

С другой стороны, при богатстве выразительности Java (которая достаточно далека от C#, Scala, Kotlin, TypeScript) есть больше вариантов сделать такое чудо, осознать которое человеческий мозг тоже не всегда может, особенно за короткое время. Кстати, насчёт Kotlin: с точки зрения введения удобных абстракций он имеет возможность строить свой DSL, что позволяет манипулировать очень удобными конструкциями и с точки зрения понимания, и с точки зрения поддержки, но я редко видел кейсы, когда эту возможность использовали удобно.

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

Посмотрим на другие аспекты — производительность и стабильность созданных программ. В среднем Java не конкурент Golang в этом вопросе. Тут можно возмутиться: как так? Да Java может быть быстрее самого C++! И да и нет. Для создания очень быстрой и суперстабильной программы, которая сложнее Hello World, нужно обладать достаточно глубокими знаниями не в самом языке, а в JVM, которая и прекрасна своими возможностями, и одновременно сложна до ужаса. Подберите один из шести GC под ваш ворклоад, сконфигурируйте его до оптимальных настроек, обойдите все подводные грабли при эксплуатации в облаке — можно продолжать бесконечно, но когда вы захотите гарантировать стабильный latency, то придётся ещё попотеть с off-heap-магией и применением оптимизаций уровня процессора. А как насчёт стабильности? Попробуй разобрать очередную проблему с Virtual Thread Pinning, провести пару бессонных ночей с выпадением исполнения в интерпретацию из-за специфики облака… Да, Java и тут сложна, но вопрос в другом: будет ли код среднего разработчика (не про уровень, а про обобщённого среднего специалиста) на Java более оптимальным и производительным, чем код такого же разработчика на Golang? Зачастую я встречал кейс, что на Golang средние разработчики пишут более стабильные и оптимальные приложения. Конечно, если копнуть чуть глубже, то и в Golang есть свои ограничения, и понимать там нужно достаточно, но это скорее уже крайние кейсы, а в Java разработчик должен понимать больше.

Не «хорошо» и «плохо», а «подходит» и «не подходит»

Я давно отказываюсь от слов «хорошо» и «плохо», заменяю их на «подходящее» и «неподходящее». Безусловно, всё зависит не только от специфики языка, а в первую очередь от уровня владения им, но в грубом приближении Java больше подходит для сложной предметной области при условии хотя бы поверхностного понимания принципов работы JVM, а Golang — для более простой предметной области, но где нужны высокопроизводительные программы.

В попытках натянуть сову на глобус мы получаем очередной момент поклонения вынесенному на берег грузу и забивание гвоздей не молотком. Когда слышу про попытки разработки сложных сервисов на Golang или производительных сервисов на Java (при условии отсутствия понимания работы JVM), то делаю только жест «рука-лицо». Конечно, мы слышим адекватную аргументацию: у нас один стек в компании, нам не нужно будет поддерживать разные стандарты разработки, процесс найма будет проще. По мне, это слабый аргумент, так как эффект от поклонения одному стеку может привести к захламлению реализаций, которые будет очень сложно поддерживать и развивать.

Дети становятся отцами

Мне интересен другой эффект, который напоминает траекторию Java. На заре появления Java были большие проблемы с зоопарком железа, и под каждую очередную железку нужно было пересобирать свою программу. Java решила эту проблему через JVM, а также привнесла ряд других удобных механизмов: сборку мусора, отсутствие множественного наследования, отсутствие необходимости разбираться с арифметикой указателей, контролируемую память, адекватную модель памяти с гарантиями, позже generics (спасибо, Мартин, мы тебя запомнили), какую-никакую (по моему мнению, даже очень подходящую) WORA. Это всё сделало Java очень популярным языком, но начали писать на ней всё, точнее вообще ВСË. Я даже видел лендинги с подключением к базе через Hibernate! Как итог: те, кто выбрал Java несоизмеримо своим потребностям, начали её же срочно хоронить… похороны идут уже 30 лет.

Вам не кажется, что очень скоро мы будем наблюдать теперь и похороны Golang?

Дети в любом случае становятся отцами.

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