Начинаем любить Go

Автор оригинала: Jeremy Mikkola
Если что, это вольный перевод статьи из блога Jeremy Mikkola.

Эта статья о том, как некоторое время спустя я распробовал и таки полюбил язык Go (аки golang).

Жалобы

Еще год назад у меня было полно жалоб на тот или иной аспект Go. В основном я жаловался на то, что при том, что ты не можешь использовать Go как «настоящий системный язык» (в плане написать-на-нем-операционку), тебе все равно приходится думать о том, о чем обычно приходится думать в системных языках: например, использовать тут указатель или нет. Система типов лежит в непродуктивном ущелье между достаточной строгостью, чтобы стать «автоматичной» (привет адептам Haskell!) и достаточной динамичностью, чтобы не отвлекать (как в Python). Какое-то время я тупил на таких вещах, как проход по юникодовой строке не символами, а байтами, и всякое такое. Я обвинял Go в том, что он так-то не всегда следует своему принципу простоты, так как в нем есть много разных узких штук, вроде make(). И конечно же я жаловался на то, что при работе с Go постоянно приходится повторять блоки if err != nil { return err }.

Поначалу я точно не мог назвать себя фанатом Go.

В техническом плане я согласен с тем, что большинство моих жалоб корректны. Я согласен с тем, что систему типов можно было бы придумать и покруче, а от указателей не помешало бы немного абстрагироваться. Но как только я начинаю понимать, что (не все, но многие) проблемы, на которые я жаловался, на самом деле вроде как даже и не непрягают. В действительности это напоминало нытье на целый лес, из-за пары некрасивых деревьев. В повседневном использовании языка большинство вещей, о которых я так волновался, вообще не давали о себе знать. Я ни разу не встречал баг, так или иначе связанный с проходом по строке. В реальном коде ты почти не кастишь interface{} так часто, как хотелось бы тем ребятам, которые дрочат на системы типов. Ах да, нет беды в том, чтобы вызывать make() в одном месте и new() в другом. Больше всего я ругался на те архитектурные решения языка, которые усложняли создание абстракций. Ты не можешь просто так сделать структуру данных, которая станет альтернативой к встроенным структурам данных (привет кодогенерации!). Без обобщений ты не сможешь строить большие обобщенные абстракции. Скорее всего, это сделано намеренно.

Серия 217: Новая надежда (на Go)

Теперь я думаю о Go иначе. Это не системный язык, это не динамический язык, и это даже не обязательно язык для веба, это язык, который стоит против абстракций. Как только я ни подумаю о Java, первая вещь, которая приходит в голову это это гигантская замыленная система, образованная благодаря экстремальным примерам обязательного обобщения и любви к созданию объектных иерархий ради объектных иерархий. Да, я знаю, что абстракции очень и очень удобны: они позволяют нам делать много разных вещей, используя несколько строчек кода. Основная проблема в том, что они очень-очень сложные!

Когда интерфейс — всего лишь интерфейс какой-то абстракции, даже не ее реализация, слишком большой, чтобы полностью поместиться в твою голову, абстракция заставляет программиста страдать! Строки кода, использованные на решение определенной задачи, это довольно убогая метрика того, как тяжело было эту проблему решить. Написав в 2 или даже в 10 раз больше кода с более незамысловатыми абстракциями (или вообще без оных), решение может в конце концов оказаться эффективнее. На досуге можешь посмотреть «Simple Made Easy» товарища по имени Rich Hickey, который классно обрисовал разницу между простотой и легкостью.

Как вы думаете, что проще понять для программиста, который только пришел в проект и не знает ничего о тех гигантских абстракциях, которые вы тут нагородили: 10 строчек кода, который имеет смысл только если ты знаешь абстракции или все-таки 20-100 строчек кода, которые говорят сами за себя? Это то место, где Go всходит на небосвод! Спасая твою бренную душу от абстракций (ценой «пары строчек кода»), код на Go сохраняет смысл и логику вплоть до самых мелких кусочков программы. За это программисту приходится платить… написанием кода (внезапно)! Учитывая то, что ты поначалу потратил значительные усилия, чтобы разобраться в той или иной абстракции, когда ты будешь вынужден использовать абстракцию поменьше, твоя продуктивность резко упадет, так как тебе придется реализовать еще больше логики.

