18 апреля в 16:31

Почему вам стоит изучить Go? из песочницы

Go*
Всем привет! Представляю вашему вниманию мой перевод статьи (включая графики) Кевала Патела Why should you learn Go? Статья содержит много интересных фактов, которые, по моему мнению, будет полезно узнать новичкам в Go.

P.S.: Статья, как и большинство статей, на мой взгляд, отражает опыт и мнение автора, которое может не совпадать с вашим, и это нормально — сколько людей, столько и мнений.
Gophers

Изображение взято с ресурса kirael-art.deviantart.com/art/Go-lang-Mascot-458285682

“Go станет серверным языком будущего.” — Tobias Lütke, Shopify

За последние пару лет произошёл мощный рост нового языка программирования: Go, или Golang. Согласитесь, ничто так не может свести с ума разработчика, как новый язык программирования. Поэтому, я начал изучать Go 4-5 месяцев назад и вот что я могу сказать о том, почему вам стоит изучить этот новый язык.

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

Ограничения железа:


Закон Мура не работает.

Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц. Таким образом, около десятилетия нет особого прогресса чистой вычислительной мощности. Ниже на графике, вы можете увидеть сравнительный график роста вычислительной мощности по времени.

Сравнительный график роста вычислительной мощности по времени

По графику можно понять, что однопоточная производительность и частота процессора оставалась стабильной почти десятилетие. Если вы думаете, что добавить больше транзисторов — это хорошее решение, то вы ошибаетесь. Так происходит потому, что в более меньших масштабах начинают проявляться квантовые свойства объекта (такие как туннелирование, [или туннельный эффект. — прим.перев.]), а добавление большего количества транзисторов действительно может привести к дополнительным расходам (почему?) и количество транзисторов, которые вы можете добавить за один доллар стремительно начинает падать.

Поэтому, для решения проблемы выше,

  • Производители начали добавлять больше ядер в процессор. На текущий день нам доступно 4-х и 8-ми ядерные процессоры.
  • Также положено начало гиперпоточности.
  • Добавили больше кэша в процессор для увеличения производительности.

Но решения выше также имеют свои ограничения. Мы не можем добавить больше кэша в процессор, поскольку кэш имеет физические ограничения: чем больше кэш, тем медленнее он становится. Добавление большего количества ядер в процессор тоже имеет свою цену. К тому же, это невозможно делать до бесконечности. Все эти многоядерные процессоры могут запускать множество потоков одновременно и это придаёт нашей картине многозадачность. Мы поговорим об этом позже.

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

“Современные процессоры похожи на забавные автомобили, заправленные нитро, — они превосходны в гонке на четверть мили. К сожалению, современные языки программирования, как трасса Монте-Карло — полны изгибов и поворотов.”  —  David Ungar

В Go есть горутины !!


Как говорилось ранее, производители аппаратного оборудования добавляют всё больше ядер в процессор, чтобы увеличить его производительность. Все дата-центры запускаются на этих процессорах и нам стоит ожидать увеличения количества ядер в ближайшие годы. Более того, современные приложения используют множество микросервисов для поддержки соединений с базой данных, очередей сообщений и кэширования. Таким образом, разрабатываемые нами программное обеспечение и языки программирования должны легко поддерживать многозадачность (concurrency. — прим. перев.) и они должны быть масштабируемыми при увеличении количества ядер.

Но большинство современных языков программирования (такие, как Java, Python) пришли из однопоточной среды разработки 90-х. Хотя большинство этих языков поддерживают многопоточность, но реальная проблема связана с одновременным выполнением, блокированием потока, состоянием гонки и тупиковой ситуацией. Эти вещи осложняют создание многопоточного приложения на вышеназванных языках.

Например, создание нового потока в Java неэффективно использует память. Поскольку каждый поток потребляет примерно 1МБ памяти из кучи (динамически распределяемой памяти. — прим. перев.) и в итоге, если вы запустите тысячи потоков, то они окажут колоссальное давление на память и могут вызвать завершение работы приложения из-за её нехватки. К тому же, если вы хотите, чтобы два или более потока могли общаться между собой, то сделать это будет довольно трудно.

С другой стороны, Go был выпущен в 2009 году, когда многоядерные процессоры были уже доступны. Вот почему Go был создан с учётом многозадачности (concurrency. — прим. перев.). Go использует горутины вместо потоков. Они потребляют почти 2КБ памяти из кучи. Поэтому, вы можете прокручивать хоть миллионы горутин в любое время.

Как работают горутины?

Как работают горутины? Подробнее: golangtutorials.blogspot.in/2011/06/goroutines.html

Другие преимущества:

  • Горутины имеют расширяемые сегментированные стеки. Это означает, что они будут использовать память только по необходимости.
  • Горутины имеют более быстрое время запуска, чем потоки.
  • Горутины поставляются со встроенными примитивами для безопасного обмена данными между собой (каналы).
  • Горутины позволяют избежать необходимости прибегать к блокированию мьютексов при совместном использовании структур данных.
  • Также, горутины и потоки ОС не имеют сопоставления 1:1. Одна горутина может запускаться во множестве потоков. Горутины объединены (multiplexed. — прим.перев.) в малое количество потоков ОС.

Вы можете посмотреть отличное выступление Роба Пайка Многозадачность — это не параллелизм, чтобы более глубоко разобраться в этой теме.

Все вышеупомянутые пункты делают Go очень мощным для обработки многозадачности так же, как в Java, С и С++, и в то же время сохраняя красоту и естественность кода, как в Erlang.

График многозадачности против эффективности
Go вобрал в себя лучшее из обоих миров. Одновременно лёгкий в написании и эффективный в управлении многозадачностью

Go запускается непосредственно на железе.


Одно из самых значимых преимуществ использования С/С++ вместо современных языков, типа Java/Python, это их производительность. Потому что С/С++ компилируются, а не интерпретируются.

Процессоры понимают только двоичный код. Как правило, когда вы пишете приложение на Java или других, основанных на JVM, языках, то при компиляции вашего проекта, он компилируется с человекопонятного кода в байт-код, который понятен для JVM или другой виртуальной машине, которая запускается поверх ОС. При выполнении, VM интерпретирует этот байт-код и конвертирует его в двоичный код, понятный процессору.

Этапы выполнения кода, основанных на JVM
Этапы выполнения кода, основанных на JVM

С другой стороны находятся С/С++, которые не используют виртуальные машины, и это позволяет убрать один этап из схемы выше, повысив при этом производительность. Происходит прямая компиляция человекопонятного кода в двоичный.

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

Go вобрал лучшее из обоих миров. Как и низкоуровневые языки, типа С/С++, Go компилируемый язык. Это подразумевает производительность, близкую к низкоуровневым языкам. Он также имеет свой сборщик мусора для распределения и удаления объектов. Больше malloc() и free()! Круто!

Код, написанный на Go, легко поддерживать.


Позвольте мне сказать вам одну вещь. У Go нет такого безумного синтаксиса, как в других языках, — всё очень аккуратно и чисто.

Разработчики Go в Google имели это ввиду, когда создавали его. Ввиду того, что у Google огромная кодовая база и над ней трудятся тысячи разработчиков, то код должен быть простым для понимания остальными разработчиками, и один участок кода должен иметь минимум побочных эффектов на другие участки. Это делает код более простым для поддержки и внесения изменений.

Go намеренно не содержит множество особенностей ООП языков.

  • Нет классов. Каждая вещь делится только на пакеты. Вместо классов Go использует только структуры (structs. — прим.перев.).
  • Не поддерживает наследование. Это упрощает модифицирование кода. В других языках, типа Java/Python, если класс ABC наследует класс XYZ, и вы при этом делаете какие-то изменения в классе XYZ, то это производит дополнительное изменения во всех наследованных от него классах. К тому же, без наследования, код Go становится более простым для понимания (так как нет super классов, на которые нужно обращать внимание при изучении участков кода).
  • Нет конструкторов.
  • Нет аннотаций.
  • Нет дженериков (универсальных шаблонов. — прим.перев.).
  • Нет исключений.

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

График читабельности кода против его производительности
Читабельность кода против его производительности.

График выше показывает, что Go почти так же эффективен как С/С++, и имеет такой же простой синтаксис, как Ruby, Python и другие языки. Это беспроигрышный вариант (win-win. — прим.перев.) как для людей, так и для компьютера!

Синтаксис Go очень стабилен, чего не скажешь о другом новом языке Swift. Синтаксис не изменился с момента его публичного релизе версии 1.0 в 2012 году. Это наделяет его обратной совместимостью.

Go поддерживается Google.


  • Я знаю, что это не совсем техническое преимущество. Но Go разработан и поддерживается Google. У Google самая большая облачная инфраструктура в мире и она всё ещё расширяется. Google создала Go для решения их собственных проблем с поддержкой масштабируемости и эффективности. С этими же проблемами вам придётся столкнуться и при создании своего собственного сервера.
  • Более того, Go используется такими компаниями, как Abode, BBC, IBM, Intel и даже Medium. (Источник: github.com/golang/go/wiki/GoUsers)

Заключение:


  • Хотя Go отличен от других ООП языков, это всё тот же зверь. Go предоставляет вам такую же высокую производительность, как в С/C++, высокоэффективную обработку многозадачности, как в Java и такое же удобство написания кода, как в Python/Perl.
  • Если вы не планируете изучать Go, то я всё же скажу, что лимит аппаратного обеспечения оказывает давление на нас, разработчиков ПО, которые хотят писать очень эффективный код. Разработчику нужно понять железо и соответственно оптимизировать свою программу. Оптимизированное ПО можно запустить на дешёвом и медленном устройстве (типа IOT), что в целом лучше влияет на опыт взаимодействия конечного пользователя (UX. — прим.перев.).
Arthur @KarafiziArthur
карма
7,0
рейтинг 16,8
Frontend learner
Самое читаемое Разработка

