14.09.2015 15:31
namespace 73 20077 Источник
Если что, это вольный перевод статьи из блога 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)


  1. Jodes
    14.09.2015 19:52
    #8572083
    -10

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

    Как только создатели и адепты Go не пытаются протолкнуть свой, мало кому нужный велосипед. Тут тебе и ежедневные посты на хабре, и загаженная RSS-лента, и вот такие «заказные» призывы любви, в остальных Интернетах, которые к тому же еще и переводят…


    1. poxu
      14.09.2015 20:00
      #8572099
      +7

      Вы хотите сказать, что большое количество постов про Go не демонстрирует, что он нужен и полезен большому количеству людей? И когда вы назвали призывы любви заказными, вы имели в виду, что за их написание кто-то кому-то заплатил?


      1. Jodes
        14.09.2015 20:27
        #8572151
        +21

        ИМХО, большое кол-тво постов про Go есть назойливая реклама помноженная на восторг неофита.


        1. deep_orange
          14.09.2015 22:28
          #8572325

          В заголовке статьи написано, о чём она. Я и не думал, что в ней будет технически полезная информация. В результате чего у Вас сложилось такое впечатление?


        1. poxu
          14.09.2015 22:43
          #8572347
          -1

          Вы считаете, что за эту реламу кто-то кому-то платит?


        1. e_asphyx
          30.09.2015 11:14
          #8596093

          Как будто восторг — это что-то плохое. Мне после C++ с «переунаследуем вот это от этого» Go с его интерфейсами показался глотком свежего воздуха.


      1. MercurieVV
        14.09.2015 20:34
        #8572159
        +5

        Осторожно соглашусь. Уж больно часто последние пол года вижу восторженные статьи о Го на Хабре. Видать все остальные ЯП — полная чепуха.


        1. esc
          14.09.2015 21:54
          #8572269
          +17

          Во многом это связанно с эмоциями, которые вызывает язык у тех, кто его пробует и остается доволен. Про Руби в свое время тоже много писали.

          Go дает новые ощущения при разработке. Можно просто сделать некоторые вещи, которые раньше казались сложными. И у него хорошая читаемость кода. Логично, что у тех кто его попробовал и кто любит писать статьи, частенько возникает желание эти ощущения выразить.


          1. creker
            14.09.2015 22:08
            #8572295
            +5

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

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


            1. divan0
              14.09.2015 22:28
              #8572323
              +2

              Он читает не лучше и не хуже, чем любой другой язык программирования,

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

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

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


              1. creker
                14.09.2015 22:38
                #8572335
                +1

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

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

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

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


                1. divan0
                  14.09.2015 22:55
                  #8572363
                  +6

                  «Python передо мной предстает как каша… а С++ легко читается».

                  Окей )

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

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


                  1. vintage
                    15.09.2015 20:38
                    #8574131
                    +1

                    А уже общепризнано как эту характеристику измерять? :-)


                    1. divan0
                      15.09.2015 20:40
                      #8574137

                      Да, в WTF/минуту измеряется :)

                      Вот, к примеру: engineering.intenthq.com/2015/03/what-is-good-code-a-scientific-definition


                  1. creker
                    15.09.2015 21:21
                    #8574219

                    Читабельность кода — это общепризнанно важнейшая характеристика хорошего кода

                    Вот именно. Это характеристика кода, но не языка.


                1. burjui
                  15.09.2015 16:11
                  #8573593
                  +3

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

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

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

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


                  1. divan0
                    15.09.2015 20:00
                    #8574061

                    Судя по результату, ваш basicBullshitFilter() работает по принципу «не пробовал, но осуждаю» :)


                    1. vintage
                      15.09.2015 20:40
                      #8574135

                      А вы всё пробуете, что плохо пахнет (ну мало ли, вкусняшка)? :-)


                      1. divan0
                        15.09.2015 20:44
                        #8574147

                        Нет, только то, что хорошо )


            1. deep_orange
              14.09.2015 22:41
              #8572343
              +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; // что, чёрт возьми???


              1. kulinich
                15.09.2015 01:19
                #8572505
                +2

                Народ, либо полегче, либо… что происходит в этом коде?


                1. QtRoS
                  15.09.2015 23:38
                  #8574481

                  UB, думается.


            1. esc
              15.09.2015 09:59
              #8572689
              +3

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

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

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

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

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


          1. mukizu
            15.09.2015 13:41
            #8573169

            >Можно просто сделать некоторые вещи, которые раньше казались сложными.

            Было бы здорово вот об этом и услышать. А то я пока что не прочитаю — не могу взять в толк, зачем мне использовать Go, хотя бы в теории, если все тоже самое можно и на Python сделать (с еще большим удовольствием, мне субъективно не нравится синтаксис гошный. После python и ruby на него банально смотреть больно)


            1. esc
              15.09.2015 19:20
              #8574007
              +4

              Go несравнимо быстрее Питона. Я вот делаю специфический реверсивный прокси на Go. Пустое проксирование у меня получилось строчек в 10 и по простеньким тестам (ab) оказалось всего в 1.5 раза медленнее nginx. В 2 раза быстрее node.js, во много раз быстрее Питона и php (про память я молчу).

              Всякие системы сбора статистики, отдачи баннеров и прочее, что раньше писали на Си ради производительности, сейчас можно делать на Го гораздо быстрее и удобнее. Да в прочем и для обычного веба он подходит неплохо, не уверен правда в наличии фреймворков для серьезно больших сайтов.


        1. denis_g
          14.09.2015 21:56
          #8572271
          +6

          Да ладно… А мне вот, например, мозолят глаза статьи про Rust или, Столлман упаси, C#, или вообще, да простят меня Керниган и Ричи, PHP. Но это не делает их плохими языками для своего сегмента. Это означает только то, что мне они не нравятся. И больше ничего. Аналогии выстраивайте сами.


      1. creker
        14.09.2015 22:02
        #8572285
        +2

        Это больше похоже на очередную молодую технологию, которая переживает короткий этап своего развития, когда все прекрасно, все старые проблемы решены, новых проблем нет, все работает. Тот же docker постепенно выходит из этой стадии и открывает людям горькую правду, что с решением старых проблем появляется вагон новых специфичных для него. Go пока видится в этой стадии и ворох одинаковых по содержанию восторженных статей тому явный показатель. Я сам поддался и побаловался, но вообще не понял фишки языка — он странный во всех своих проявлениях, его go-рутины вообще обыденность какая-то особенно после async-await штук, но они почему-то преподносятся как решение всех бед многопоточности. Хотя это банальная job-система с простенькими примитивами синхронизации. А за пределами этого есть вроде бы богатый framework и все. Я лично не верю, что этот язык ждет какое-то невероятное будущее.


        1. divan0
          15.09.2015 20:12
          #8574083

          Это вы попытались описать своими словами Hype Cycle и наложили свои представления на него, подав как вывод. На самом деле на Go не просто так пишут почти весь современный софт для кластеров и всего вокруг, и все кто строит бизнес на Go уже прекрасно знают, чего ожидать, что язык может, что не может — так что по hype cycle Go уже давно вышел на «плато продуктивности». Если вам еще интересно мнение специалистов, мониторящих технологии, то посмотрите на TechRadar от ThoughtWorks, согласны ли они с вашей оценкой.

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

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


          1. creker
            15.09.2015 21:19
            #8574215

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

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

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

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

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


            1. divan0
              15.09.2015 21:40
              #8574271
              +2

              На самом же деле, ни тот, ни другой стадию хайпа не перешагнули

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

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

              Kubernetes, Etcd, Racket, Docker, Influxdb, Vault, Consul, Salt, CoreOS, Aerospike и тд. Dropbox вообще весь на Go бегает.


              1. Semmaz
                16.09.2015 17:24
                #8575695

                Dropbox вообще весь на Go бегает
                Не весь, например комментарий от разработчика Dropbox :P


                1. divan0
                  16.09.2015 17:28
                  #8575705

                  В том же комментарии есть две ссылки, объясняющие, что это research и в продакшене не то что не бегает, но еще даже не планируется. Но спасибо за линк )


                  1. Semmaz
                    16.09.2015 17:38
                    #8575725

                    Таки планы протестировать в проде есть, дам еще один линк ;)


    1. shoomyst
      14.09.2015 20:47
      #8572175
      +4

      Готов выслушать кроссплатформенные варианты для небольших утилит на 1-5 тыс. строк


      1. NickKolok
        14.09.2015 21:16
        #8572205
        -2

        Осторожно предложу NodeJS.


        1. IncorrecTSW
          14.09.2015 21:32
          #8572235
          +4

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


        1. shoomyst
          14.09.2015 21:48
          #8572259
          +4

          Чем компилить в нативный код? И как по быстродействию относительно С?


          1. RPG18
            15.09.2015 00:42
            #8572471

            До недавнего времени и у Go с быстродействием было не лучше. GC в Go: приоритет на скорость и простоту.
            К примеру Доклад Антона Поварова «Go в Badoo» на Golang Meetup


          1. edeldm
            15.09.2015 14:13
            #8573237

            Быстродействие оценивается на тестах, примерах и критериях.
            Смотря какая задача стоит.

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

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

            И, лучше один раз попробовать, чем сто раз послушать. И сами решите все для себя.


      1. evocatus
        14.09.2015 21:53
        #8572265
        +4

        Да хоть Lua


      1. shoomyst
        14.09.2015 22:16
        #8572313
        +2

        Я недавно искал варианты не для веба. Остановился на Python и Go. Питоновские фризеры генерят что-то невероятное под 20мб. У Go скромные 3мб. Единственное, заметил что программы на Go со старта выделяют порядка 75мб виртуальной памяти на процесс под win.
        Node как вариант, но там нужно тянуть тот же интерпретатор с кучей node_modules. Си слишком низкоуровневый для таких задач, до Rust я пока не добрался толком, но предполагаю, что он где-то между C и Go. Для джавы jre тянуть. И т.д.
        Так что у Go неплохая ниша есть сейчас. Rust держим в уме.


        1. danfe
          15.09.2015 08:22
          #8572603

          Питоновские фризеры вполне можно заставить ужаться, +20 метров к payload'у это как-то чересчур; у меня в свое время с букетом зависимостей, включая PyQt4, выходило немногим более 10 МБ (до сжатия, кажется). Но вообще согласен: деплоить standalone-программы на питоне не очень удобно.

          Из интересных альтернатив (не-для-веба) Rust и Go, думаю, еще имеет посмотреть в сторону Haskell и Ocaml: нативные бинарники, небольшой футпринт, оптимизирующая компиляция, есть биндинги к в т.ч. граф. библиотекам (у хаскеля их побольше, но ocaml-lablgtk2 и ocaml-labltk охватывают практически 100% API соответствующих нативных тулкитов, существуют давно, и каких-то особых проблем с ними возникнуть не должно).


        1. gurinderu
          15.09.2015 14:05
          #8573219

          Есть шанс, что с выходом java 9 не нужно будет тянуть jre.
          Судя по этой ссылке http://openjdk.java.net/projects/jigsaw/goals-reqs/03#performance


      1. gurinderu
        15.09.2015 10:10
        #8572707
        +1

        Java)


      1. vintage
        15.09.2015 20:51
        #8574163

        Из неупомянутого ещё — D.


    1. cy-ernado
      14.09.2015 22:39
      #8572339

      Вы можете продолжать писать дальше на PHP, никто вас не заставляет же на go переходить.

      Если бы гугл тратил хотя бы какой-то бюджет на пиар go, то всё было бы намного иначе, я вас уверяю.
      Мне не понятно, если честно, откуда столько хейтеров.


      1. ServPonomarev
        15.09.2015 08:16
        #8572599
        +8

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

        Какие-то задачи на го решать, наверное, лучше чем на любом другом языке. Вот только какие?


        1. cy-ernado
          15.09.2015 14:31
          #8573277
          +2

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

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

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

          Да, на хабре есть спорные статьи-переводы, от которых хейтерам сильно неприятно, но на них можно не обращать внимания.


          1. RPG18
            15.09.2015 14:57
            #8573363

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


            1. cy-ernado
              15.09.2015 15:12
              #8573395

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


        1. LionAlex
          15.09.2015 17:19
          #8573743
          +1

          Ну тут Вы несправедливы. divan0 регулярно переводит технические статьи про Go, в том числе с решением реальных задач.
          Также вот ВК написал, как неплохо Го справился с рассылкой пушей — http://habrahabr.ru/post/265731/, а Mail.Ru — как они перенесли сервер очередей с Питона на Го — http://habrahabr.ru/company/mailru/blog/266017/


    1. horlon
      15.09.2015 08:35
      #8572619
      -13

      Меня это тоже задолбало… Есть куча языков программирования, тот же Python… Постоянно оно вылазит… какой-то бобер… Что за бред сивой кобылы… Ненавижу Go Видимо сокращение слова Go...no…


      1. horlon
        15.09.2015 21:34
        #8574257
        -6

        Минусующим правда глаза режет…


        1. ingrysty
          15.09.2015 23:15
          #8574449

          Третье сообщение обычно набирает плюсы


  1. deep_orange
    14.09.2015 19:57
    #8572091
    +9

    В купе с gofmt и таким плагином как, например, GoSublime я теперь не хочу писать на других языках, т.к. они не расставляют отступы за меня и не «красивят» код, не говорят о нелепых опечатках. В качестве примера хочу указать CONTRIBUTING.md одного из проектов:

    ...Make sure to use gofmt on your Go code
    Да это же круто. Единый формат — это круто!


    1. var-log
      14.09.2015 21:00
      #8572185
      +8

      Ну а благодаря vim-go + syntastic gofmt вызывается сразу при сохранении (никак не забудешь перед коммитом отформатировать) + vim превращается в некое подобие IDE


      1. denis_g
        14.09.2015 21:57
        #8572277
        +1

        Согласен. А можно на ваш .vimrc взглянуть, пожалуйста?


        1. var-log
          14.09.2015 22:39
          #8572337
          +3

          .vimrc
          Вимом пользуюсь только третий день, так что могут быть недостатки. Использую gvim (и конфиг чисто под него), так как urxvt криво шрифты рендерит.

          Плагины
          ctrlp.vim — особенно крут, аналог Ctrl+P из сублайма
          emmet-vim
          nerdcommenter
          nerdtree
          SearchComplete
          supertab
          syntastic
          vim-airline
          vim-fugitive
          vim-go
          vim-surround


          1. denis_g
            14.09.2015 22:43
            #8572351
            +1

            Спасибо!


          1. lain8dono
            15.09.2015 15:22
            #8573423
            +1

            так как urxvt криво шрифты рендерит

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

            А к NerdTree советую добавить плагин Xuyuanp/nerdtree-git-plugin.


            1. var-log
              15.09.2015 19:12
              #8573987

              Использую urxvt по причине его полной кастоматизации, например, по наличию настройки отступив от рамки, что полезно/красиво в тайловой вм… Sakura хорош, может станет заменой xfce4-terminal, если я перейду на оконные wm, спасибо.


          1. Leshrac
            15.09.2015 17:15
            #8573739
            +1

            Советую еще попробовать vim-git, vim-startify и vim-colorschemes.


            1. var-log
              15.09.2015 19:08
              #8573985
              +1

              1) использую vim-fugitive, так как у него хорошая интеграция с другими плагинами, vim-git даже не гуглится
              2) спасибо, хорошая вещь
              3) тут я настроил цветовую палитру под цвеовую палитру терминала, пользоваться чужими схемами пока не буду


    1. creker
      14.09.2015 21:51
      #8572263
      +2

      Помимо Go этим радует C# вкупе с visual studio — там оно все само делается, а одной кнопкой можно весь файл привести к правильному виду.


    1. toxicdream
      15.09.2015 06:28
      #8572561
      +2

      Да-да-да, Visual Basic с бородатых годов так умеет делать, и что?


      1. denis_g
        16.09.2015 11:51
        #8575069

        Visual Basic 6.0 — вообще зачетная штука была!


  1. var-log
    14.09.2015 19:59
    #8572097

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

    Собственно, вот код: gist.github.com/the-varlog/9a289d9affb92e96a0c2. Скорее всего есть нормальное решение, о котором я не знал.


    1. david_mz
      15.09.2015 00:38
      #8572465
      +2

      Попробуйте вот это для сортировки: http://godoc.org/github.com/bradfitz/slice


      1. var-log
        15.09.2015 00:52
        #8572483
        +1

        Спасибо. Код стал чище. Почему-то после ruby/node.js/py осталась привычка не подключать лишние пакеты ради одной-двух функций. Тут же, благодаря компиляции, можно ставить любые пакеты в любом количестве.


    1. nwalker
      15.09.2015 00:43
      #8572473

      А PostGIS не проще прикрутить?


      1. var-log
        15.09.2015 01:28
        #8572513

        Там mongodb


        1. nwalker
          15.09.2015 02:16
          #8572525

          Я заметил. Но это только повод задуматься, зачем она там.


  1. divan0
    14.09.2015 20:15
    #8572133
    +8

    Стоит отметить, что это достаточно вольный перевод, с некоторыми добавлениями и стилистикой, которых нет в оригинальном посте.