Ну и чушь написали, используя неуместную аргументацию аппелирования к Сысоеву с его специфичным продуктом. Большинство разработчиков, которые хотят нормальных денег, работают в кровавом ынтерпрайзе с огромными монорепозиториями, легаси кодовыми базами на сотни тысяч строк кода, десятками (иногда сотнями) ежедневно коммитящих коллег и десятками библиотек и фреймворков в зависимостях. В каждой из third-party библиотек могут быть баги. Вы как, возьмете на себя смелость утверждать, что поняли проблему чисто по воткнутым логам, если, к примеру, зарепортили жалобу от клиентов, что иногда возникает немотивированный обрыв передачи данных или данные приходят испорченными? В лучшем случае по логам получится только поверхностно локализовать область поиска виновника. А такие ситуации сплошь и рядом бывают, когда проблема не в твоем клиентском коде, а в библиотечном. Например, там гонка или какой-то хардкод, который невозможно переконфигурировать. И в документации к библиотеке он не описан. И в этом Go удобен тем, что там очень сложно сделать не KISS-архитектуру и как результат, поиск проблемы и написание к ней костыля (или решение поднять или понизить версию) занимает меньше времени, чем на C++/Java/C#. Спасибо, хватило в свое время джавы со всякими интересными "особенностями реализации" Spring или Hibernate, стектрейсы которых приходилось кропотливо простукивать иногда несколько рабочих дней, продираясь через рефлексию, проксирование и кодогенерацию, чтобы понять, что где-то в промежуточном middleware отсутствует какая-нибудь проверка, из-за чего при совокупности различных условий происходит бажное поведение.