Мой главный язык — джава. Немного питона. Языки с ручным управлением памятью, в общем, как-то обошли стороной, поэтому могу сравнить с тем что знаю

Плюсы:
— свежим глотком после java стало наличие структур и пойнтеров (без арифметики). легче представить как выглядят данные с которыми работаешь и например, в каком виде что передается в метод. это избавление от одного уровня абстракции что имхо есть хорошо. тем более что возможность "привязывать" поведение к данным не пострадала. из С же пришли конвенции стандартных библиотек (strconv, fmt и тп), тоже хорошо, не дает повязнуть в специфичной джаве jdk номенклатуре
— вменяемые литералы для популярных типов ([]) и работы с ними. это скорее не к заслугам именно го, а к костности джава. вроде как стандарт везде. вот в жаве в 12й собирались ввести raw строковые типы и даже уже запилили, сам на бете игрался, а потом архитектор пишет "есть корнер кейсы которые не устраивают, и не уверен, что мы займем литерал ` а через 100500 лет (утрирую) он нам не понадобится под другое. их не так много свободных" no comments как говорится
— нативность бинарников и быстрый запуск что как бы очевидно, но приятно удивляет еще скорость компиляции. почитав архивы разработчиков языка нашел, что скорость компиляции -- один из приоритетов в разработке языка.
— прозрачный toolchain, написанный на го. можно отпрофилировать программу вплоть до системных вызов. в жестких случаях в компиляторе используется сразу asm, ну да. но никакого промежуточного black box в виде jvm-монстра с ее неявным поведением требующим в итоге "прогрева" и прочей магии, нет.
— спорно, но авторы заявляют "простоту" языка приоритетом в разработке, и так во всем: в реализации методов, в семантике, в тулинге. и в целом у них кмк получается. пример 1: сортировка это mergesort для не-примитивных типов (ускоренный insertion sort) такая реализация занимает несколько десятков строк. в java и python более эффективный (+30% скажем в среднем) tim sort на порядок больше (сотни строк). стоит ли одного другого вопрос выбора. если у меня все будет упираться в сортировку, и я это смог понять, всегда можно именно ее впилить, какую нужно, но мне нравится по умолчанию подход с "least surprise" во всем, куда бы не полез. пример 2: в java для мап есть хитрые методы computeIfAbsent() compute ifPresent() putIfAbsent() (внимание! putIfPresent() нету) это пример развитости стандартной библиотеки что с одной стороны хорошо. но экономит ли это время разработки, вопрос. авторы go хотят оптимизировать фактор времени освовения/разработки, в т.ч. за счет вычислительной сложности. это осознанный выбор
— авторы языка позиционируют его как ... язык системного программирования. не ядра наверняка, но все равно, сишники вряд ли с ними согласятся. по мне — дернуть системный вызов, обернув вокруг него какую-то логику, без JNI, jvm и т.п. удобно, да. в итоге интересный эффект: если в java профессиональный рост возможен только "вверх по стеку" (архитектура, энтерпрайз) то в го вполне можно заниматься полезными вещами, в сторону системы. кмк плюс
— из стандартных библиотек нравится сетевой стек, ну, его многие хвалят
— нравится community (разработчиков языка, про девелоперское ниже). вот возник вопрос — в го нет бинарных литералов, нашел ветку обсуждения, proposal, написал туда своей пример, ответили. уже комиты идут. а в питоне хотел поинтересоваться, почему с версии 3.3 стали рандомайзить seed встроенной hash() функции при каждом старте рантайма, и насколько это правильно, ничего не нашел. может, совпало, но вот...
— каналы. inmemory cache на них не сделать, но для большого числа ("простых" ага) случаев message passing работает хорошо.
— есть goto... хм



Не нравится:
— обработка ошибок. например у меня передается буфер и я делаю в методе несколько записей в него. мне все равно на какой по счету записи я сфейлюсь, мне нужно выкинуть ошибку а количество записанных символов не важно (ответ по http скажем шлем). так бы я поставил try/catch и все, а в го нужно If на каждую запись. и дело не в сборке стека. если в го есть семантика сигнализирования об ошибке то хотелось бы механизмы удобной их аггрегации и без сбора стека
— традиционно сюда относят отсутствие дженериков. не уверен что это именно недостаток языка как такового. если у меня не библиотека, можно подкорректировать механизмы управления сложностью под доступные языковые инструменты. в го для этого интерфейсы которые включением других как бы наследуют поведение и соответственно reciever types которые позволяют неявно (без implements) задавать имплементацию, интерфейсов или структур. встроенные типы (мапа, слайсы) параметризованы. доступен type casting но это небезопасно, и делает код малочитаемым, поэтому когда необходим богатый полиморфизм типов, лучше посмотреть в сторону других языков. это как бы официальная позиция разработчиков. пока не найдут "идеальный" вариант генериков по крайней мере. сколько его искать будут...
— долгоживущих монолитов на нем не писал, но вызывает вопросы их работоспособность учитывая что гошный GC (afaik) не умеет compaction
— в некоторых случаях желание сделать "просто" и оградить разраба от ошибок заходит далековато. например в memory model нет атомиков. совсем. при том, что в самом runtime авторы их используют но гарантий разрабам не дают. и это в языке заточенном на конкарренси. тикет открыт уже много лет. бывают такие wtf
— управление зависимостями. тема известная. авторы языка не сидят на месте. здесь пусть выскажутся те, кто пишут большие проекты в продакшн с многими зависимостями. вроде как работа ведется постоянно. без конфликтующих зависимостей проблем нет как с GOPATH так и с новыми модулями (с модулями есть баги, допиливают)
— девелоперское сообщество. когда пытаются перенести практику ООП. с интерфейсами и тайп кастингом в го можно можно накрутить, но в таких случаях непонятно, зачем берут именно го, если нужен энтерпрайз то это другие языки. на го это получается.. плохо
— востребованность. найти проект сложно. особенно с учетом предыдущего. джавы завались


В целом как как один из мейнстримовых языков, компилируемый, статически типизированный и с автоматическим управлением памятью golang неплох и вроде как без особых альтернатив. плюс удобная модель асинхронной работы. нравится

Более подходящего форума не нашел, философия, ок. просьба перенести если что