Комментарии (324)

  • +22
    1) «you should» != «вы должны»
    2) беглое прочтение статьи показывает что из всего перечисленного для Go уникальным является только «Go поддерживается Google.», это (без иронии) мощный агрумент.
    • +4
      Загляните на кладбище проектов Google.
      • 0
        ну пока язык не на кладбище — поддержка гугла ему только в помощь. а что будет дальше — жизнь покажет.
        • +5
          Dart тоже поддерживается Google
          • –2
            Извините, но вы сейчас привели глупое сравнение. У всех людей могут быть идеи как благоприятно восприняты обществом, так и нет. И к слову Dart мог быть очень популярным языком, если бы не одна история во время его разработки.
            • +6
              если бы не одна история во время его разработки.

              За языком не следил, но любопытно. Можно в двух словах?

              • +2
                Присоединюсь, тоже любопытно.
              • +1
                Самому стало интересно, нашел только https://arc.applause.com/2015/03/27/google-dart-virtual-machine-chrome/
                Как я понял, гугл не захотел добавлять виртуальную машину для Dart в хром
              • +2
                image
              • 0
                По поводу Dart, Андрей Листочкин думаю расскажет лучше меня.
            • +2
              можно ссылку на историю для тех, кто не в курсе, но интересуется?
            • +2
              Извините, но вы сейчас привели глупое сравнение

              Почему глупое? Я просто акцентировал на том, что факт поддержки Гуглом ничего не означает
              • –1
                Ну почему ничего не означает, всё субъективно и нельзя одно футболку одеть на всех. К примеру либы в dart поддерживаются гуглом, и это преимущество перед опен-сорсом npm. Потому что это означает стабильность и ясность направления библиотеки в отличии от npm. Согласитесь что такая компания как гугл не будет прекращать разработку чего-то вот так вот просто без слов, потому что «не хочется» или «нет настроения».
                • +4

                  Зато может потому что "не окупается" или "нет коммерческой перспективы".

  • +36
    Изображение «Красота и естественность кода» мне кажется очень холиварная.
    Тоже самое могу сказать и про изображение «Эффективность и производительность для компьютера»
    • +8
      Да там вообще всё отвратительно.

      Настолько, что даже читать не стал вообще.
  • +43
    Go запускается непосредственно на железе

    Rust тоже.


    Код, написанный на Go, легко поддерживать.

    Сложно назвать легко поддерживаемым код на языке, в котором можно случайно забыть написать «if err != nil». Rust за это надаёт по ушам ещё при компиляции, да даже C++ выкинет исключение во время работы.


    Классов в Rust нет, наследования нет, конструкторов нет, исключений тоже нет (про остальное точно не помню)


    Go почти так же эффективен как С/С++

    Rust тоже


    Синтаксис Go очень стабилен

    Подозреваю, синтаксис Rust ещё более стабилен)


    Go поддерживается Google

    Rust поддерживается Mozilla и целым сообществом и используется много кем


    Горутины, думаю, можно заменить на Futures и в будущем async/await.


    А ещё у Rust zero-cost abstractions и отсутствие gc.


    И почему же мы должны учить Go, а не Rust? :)


    (на правах вброса:)

    • –8
      Сложно назвать легко поддерживаемым код на языке, в котором можно случайно забыть написать «if err != nil».

      Ну, вроде как, Go все же возмутится за неиспользование переменной err на уровне сборки.


      И почему же мы должны учить Go, а не Rust? :)

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

      • +17
        Вот интересная ситуация. Низкий порог вхождения в php записывают ему в минусы и постоянно тычут этим. А у go это уже плюс. Двойные стандарты.
        • 0

          Лично я не записывал и не тыкал, просто выразил мнение. Но Растариане не дремлют :)

          • +4

            Мне б кто-то объяснил за что минусы ставят, может я бы и переосмыслил точку зрения? Не могу понять в чем я не прав.

          • +3
            Я это не лично вам писал. Просто часто сталкиваюсь с этим доводом в обоих его представлениях. И вот стало интересно отношение аудитории к этому.
        • 0
          Скорее порог вхождения не должен являться аргументом при рассмотрении самого языка. Например, высокий порог вхождения в Haskell совсем не делает его хуже в своем классе задач.

          Логика мне видится примерно такой: низкий порог вхождения ведет к росту комьюнити вокруг языка, широкое комьюнити оправдывает использование языка в коммерческих проектах, удачные примеры проектов — потенциальные инвестиции в развитие самого языка и его экосистемы, что опять приведет к росту количества практикующих на этом языке разрабов.
      • +1
        > возмутится за неиспользование переменной err на уровне сборки.

        Если она была присвоена — да, а если нет — то нет.

        foo()


        Если функция `foo` возвращает значение типа `error`, то этот код вполне себе скомпилируется. Правда, для обнаружения таких проблем есть линтер: https://github.com/kisielk/errcheck
    • –4
      Все эти неоспоримые плюсы перекрывает сложность написания и сложность чтения когда на Rust. Увы, но в таком виде он не пойдет в массы, ибо Rust не для средних умов, а таких большинство.
      • +9

        А это ещё целая тема для срача, минус ли «не для средних умов» или таки плюс :D


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

      • +8

        Знаете, я вот совсем недавно интересовался, для каких языков есть клиентские библиотеки к docker. Среди тех, что мне были интересны, были и Go и Rust.


        Де факто мой практический опыт для обоих языков почти одинаков и невелик. Так вот, для меня не было никакой сложности в том, чтобы читать код на обоих. И Rust ничем тут не сложнее. Я больше скажу — думаю что для тех, кто видел java generics (или другие языки с параметризованными типами данных, скалу скажем или хаскель), или алгебраические типы, знает хоть один язык из функциональных — читать Rust значительно проще.


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

        • 0
          Ещё бы, докер то написан на Го.
          • +4

            Вы уверены, что поняли мой коммент? Клиент к докеру, написанный на Rust, не сложнее (а на мой личный вкус — проще), чем клиент к докеру, написанный на Go. То что Rust хуже
            сложнее читается — в значительной степени миф. Объемы кода сопоставимые.


            Так понятнее?

    • +13
      Go запускается непосредственно на железе
      Rust тоже.

      И на голом железе без особой потери функциональности. В отличии от Go, в котором есть сборка мусора.


      if err != nil

      По крайней мере выдаст варнинг, если не поставить затычку.


      А ещё там можно вызвать функцию от nil. И даже нормально обрабатывать это. Где-то в недрах stdlib даже используется.


      конструкторов нет

      Есть же. Но не как часть синтаксиса, а как часть хороших практик.


      type Thing struct { a int }
      
      func NewThing() Thing { return Thing { 10 } }

      struct Thing { a: isize }
      
      impl Thing {
        fn new() Self { Self { a: 10 } }
      }

      При этом в rust ещё и трейт Default есть.


      исключений тоже нет

      Но раскрутка стека есть. В golang перехватываемая при помощи recover. В rust убивает весь поток выполнения, но из родительского потока перехватывается. При этом в последнем есть оптимизации на этот счёт.


      Go почти так же эффективен как С/С++
      Rust тоже

      Rust на текущий момент лишь чуть медленнее оных (примерно на разницу между llvm и gcc/msvc и компанией).
      Go не особо быстр в сравнении с фаворитами, но намного быстрее скриптовых ЯП. Он больше про экономию памяти при общем удобстве, чем про чистую скорость в отличии от.


      Кстати. И у того и другого есть костыли для полуавтоматического транслирования с няшной сишечки. Иногда даже получается.


      Подозреваю, синтаксис Rust ещё более стабилен)

      Не на столько стабилен. Но обратная совместимость поддерживается в пределах мажорной версии. Кроме того есть достаточно годная система ввода новых возможностей в язык.


      Rust поддерживается Mozilla и целым сообществом

      С корпорацией добра и зла не сравнить, да.


      Горутины, думаю, можно заменить на Futures и в будущем async/await.

      Пф. Уже есть https://github.com/dpc/mioco А каналы в stdlib присутствуют.


      А ещё у Rust zero-cost abstractions и отсутствие gc.

      И приятная боль от borrow-checker'а.


      И почему же мы должны учить Go, а не Rust?

      Сначала golang, потом rust. :3

      • 0
        Спасибо за конструктивные дополнения!
      • +3
        Но раскрутка стека есть. В golang перехватываемая при помощи recover. В rust убивает весь поток выполнения, но из родительского потока перехватывается. При этом в последнем есть оптимизации на этот счёт.

        Начиная с 1.9.0 не верно, можно изолировать панику не на уровне нативного потока, см. https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

        • +1

          И еще всю раскрутку очень легко можно отключить через panic='abort', так что в общем случае в библиотеке на нее полагаться тем более не стоит.

          • 0

            Полагаться, ессно, не стоит. Для меня catch_unwind актуален, чтобы не произошла раскрутка через ffi'ную границу (сишный код дёргает callback моей библиотеки, которая дёргает пользовательский callback).

        • 0
          Основная проблема rust — посты про него устаревают ещё до их написания. Однако и это плюс. Ибо живой язык, не слишком обременённый обратной совместимостью.
          • +4
            С версии 1.0 добавляются / стабилизируются новые фичи, ничего не меняется и не удаляется, так что 99%, что писалось под 1.0, должно собираться до сих пор.
            • 0

              В смысле тонной легаси конечно. Не совсем правильно выразился.

    • 0
      Rust слишком многословен. Синтаксис Go действительно проще, порог входа ниже, и начать программировать на нем можно очень быстро. Когда я последний раз ковырял Rust, они постоянно что-то меняли, ломали совместимость и т.д. Не знаю, как с этим счас, это было давно. Плюс Go действительно заточен для написания приложений, работающих с сетью / микросервисов. Все, что нужно в нем есть из коробки. В прочем, в Go тоже есть куча своих проблем.
      • +5
        Когда я последний раз ковырял Rust, они постоянно что-то меняли, ломали совместимость и т.д. Не знаю, как с этим счас, это было давно.

        https://blog.rust-lang.org/2015/05/15/Rust-1.0.html — 1.0 давно уже вышел, с того времени строгая обратная совместимость поддерживается.

    • +1
      Осталось понять, зачем нужен Rust, когда уже есть С++ и огромное количество совместимых с ним библиотек :)
      Отсутствие ООП — странное преимущество, очень странное.
      • +4

        C++ позволяет выстрелить в ногу, если случайно забыть про меры предосторожности. Rust позволяет выстрелить в ногу, только если явно воткнуть в код стопицот предупреждений «да, я в здравом уме и твёрдой памяти хочу выстрелить в ногу ради всегобщего блага».


        А остальное касается любого другого языка, сабжа в том числе, и на ООП свет клином не сошёлся

      • +2

        ООП как таковое и не отсутствует. Отсутствуют классы и наследование. Вместо них трейты и композиция. Принципы ООП при этом никуда не делись.

        • 0
          Хм, ладно. Статья обходит это стороной, и можно подумать, что в Гугл переизобрели С.
          • 0

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

            • +1
              основной целью ржавчинки является создание языка с… отсутствием утечек памяти

              кхем, нет, с утечками железных гарантий не дают — https://habrahabr.ru/post/281370/

              • 0

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

                • 0

                  Смотря при каких условиях, можно просто запретить память в хипе выделять. И больше никаких утечек :^)

                  • 0

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

        • 0

          Наследование (на классах ли, на прототипах ли, может ещё на чём) — один из основных факторов отделяющих ООП от других парадигм.

          • +2

            Возможность наследования есть у трейтов.

            • 0

              Значит наследование не отсуствует?

              • +1

                Только для трейтов, структуры/атд расширять нельзя.

      • 0
        Хз, наверное потому что за 30+ лет своего существования ООП так и не взлетела.

        Ну реально, в мейнстримовых интерпрайз языках все что можно было запретить в ООП — запретили, все что можно было порезать — порезали, ибо
        а) Наследование не работает. Ну реально, больше 2 ступенек иерархии наследования уже трудно-сопровождаемые (я как-то видел глубину наследования в 20+ классов — это был страшно), наличие наследования заметно заметно снижает скорость вызова функций (наплодить сотни тысяч и миллионов экземпляров класса СO2, который является наследником классов C и O, а те в свою очередь являются наследником абстрактного класса H и все это заставить моделировать термодинамику — увы и ах, но не получится), плюс к этому огребаем кучу неприятных моментов, как сильное связывание, хрупкие базовые классы и прочий рутинный трешняк
        б) Полиморфизм тоже не работает. С множественным наследованием нас обламалали, напридумывали всяких там еретических интерфейсов. В общем ромбик уже не тру
        в) Ну классы/типы вроде как какую-то пользу приносят, вот только всякие там структуры были еще задолго до этого вашего ООП
        г) В принципе использование ООП несет большие накладные расходы. Сейчас правда все ошалели от гигагерцев частоты и гигабайтов памяти… в итоге требования к ресурсам растут и растут, а вот функционал — нет. Если честно в программах с HPC все кладут болт на на это ООП и переходят на композицию

        Ну т.е. реально, на бумаге и когда рядом стоит умный архитектор, который сходу придумает структуру всего проекта и учтет все ньюансы, то ООП красиво выглядит, а вот когда надо выпустить совершенно новый продукт… в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали, а самые ответственные куски кода в итоге выполняются, например, как описано в этой статье https://habrahabr.ru/company/mailru/blog/319194/
        • +1
          в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали

          А как обещали?

          • –2
            На XXII съезде КПСС обещали построить коммунизм к 1980 году… но коммунизм так не построили, поэтому решили изобрести ООП и сказать, что вот оно счастье. Приверженцы этой новой парадигмы обещали возможность создания повторно используемых классов и паттернов, и это звучало заманчиво. Возможность комбинировать эти классы в многократно используемые и настраиваемые бизнес компоненты казалась Святым Граалем индустрии ПО. (с — https://habrahabr.ru/post/143620/ )

            Но мы не будем говорить о наступлении кодерского коммунизма, т.к. ключевые обещания: наследование, инкапсуляцию, полиморфизм и абстракцию нифига не выполняются дальше чем сферовакуумные примеры.
        • 0
          Не работает? Вот же блин, а я-то не знал, и по наивности пользуюсь…
          • 0
            Уверены, что пользуйтесь? :-) На Smalltalk'е поднимайте здоровенные бизнес-проекты с какой-нибудь зубодробильной математикой? :-)
            • 0
              Smalltalk в 2017 году? Увольте.
              Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.
              • –2
                Smalltalk в 2017 году? Увольте.
                Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.


                Ну т.е. Вы тока что расписались, шо чистое ООП — это УГ, и подтвердили мои слова :-)

                Вы знайте, по возможностям ООП Java от Smalltalk отличается менее чем никак (на самом деле Жаба все же более куцая, в отличии от неё Smalltalk использует чистую ОО модель, компиляторщики вон говорят, что он так вообще — первый и единственный ООП язык, а они люди вумные — с ними лучше не спорить). Ну у C# правда есть еще мультиметоды — супер-достижение, которое перебивается паттерном Визитёр.

                В общем, если не копаться в глубь (шо нынче не в моде), то существенной разницы не заметите:

                |f|
                "A comment"
                f := Foo new: 'AString';
                


                Foo f;
                // A comment
                f = new Foo("AString");
                


                Разница просто гигантская, не правда ли? :-)

                  initReports
                	"Initialize the list of reports by reparsing the index file."
                
                	| parser |
                	self resetReports.
                	parser := IndexFileParser 
                            documentBase: self documentBase 
                            source: self getIndexFileStream.
                	[parser atEnd]
                		whileFalse: [self addReport: parser next]
                


                    /*
                     * Initialize the list of reports by reparsing the index file.
                     */
                    public void initReports(String reportBase)
                    {
                        IndexFileParser parser;
                        Report report;
                
                        resetReports();
                        parser = new IndexFileParser(getDocumentBase(), getIndexFileStream());
                        while ((report = getNextReport(parser)) != null) {
                            addReport(report);
                        }
                    }
                


                Ну я все-таки подскажу одно значительное отличие на котором попадаются все хелоувордщики:
                |i|
                i := 1+(5*6).
                


                int i;
                i=1+5*6;
                


                Впрочем порой он даже более читабелен:
                Rectangle width: 100 height: 200
                

                new Rectangle(100, 200);
                
                • 0
                  Вот ничего плохого про язык Smalltalk не хотел сказать. Да и вообще, наверное, я неправ, но у меня Smalltalk ассоциируется только с легаси-кодом, а легаси-код с большим трудом ассоциируется с хорошей архитектурой. Даже если на момент разработки в 1981-м она была хорошей.
                  Спасибо за примеры, интересно взглянуть на синтаксис (да, разница колоссальная).
                  • –1
                    Ну как я слышал, Смоллтолк нынче больше популярен как обучающий язык программирования, т.к. все остальные ООП языки так или иначе испытывали его влияние. Но язык действительно не смог взлететь (ну по сравнению с С++, Жаба, C# и т.д.) — я хз почему, только могу предположить, мне кажется потому:
                    1/ Он появился слишком рано и сообщество, как и оборудование было не готово с ним работать,
                    2/ За этим языком не стояло никакой корпорации Зла, зато ее Жаба с ним конкурировала, я вообще про Смоллтолк узнал, когда знал уже C# (лучше бы не знал)
                    3/ Ну и последнее, это потому что чистое ООП оказалось не практичным и торчать в рамках одной парадигмы не тру, что С++, что Жаба, что C#, что Object Pascal — все они гибридные и мультипарадигменные языки, а в некоторых из них ООП так вообще не главное, и вероятно это не с проста.
                    Собственно все эти Расты, Голэнги и F# которые вообще исповедуют совершенно другие принципы появляются также не с проста. Я правда хз — взлетят ли они.

                    Синтаксис у Смоллтолка, конечно немного архаизмов, но в целом все тоже самое получается шо и в современных языках, некоторые вещи кажутся вполне себе даже удачными (пример с Rectangle)
                  • 0

                    Легаси это не обязательно плохой код, это всего лишь продукт, активная разработка которого прекращена. (Имхо.)

                    • 0
                      Скорее, это продукт, который активно разрабатывали несколько десятков лет несколько десятков (или сотен) человек.
                    • –1

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

          • 0

            OO design patterns пользуетесь? про что они вообще, замечали?

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

              Паттерны, очевидно, про хорошие способы решения типовых задач. Вот только на практике задачи редко бывают настолько типовыми, и без доработки напильником паттерны из той книги на задачу не натягиваются.
        • +2
          экземпляров класса СO2, который является наследником классов C и O

          Ну если писать вот так оно конечно не будет работать. (CO2 точно не наследовать от C и O надо.)

          • –1
            А от чего их надо наследовать? От Господа Бога? :-)

            Впрочем их вообще не надо ни откуда наследовать, Data oriented design и композиция отлично справляется, но это уже нисколько не ООП :-)
            • 0
              Правильно. А класс «кошка» нужно наследовать от классов «усы», «лапа», «хвост». Но ни в коем случае не от класса «животное».
              При таком понимании ООП понятно, откуда у вас такие претензии…

              Мартышка к старости слаба глазами стала;
              А у людей она слыхала,
              Что это зло еще не так большой руки:
              Лишь стоит завести Очки.
              Очков с полдюжины себе она достала;
              Вертит Очками так и сяк:
              То к темю их прижмет, то их на хвост нанижет,
              То их понюхает, то их полижет;
              Очки не действуют никак.
              «Тьфу пропасть! — говорит она, — и тот дурак,
              Кто слушает людских всех врак:
              Всё про Очки лишь мне налгали;
              А проку на-волос нет в них».
              Мартышка тут с досады и с печали
              О камень так хватила их,
              Что только брызги засверкали.

              К несчастью, то ж бывает у людей:
              Как ни полезна вещь, — цены не зная ей,
              Невежда про нее свой толк все к худу клонит;
              А ежели невежда познатней,
              Так он ее еще и гонит.
        • 0

          В иерархии классов стандартной библиотеки Java очень часто встречается многоуровневое наследование. Уровней пять могу припомнить легко. Думаю что 10 найдется.


          Ну и достоверность остальных аргументов тоже слегка того… упрощаете вы. Или излишне обобщаете.


          Я прекрасно помню, как выглядело скажем программирование на PL/1. Или Фортран. До ООП, в общем. И не надо далеко ходить, чтобы понять, что сегодня прикладные программисты в значительной степени занимаются тем, что собирают программы их готовых уже кусков. Не везде и не всегда — но там где это прокатывает (в первую очередь по ресурсам) — там это реально ускоряет разработку.


          Так что термин "ООП не взлетело" я бы переформулировал скорее как "не смогло захватить мир". Так будет правдивее.

          • –5
            Вероятно просто у Оракла индусов больше чем классов, так что если кто-то что-то сломает на самом верху этой 5-и уровненной пирамидки, то они просто натравят всю эту ораву прилаживать костыли. В принципе им должно хватить всех сотрудников, шоб натравить на пирамидку из 12 ступенек наследования. А так-то большинство паттернов содержат 2-3 слоя наследования, ну было дело -пришлось как-то забацать 4 иерархии наследования (крайне специфическая задача). А все что 5+ ИМХО просто отсутствие архитектуры, клацц-клац и в продакшен, а рефакторинг для трусов, а может просто разработчики писали калькулятор для конкурса сайта http://govnokod.ru
            Тем более Java наглядный пример того, что не все йогурты одинаково полезны — там вообще много чего можно и много чего есть, но это не значит что это хорошо (иногда даже об этом предупреждают) — тут даже на хабре можно много примеров найти.

            Дык, на Фортране я и сейчас отлично иногда программирую — отличный язык, жалко шо бабосов стоит немерено (хотя один фиг выходит дешевле Матлаба), и при написании больших моделей выполняемых на супер-пупер-компьютерах (да и вообще для научных вычислений) выбор тут не особо велик: либо Фортран, либо Си.

            Что касается того шо программисты собирают программы из готовых кусков, то эта тема не нова: злые языки поговаривают, что так и Модула умела в 70-ых года и вероятно такой подход был известен и ранее. Ну а всевозможные LAPACK, LINPACK и прочие BLAS, рожки которых торчат там где нужно выполнять операции сложнее сложения двух чисел, также были написаны на упомянутом Вами Фортране еще до того как я наверное родился (это чисто гипотеза)… не ну иногда встречаются велосипеды переписанные на Си, но без этих ваших ++ Т.е. заслуги очередной серебряной пули под названием ООП я тут не вижу.

            А по поводу взлетело-невзлетело, это уже вопрос личной терминологии. И вот по-моему мнению ООП как раз таки смогло захватить весь мир: посмотрите — все мейнстримовые ЯП пытаются реализовать так или иначе ООП (мыши кололись, плакали, но продолжали есть кактус). Есть конечно небольшая группа лямбда-извращенцев, растаманов и прочих хипстеров из фанклуба Гугла, но это пока все попытки выйти из порочного круга и погоды они не делают. А вот взлететь ООП как раз таки не смогло, начиная с самого простого — любые нетривиальные абстракции текут (вроде изобретатель stackoverflow.com сказанул как-то не подумав) а дальше уже начинается… Ну или например где это ваш полиморфизм (вот только сегодня думку думал кагбэ мне написать супер-полиморфные функции, которые смогут переварить 100500 самых разных типов данных)? Мне вот нравиться как это сделано в С++ или в богомерзком Пухтоне, можно даже ромбиком наследоваться, но все кругом считают шо это не тру, поэтому давайте напридумываем всяких бесполезных интерфейсов…
            • 0

              По-моему вы путаетесь в показаниях. Либо ООП "не взлетело", либо "смогло захватить мир". Либо ничего серьезно лучше нет — либо одно из двух (с).


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


              И я вам даже на пальцах объясню, откуда она берется — да, один паттерн это как правило 1-2 слоя, больше вряд ли. Но это совершенно не значит, что в сложном фреймворке есть только один паттерн. Вот отсюда она и берется. А вот четыре иерархии и 10 уровней наследования — это совершенно перпендикулярные вещи.

              • +1
                В Unity3D мы все объекты наследуем от MonoBehaviour, который наследуется от Behaviour, который наследуется от Component, который наследуется от Object. 5 уровней, с которыми каждый день работаешь и ничего — никто не путается.
                • –2
                  Конечно не путаются, ведь разработчики не могут добраться своими кривыми ручками до Object (внезапно), который является родителем всего и всея (внезапно). Добрые дяди уже позаботились, так что можете работать лишь с наследниками MonoBeheavor, все что выше — уже Вас не касается — это черный ящик. Правда Юнити далеко не образчик стабильности — после каждого обновления обнаруживается несовместимость со старым API, да и производительность движка оставляет желать лучшего, что кагюбэ намекает ;-)

                  Но в любом случае имеем в Юнити всего 4 иерархии наследования, не 5, а именно 4 — отделяйте мух от котлет, точнее говнокод от фреймоврка, вы еще посчитайте сколько иерархий наследований в сорцах ОС и тоже их добавьте ;-)

                  При этом: object — в принципе обязательный (без него никак), а component — необходимый для реализации игровой логики, т.к. Юнити это вообще не про ООП, там изначально используется компонентная модель, если что.
                  • +2
                    Юнити это вообще не про ООП, там изначально используется компонентная модель

                    С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.

                    который является родителем всего и всея (внезапно)

                    Внезапно, я говорил о UnityEngine.Object, а не о System.Object.

                    Правда Юнити далеко не образчик стабильности — после каждого обновления обнаруживается несовместимость со старым API

                    Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API?

                    производительность движка оставляет желать лучшего, что кагюбэ намекает ;-)

                    Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах. О каких проблемах с производительностью вы говорите? Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.

                    могут добраться своими кривыми ручками

                    Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?
                    • –3
                      С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.

                      С таких, что компонентно-ориентированное программирование это независимая парадигма программирования, которая была придумана Виртом для решения проблем внезапно возникших у ООП, и реализованная в языке, который является ОО менее чем никак
                      https://ru.wikipedia.org/wiki/Оберон_(язык_программирования)
                      Оттуда КОП ушло в ныне мейнстримовые языки и стало их частью, т.к. действительно, в большинстве случаев композиция предпочтительнее наследования. Тут же на хабре, уже ни раз обсуждали разницу между КОП и ООП.

                      Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API


                      Вот только недавно это на работе обсуждали, правда в контексте Python 2 RIP: программа написанная на С++ в 1989 году, компилится в 2017, программа написанная на C# под .NET 1.0 в 2002..2003 годах (язык был стандартизирован по ISO в 2003 вроде бы, а бета-версию вроде как опубликовали эдак в году 2001), точно также внезапно скомпилится и заработает в 2017 году. Хотя там тоже бывали костыли, например, до появления Джнерик-типов в .NET 2.0, в общем обратная совместимость худо-бедно выполняется. Хз, чего там у Жабы — не занимался такой глубокой интроспекцией в ней, но думаю худо-бедно норм.

                      Однако в большинстве своем все не так безоблачно.

                      Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?

                      Ну потому что, то что зарыто внутри фреймворка, разработчика уже не касается, т.к. отнаследовавшись один раз для него вот энта проблема:
                      https://ru.wikipedia.org/wiki/Хрупкий_базовый_класс
                      еще не актуальна, все что внутри фреймворка — это уже головная боль его создателей. К счастью, у них индусов (в штате, на аутсорсе, на аутстафее) вероятно больше чем классов а также есть вумные архитекторы-надсмоторщики с кнутами, так что они могут себе позволить сопровождать, поддерживать и развивать ПО где объемы наследования очень-очень велики.
                      Так что в условиях неограниченных ресурсов (как индусо-часы, так и ресурсы вычислительных машин) — это работает. Но у большинства ресурсы ограниченные — и тут выясняется, что сложность программы (как разработки, так и цикломатическая сложность) растет экспоненциально от глубины наследования. В тоже время какой-то учитель математики по фамилии Степанов в 3.5 написал STL, которая уже больше 20 лет успешно используется и включена в стандарт. Заранее предупрежу, что STL это тоже не про ООП, а Степановтак вообще один из самых ярых критиков ОО-подхода.

                      Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах.

                      Слабое мобильное устройство — это Нокиа 1100, еще космические спутники (там до сих пор летают на 51-ой архитектуре и килобайтами памяти). А современные говносмартфоны и говнопланшеты по вычислительной мощности круче домашних писюков начала 2000-ых. К слову сказать Unreal и Quake были изначально написаны на чистом Си еще в 90-ых
                      Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.

                      Вы просто всего 2 движка знайте
                      … способен выдавать 60+ fps сложной логики с физикой....

                      Уравнения Максвелла тожее умеет решать, или кварк-глюонную плазму смоделирует? В физике там ничего особенного: коллизии, 2-ой закон Ньютона, уравнение движение и т.п. — примерно 1-ый курс… потом студенты в рамках лабораторных работ/курсовых сами пишут куда более сложные физические модели.
                      способен выдавать 60+ fps

                      Если там на сцене живет 3.5 МоноБихеавор, то да, а так:
                      https://forum.unity3d.com/threads/general-performance-optimization-tips-for-unity.386338/
                      В общем удже давно известно, что производительность и Юнити ТрыДэ это несовместимые понятия. Но Unity3D не за это любят, а за
                      Это универсальный игровой движок

                      Но за все надо платить https://ru.wikipedia.org/wiki/Технический_долг

                      Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.

                      Обычно там внутри что-то типа такого:
                      https://www.youtube.com/watch?v=rX0ItVEVjHc&t=270s
                      Что тоже не ООП. У меня вон тоже, когда говнокодю на C# начинают плодиться всякие unsafe:
                      public unsafe static Matrix UnsafeMultiplication(Matrix A, Matrix B)
                         {
                             int h = A.Height;
                             int w = B.Width;
                             int l = A.Width;
                             Matrix resultMatrix = new Matrix(h, w);
                             unsafe
                             {
                                 fixed (double* pM = resultMatrix._matrix, pA = A._matrix, pB = B._matrix)
                                 {
                                     int indexA, indexB;
                                     for (int i = 0; i < h; i++)
                                     {
                                         indexA = i * l;
                                         for (int j = 0; j < w; j++)
                                         {
                                             indexB = j;
                                             double result = 0;
                                             for (int k = 0; k < l; k++, indexB += w)
                                             {
                                                 result += pA[indexA + k] * pB[indexB];
                                             }
                                             pM[i * w + j] = result;
                                         }
                                     }
                                 }
                             }
                             return resultMatrix;
                         }
                      


                      Это примерно раз в 10 быстрее чем вот такое:
                       public static Matrix NaiveMultiplication(Matrix A, Matrix B)
                          {
                              Matrix resultMatrix = new Matrix(A.Height, B.Width);
                              for (int i = 0; i < resultMatrix.Height; i++)
                              {
                                  for (int j = 0; j < resultMatrix.Width; j++)
                                  {
                                      resultMatrix[i, j] = 0;
                                      for (int k = 0; k < A.Width; k++)
                                      {
                                          resultMatrix[i, j] += A[i, k] * B[k, j];
                                      }
                                  }
                              }
                              return resultMatrix;
                          }
                      

                      Правда unsafe это вообще не про .NET, а так — грязный трюк (да, мыши кололись, плакали, но продолжали жрать кактус). И ООП тут встречается в гомеопатических количествах, лишь при описании собственного класса Matrix. Впрочем к версии 4.5 .NET все же узнал, шо есть такая офигенная штука как SIMD (Intel Pentium MMX, 1997 год, 16кБ L1, 166 МГц), так что жить стало лучше, жить стало веселее.

                      Потом да, потом это все будет обернуто со стороны клиента уже в читабильный ООП-код
              • 0
                По-моему вы путаетесь в показаниях. Либо ООП «не взлетело», либо «смогло захватить мир». Либо ничего серьезно лучше нет — либо одно из двух (с).

                Открою тайну — это два разных понятия, если не догадались. Что значит «не взлетело» — я пояснил, что значит «захватило мир» — я тоже пояснил, так что Ваше непонимание вызывает у меня недоумение 0_0

                Да, про Оракл вы просто гоните

                Т.е. Вы считайте, что у них классов все же больше чем индусов? Ну допустим.

                Не везле, далеко не везде — скажем, один класс из десятков, но такая вложенность встречается, во вполне промышленных количествах.

                Так не везде или все же в промышленных масштабах? Определитесь уже. Вы похоже пытайтесь выдать исключительную ситуацию за рядовую, при этом мой рекорд в 20+ иерархий наследования так и не побили. При этом я могу дать подсказку (по крайней мере для .NET), где искать большую вложенность — обычно в компонентах UI любят наплодить дофига наследников (но правда 20+ Вы там все равно не найдете), на то даже есть свои причины

                • 0
                  не совсем про наследование, но про стектрейсы в JavaEE
                  • –2
                    Странно шо Вы не выложили снимок всего дампа памяти. Вы просто путайте стэк вызовов с наследованием. Можно и в Сях без всякого наследования получить не меньше, а если еще и функция рекурсивная…

                    Другое дело, шо как форма отражения цикломатической сложности, снимок стэка вызовов должен отразить её повышение при использовании наследования
                    • 0

                      Не бойтесь, не путаю. Просто вы не осилили прочитать название спойлера.

                      • –1
                        Нет, просто я не очень понимаю:
                        1) Какое это имеет отношение к сабжу (если забыли, то это Go)
                        2) Как это имеет отношение к срачу про наследование
                        То что Вы осилили Java.lang.Thread.getStackTrace() меня, конечно, несказанно радует, но не обязательно об этом на каждом углу кричать? А то вдруг набижит бородатый погромист и выложит свой дамп :-)
    • –2
      Вброс засчитан… осталось только выяснить, шо такое Rust и использует ли его хоть кто-нибудь, кроме Мозиллы для задач сложнее ХеллоуВорлда. Я вот только про игру с таким названием слышал, но сомневаюсь, что это хоть как-то связано с этим языком, его популярностью и применимостью…
      • +2
        Я вот только про игру с таким названием слышал

        Показательно, только не в том смысле, что ты думаешь.

        • –3
          Показательно это то что Rust в продакшене не используется от слова «совсем» (ну допустим «почти совсем»), по крайней мере за пределами Мозилы и 3.5 фанбоев. В то время как на сабже написан тот же Докер, а пользуются всякие Атлласианы, Адобы, АйБиЭмы и прочие Дропбоксы, даже китайцы на нем пишут — вот это показательно.

          Так шо я даже хз, представляет ли слово Rust хоть какой-нибудь интерес за пределами одноименной игры :-) Вероятно нет — все его хвалят, но никто замуж не берет, пичалька :-)
          • +3
            и прочие Дропбоксы

            Действительно

            • –2
              Странно, не хватает еще скриншотов с IBM, Atlassian, Adobe, ну и т.д. по списку, пичалька, ну шо Вы ей Б-г прям как маленький — ищите и обрящите: https://github.com/golang/go/wiki/GoUsers
              Ссылку на rust-friends для сравнения судя по всему сами в состоянии найти ;-)
              • 0

                Ещё даже пары лет не прошло как раст релизнулся, просто не успели же ещё ничего накодить, это вам не фигак-фигак и в продакшен, ну шо Вы ей Б-г прям как маленький :)

                • 0
                  Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)
                  Помниться мне первая версия C# появилась одновременно с появлением самого языка в 2002 году и она уже была стабильна, через год — в 2003 году — язык был стандартизирован в ISO, а в 2005 вышла уже 2.0 в которой он уже предстал полностью сформированный языком (дальше пошли свистели и переделки, да синтаксический сахар для индусов). И да, никаких проблем с обратной совместимостью (это правда не значит что хорошо использовать ArrayList!) За 15 лет существования.

                  Аналогично можно сказать и за Голэнг — он причем ровесник Раста, но первая версия релизнулась еще 5 лет назад :-)
                  • +2

                    Ну так результат наглядно виден: Rust намного более тщательно проработан чем Go или C# :D

                    • 0
                      Ээээ… это кто сказал?
                  • +2
                    Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)

                    Учитывая постоянные передёргивания, на нормальный ответ не надёюсь, но всё-таки. Про C# пишут, что в январе 1999 была уже сформирована команда, которая занималась языком. Причём мне что-то подсказывает, что видение конечного результата было уже сформировано. Раст же начинался как проект одного человека, язык прошёл через множество экспериментов до того как окончательно оформился. Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.


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

                    • 0
                      Ну вообще я об этом и говорил.

                      Сообществу .NET был предоставлен сразу рабочим (ну почти, где-то за год подписчики msdn получили бета-версию .NET, меня в их числе естественно тогда еще не было — я с говнокодингом на нем познакомился лишь в 2005 году), после чего он очень шустро был стандартизирован, и тут же пошел в продакшен и начал набирать популярность. Java конечно он не переплюнул, но вполне с ней конкурирует и даже вопреки политике Microsoft стал кросс-платформенным языком, да и Java куда старее и к моменту появления C# у неё уже было устойчивое сообщество погромистов. И всю свою публичную историю существования этот язык идет по пути расширения и добавления новых свистелок и переделок.

                      И это важно, т.к. предыстория появления языка может быть очень долгой и богатой — вообще C# можно считать потомком Delphi, создавали их одни и те же люди, вообще папа Delphi и C# — создатель компилятор Turbo Pascal, так что при желании можно отследить историю языка начиная с даты рождения Вирта. А еще у Корпорации Добра была своя Жаба.
                      Но вот история конкретно языка начинается все же с его обнародования и начала использования — официальная дата его рождения: 2000-ый год (я так понимаю его тогда анонсировали), а в 2002..2003 пришла Visual Studio.NET где он был. Так что история использования языка и платформы .NET начинается с 2002 года. Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).

                      Причём мне что-то подсказывает, что видение конечного результата было уже сформировано.

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

                      Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.

                      Об этом я тоже где-то здесь уже писал (Оракл и его тысячи и тысячи индусов). Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL. А еще вот всопмнился язык D — его тоже одиночки поднимали. Не сказать что он убер-популярный, скорее совсем непопулярный, но кое-кто им пользуется, я даже кусок живого проекта на нем видел.
                      • +1
                        Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).

                        Так в чём вред того, что язык показали ещё до релиза? Никто ведь, на тот момент, ничего не обещал, даже наоборот — всячески предупреждали, что использовать можно только на свой страх и риск. В итоге большинство поглядывали на прогресс с "безопасного расстояния", зато заинтересованные люди могли повлиять на конечный результат. С майкрософтом о последнем можно только мечтать.


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


                        С видением проект у создателей Раста явно какие-то проблемы

                        Не очень согласен, но безотносительно этого: как по мне, лучше пусть будет много экспериментов до релиза, чем потом будет язык из стороны в сторону бросать. Интересно было бы послушать если ли какие-то претензии к языку в этом плане после версии 1.0.


                        Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL.

                        Ну положим они больше пруф оф концепт делали, чем конечную (современную) реализацию.


                        А еще вот всопмнился язык D — его тоже одиночки поднимали.

                        Вот мне кажется, что все эти метания с D1/D2 и фобос/деймос, в немалой степени, тому причина. И если бы они подольше подержали язык в "дорелизном" состоянии, то этого, возможно, удалось бы избежать.

              • +3

                Дык, изначально речь шла о том, что вообще никто кроме мозиллы не использует? Рад, что мы достигли взаимопонимания, что это неправда.

                • –3
                  Если внимательно прочитайте, то речь шла о том, что за 7 лет существования Раста им пользуется только Мозилла, да 3.5 фанбоев — увы, но такова жестокая реальность :)
                  Может еще лет через 7, когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)
                  • +2

                    Ну то есть, все, кто перечислен в списке "друзей раста" — это те самые три с половиной фанбоя? Если так фактами оперировать, то и правда можно доказать всё, что угодно.


                    когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)

                    А это к чему? С версии 1.0 совместимость вполне обеспечивается. Есть конкретные претензии или это просто сотрясание воздуха?

          • +2
            Показательно это то что Rust в продакшене не используется от слова «совсем»

            Лично мне достаточно, что у нас есть проект на расте. Правда пока показать не могу, но относительно скоро будет выложен в опенсурс.

            • –2
              Ну также можно запилить проект на Брейнфаке, и это наверное будет очень показательно…
              Проект на Растет и у меня был, но пока не наберется критической массы таких проектов, говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво. Голэнг уже успешен, Растт — нет, он даже в 20-ку языков по версии IEEE и TIOBE не входит — гордо тусуется в компании всяких узкоспециализированных Верилогов (но им не стыдно, ибо эртээльщики народ особый и их мало), а вот Scratch входит :-)
              • +1
                говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво

                А кто говорит о суперуспешности? Изначальное утверждение звучало совсем не так. Я просто хочу сказать, что на расте работу найти реально. Да, её (очень) мало, но тот самый "продакшен" имеется.


                Ну и поразительная осведомлённость, как для человека, который "только про игру с таким названием слышал".

                • 0
                  Ну тут гипербола. Просто оперировать «вот мы щас пилим проект на Расте и нам этого достаточно» — выглядит не совсем корректно. Я вот как-то запилил целый Asteroids на F# (самом деле XNA+C#+F#), но это не делает его языком выбора, не смотря на все его достоинства и няшность. И естественно я никому его не навязываю (не смотря на его няшность). И даже кое-что на Расте заговнокодил (есть у меня подозрение, не для того, для чего его обычно используют), что и его не превращает в язык выбора (тем более F# няшнее)…
                  А еще у меня в универе был знакомый который на протяжении нескольких лет запилил на асме игровой движок (ТрыДэ!) — что, конечно, круто, но не понятно, нафига это. Ну в общем хвалиться не прикольно.

                  Впрочем у Раста в этом плане все же дела лучше — хз на сколько, но вот про вакансии Java-программистов с опытом разработки в Rust и Golang 0_0 я уже слышал, ну и по крайней мере его хотя бы Samsung начал активно педалить. Но все равно пока это «самый любимый язык программирования на котором никто не кодит» https://stackoverflow.com/insights/survey/2016#technology-most-loved-dreaded-and-wanted
                  а самымой популярной технологией по-прежнему остается богомерзкий ЖабаСкрипт https://stackoverflow.com/insights/survey/2016#technology-most-popular-technologies

                  Хз, может он и через пару лет выбъется в топ-20 используемых языков общего назначения (и холивары Go vs Rust станут еще более острее, что не может не огорчать)
                  • 0
                    но это не делает его языком выбора, не смотря на все его достоинства и няшность.

                    Почему? Если в каком-то определённом случае достоинства перевешивают недостатки, то как по мне, язык вполне можно рассматривать


                    Ну в общем хвалиться не прикольно.

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

            • +1

              Мы тоже пилим небольшой проектик на rust, который пойдёт в open source (под GPLv3+, т. к. samba, которая используется внизу, под GPL). Когда запилим пока неясно, т. к. висят более приоритетные задачи.


              Есть ещё одна библиотека, которую я планирую нафигачить сам с перспективой использование на работе. Только там сначала надо написать dissector для wireshark'а и отреверсить протокол xD

              • –3
                Ок, с прожектерством разобрались, теперь ждем первого человека, кто пилил-пили и все же таки запил свой проект на Rust ;-)
                • +2

                  Вы не осилили в поиск по гитхабу или как?

                  • –1
                    Ок Гугл, покажи мне Nelder-Mead:
                    Languages
                    14 C#
                    13 C++
                    11 Python
                    4 C
                    2 JavaScript
                    2 Jupyter Notebook
                    2 Matlab
                    1 Go
                    1 Java
                    1 Julia

                    Хм… чего-то не хватает. Ок, Гугл, нука покажи nonlinear optimization:
                    Languages
                    26 Matlab
                    17 C++
                    14 C
                    11 Python
                    6 Java
                    6 R
                    5 Julia
                    4 Fortran
                    4 Jupyter Notebook
                    3 Haskell

                    Хм… Хаскель — есть, C# — есть, Фортран — есть, Джулия — есть, Пухтон тоже есть, как и R, C/C++, C#, Java, внезапно даже сбаж [если не забыли, то говорили о Go] есть.

                    Хм, что я делаю не так? Ах да, точно, можно же было бы посмотреть сводную статистику, например тут https://octoverse.github.com/

                    Понимайте, мне нет нужды целенаправленно выискивать сорцы языка Мозиллы и прожектеров, т.к. есть 20 десятка наиболее везде-используемых языков + нишевые специализированные языки (типа Verilog или VHDL), на половине из которых я худо-бедно говнокодю. А еще на них говнокодят миллионы других людей, а еще больше пользуются их продуктами.

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

                    Но вообще-то для конструктивной беседы было бы хорошо провести сравнение с языком сабжа [еще раз напомню — это Go]: какие компании пользуют, сколько выпущено реальных проектов, какой был получен перфоманс в индусо-часах при переводе проекта на этот язык, сделать разбивку по нишам и секторам, ну и провести прочий серьезный анализ. И все это даже влезет в компактную таблицу, которая будет играть явно не в пользу Rust. При этом Go и Rust вообще-то ровесники.

                    Может быть, когда-нибудь, когда на Марсе начнут сажать яблони (а может даже и завтра), к Rust проснется вторая волна интереса и на нем начнут массово писать, тогда да, тогда Rust будет интересен, сейчас куда более интересен тот же COBOL, например.
              • 0

                Тоже похвастаться хочется, но сдержусь до того момента как проект официально анонсируют и когда можно будет ссылку на гитхаб дать. (:

  • +23

    Как круто, автор наконец изобрел универсальную объективную метрику "красоты и естественности кода"! Ну вот теперь заживем, теперь-то узнаем, кто говнокодит, а кто рефакторингом занимается! Интересно, в чем она измеряется, в сусликах/1k LOC, или еще как-то? Хотелось бы так же узнать точные значения для js/perl/python/ruby и прочих неудачников из левого нижнего угла, чтоб выяснить раз и навсегда, кто наименее отстойный.

    • 0
      Меня особо js интересует. По каким таким критериям он попал в список красивых и естественных?
      • 0
        Меня больше интересует Perl, на котором можно писать стихи
      • 0

        Вот это щас обидно было!


        А вы вообще заметили, в каком месте он находится на графике?

        • 0
          Да, графики перепутал, но удобным и читаемым я бы его тоже не назвал бы.
          • 0
            neit_kas
            но удобным и читаемым я бы его тоже не назвал бы.

            К примеру, отобразите на другом языке такое лаконичное в JS:
            let sobaka = { klichka: «Jim», poroda: «dog», say() {console.log( this.klichka + ":gav" )}};
            sobaka.say();
            • +5
              Замечательно! И обфускации никакой не надо: код самообфусцирующийся.
            • 0
              К примеру, отобразите на другом языке такое лаконичное в JS:

              C#. Никто в здравом уме, конечно, такое делать не будет:

              var jim = new {
                Name  = "Jim",
                Breed = "Dog"
              }; 
                          
              Console.WriteLine( jim.Name + ":woof" );
              
            • +1

              F#


              let jim =
                {
                  name = "Jim";
                  breed = "unknown";
                  say = fun self -> printfn "%s: woof!" self.name;
                }

              тип, правда, самому придется написать.

            • +2
              Scala.
              scalafiddle.io
              val sobaka = new {
                val klichka = "Jim"
                val poroda = "dog"
                def say() = println(klichka + ":gav")
              }
              
              sobaka.say()
              

            • +3
              Тут люди думаю достаточно привели не менее лаконичных примеров. Сам на плюсах в основном, а с его местом в том графике я вполне согласен, так что вариант от туда приводить не буду. А так, что лично мне не нравится в читаемости js:
              1) Полное отсутствие типизации. Меня это дико напрягает. Это удобно в использовании, но в оочевидности.
              2) Когда this может оказаться совсем не this.
              3) В реальном коде в нём часто куча артефактов от html. Сам html убирается всякими библиотеками, а вот классы несколько мешаются.
              4) ES6 явно позитивно не сказался на его читаемости.

              Я бы его в самый низ графика ясное дело не засунул, но и в самую верхушку тоже.
              • –5
                neit_kas
                Тут люди думаю достаточно привели не менее лаконичных примеров.


                Разберём эти примеры на лаконичность:

                TheShock C#.

                var jim = new {
                  Name  = "Jim",
                  Breed = "Dog"
                }; 
                            
                Console.WriteLine( jim.Name + ":woof" );
                


                Хм, зачем тут new? — И это же структура, а не объект. Не так ли?
                Поэтому вам и пришлось использовать внешнюю функцию, которая никак не связана со структурой jim
                Печально.

                Sirikid F#

                type Dog =
                  {
                    name : string;
                    breed : string;
                    say : Dog -> unit;
                  }
                    member self.callSay () = self.say self
                 
                let jim =
                  {
                    name = "Jim";
                    breed = "unknown";
                    say = fun self -> printfn "%s: woof!" self.name;
                  }
                 
                jim.callSay ()
                


                Хм, это лаконично?
                Я не понял — а как jim связан у вас с «type Dog»?

                Эта строка — «member self.callSay () = self.say self» — очевидно крутая, и имеет наверное какой-то смысл, но явно не лаконичный.

                «say = fun self -> printfn „%s: woof!“ self.name;» — тут похоже «fun» от слово «function», но не помешало бы убрать его вообще, заменив на ().

                %s глазами нужно сопоставить с self.name? Это конечно было давно придумано. Привыкнуть можно. Но и глаза ломаются, если много параметров надо в шаблон подставлять. Имхо.

                Ну, ладно, я бы по лаконичности поставил этот код не на первое место.

                senia Scala.

                val sobaka = new {
                  val klichka = "Jim"
                  val poroda = "dog"
                  def say() = println(klichka + ":gav")
                }
                
                sobaka.say()
                
                


                Scala — это здорово. Особенно отсутствие запятых, их похоже заменяют слова «val» и «def»
                А «println(klichka + »:gav")" — без лишних (обрамляющих скобок в данном случае) — это лаконично.
                Так и не использование «this» в строке:
                 def say() = println(klichka + ":gav")
                

                Это впечатляет, однозначно.

                Слово new конечно не даёт лаконичности, но ладно. Терпимо. Имхо.

                neit_kas
                Что лично мне не нравится в читаемости js:
                1) Полное отсутствие типизации. Меня это дико напрягает. Это удобно в использовании, но в оочевидности.

                Типизация — это признак "бюрократичности" языка.
                Конечно, она помогает.
                Но иногда её хочется не использовать. В JS её можно применить (Flow, TypeScript — ну, это конечно, не так бронебойно как в иных языках) или нет. Выбор есть.

                neit_kas
                2) Когда this может оказаться совсем не this.

                Вот тут не поспоришь. Кое-что меняется — стрелочные функции. Но всё же тут надо думать, это верно.

                neit_kas
                4) ES6 явно позитивно не сказался на его читаемости.


                Но лаконичности добавилось. Это несомненно. Имхо, конечно, имхо (С)

                P.S. и ещё пример на лаконичность (JavaScript):

                var klichka = 'Jim';
                var poroda = 'dog';
                
                var sobaka = { klichka, poroda, say(){console.log(`${this.klichka} : gav` )}};
                
                sobaka.say();
                

                В коде создаётся объект:
                Object {klichka: "Jim", poroda: "dog", say: function}
                

                Ну, разве это не лаконичное создание объектного литерала?
                (А как же лаконично выглядит сейчас выражение без "+" в console.log метода say()!)

                • 0

                  Синтаксическим оверхедом повеяло...

            • +3
              К примеру, отобразите на другом языке такое лаконичное в JS:

              Видите ли, ваша задача в такой постановке вопроса не имеет смысла. Даже когда я пишу на JS — я не пишу такой плохой код, ибо пускай он лаконичный — он:
              1. Не имеет смысла в таком виде (например, зачем тут вообще использовать метод?)
              2. Не расширяется.

              Так что на любом языке задачу в такой постановке можно записать очень кратко:
              Console.WriteLine("Jim:gav")
              


              Вопрос обычно к реюзу кода, а тут что в JS, что в C# код будет приблизительно одинаковый и все более выравниваться с увеличением кодобазы.
              • –4
                TheShock
                Так что на любом языке задачу в такой постановке можно записать очень кратко:


                Я привел пример лаконичного создание объектного литерала и вызова у него метода.

                Я это выше выделил и не раз.

                Остальные либо не привели ничего такого, либо, как вы, не поняли, что же нужно привести в пример лаконичного.

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

                • +1
                  Понимаете ли, вы ставите ненужное в программировании условие.
                  Вот давайте я вам приведу пример шоковицкого (от моего никнейма) куска кода на C#:

                  public class Progression
                  {
                      public readonly int Time;
                  
                      public int Progress { get; private set; }
                  
                      public bool IsReady {
                          get { return Progress >= Time; }
                      }
                  
                      public Progression ()
                      {
                          Progression(0);
                      }
                  
                      public Progression (int time)
                      {
                          Time = time;
                          Progress = 0;
                      }
                  }
                  


                  Видите, как шоковицки у меня получилось? Просто 10 из 10. Попробуйте повторить на JS! И как только у вас на JS получится так же шоковицки, то я обязательно вам напишу лаконично все, что захотите.

                  Конечно, данная метрика никакого отношения к практическому написанию кода не имеет. Как и ваша, впрочем.
                • 0
                  Создание объекта без формализации его контракта — занятие в общем случае бесполезное.
                  И в JS для этого раньше использовались методы-конструкторы. Сейчас появился синтаксис с классами, а ещё лучше — полноценная типизация с Flow.
                  В этом отношении мой пример на Scala был призван продемонстрировать то, что на других языках так не пишут не потому, что так не получится, а потому, что бесполезно. И лаконичными делают на этих языках полезные конструкции. Но иногда, как на Scala, и бесполезные конструкции случайно оказываются лаконичными. Не стоит из этого делать далеко идущие выводы.
                  • –4
                    senia >
                    В этом отношении мой пример на Scala был призван продемонстрировать то, что на других языках так не пишут не потому, что так не получится, а потому, что бесполезно. И лаконичными делают на этих языках полезные конструкции

                    TheShock
                    Конечно, данная метрика никакого отношения к практическому написанию кода не имеет. Как и ваша, впрочем.

                    «Сражение в Фермопилах было выиграно персидским царём Ксерксом, но… известен лаконичный ответ царя Леонида на предложение сложить оружие в обмен на жизнь: «Придите и возьмите»» (Википедия)

                    Так что полезность (практичность) и лаконичность — это перпендикулярные понятия. (С)

                    TheShock
                    Видите, как шоковицки у меня получилось? Просто 10 из 10. Попробуйте повторить на JS!

                    Повторить что? Ваш совсем не лаконичный код что делает то?

                    P.S.
                    Пример на JS лаконичной, но по мнению автора этих строк — «сонной сортировки» — "sleep sort")
                    var numbers = [7, 1, 77, 15, 145, 9, 5];
                    numbers.forEach( num => {
                        setTimeout(() => {console.log (num)} , num);
                    });
                    
                    

                    Разве это не супер! ;-)
                    • +4
                      Нет, не супер. Все эти дрочерства на призрачные и в общем случае не самые полезные метрики типа «лаконичность» и «смотри как я могу» обычно заканчиваются трудночитаемым и трудноподдерживаемым кодом.
                    • +4

                      Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш "лаконичный" код содержит только глупую шутку в стиле "смотри как я могу".

                      • –1
                        Azoh
                        Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш «лаконичный» код содержит только глупую шутку в стиле «смотри как я могу».

                        Сами понимаете, что отличие пошлого(или глупого) анекдота от остроумного — оно не в количестве текста анекдота, а в голове внимающего, хотя всё же «Скверный анекдот» — это рассказ.

                        Что касается JS — то он и был фактически создан для лаконичного написания кода, выполняющегося в броузере, в отличии от развесистого синтаксиса Java и прочих подобных языков.

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

                        На любом языке можно написать трудно читаемый код. Но есть языки на которых нельзя
                        трудно написать лаконичный код.
                        image

  • +2
    а что у Go с поддержкой GTK3? Гугл сказал, что пока не очень. Может я и ошибаюсь. Но переписывать все под другой язык, только потому, что он лучше, как-то влом…
  • +14
    Может я такой нулёвый, но мне кажется, что с этим багажом:
    Нет классов.
    Не поддерживает наследование.
    Нет конструкторов.
    Нет аннотаций.
    Нет дженериков (универсальных шаблонов. — прим.перев.).
    Нет исключений.

    сложно будет написать поддерживаемый код.

    Хотя если развить мысль «Go станет серверным языком будущего», в направлении, что всё уйдет на клиент и у нас будет огромный объем клиентского кода на js, и тоненький бэкенд на go, то все может быть =)
    • +3

      Например, в Rust для всего этого предоставлены довольно удобные альтернативы, которые юзать иногда таки сильно проще чем классическое ООП (композиция, типажи, функции у структур (не экземпляров), Option/Result, замыкания итп), возможно в Go тоже что-то такое есть

      • 0
        функции у структур (не экземпляров)

        Если не путаю, то в GO как раз можно расширять типы данных.
        • 0

          Вот и я о том же

    • +3
      Нет, позвольте, но и до эпохи ООП можно было писать поддерживаемый код. Да, написать мусор в процедурном стиле легче, но это же не требование. Не баг, а фича.
      Вот по дженерикам да, плачу и мечтаю.
    • 0
      тоненький бэкенд на go, то все может быть

      Естественно, если программа занимает строчек 100-200 кода, то все вышеперечисленное конечно не нужно (можно легко без этого обойтись).
      Поэтому если применять Go там где ему место, то все будет отлично.


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


      В этом плане отличный пример — это язык HQ9+
      Писать на нем программу типа "Hello world". Очень просто и удобно. Никто на нем микросервисы писать не будет.


      Ну и на Go не надо писать огромные программы, где все ограничения языка очень быстро вылезут наружу.

  • +1
    Горутины сжаты (multiplexed. — прим.перев.) в малое количество потоков ОС.

    multiplexed это не «сжаты». Я бы сказал, что это «распределены» в данном контексте.
    Гошники, или как правильно? К вам вопрос: это по сути пул worker-thread'ов, которые выполняют поток команд в легковесных нитях?
    • 0
      Смысл в том, что N горутин выполняется в M потоков ОС, где число M обычно гораздо меньше N. Поэтому происходит объединение нескольких горутин в один поток.
      • 0
        Это и есть мультиплексирование, тут все понятно. «объединение» означает все равно последовательное выполнение, верно? Это означает что вот эти вот горутины стоят в очереди на выполнение этим потоком. Или другим. Нет?
        • +1
          Да, в оригинальной статье так и сказано, что они мультиплексированы. Про сжатие автор сам придумал.
          • –3
            Спасибо за замечание, поправил. Мультиплексированы — для новичков было бы непонятно, думаю. Поэтому заменил на близкий по значению термин (со сноской на оригинальный термин для продвинутых).
  • +16
    Вкинул так вкинул
  • +1
    Вышеназванные изменения отличают Go от остальных языков и это делает программирование на нём не похожим на программирование на других языках

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

      На роль современного BASICа больше подходит Python. Он гораздо ближе к оригиналу.

      • 0
        Думаю, здесь можно поспорить, но лень. Потому что критерии «бейсиковости» будут разными.
  • +4
    он компилируется с человекопонятного кода в байт-код, который понятен для JVM или другой виртуальной
    машине, которая запускается поверх ОС. При выполнении, VM интерпретирует этот байт-код и конвертирует его в
    двоичный код, понятный процессору.

    Серьезно? А пацаны-то (James Gosling) думали, что там JIT compiler.

  • +9
    Не поддерживает наследование.
    Нет конструкторов.
    Нет аннотаций.
    Нет дженериков (универсальных шаблонов. — прим.перев.).
    Нет исключений

    Я бы сказал, что это именно минусы, причем очень и очень существенные.
    • +1

      Если есть альтернативы, это может быть и плюсом, не стоит подпускать ООП головного мозга)

      • +5
        Вообще то наличие корутин и отсутствие вышеперечисленного весьма напоминает Active Oberon

        Он не взлетел, может потому что его Гугл не пропихивал?
    • +1

      Почему отсутствие конструкторов — минус?

  • +11
    Я знаю, что это не совсем техническое преимущество. Но Go разработан и поддерживается Google.


    Это можно отнести и к недостаткам, см. кладбище Google.
  • +10

    "Go быстрый" — сомнительно мне очень
    "Go простой" — слишком простой, я бы сказал.


    И не указаны уникальные преимущества этого языка:


    • очень быстрая компиляция, значительно облегчающая TDD/turnaround
    • очень быстрый старт приложений (привет, Java!)
    • компиляция в единственный бинарник, что упрощает деплоймент
    • очень хорошая поддержка модульности вкупе с очень простым языком позволяет натравить на один проект орду миддлов с шансом на успех
    • +2
      компиляция в единственный бинарник, что упрощает деплоймент


      Кто сейчас так не умеет? Динамическая линковка — это, как правило, фича.
      • 0

        Джава разве умеет создать один бинарник со всем своим рантаймом?

        • 0
          С рантаймом не умеет, но JAR-файл со всеми зависимостями получить можно. Очень удобно.
          • +1

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

            • –1
              Добавлю, что Go-приложение (при определенных условиях) может запускаться в докер-контейнере без ОС (FROM scratch).
              • +3

                Мало-мальски нетривиальное потащит за собой libpthread, libc, linux-vdso.so, ld-so.

                • 0
                  все верно
                  $ go build
                  $ ldd main
                  linux-vdso.so.1 => (0x00007fffd4bf7000)
                  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc4679b7000)
                  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc4675f0000)
                  /lib64/ld-linux-x86-64.so.2 (0x000055cfc4c89000)

                  но, при определенных условиях это не так
                  $ CGO_ENABLED=0 GOOS=linux go build -ldflags "-s -w" -a -installsuffix cgo
                  $ ldd main
                  не является динамическим исполняемым файлом
            • 0
              Это не то?
              http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html
              • 0

                Типа того, только не каталог или инсталлер, а просто один бинарник. Наверное можно организовать.

                • 0
                  Можно.
                  Есть такая программа launch4j
                  А тут как сделать с помощью ее один .exe-файл (упаковать свой .jar-проект и JVM, чтобы Ваш проект мог запускаться и работать без предустановки JVM).
                  http://stackoverflow.com/questions/7071133/how-to-bundle-a-jre-with-launch4j/7582064#7582064
      • –1

        java, .NET, python...

        • –2
          Питон умеет
        • +1
          Java собирается в {J,E,W}AR-пакеты. Аналог в .NET — сборки, в которые помещаются логические единицы — модули.
          То есть собрать в один файл все добро со всеми зависимостями — это не проблема, чаще же напротив, для гибкости (релиза, деплоя) и модуляризации стремятся разнести по разным сборкам различные компоненты. Пример такой идеологии — .NET Core, представляющий собой (в перспективе) аналог огромного во многих частях монолитного .NET Framework.
    • +3

      Опять эти сказки. В который уже раз — JVM стартует быстро. Я уже как-то демонстрировал, что маленькие классы на groovy, которые делают примерно следующее:


      • сконнектиться к JMX порту
      • взять там некие метрики процесса
      • обработать все это, и отдать скажем в Nagios (просто записать в файл)

      Так вот это вот все отрабатывает меньше чем за секунду, если JMX порт локальный, и сервер отвечает тоже быстро. Т.е. JVM успевает за секунду запуститься, отработать класс, и завершить работу.


      А медленный старт — это медленный старт приложений. Самих.


      Что до поддержки модульности — то извините, но это мимо. Есть множество языков, где с этим намного, намного лучше. Скажем, все языки из мира JVM — ну просто потому, что модули уже собраны, под любую платформу, лежат в стандартном репозитории мавен централ, с известным API, в общем — вокруг этого есть инфраструктура.


      А что взамен мы видим у Go? Guthib? Ну это как бы не самое плохое решение, но далеко не самое универсальное. Понятно, что у языка компилируемого в бинарник под конкретную платформу, с этим все сложнее by design, но тем не менее факты налицо.


      Кстати, что там с работой за файрволом? Вот в случае maven, скажем, в 99% случаев достаточно завести внутренний репозиторий, и переключить всех клиентов на него (одним пинком ноги). А что делается в случае go get, если вы в интранете?

      • 0

        Сама jvm стартует быстро, да. helloworld запускается меньше, чем за миллисекунду. Но загрузка и JIT занимают существенное время и способа написать на java большое быстро стартующее приложение нет. Предкомпиляция в java9 может улучшить ситуацию, но не принципиально — она выдает на выходе объектники в 100-200 мегабайт.

        • 0

          Ну так давайте формулировать преимущества как-то более корректно что-ли?


          А то я могу написать примерно так: запускаем (написанный на Go) docker что-нибудь, а он, собака, отрабатывает сто лет. А почему? А потому что нужного нам image не оказалось в наличии, и мы пошли его загружать, а registry медленный, потому что интернет, а диски тоже не очень быстрые, ну и пошло-поехало. Вывод — Go медленный, не? )))


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


          Хотите быстрый старт в Java? Сделайте так, чтобы JVM вообще не поднималась, а была запущена всегда. Так можно, и так делается легко — таких приложений множество.


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


          В общем, суть вопроса в том, что вы упрощаете, формулируя преимущества. Не сильно, но тем не менее.


          компиляция в единственный бинарник, что упрощает деплоймент

          А представьте, что у вас много хостов разной архитектуры (ну например, вы деплоитесь на смартфоны). Вы все еще уверены, что единственный бинарник упрощает задачу деплоймента, а уже не наоборот?

          • 0

            Какая уж тут субъективность :-)


            На JIT языках без предкомпиляции нельзя писать приложения с быстрым стартом, а на компилируемых языках можно. Вот и вся разница.


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


            Я имел в виду отсутствие зависимостей, которые нужно ставить на целевую систему. Давайте оставим в покое телефоны, у них свой подход к деплойменту. У Go немного другая сфера применения.

            • 0

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


              А про быстрый старт… ну вот смотрите — любой GUI на базе web, для простоты, как пример. http сервер запущен, и всегда готов к работе. Время его старта никого никогда не волнует. И это с таким же успехом может быть тяжелый сервер типа вебсферы, или легкий и примитивный, потому что критерии быстроты тут уже другие.


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

  • +3
    Первое же ограничение железо — «Закон Мура не работает.»
    Это почему оно не работает? Собственно, в ссылке автора на закон в первых же строках:
    «He noticed that the number of transistors per square inch on integrated circuits had doubled every year since their invention.»

    Мур ничего не говорит про тактовую частоту. Он говорит о плотности транзисторов.

    Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц

    Да, частота меньше. Но сколько ядер в процессоре Macbook Pro 2016 и сколько ядер в Pentium 4. При этом размеры процессоров одинаковы.
    • 0

      А ещё производительность на гигагерц на ядро выше, потому меньше тепла при той же полезной работе. Попробовал бы автор поставить P4 в свой ноутбук. Помимо SpecINT есть и другие тесты и там хорошо виден рост за десяток лет.

  • +9
    мне очень нравится в этой статье «удобство и читабельность кода», где js выше джавы, го и на уровне питона)
    «При этом красота и естественность» у джса, с++, джавы и питона одинаковая и сильно проигрывают с#)
    • 0
      Я так понимаю, что автор оценивал «простоту и естественность» при использовании concurrency.
  • +16
    Но большинство современных языков программирования (такие, как Java, Python) пришли из однопоточной среды разработки 90-х.

    С другой стороны, Go был выпущен в 2009 году, когда многоядерные процессоры были уже доступны. Вот почему Go был создан с учётом многозадачности (concurrency. — прим. перев.).

    Тогда каким образом объясняется создание таких языков как Ada и Erlang в середине 80-х годов?


    Горутины имеют более быстрое время запуска, чем потоки.
    Также, горутины и потоки ОС не имеют сопоставления 1:1. Одна горутина может запускаться во множестве потоков. Горутины сжаты (multiplexed. — прим.перев.) в малое количество потоков ОС.

    Ну тредпул же, файберы и так далее.


    Горутины поставляются со встроенными примитивами для безопасного обмена данными между собой (каналы).

    Но не обязывают их использовать.


    Горутины позволяют избежать необходимости прибегать к блокированию мьютексов при совместном использовании структур данных.

    Это каким образом?


    Полыхание
    Нет конструкторов.

    Отлично, правда если мы хотим проинициализировать поля значениями, отличными от дефолтных, мы должны либо копировать постоянно код инициализации структуры, либо выносить его в функцию. И, конечно, мы не в коем случае не будем называть такую функцию конструктором.


    Нет аннотаций.

    https://golang.org/ref/spec#Tag


    Нет дженериков (универсальных шаблонов. — прим.перев.).

    Нет и системы типов.


    Нет исключений.

    Как и других типов-сумм, вместо них, какая ирония, мы используем типы-произведения.


    creator116 надеюсь вы разделяете точку зрения автора и можете ответить хотя бы на часть вопросов в комментариях.

    • +3
      Спасибо за комментарий. Я в начале написал, что статья (оригинальная) — это отражение опыта и мнения автора, защищать или опровергать его я не могу. Вполне возможно, что вы гораздо опытнее автора.
      • 0

        Зачем тогда переводить?

        • 0
          По Go мало вводных статей на русском. На мой взгляд, эта статья стоит перевода. Она хоть и содержит субъективную оценку, но также содержит и моменты, на которые стоит обратить внимание в начале его изучения.
          • +13

            Вы, наверное, хотели сказать "мало за эту неделю"?

          • +7
            По Go прям много таких статей на русском, в том числе и на хабре. И очень многие из них содержат «субъективную оценку» в виде «смотрите, какой он крутой, вы непременно обязаны его изучить».
            Возможно даже (не берусь утверждать на 100%), что ни про какой другой язык здесь не выходило такого количества однообразно оформленного восхищения.
    • +4
      Тогда каким образом объясняется создание таких языков как Ada и Erlang в середине 80-х годов?

      Ой, да бросьте. Это не более чем малограмотный вброс. Вы бы еще спросили, зачем в Java класс Thread, с первой версии (а это 1996 где-то). А еще средства координации потоков, разнообразию которых Go может только позавидовать белой завистью.

  • –3

    Источник: github.com/golang/go/wiki/GoUsers
    Я не нашёл там Abode, обманщик!

    • +2
      image
      • +1

        Abode
        Ctrl+C
        Ctrl+F
        Ctrl+C

        • 0
          4. Ctrl+V
  • –17
    Эх… Побегу изучу ещё один язык программирование, глядишь можно будет скормить быдло интервьюру, что я изучил ещё одно гавно которого и так много…
    • –4
      15 быдлоинтервьюров заимнусовала.
  • +6
    Go

    Красота кода

    Выберите что-то одно.

    А если серьёзно
    Красота — понятие крайне субъективное. Поэтому приводить в качестве важного свойства языка «красоту» кода на нём неправильно. У меня, например, глаза вытекают, если я вижу фигурные скобки на той же строке, что и условие. При этом WinAPI-код с его капсом и венгерской нотацией у меня вызвывает восхищение.

    Пожалуйста, перестаньте оценивать языки по субъективным критериям. На любом языке можно сделать как и совершенно нечитаемый, так и наглядный код. Не постите больше подобных графиков. Хотите сравнить языки — пишите об особенных фичах и как их использовать.

  • +6
    Не поддерживает наследование. Это упрощает модифицирование кода. В других языках, типа Java/Python, если класс ABC наследует класс XYZ, и вы при этом делаете какие-то изменения в классе XYZ, то это производит дополнительное изменения во всех наследованных от него классах. К тому же, без наследования, код Go становится более простым для понимания (так как нет super классов, на которые нужно обращать внимание при изучении участков кода).

    Т.е. повсеместно будет использоваться агрегация и изменения класса XYZ коснуться всех классов, которые содержат XYZ… так в чем тут преимущество у Go?

    Вообще, статья про то как превратить особенности языка в его сплошные преимущества.
    • +11
      превратить особенности языка в его сплошные преимущества

      Именно

      «Общеизвестно, что поворот налево — опасный маневр, потому создатели автомобиля Гоу использовали гениальное решение — автомобиль может поворачивать только направо, а при необходимости повернуть налево — просто поверните направо трижды. Одного этого факта достаточно, чтобы понять, насколько Гоу лучше других автомобилей!»
  • +2
    Перешёл с Python на Go, не понимаю почему на диаграмме Python в нулях по красоте и естественности кода?

    • –2
      Может, потому что в нем невидимые символы являются значимыми лексемами?

      Вообще диаграмма крайне холиварная, в отношении того же erlang. (например строка = список чисел).
      С производительностью тоже не всё в порядке — все интерпретируемые языки на картинке по оверхеду самого языка на производительность плюс-минус однохренственны, больше зависит от решаемой задачи и используемой библиотеки.
      • –2
        невидимые символы являются значимыми лексемами

        Только в начале строки. А так как все всё равно форматируют код лесенкой, это не является проблемой

        • +2
          Это не проблема, но табы против пробелов могут доставить боль. А выглядят много где одинаково.
          А влияние форматирования на интерпретацию — крайне холиварная тема.
          • –1

            Это да. Но pep8 настаивает на чётырёх пробелах, подключаем pylint для проверки сего и можно жить

          • 0

            Pre-commit хук и/или линтер на CI-сервере снимают проблему. Когда смесь табов и пробелов (очевидно, подавляющее большинство языков) не влияет, в коде средних и крупных проектов рано или поздно появляется каша, если нет явного битья по пальцам за несоблюдение code style. Наблюдаю во многих open source проектах, например.

            • 0
              Да проблема не в репозитории и правилах, когда есть большой проект — правила форматирования всё равно рано или поздно накатываются.
              Проблема больше во всяких мини-скриптах, небольших чужих приложения ( например, игрушки на питоне) — там, где ты редактируешь код быстро, и чаще всего — не из родного редактора.
              Значимость невидимых на письме символов при компиляции — расходится с практикой естественных языков, не самая ожидаемая для человека вещь.
              • 0

                Человекконечноможетчитатьбезпробеловносогласитесьэтонеоченьудобно ,)

  • 0

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


    Все эти баги с мьютексами и "if err==nil" (и проч, что обычно приводят в доказательство ущербности go) на самом деле легко обнаруживаются при наличии минимальных юниттестов. Ну и стат.типизация даже без джененриков после петона и похапе — щастье же.


    По поводу rust. Представим гипотетическую ситуацию, при которой коллективу кодеров приказывают на него перейти с условного жабопетона — взвоют. Go — поноют немножко, и будут кодить как ни вчем не бывало.

    • +16
      Я уже примерно 2 года как Go-пник. И мне это постепенно начинает нравится чорт вазьми!

      Это всего лишь стокгольмский синдром.
      • –7

        Вам лучше знать, анонимный Психолог из интернета.

  • +1

    Посмотрел вакансии в родном городе, нашёл две вакансии по Go:


    • одна с очень большим разбросом зарплат от джуниора до сеньора, требует Go, Python, Java и Scala
    • другая с очень большой зарплатой, с требованием помимо Go знать ещё и PHP
    • 0

      Вторая, вероятно, связана с переписыванием чего-то с PHP на Go. Либо, как вариант, бэкенд в целом на Go, а PHP — шаблонизатор. Третий вариант, приходящий в голову, наоборот требования подразумевает — главное надо знать PHP, но ещё и Go для какого-нибудь веб-сокет сервера.

  • +9
    Хочу статью " Почему вам не стоит изучить Go?"!!!
  • +2

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

    • 0

      Сорри, промахнулся и поставил минус. А хотел плюс.


      Очень хороший пример, кстати, средства работы с базами данных в стандартной библиотеке, и наличие драйверов под все известные базы.

      • +1
        По мне так интерфейсы для работы с БД не очень.
        • +1

          В смысле у Go? Мне они показались наиболее рабочими. После Java и .Net, скажем так, у которых пожалуй есть драйверы под все базы вообще, и API наиболее полноценный.

          • +2
            А мне не очень. API довольно таки скудный.
            Да, универсально, пул под капотом, потокобезопастность тоже…
            с другой стороны (это то что наболело)
            — пул плохо настраивается, макс кол-во соединений и макс. кол-во простаивающих соединений и все, а я бы хотел задать мин. кол-во простаивающих соединений, кол-во соединений при старте, чтобы не ждать пока соединение откроется
            — средств профайлинга нет. измерить время выполнения запросов можно и снаружи, а вот какие затраты были на установку соединения при вызове db.Query и были ли вообще — непонятно
            — следствия универсальности: нет доступа к спец. возможностям субд, нельзя получить из пула соединение. Даже если разработчик драйвера предоставит методы для работы с API, то надо предоставлять механизмы для создания соединений и отдельный пул, т.к. к стандартному доступа нет. А если такое случится, то нафига тогда database/sql/
            — с логированием, если ошибаюсь, тоже никак
            • 0

              Ну, если сравнивать с JDBC — то да, вы правы. Причем я бы так сказал — компилируемый язык, без VM, инструментировать код наподобие того, как делается в мире JVM, чтобы добавить профайлинг или логирование уже после разработки — это вряд ли.


              Но если сравнивать например с Python, где драйвер MS SQL урезает строки до 100 — это все-таки более рабочее решение.

  • +7
    Не поддерживает наследование.
    Нет конструкторов.
    Нет аннотаций.
    Нет дженериков (универсальных шаблонов. — прим.перев.).
    Нет исключений

    Go это реинкарнация PL/1 ?
  • +2
    реализация concurrency (JAVA) и синтаксис (гомоиконность) мне больше по душе в Clojure. Только там еще иммутабельность, которая так необходима для этого. delay, futures, promises, atoms, refs, agents.
    В общем в контексте использования для concurrency Clojure мне видится более приятной чем Go.
  • +1
    В Go time format не привычен для нас привыкших к strftime.
    Кого-то это сильно взбесило и он запилил сервис http://fuckinggodateformat.com
  • +3
    Задам свой любимый вопрос: а что там с обратной совместимостью?
    Код написанный на го, будет хотя бы собираться в новых версиях компилитора хотя бы через 3-5 лет? я молчу про такую «ынтерпрайзную роскошь», как «работать точно так же»…

    Или будет как с руби? (гугль выпутит новую, улучшенную версию языка, не совместимую с предыдущей, и через 2 года снимет старую с поддержки, со словами, мол, " мы скорбим, что до сих пор ещё много проектов не смогли перейти на новую версию, из-за проблем с перерабокой исх. кода, но мы все-таки снимаем старую версию с поддержки. (читаем между строк: «Мы плевать хотели на ваши проблемы. Это ваши проблемы, трудоемкость и деньги. А мы будем дальше делать наш красивый язык, ибо нас волнует только красота нашего поделия.»)?

    Ещё, во всей статье, так и не нашел позиционирования языка. Под какие задачи он заточен? Какой сдк и библиотеки под него есть?

    Ещё вопрос, как разработчика с 20 годами стажа, которого, вопреки заявленному в статье тезису, никогда не сводили с ума новые языки, которого эта череда «новых откровений» банально достала: зачем нужен ваш язык, если всё, что нам надо, мы прекрасно делаем на уже существующих технологиях: java, javascript, с/с++? кто то еще вспомнит про си-диез (простите, не люблю я его — но и ладно..., живет и даже что ть полезное можно на на нем делать)… кто то вспомнит про питон ( скажу — «остыньте, уже не модно»), руби ( «и вы пойдете на свалку моды»), хацкель (подмигну -ну ты понял, посмтри на питон и руби)… Но чем го отличается от этого разношерстного безобразия? Это нишевый язык или общего назначения?

    Да, вы проводите какие, весьма спорные, сравнения, очень пахнущие глубоким субъективизмом, картинки рисуете. Говорите про какую-то понятность… Но вот я так и не понял — это замена питону или башу в скриптах инициализации линукса?

    Это скриптовый язык с возможностью компиляции и возможностью использовать .dll/.so? Или это легкое нечто которое позволяет набросать что то на коленке типа мини утилиты? Или это нечто для веб, компилируемое и мегашустрое в обработке мегатонн микро-запросов?.. Ведь нечто большое, мега-интерпрайзное этот язык, как сложилось впечатление, в силу отсутствия ооп -банально не потянет (в си же вон от структур и пакетов к ооп перещли?.. зачем, не понятно, наверное… но си, сегодня, остался, видимо, только при программировании микроконтроллеров...). Или го — это замены простому си, пригодному для програмирования микроконтроллеров?

    Какие прикладные пакеты есть в го?(кодогенератор веб сервис-клиента из .wsdl-файла есть? Я могу тестовый скриптик типа как для junit набросать? А к базе данных могу подключиться? jdbc-драйвера он понимает? Нет? а odbc?) Какие средства для управления GUI есть? я могу его интегрировать с Qt? нет? а какие средства есть для воддержки веб-интерфейса? Поддержка вебсокетов есть?

    Эти, и ещё полсотни других влпросов я могу задать, и не остановиться, потому, что есть еще много за этой полсотней…

    Не должен я учить го. Не вижу я в этой статье, чем го отличается от мегасотен других «откровений». Извините.

    Зачем мне писать что то серьезное на го, если никто не гарантирует, что завтра они не выкинут такой же финт как руби? или как питон не выпустят новую версию, на которой старый код не работает?

    А если не серьезное — то что тогда писать? как этот язык поможет улучшить жизнь моему бизнес-заказчику? какие проблемы я могу на нем решать? плевать на синтаксис ( хотя, нет, не плевать — за отступы-табы-проблемы в питоне надо «бить в голову с ноги»)))))(шутка)) но как этот язык облегчит мне жизнь?
    • 0
      Простите, пропустил, с просонок ту часть, где говорится по синтаксис в части обратной совместимости.
      Обратная совместимость не только стабильностью синтаксиса гарантируется. В джаве вон синтаксис меняется, но обратная 100% совсестимость остается. То, что гугль заморозил синтаксис, это может быть и хорошо, но что с базовыми библиотеками? Или будет как в си? (через 5 лет, на другой платформе, теоретически, собрать софтину можно, но вот половины библиотек уже нет или они просто не перенесены на эту платформу? да и разрядность уже поменялась, потому вылазят нулл-поинеры да сег-фолты?)

      Что у языка с кроссплатформенностью?

      И повторюсь: не увидел, даже после перепросмотра статьи производственных задач, которые решаеются языком у тех или иных вендоров! Или вы как «свидетели руби» — обосновывают выбор руби для сложного «иниерпрайз» проекта с ЖЦ длительностью лет 10 тем, что «там-то оно используется» — а когда выясняешь как именно используется — выясняется что там 5-и строчники-скриптики для тестирования оборудования на нем пишут?)))
      • –2
        Что значит «Что у языка с кроссплатформенностью?»

        Компилите исходник в нужную платформу: о)
        Странный вопрос канеш: о))) Не поленитесь потратить десять минут на Го ЧаВо.
        • +5
          У руби тоже типа с кроссплатформенностью все хорошо.
          На бумаге. На словах.
          Но различные реализации интерпретаторов руби, под разные платформы, в разных средах, на практике оказываются малосовместимы друг с другом, или ведут себя по разному (код ведет себя по разному) (тут я сошлюсь на мнение знакомого рубиста. бывшего рубиста.).

          И у с/с++ тоже с кроссплатформенностью все хорошо. Ну как хорошо — только анси-си в примитивном виде можно переести между платформами. Но это не точно. Не факт, что после сборки взлетит (банально, int у всех разной длины.).

          Самый яркий пример красот кросскомпиляции C++ кода — необходимость фазы метакомпиляции в Qt, когда универсальный кроссплатформенный Qt/C++ превращается в код код конкретный компилятор. мол в линуксе — gcc, но код, который gcc проглотит, не проглотит майкросовтовская вижуал студия (ну не понмает она шаблонные классы — generic, и это в 21м веке, году 2010 от Рождества Христова....) и тд. и тп.

          Потому и спрашиваю — как в гоу с кроссплатформенностью на самом деле. Хочу ответ услышать с деталями.
          * Как обеспечивается кроссплатформенность. Как решены проблемы присущие С/С++ коду при сборке на разных системах?
          * Eсть ли (как у джавы, снова) процедура сертификации компилятора/интерпретатора на соответствие стандарту? (ибо как вы собираетесь кроссплатформенность соблюдать без наличия четкого стандарта).
          * Сам стандарт на язык вообще есть и в каком виде? или «оно как в питоне» — это некая малоформального вида бумага, поддерживаемая автором и сообществом?(поправьте если ошибаюсь).

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

          Ибо кроме вас есть еще руби, питон, раст, хаскель, свифт, сишарп, ди, 1с,… и каждый кричит — все просто, все на поверхности, вот почитай фак/идеологию/роадмап/вижен/идею… да вы что, все, смеетесь?)))

          Вы эксперт — вы и ответьте, пожалуйста на вопросы. Со ссылками. Заранее спасибо.
    • –5

      Судя по вопросам, которые вы задали, как только вы получите на них ответы, следующий проект вы будете писать на Go :)

      • +2

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


        Рубисты/питонисты говорили точно так. Но нет, подташнивает. А ещё, все знают об "успехах" рубистов на проекте в росреестре. Сданый вовремя проект, довольный заказчик, коммерческий успех компании подрядчика, безоблачные перспективы команды проекта… ага...


        Следующие свои проекты, особенно после прочтения статьи "50 оттенков го", я буду писать на java. Как и последние несколько лет.

        • +1

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


          На вопросы себя тут не утруждаю отвечать, поскольку


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

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


          Но раз подташнивает, то пишите на Java, конечно, как и последние несколько лет, никто ж не заставляет :)

          • +5
            Пока, список моих потребностей, в части поддержки тех-же wsdl, xsd, xml, orm на уровне, на котором мне это требуется что бы решать быстро и легко практические задачи — и попытка прояснить а как же дела с этим в гоу — говорит что дела у гоу с этим «никак».

            Как вы предлагаете мне приятно удивиться?

            Вы говорите ледит на поверхности? на поверхности вон по wsdl например — лежит пакет goWsdl (спасибо камраду за ссылку). но из описания пакета, я понял, что в сравнении с тем, что умеет в этой части джава — goWsdl это дешевая студенческая поделка. Где генерация wsdl, где xsd 1.1, где сериализация и десериализация в код через аннотации?

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

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

            парой пос ов пиже, я описал вполне конкретные вопросы и ситуации про вебсервисы, wsdl и soap. у вас есть что ответить? и да, ответ я много раз отвечал — тоже гнилой ответ. отвечали — дайте ссылку, сделайте фак и ссылайтесь на него. но не отсылайте в никуда)
            • –1

              Вот заладили вы со своим WSDL. На поверхности лежат ответы на вопросы про обратную совместимость, кросскомпиляцию, возможность использования .so и так далее. Я понимаю, что у вас нет времени открыть Golang FAQ и получить более, чем исчерпывающие ответы на эти вопросы — оно занято написанием длинных комментариев.


              Отвечая про WSDL — приятно был удивлён, что оно ещё не умерло и кем-то используется, хехе — всё на что есть спрос в современной серверной разработке, в Go реализовано — коммьюнити то большое, и, в основном, очень технически сильное. То на что спрос особый — вообще в стандартной библиотеке.


              Извините, не хочу я тратить время на изучение очередного изделия.

              Да мне какое дело, вот прицепились ) Я всего лишь обратил внимание на то, что ваши вопросы намекают на то, что ответами (которые есть в FAQ) вы будете удовлетворены.

              • +2
                про WSDL — приятно был удивлён, что оно ещё не умерло и кем-то используется, хехе

                Это говорит лишь об одном — определенной (узкой) направленности вашей работы. Попросту говоря, soap — это весь ентерпрайз. SAP какой-нибудь. А еще например Sharepoint. То что вы с этим не работаете — ни разу не означает, что этого нет в природе.


                Кстати, у Go и с JSON тоже все не очень хорошо. По сравнению скажем с Groovy — так вообще не впечатляет. Та же клиентская часть докера — так это ужас-ужас какой-то (там собственно внутри же REST, поэтому оно все из такого кода состоит). Поэтому мне лично заявления "ну так докер же на Go" — они довольно-таки смешные. Читается этот код докера ужасно, и писать кучу такого же своего — никакого желания не возникает.

      • +4
        Вот интересно. Статья у нас про то, что нам всем надо изучить Go (с некоторыми странно выглядящими попытками это аргументировать).
        Пришел человек, задал некоторые вопросы, много вопросов задал, интересуют его ответы от кого-нибудь из Go-сообщества.
        Пришел представитель сообщества и ответил только одно: «следующий проект вы будете писать на Go». Wat? Это всё? Даже секты как-то больше заморачиваются с объяснениями того, зачем все должны в них вступать :)
        • –1
          и ответил только одно: «следующий проект вы будете писать на Go»
          Это не то что я ответил, но вы можете трактовать, как вам удобно :)
        • –1
          Пришел представитель сообщества и ответил только одно: «следующий проект вы будете писать на Go».

          Очень простой и правильный встречный вопрос, позволяющий ответить "теперь точно нет" и не терять время.

    • 0
      Удобнее всего на го писать небольшие веб-приложения, в которых важна производительность или большое количество одновременных соединений. Это легкое нечто, которое позволяет на коленке набросать микросервис или утилиту. Компиляция очень быстрая, а полностью статический бинарник упрощает деплой.
      Рантайм у го довольно легковесный, так что можно писать и для слабых встраиваемых систем.

      Неполный список прикладных пакетов
      Драйвера баз данных из этого списка

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

      Для бизнеса го выгоден из-за простоты и единообразия. Легко обучить разработчиков, которые писали на других языках и легко разбирать код из-за автоформатирования и простого синтаксиса. Насчет отступов и вообще форматирования кода, кстати, они расставляются автоматически, а соответственно, единообразно у всех. gofmt — это стандарт де-факто.

      Го уже используется столькими проектами, что Гугл вряд ли просто так его выкинет.
      • 0

        А как он подходит к сложным бизнес-процессам? Тот же веб-сервис, но со сложной логикой, а не просто CRUD-морда к базе данных. Пока у меня о Go представление как о гибриде C как системного инструмента и чего-то типа NodeJS как инструмента создания мостов и фасадов к СУБД, сложным SOAP-сервисам и т. п.

        • –1
          Бизнес логика будет многословнее, чем в более сложных языках, но проблем с её написанием я не вижу. Особенно удобно то, что пишется все просто как последовательный код, без коллбэков и прочей лапши с промисами.
          • 0
            Особенно удобно то, что пишется все просто как последовательный код, без коллбэков и прочей лапши с промисами.

            Хе-хе, а история-то идет по спирали, ага.
    • 0
      Go не для GUI. На нем backend высоконагруженный хорошо программировать, микросервисы всякие. К базам подключаться умеет, WSDL — сторонние библиотеки есть. Docker и Kubernetes на нем написаны, части высоконагруженного бекэнда DropBox'a, Juju, Heroku.
  • 0
    Тоже был ярым противником Go пока не запилил реальный проект на нем. Вся его красота в наивной простоте и в тоже время в мощности и возможностях как у взрослых. Можно через год возвращаться к проекту (проверенно) и продолжать его допиливать без потери времени на разборки что да как, особенно при хорошей структуре проекта. Исходники стандартной библиотеки тоже читаются на ура — нет желания по-быстрее их закрыть как у других языках.

    Go приучает к простому и понятному коду, хоть и чуть избыточному, вместо писанины «смотри как я могу». Невольно эту практику переносишь в java/C#.

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

      Попробуйте D. Он объективно получше Go будет.

  • +1
    ЯП — средство разработки. Никто же не задумывается, почему отверток разных видов так много.
    ЯП в достатке — выбирай, пробуй, тестируй, работай, хвали, ругай, помогай в развитии. Адекватными при сравнении считаются аналитические заключения о соответствии ЯП целям поставленной задачи, остальное вода в ступе.
    Некоторых прям неадекватно распирает от «экспертных» оценок.
    • +1

      Вот именно о задачах, которым соответствует описываемый язык — в статье нет ни слова. Не о чем делать аналитические заключения. Статья — реклама, рассчитанная на восторженного наивного, не отягощенного практикой новичка. Потому и "срач". Имхо.

      • 0
        Просто все знают, что Go — для веб-сервисов
        • +1

          А мне казалось, что для быстрой (псевдо)параллельной работы большого числа (псевдо)потоков. С требованиями к веб-сервисам это пересекается, но не более.

        • +2
          а что именно под «вебсервисами» вы понимаете? для меня вебсервисы описываются в .wsdl, работаю я с ними с использованием soap, а http — это только один из транспортов, причем не самый идеальный.
          Это вебсервисы, потому что это они описываются в спецификациях с соответствующими названиями.
          Если открыть википедию, то там как раз о wsdl/soap/xml и говорится.

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

          для каких именно «вебсервисов» предназначен этот язык?
          • 0
            Задать абстрактный вопрос, сославшись на абстрактный стандарт (даже не стандарт, а рекомендацию)?

            Получите абстрактный ответ. Да, Go поддерживает все эти буквы библиотеками + WDSL.

            Собственно, он больше толком ничего и не поддерживает, как я посмотрю (но я тоже не гоадепт — web не моя экосистема).
            • +3
              wsdl значит поддерживает?

              а как именно «поддерживает»? вы эту «поддержку» с джавовским стеком сравнивали?

              давайте по порядку: первое — кодогенератор по ссылке — это клиентская часть или серверная?

              если серверная, то для какой серверной платформы или какого сервера приложений ?(такое понятие в гоу есть?)

              я к чему — управление ресурсами в этом сервере есть? пул потоков, скажем? А то, знаете, видели мы тут недавеча «супер сервер». на руби писанный. Когда ему 5 потоков запросов в параллель пускаешь… он… падает. Понимаете, Карл,… падает!!! Не выдает 5хх-й код, не закрывает соединение с месседжем типа — превышены ресурсы, и продолжает работать, как это делает практически любой сервер приложений для всеми ненавидимой джавы… а просто падает.

              Как в гоу решается вопрос управления русурсом подключений? Так же, как в руби на том сервере?)))

              Ладно. Следующий вопрос: где генератор wsdl по коду? обратный, так сказать, генератор? я могу написать структуры, массивы, определить их обязательность или не очень, функции… а она мне — по моему коду — и wsdl, и опубликованный сервис на сервере и сразу подключайся-не-хочу… умеет? почему джава и сишарп (мать его))) — умеют, а гоу… для вебсервисов ориентированный, все поддерживающий — … умеет?

              Теперь следующий вопрос: xml schema 1.1 — где? А то нам тут АТ-К прислали файлики как-то раз… так мы их едва открыли… кстати, не wsdl прислали, а xsd.

              xds..., да, а что у нас с xsd? Что с валидацией xml, на соответствие xsd?

              Что, с сериализацией/десериализацией xml? Есть в «красивом синтаксисе гоу» аналог джавовских аннотаций? Есть возможность просто «промаркировать» поля структуры xpath-ами — и отдать структуру в некую «фабрику», а на выходе — получить xml-заданной структуры? ну не охота мне руками раскладывать поля по элементам xml…

              Что с ОРМ? Могу я в «аннотациях структур» гоу описать какое поле в какой таблице в какой колонке лежать? И что бы была просто фабрика, которой, подсовываешь струтуры, а она сама тебе и базу данных перестроит, и сохранение-восстановление сделает? и что бы мне — только одну строчку над каждым полем прямо в классе прописать. можно так в гоу? или только gowsdl пакет, который, судя по всему, упадет если ему на вход подать не корректную структуру?

              и я ещё много могу рассказать чего у вас в вашем распрекрасном гоу нету, что есть в ненавидимой хопстотой «джаве-йе-йе».

              просто я к чему? гоу, насколько я могу сейчас судить, находится на уровне технологичности джавы 1 или 2. аннотации, вон, и «рефлекшен» в какой джаве появиоись? в третьей кажется, поправьте? какой это год? начало 2000-х? вот и гоу сейчас — примерно на этом уровне готовности для «промышленной разработки». Играйтесь конечно, но прошу, давайте не портить пространство воплями типа «большой код», все умеет, вебсервисы… вы видели «большой код»? сколько читающих этот пост хотя бы знает о «монструозности» стека приложений «ibm websphere»? а «рейшионал»? вы пытались писать систему которая должна хранить ваши данные 75 лет после вашей смерти? Эта «простая задача» сейчас решается в пенсионке. На джаве и майфреймах ibm. Ну смешно же выглядят сказки про «большой код» на гоу, на фоне достаточно примитивного набора возможностей языка. Ну серьезно, народ)))) Не ведитесь.

              Да, в нем есть, вероятно прикольные фичи типа горутин (так и не понял из статьи, что эта за фигня, кстати) — но это не делает картины на фоне провала по всем остальным фронтам. Не может сделать, извините.

              В пхп вон тоже поддержка wsdl есть. и причем на уровне более серьезном, чем это единственное поделие «gowsdl»… только что с этого?..
              • –3
                Ну если вы вообще не в курсе, что такое Го, то к чему эти вопросы?: о)
                • +1
                  К тому, что интерес к языку либо академический, либо практический.

                  Посмаковать синтаксический сахар на досуге — это прекрасно.

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

                  В частности, к прмеру — была заявлена поддержка вебсервисов.
                  Я начинаю «разбираться» — описываю кейсы (рабочие ситуации) и проблемы с которыми мы столкнулись в жизни, с примерами «провала кейса» на «других модных языках».

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

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

                  Хотя, остается шанс, что я не прав, и я буду приятно удивлен.

                  Увы, но такое впечатление, что очень многие идеологи новомодных языков и их последователи как правило мало подкованы в технической части и практике применения IT в жизни. Для них сложный код — это сложная курсовая. для них важнее запилит красивую модную фичу в язык, а не обеспечить 100% ьбратную совместимость. Их понимание того, что такое технология и как она применяется — толькь пара лежащих на поверхности случаев, причем о проверке валидности структур и об обработке ошибок и исключерий — они и не слышали, или даже хуже — сознательно выпилили это из языка.

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

                  Другая причина почему я это все говорю — надежда, что сегодняшний «свидетель гоу/руби/питона/хацкеля», погрущившись в детали технической части и сравнительный анализ возможностей языков — начнет изучать нечто более серьезное, и будет смотреть на вещи более критично. Для этого, имзо, достаточно просто ответить на вопросы которые я задаю. Только честно. Хотя бы самому себе )))

                  Адекватных инженеров очень мало.

                  Когда-то, мне перла для веб — вполне хватало. Для дипломной работы. Но потом был пхп, дельфи, си++, джава… Задали бы мне пяток таких вопросов в свое время…

                  • –2
                    Например «пул потоков».
                    Я не вижу, какой смысл в пуле потоков в Го, так как есть горутины. В промышленных приложениях работают сотни тысяч горутин.
                    Или у вас задача мапить потоки вашего приложения на потоки ОС и поэтому вам нужен собственный супервизор потоков?

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

                    • +4
                      Да не вопрос, нет пула потоков — опишите как управляются горутины, как они исчерпывают ресурсы системы (и какие есть ресурсы вообще? память, процессорное время, потоки, ещё что то?) и как их лимитировать на сервере гоу, как не дать гоу серверу банально подохнуть с серфолтом (или аакой тип ошибок у вас там в гоу?) под потоком запросов?

                      Давайте по сути обсуждать, а не по форме?) я знаю что вам кажется все это чужеродным в отношении гоу ) да, я не понмаю «этом вашем гоу» — и я задаю вопросы в терминах, которые сейчас применяются в промышленных технологиях. В общепринятых тезнологиях. а Термин горутины — это специфиака. «Ваша специфика». Проведите параллели с промышленными терминами и объясните на пал цах как не дать гоу серверу вывалиться в нерабочее состояние при попытке перерасхода выделенных ресурсов? и как вообще ему выделять ресурсы?)
                    • 0
                      Функционал пула потоков предоставляется, например, WinAPI, тут вообще языковые абстракции не нужны.
                      • 0
                        Видимо речь шла о пуле воркеров, которых нужно натравить на входную очередь.
                        Чуть выше я привёл ссылку на статью, где такой пул воркеров реализован.
              • +5
                а будущим авторам статей (самим авторам и переводчикам тоже) типа «про прекрасное гоу»: предлагаю: вместо заявлений, типа вот гоу такой хороший — описали бы ниши, и как ниже хорошо в одном посте сказали — кейсы применения описали с конкретными параметрами, и задачами, вместо того, что бы разводить «какой то рекламный буллшит».

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

                Так вот и опишите эти ниши. Конкретно. С техническии деталями и подробностями.
                Так вы завоюете больше последователей. Мне вот все равно на чем писать на проекте — надо было -мы на сишарпе «прокси» с интерфейсом на вебсервисах для доступа с андроида к доксвижену сделали. Хотя сам я джаву люблю — но надо — ращобрались и сделали.) есть на Qt проекты. Будем понимать нишу гоу — почему бы на гоу не продать пару проектов — но нужны конкретные примеры с тех подробностями. Я вот не буду разбираться в интимных откровениях и проблемах недо-языков за свой счет — мне бы сделать бизнес-задачу, что бы клиент был доволен))) А гоу пока не ложится ну никак супротив джавы, имхо. и не будет ложиться, пока будут дешевые переводные статьия с рекламным буллшитом, вместо сухих технических данных и статистики с плюсами и минусами. когда мы инструменты для проекта выбираем — надо профиль понимать, и риски минимизировать.

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

                • 0
                  Так куча же фактов прям в етом хабе: о)
          • 0
            Вебсервис — это обычно нечто, отвечающее по протоколу http.
            Внутри http оно может класть html, json или всякие другие данные, хоть вебсокет. Граница довольно размытая, на самом деле. Думаю, имеется ввиду, что приложение является при этом частью системы сайта.
  • 0
    Интересно было узнать, что у Erlang — выразительный код.
    Есть у меня друг — не программист. И я решил ради эксперимента, научить его программировать, причем сразу на Erlang'e. И вот глядя на то, как у него ничего не получается, прихожу к выводу, что да, синтаксис Erlang прост и логичен. То же самое я сейчас вижу глазами Elixir разработчика. Но Erlang сложен из за того, что надо понять, как правильно его применять, как решать на нем задачи, типичные приемы, идеологии ОТП.
    • +3

      Ну вообще, по сравнению с С-подобными языками код Erlang ОЧЕНЬ выразительный в смысле "количества смысла" на символ кода. Pattern matching, даже обычный, не binary, решает.

      • 0
        Я немножко перефразирую: приятно было услышать от специалистов на Go, что у Erlang выразительный код )
        А то обычно нападки. Мир, дружба )
    • 0

      Ну так и у пролога код выразительный :^)

  • 0

    А как с отладкой горутин? Какие отладчики существуют, что бы можно было пощёлкать контексты, посмотреть где что и в каком состоянии? А то мне в Asio понравилось писать с короутинами, но зело сложно отлаживаться с ткущим инструментарием.

  • 0
    Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц. Таким образом, около десятилетия нет особого прогресса чистой вычислительной мощности.

    Только производительность одного потока выросла в 3 раза.
  • +5
    Perl отнесли к самым легкочитаемым языкам! Perl! Эту оценку инопланетянам доверили что ли?
  • 0
    Есть ли для Go удобоваримая IDE по типу Visual Studio?
  • +3
    Статья — какой-то рекламный буллшит, местами с перевиранием и притягиванием за уши удобных примеров.
    Лучше бы вместо отого описали реальные кейсы, в которых Go применять действительно удобно.
    • +2
      На Го удобно писать всё, что не требует ГУЯ и риалтайма. Хотя ГУЙ можно отдать фронтенду, включив в прогу на Го вебсервер. А с реалтаймом типа онлайновых игр придётся разбить сервер на микросервисы, чтобы не притормаживать при сборке мусора в монолитном сервере. Хотя вон Juju вроде монолит на Го на полмиллиона строк, ну так жужа и не риалтаймовая.
      Вобщем Го — красивенький, и на нём уже много критичных серверных приложений написано.
      • 0

        Сложную транзакционную бизнес-логику систем класса ERP, CRM и т. д. удобно писать? Задержки на секунды не критичны, если надежно обеспечена блокировка при старте транзакции, но простая команда типа signContract(contractId) может вызывать создание и изменение сотен записей в СУБД и генерацию десятка событий в MQ/шину.

        • 0
          Насчёт бизнес-логики не скажу, потому что не имел опыта. А вот насчёт как принять миллионы событий и обработать их и разослать — в этом Го — вентилятор. Мне кажется, что те куски приложений, которые конвейеризуются — самое то для применения Го.
          • 0

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

            • –1
              Ключевое слово «сложная логика»?: о)
              Ну не замечал сложностей в Го для такой логики. а мож не сталкивался: о)
              Но если нужно сожрать, переварить и выдать мегаллионы байт, то тут Го канеш безусловный фаворит.
              • +1
                Ключевое слово «сложная логика»

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

                вопрос с интерпрайзом не в мегатоннах байт и простых запросов, а в сложных и часто постоянно плавающих бизнес правилах.

                всем плева-ть на миллион запросов в секунду. совершенно.

                важно, что бы хотя бы один отработал за преемлемое время, сопоставимое хотя бы с часом.

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

                особенно после того, как совещанме мэра начинается _без_ основной бумажки об исполнительской дисциплине. потому что язык, способный перелапачивать мегатонны байт в секунду, и миллины рест запросов — не смог за 6 часов построить один-единственный отчет, на горизонте событий 1 неделя, попоручениямодного человека
                • 0
                  А причём тут Го, если ваши спецы не могут собрать отчёт за шесть часов?