В большинстве случаев, эта изначальная стоимость разработки в последствии многократно оправдывается, когда другие программисты (или ты через полгода) приходят и пытаются читать, а то и работать с кодом. Go скорее оптимизирует непосредственно понимание кода на протяжении всего цикла разработки, чем позволяет быстро клепать большие штуки.

Чтение кода

Эту штуку точно стоит оптимизировать. Код никогда не удаляется сразу после написания, люди его читают. Давайте вспомним Исаака Азимова и его «Три закона роботехники»:

  1. Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
  2. Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
  3. Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому и Второму Законам.

А я придумал «Три закона кодонаписания»:

  1. Программа не должна быть сложна в понимании для человека, в той же степени в которой нехватка ясности должна позволять установиться непониманию.
  2. Программа должна быть быстрой и краткой, кроме тех случаев, когда она станет нарушать Первый Закон.
  3. Программа должна быть легко понятна компьютеру в той мере, в которой это не противоречит Первому и Второму Законам.

Кто-то вообще говорил, что «программы нужно писать так, чтобы их могли читать люди и только иногда запускали комьютеры».

Обычно эти правила таки применяют, только в обратной последовательности. Сначала разрабатывают язык, который позволяет легко доносить суть комьютеру. Потом, уже работая в этих рамках, программу делают максимально быстрой и краткой. И наконец, в качестве «бонуса», мы немного допиливаем язык в плане его, собственно, понимания. А вот Go, например, выбирает правильную последовательность. Программы на Go, в первую очередь, легко читаются людьми, затем легко разбираются компьютером (Go заботится об уменьшении времени компиляции) и только в последнюю очередь — быстрые и краткие. Интересный факт: нельзя сказать, что программы на Go не быстрые, Go очень даже быстрый язык. Go может быть излишне «многословен», но на то есть причина.

Как только мы ставим Второй Закон на первое место, то получаем «преждевременную оптимизацию», или ее не такого популярного братца — «преждевременное обобщение». Оба, в общем-то, являются корнем зла в программировании. Как только мы ставим Третий Закон на первое место, то получаем ассемблер. Нравится? Мне нет!

Год назад

Когда я изначально писал свои впечатления о Go, я еще не знал о другом новом системном языке — Rust.

Я уверен, что если бы я тогда увидел Rust, по крайней мере, в том виде, в котором мы видим Rust сегодня, то я бы определенно предпочел бы его Go. В языке Rust есть все: «человеческий» вывод типов, генерики, примеси, макросы, разные замечательные compile-time проверки. Ты даже можешь попросить компилятор проверить, что возвратные значения определенных типов нигде не игнорируются! Rust отвечает на почти все вопросы, которые у меня были к Go. В таком случае, зачем я все еще выбираю Go, начиная новый проект?

В языке Rust ты работаешь с мощными абстракциями. Ты много чего можешь сделать с небольшим количеством кода — иногда даже не кода. Это, конечно, оплачивается тем, что приходится учить абстракции. Так как это новый язык, очень большую долю этой «дани» еще предстоит заплатить. Каждый раз, когда я делаю что-то с Rust, я постоянно ловлю себя на том, что я весело провожу время, играясь с разными абстракциями, но реально почти ничего не делаю в сторону решения поставленной задачи. В языке Go я начинаю решать проблему с самого начала работы над ней.

Размер имеет значение

Что уж говорить, для определенных проектов я все-таки выберу Rust. Особенно для очень больших проектов, где внушительное доверие абстракциям будет иметь больше смысла. У языка Rust есть классная система типов, которая приносит больше плодов именно в огромных (100.000+ строчек кода) проектах. Но даже с абстракциями, код на Rust не обязательно будет яснее, чем код на Go, так как первый обменивает немного краткости на такие мощные вещи, как генерики.

Размер имеет значение, но имеет значение не размер проекта как такового, а размер области видимости, которую ты должен держать в голове, чтобы осознавать происходящее. Go классно уменьшает эту область для маленьких и средних проектов. Да, попечатать придется, но ведь это не самое сложное в программировании!
Поделиться публикацией

Комментарии 73

    –10
    Я конечно выражу непопулярное мнение, но:

    Как только создатели и адепты Go не пытаются протолкнуть свой, мало кому нужный велосипед. Тут тебе и ежедневные посты на хабре, и загаженная RSS-лента, и вот такие «заказные» призывы любви, в остальных Интернетах, которые к тому же еще и переводят…
      +7
      Вы хотите сказать, что большое количество постов про Go не демонстрирует, что он нужен и полезен большому количеству людей? И когда вы назвали призывы любви заказными, вы имели в виду, что за их написание кто-то кому-то заплатил?
        +21
        ИМХО, большое кол-тво постов про Go есть назойливая реклама помноженная на восторг неофита.
          0
          В заголовке статьи написано, о чём она. Я и не думал, что в ней будет технически полезная информация. В результате чего у Вас сложилось такое впечатление?
            –1
            Вы считаете, что за эту реламу кто-то кому-то платит?
              0
              Как будто восторг — это что-то плохое. Мне после C++ с «переунаследуем вот это от этого» Go с его интерфейсами показался глотком свежего воздуха.
              +5
              Осторожно соглашусь. Уж больно часто последние пол года вижу восторженные статьи о Го на Хабре. Видать все остальные ЯП — полная чепуха.
                +17
                Во многом это связанно с эмоциями, которые вызывает язык у тех, кто его пробует и остается доволен. Про Руби в свое время тоже много писали.

                Go дает новые ощущения при разработке. Можно просто сделать некоторые вещи, которые раньше казались сложными. И у него хорошая читаемость кода. Логично, что у тех кто его попробовал и кто любит писать статьи, частенько возникает желание эти ощущения выразить.
                  +5
                  Вот честно, всегда удивлял этот аргумент с читаемостью. Открываю вот я портянку Go кода — ну нифига она не читается прям вот слету, что готов комитить тут же. Он читает не лучше и не хуже, чем любой другой язык программирования, с которым я не часто работаю. Но значительно хуже, чем основные мои языки. Мне, о хоспаде, проще тонну objc кода прочитать, чем читать go или swift. Читаемость она приходит с навыком и опытом на этом языке, а так же, когда сам код простой. За редкими исключениями действительно сложных синтаксически языков вроде С++.

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

                    Так не бывает. Безотносительно вопроса о Go, у разных языков разные свойства и с этим незачем спорить.

                    Читаемость она приходит с навыком и опытом на этом языке, а так же, когда сам код простой.

                    Ну вот вы и сами ответили на свое удивление. Go объективно меньше (меньше абстракций и конструкций, проще грамматика, меньше вещей запоминать, переиспользование знакомых концепций из С-подобных языков и тп) — отсюда вывод, что навыка для достижения «читабельности» нужно меньше, чем с более «большими» языками. А потуги авторов создать программистам стимул писать более простой и читабельный код приводят к тому, что код на Go как правило такой и есть.

                      +1
                      Go объективно меньше (меньше абстракций и конструкций, проще грамматика, меньше вещей запоминать, переиспользование знакомых концепций из С-подобных языков и тп)

                      Это все сферические кони в вакууме, которыми любят хвастать авторы языка и влюбленные в него с первого взгляда. Сложный код пишется на любом языке и Go не предоставляет ничего революционного, что бы решило эту проблему. Это просто еще один язык с немного другим синтаксисом.

                      Так не бывает. Безотносительно вопроса о Go, у разных языков разные свойства и с этим незачем спорить.

                      Так бывает. Я не беру экстремальные варианты, а популярные вещи, на которых сам не пишу — swift, python, ruby. Мне знаком синтаксис этих языков, но я с ними не работают. Все они предстают передо мной как каша, в которой надо все равно разбираться, но их создатели преподносят их как решение беды читаемости и продуктивности. А когда же ты имеешь опыт, но байки про простую грамматику как-то улетучиваются и Objc становится прекрасно читаемым языком, а объем синтактического сахара C# лишь приводит к сокращению объема кода, но не увеличению его сложности. Все эти рассуждения про читаемость абстрактны и бессмысленны. С++ тоже легко читается до тех пор, пока не приходит извращенец со своим мета-программированием.
                        +6
                        «Python передо мной предстает как каша… а С++ легко читается».

                        Окей )

                        Все эти рассуждения про читаемость абстрактны и бессмысленны.

                        Жаль, если для вас это так. Читабельность кода — это общепризнанно важнейшая характеристика хорошего кода, и Go создавался людьми, которые считают это очень важным аспектом программирования — даже слишком важным, чтобы заложить это в дизайн языка.
                          +1
                          А уже общепризнано как эту характеристику измерять? :-)
                          0
                          Читабельность кода — это общепризнанно важнейшая характеристика хорошего кода

                          Вот именно. Это характеристика кода, но не языка.
                          +3
                          Go объективно меньше (меньше абстракций и конструкций, проще грамматика, меньше вещей запоминать, переиспользование знакомых концепций из С-подобных языков и тп)

                          Чем нас кормят создатели очередного «простого и лёгковесного» ЯП/библиотеки:
                          Наш ЯП/библиотека проще, меньше по размерам и исходники компилятора/библиотеки содержат всего N тысяч/сотен строк кода! Код проще читать и поддерживать, в нём меньше багов, он быстрее работает и занимает всего N десятков килобайт! Даёшь упрощение во все щели!!11

                          Подаём всё это на вход basicBullshitFilter() и получаем:
                          Да на этом грёбаном ЯП/библиотеке невозможно толком написать ничего сложнее калькулятора! Повырезали все крутые, но сложные в реализации фичи, чтобы меньше париться. Исходный код библиотеки небольшой? Значит, меньше фич! Исходный код компилятора небольшой? Значит, компилятор тупой, а генерируемый им код — отстой! ЯП содержит в N раз меньше синтаксических конструкций, чем большинство популярных ЯП? Значит, код на нём будет в log N раз менее читабелен, а для решения задачи на нём придётся написать в log N раз больше кода и это займёт в log N больше времени, а на очень сложных задачах — до N раз больше времени!

                          В общем, время покажет. Пока что, после пробы Go, я могу охарактеризовать его лишь как причёсанный C со сборщиком мусора, но никак не вменяемым ЯП общего назначения. Впрочем, учитывая, для чего его создавали (на мой взляд — для AppEngine), это нормально. Просто мне не хочется на нём ни писать, ни читать.
                            0
                            Судя по результату, ваш basicBullshitFilter() работает по принципу «не пробовал, но осуждаю» :)
                              0
                              А вы всё пробуете, что плохо пахнет (ну мало ли, вкусняшка)? :-)
                                0
                                Нет, только то, что хорошо )
                        +2
                        Дело в едином формате. Глаз, со временем, будет вытаскивать нужные конструкции из кода. Но когда:
                        // 1
                        if (0 > printf("%d", i))
                            return EXIT_FAILURE;
                        // 2
                        if (0 > printf("%d", i)) {
                            return EXIT_FAILURE;
                        }
                        // 3
                        if (0 > printf("%d", i))
                        {
                            return EXIT_FAILURE;
                        }
                        

                        Тысячи вариантов. Только не нужно говорить, что мозгу всё-равно. Особенно при большом количестве кода под утро. Да я люблю Си. Си великолепен. Но некоторые программисты не заботятся о читаемости кода, и Си даёт им такую возможность.
                        if (0 > printf())
                            stuff(), stuff2(), i++, j += i++ + ++j; // что, чёрт возьми???
                        
                          +2
                          Народ, либо полегче, либо… что происходит в этом коде?
                            0
                            UB, думается.
                          +3
                          Читаемость обусловлена лаконичностью, отсутсвием «лишних» символов и довольно жесткими правилами форматирования, что обязует использовать определенный единый стиль, чтобы программа скомпилировалась.

                          В процессе изучения языка исходники читать приходится очень много т.к. многие вещи реализованы модулями на Гитхабе, из которых надо сначала выбрать, а потом понять что он хочет т.к. доки может и не быть. Большой минус языка, надеюсь в будущем с этим будет лучше.

                          Так вот в процессе чтения, лично я понял, что оно дается мне гораздо легче, чем чтение кода на js, php, c, я уже молчу про c++ или perl. Не просто кода из документации, а реального кода из чьих-то проектов.

                          Да и судя по всему, многим дается легче. Где-то на уровне Питона.

                          Понятно, что без знания синтаксиса читать не выйдет. Да и набыдлокодить можно везде. Но в среднем, читаемость находится на очень хорошем уровне.
                          0
                          >Можно просто сделать некоторые вещи, которые раньше казались сложными.

                          Было бы здорово вот об этом и услышать. А то я пока что не прочитаю — не могу взять в толк, зачем мне использовать Go, хотя бы в теории, если все тоже самое можно и на Python сделать (с еще большим удовольствием, мне субъективно не нравится синтаксис гошный. После python и ruby на него банально смотреть больно)
                            +4
                            Go несравнимо быстрее Питона. Я вот делаю специфический реверсивный прокси на Go. Пустое проксирование у меня получилось строчек в 10 и по простеньким тестам (ab) оказалось всего в 1.5 раза медленнее nginx. В 2 раза быстрее node.js, во много раз быстрее Питона и php (про память я молчу).

                            Всякие системы сбора статистики, отдачи баннеров и прочее, что раньше писали на Си ради производительности, сейчас можно делать на Го гораздо быстрее и удобнее. Да в прочем и для обычного веба он подходит неплохо, не уверен правда в наличии фреймворков для серьезно больших сайтов.
                          +6
                          Да ладно… А мне вот, например, мозолят глаза статьи про Rust или, Столлман упаси, C#, или вообще, да простят меня Керниган и Ричи, PHP. Но это не делает их плохими языками для своего сегмента. Это означает только то, что мне они не нравятся. И больше ничего. Аналогии выстраивайте сами.
                          +2
                          Это больше похоже на очередную молодую технологию, которая переживает короткий этап своего развития, когда все прекрасно, все старые проблемы решены, новых проблем нет, все работает. Тот же docker постепенно выходит из этой стадии и открывает людям горькую правду, что с решением старых проблем появляется вагон новых специфичных для него. Go пока видится в этой стадии и ворох одинаковых по содержанию восторженных статей тому явный показатель. Я сам поддался и побаловался, но вообще не понял фишки языка — он странный во всех своих проявлениях, его go-рутины вообще обыденность какая-то особенно после async-await штук, но они почему-то преподносятся как решение всех бед многопоточности. Хотя это банальная job-система с простенькими примитивами синхронизации. А за пределами этого есть вроде бы богатый framework и все. Я лично не верю, что этот язык ждет какое-то невероятное будущее.
                            0
                            Это вы попытались описать своими словами Hype Cycle и наложили свои представления на него, подав как вывод. На самом деле на Go не просто так пишут почти весь современный софт для кластеров и всего вокруг, и все кто строит бизнес на Go уже прекрасно знают, чего ожидать, что язык может, что не может — так что по hype cycle Go уже давно вышел на «плато продуктивности». Если вам еще интересно мнение специалистов, мониторящих технологии, то посмотрите на TechRadar от ThoughtWorks, согласны ли они с вашей оценкой.

                            go-рутины вообще обыденность какая-то особенно после async-await штук

                            Однозначно обыденность. Ну чего же вы хотите от Google и Томпсона с Пайком — не все же настолько умны, чтобы знать про «async-await штуки» )
                              0
                              Однозначно обыденность. Ну чего же вы хотите от Google и Томпсона с Пайком — не все же настолько умны, чтобы знать про «async-await штуки» )

                              Сарказм непонятен. Эта конструкция языка предельно проста и повсеместна, но ее преподносят как какое-то серьезное достижение. Наоборот даже, индустрия пытается уйти от этого устаревшего варианта, который порождает слишком много кода, который невозможно читать.

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

                              На самом деле на Go не просто так пишут почти весь современный софт для кластеров

                              Смелое заявление. Доказательства? Кроме гугла конечно и недавних полутора статей на хабре.
                                +2
                                На самом же деле, ни тот, ни другой стадию хайпа не перешагнули

                                А, ну раз звучит фраза «на самом же деле», то это действительно так.

                                Доказательства? Кроме гугла конечно и недавних полутора статей на хабре.

                                Kubernetes, Etcd, Racket, Docker, Influxdb, Vault, Consul, Salt, CoreOS, Aerospike и тд. Dropbox вообще весь на Go бегает.
                                  0
                                  Dropbox вообще весь на Go бегает
                                  Не весь, например комментарий от разработчика Dropbox :P
                                    0
                                    В том же комментарии есть две ссылки, объясняющие, что это research и в продакшене не то что не бегает, но еще даже не планируется. Но спасибо за линк )
                                      0
                                      Таки планы протестировать в проде есть, дам еще один линк ;)
                          +4
                          Готов выслушать кроссплатформенные варианты для небольших утилит на 1-5 тыс. строк
                            –2
                            Осторожно предложу NodeJS.
                              +4
                              Несмотря на что то области применения у них регулярно схожи, NodeJS слабая альтернатива для Go (если исключить цену разработки).
                                +4
                                Чем компилить в нативный код? И как по быстродействию относительно С?
                                  0
                                  До недавнего времени и у Go с быстродействием было не лучше. GC в Go: приоритет на скорость и простоту.
                                  К примеру Доклад Антона Поварова «Go в Badoo» на Golang Meetup
                                    0
                                    Быстродействие оценивается на тестах, примерах и критериях.
                                    Смотря какая задача стоит.

                                    >go build source.go
                                    выдаст source.exe

                                    И не забываем, язык НЕ ИНТЕРПРЕТИРУЕМЫЙ! А компилируемый.
                                    Более того, вы можете свой код скомпилить под любую платформу без изменения кода (Windows, Apple iOS, Linux), также ARM.

                                    И, лучше один раз попробовать, чем сто раз послушать. И сами решите все для себя.
                                  +4
                                  Да хоть Lua
                                    +2
                                    Я недавно искал варианты не для веба. Остановился на Python и Go. Питоновские фризеры генерят что-то невероятное под 20мб. У Go скромные 3мб. Единственное, заметил что программы на Go со старта выделяют порядка 75мб виртуальной памяти на процесс под win.
                                    Node как вариант, но там нужно тянуть тот же интерпретатор с кучей node_modules. Си слишком низкоуровневый для таких задач, до Rust я пока не добрался толком, но предполагаю, что он где-то между C и Go. Для джавы jre тянуть. И т.д.
                                    Так что у Go неплохая ниша есть сейчас. Rust держим в уме.
                                      0
                                      Питоновские фризеры вполне можно заставить ужаться, +20 метров к payload'у это как-то чересчур; у меня в свое время с букетом зависимостей, включая PyQt4, выходило немногим более 10 МБ (до сжатия, кажется). Но вообще согласен: деплоить standalone-программы на питоне не очень удобно.

                                      Из интересных альтернатив (не-для-веба) Rust и Go, думаю, еще имеет посмотреть в сторону Haskell и Ocaml: нативные бинарники, небольшой футпринт, оптимизирующая компиляция, есть биндинги к в т.ч. граф. библиотекам (у хаскеля их побольше, но ocaml-lablgtk2 и ocaml-labltk охватывают практически 100% API соответствующих нативных тулкитов, существуют давно, и каких-то особых проблем с ними возникнуть не должно).
                                        0
                                        Есть шанс, что с выходом java 9 не нужно будет тянуть jre.
                                        Судя по этой ссылке http://openjdk.java.net/projects/jigsaw/goals-reqs/03#performance
                                        +1
                                        Java)
                                          0
                                          Из неупомянутого ещё — D.
                                          0
                                          Вы можете продолжать писать дальше на PHP, никто вас не заставляет же на go переходить.

                                          Если бы гугл тратил хотя бы какой-то бюджет на пиар go, то всё было бы намного иначе, я вас уверяю.
                                          Мне не понятно, если честно, откуда столько хейтеров.
                                            +8
                                            Это не хейтеры. Просто подача статей про го — раздражает. Как нам видится хорошая статья про язык программирования — описан определённый класс задач и показано, что эти задачи на ЯП решать просто и удобно. В статьях про го такого обычно нет — просто восторги без привязки к конкретной предметной области.

                                            Какие-то задачи на го решать, наверное, лучше чем на любом другом языке. Вот только какие?
                                              +2
                                              По поводу статей про го — очень много пишут так называемые «success story».
                                              Вот, например, недавняя статья от ScriptRock — там расписаны и плюсы, и минусы го, с которыми ребята столкнулись, когда переходили с node.js. Если вам интересно — посмотрите, статья содержит в том числе критику.

                                              Недавние статьи в хабе: переписали с питона на го Центрифугу, получили + к производительности, Баду написали свой логгер, Вконтакте заюзали го для рассылки пуш-уведомлений для всех мобильных клиентов, тоже, кстати, вместо ноды. Это восторги без привязки к конкретной области?

                                              По поводу задач, которые лучше на го решать — в основном это бекенд сервисы. Можно посмотреть на успешные результаты применения го в разных компаниях (небольшие компании вроде Вконтакте, Яндекса, Баду и Гугла используют го для определенных вещей, можно ориентироваться на них)

                                              Да, на хабре есть спорные статьи-переводы, от которых хейтерам сильно неприятно, но на них можно не обращать внимания.
                                                0
                                                Тут нужно сделать оговорку на счет нагрузки этих самых бекенд сервисов. Если например делается enterprise решение которое будут использовать человек 300, то бекенд можно писать на чем угодно.
                                                  0
                                                  Совершенно с вами согласен. Переход на го — часто одна из мер для преодоления проблем именно с производительностью, насколько можно судить из статей. Но это явно не серебряная пуля или какое-то волшебство, в большинстве случаев бывает проблема и в архитектуре (а не в выбранном ранее языке), и на го система пишется с нуля, учитывая прошлый опыт.
                                                +1
                                                Ну тут Вы несправедливы. divan0 регулярно переводит технические статьи про Go, в том числе с решением реальных задач.
                                                Также вот ВК написал, как неплохо Го справился с рассылкой пушей — http://habrahabr.ru/post/265731/, а Mail.Ru — как они перенесли сервер очередей с Питона на Го — http://habrahabr.ru/company/mailru/blog/266017/
                                              –13
                                              Меня это тоже задолбало… Есть куча языков программирования, тот же Python… Постоянно оно вылазит… какой-то бобер… Что за бред сивой кобылы… Ненавижу Go Видимо сокращение слова Go...no…
                                                –6
                                                Минусующим правда глаза режет…
                                                  0
                                                  Третье сообщение обычно набирает плюсы
                                              +9
                                              В купе с gofmt и таким плагином как, например, GoSublime я теперь не хочу писать на других языках, т.к. они не расставляют отступы за меня и не «красивят» код, не говорят о нелепых опечатках. В качестве примера хочу указать CONTRIBUTING.md одного из проектов:
                                              ...Make sure to use gofmt on your Go code
                                              Да это же круто. Единый формат — это круто!
                                                +8
                                                Ну а благодаря vim-go + syntastic gofmt вызывается сразу при сохранении (никак не забудешь перед коммитом отформатировать) + vim превращается в некое подобие IDE
                                                  +1
                                                  Согласен. А можно на ваш .vimrc взглянуть, пожалуйста?
                                                    +3
                                                    .vimrc
                                                    Вимом пользуюсь только третий день, так что могут быть недостатки. Использую gvim (и конфиг чисто под него), так как urxvt криво шрифты рендерит.
                                                    Плагины
                                                    ctrlp.vim — особенно крут, аналог Ctrl+P из сублайма
                                                    emmet-vim
                                                    nerdcommenter
                                                    nerdtree
                                                    SearchComplete
                                                    supertab
                                                    syntastic
                                                    vim-airline
                                                    vim-fugitive
                                                    vim-go
                                                    vim-surround
                                                      +1
                                                      Спасибо!
                                                        +1
                                                        так как urxvt криво шрифты рендерит

                                                        Попробуйте sakura.

                                                        А к NerdTree советую добавить плагин Xuyuanp/nerdtree-git-plugin.
                                                          0
                                                          Использую urxvt по причине его полной кастоматизации, например, по наличию настройки отступив от рамки, что полезно/красиво в тайловой вм… Sakura хорош, может станет заменой xfce4-terminal, если я перейду на оконные wm, спасибо.
                                                          +1
                                                          Советую еще попробовать vim-git, vim-startify и vim-colorschemes.
                                                            +1
                                                            1) использую vim-fugitive, так как у него хорошая интеграция с другими плагинами, vim-git даже не гуглится
                                                            2) спасибо, хорошая вещь
                                                            3) тут я настроил цветовую палитру под цвеовую палитру терминала, пользоваться чужими схемами пока не буду
                                                      +2
                                                      Помимо Go этим радует C# вкупе с visual studio — там оно все само делается, а одной кнопкой можно весь файл привести к правильному виду.
                                                        +2
                                                        Да-да-да, Visual Basic с бородатых годов так умеет делать, и что?
                                                          0
                                                          Visual Basic 6.0 — вообще зачетная штука была!
                                                        0
                                                        Сам начал писать на Go лишь недавно (пищу первый среднего размера проект), но вот про уровни абстракций уже не соглашусь. Уже для того, чтобы делать сортировку слайса с объектами типа A нужно создать тип слайса (чем не абстракция), потом написать по 3 функции для этого типа (тут более менее понятно, все таки это может быть не только слайс, но можно же сделать отдельную функцию для массива-подобных, где передается функция сравнения в аргументе).

                                                        Собственно, вот код: gist.github.com/the-varlog/9a289d9affb92e96a0c2. Скорее всего есть нормальное решение, о котором я не знал.
                                                          +2
                                                          Попробуйте вот это для сортировки: http://godoc.org/github.com/bradfitz/slice
                                                            +1
                                                            Спасибо. Код стал чище. Почему-то после ruby/node.js/py осталась привычка не подключать лишние пакеты ради одной-двух функций. Тут же, благодаря компиляции, можно ставить любые пакеты в любом количестве.
                                                            0
                                                            А PostGIS не проще прикрутить?

                                                              0
                                                              Там mongodb
                                                                0
                                                                Я заметил. Но это только повод задуматься, зачем она там.
                                                            +8
                                                            Стоит отметить, что это достаточно вольный перевод, с некоторыми добавлениями и стилистикой, которых нет в оригинальном посте.

                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                            Самое читаемое