Go глазами java программиста

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

    Принципы go


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

    Принцип простоты звучит так:
    Если без чего-то можно обойтись, без этого нужно обойтись.

    Принцип продуктивности:
    Самое ценное — это время, затрачиваемое разработчиком. Его надо минимизировать всеми доступными способами.

    Проиллюстрирую принцип простоты:
    В go очень мало языковых конструкций. Например, только один цикл. Go можно выучить за два вечера.
    В go отказались от динамической загрузки библиотек — результат компиляции один большой исполняемый файл
    В go нет warning-ов при компиляции. Любая некорректность или «многословие» — это ошибка компиляции.
    В go встроен автоформат кода на уровне самого языка. Есть только один каноничный вид кода на go.

    Теперь несколько примеров продуктивности:
    Код на go на 20-30 процентов короче аналогичного на яве (там просто не лишних слов, например, нет точки с запятой в конце каждого предложения, нет круглых скобок в операторах условия или цикла etc).
    В go очень быстрый компилятор (несколько секунд на компиляцию большого проекта).

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

    Инструменты повышения производительности


    Профилировщики


    начну с небольшого отступления о том как я, программист java, пришел к использованию go.
    Я делал игровой проект — многопользовательский космический шутер.
    Изначально я написал серверную часть на java. Она работала.
    Но очень быстро все уперлось в производительность.
    На одном сервере можно было запустить не более 300 клиентов.
    Это слишком мало, чтобы игра стала рентабельной.

    Что я мог сделать с этим, как программист java?
    На самом деле немногое:

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

    2) Погрузиться в изучение альтернативных серверных библиотек, пробовать разные варианты. Это тоже не дает никаких гарантий — возможно проблемы в моём собственном коде, или вообще в самом языке java.

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

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

    В моем проекте сервер, переписанный на go изначально «тянул» только 20 клиентов (много хуже, чем на яве). После работы с профилировщиками эта цифра выросла до 2500.

    Race detector


    Другая головная боль всех писателей многопоточных приложений — race conditions.
    Это такие трудноуловимые баги, которые возникают только если звезды сошлись определенным образом. То есть, если потоки запустились в одном порядке, баг есть, если в другом — нет. А порядок непредсказуем.
    В go для решения этой проблемы есть стандартный инструмент — race detector. Если его включить, программа на go будет писать в лог обо всех небезопасных обращениях к общей памяти из разных потоков.
    Используя race detector можно быстро, целенаправленно найти и устранить все проблемные места.

    Интересные конструкции


    Я не имею целью научить программировать на go и не стану разбирать все его конструкции. Хочу остановиться только на трех, наиболее интересных. Все они описывают парадигмы, которых в яве в чистом виде нет. И эти парадигмы очень полезны.

    Это интерфейсы, горутины и каналы.

    Интерфейсы


    Интерфейс в go похож на интерфейс в яве или c#. Это — набор сигнатур методов, но без реализаций.
    Основная разница в том, что go не требует объявлять, что какая-то сущность имплементирует какой-то интерфейс.
    Достаточно, чтобы у сущности просто были все нужные методы.
    Что это даёт? Decoupling.
    Вы можете взять чужую библиотеку. Найти там сущность с каким-то набором методов, создать у себя интерфейс с тем же набором и использовать эту сущность, как этот интерфейс. Вам не надо изменять чужой код, не надо завязывать свой код на чужие сущности и не надо писать адаптеров, которые являются классическим boilerplate кодом. Еще одна иллюстрация принципа продуктивности.

    Горутины


    Сначала для многозадачных приложений в языках программирования были придуманы процессы. Они были тяжеловесными, имели собственное адресное пространство и быстро «жрали» ресурсы системы. Потом появились треды (или нитки). Они были гораздо легче и работали в одном адресном пространстве. Если процессов обычно запускали единицы или десятки, то тредов можно было иметь уже сотни. Однако при неаккуратном использовании и они могли отнять все ресурсы системы. Каждый тред всё-таки занимал какие-то ресурсы, даже если был заблокирован.
    Чтобы ограничить число тредов, начали использовать тред пулы.

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

    Каналы


    Каналы являются расово правильным средством коммуникаций между горутинами.
    В go есть важное правило:

    Don't communicate by shared state. Share state by communication.

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

    Канал в go это очередь (буфер) в один конец которого можно писать, а из другого читать.
    При этом, горутина блокируется при попытке писать в переполненный канал или читать из пустого канала.

    Но самое интересное — go имеет конструкцию для одновременного чтения из нескольких каналов.
    Горутина может перечислить несколько каналов, на которых она будет сидеть и ждать появления сообщения в одном из них. Получив это сообщение, горутина разблокируется, обрабатывает его и (обычно) снова ждет следующего сообщения.
    Так, например, в чат сервере горутина может ждать как сообщение от пользователя так и сигнала о выходе из чата. Одновременно.

    Управление зависимостями


    Такие инструменты управления зависимостями, как maven или gradle сегодня существуют для всех серьезных языков.
    В go пошли дальше и сделали поддержку управления зависимостями на уровне самого языка.
    При импорте пакета (конструкцией, аналогичной import в яве) можно указать как локальное имя, так и адрес пакета в любой современной системе контроля версий (например, в git).

    Например, «github.com/gorilla/websocket»

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

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

    Для решения этой проблемы используются внешние инструменты — менеджеры пакетов.
    Один из лучших на сегодняшний день — glide.
    В основе glide – два действия:
    1) Найти все зависимости проекта, и записать их в файл
    2) Cкачать эти зависимости

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

    В качестве идентификатора версии в GIT используется идентификатор коммита (в других системах контроля версий используются специфичные для них идентификаторы).

    Слабые стороны go


    Любой принцип имеет не только сильные стороны, но и слабые.
    В go, на мой взгляд, есть одна плохая и одна ужасная вещь, которые проистекают из принципа простоты.
    Плохая — это отсутствие generic-ов. Ужасная — обработка ошибок путем проверки возвращаемого функцией кода.

    Без generic-ов приходится отказываться от строгой типизации.
    А обработка ошибок приводит к большому количеству однотипного кода. Который, к тому же, можно вовсе забыть написать и оставить ошибку необработанной.

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

    Выводы


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

    Стоит ли использовать go для решения определенных задач? Однозначно, стоит.

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

    Какой язык лучше учить новичку — go или яву? Однозначного ответа нет, но со временем аргументов в пользу go будет все больше.

    Возраст языка играет роль. Более старый язык обрастает «историческими» вещами. Что-то было добавлено давно, теперь никому не нужно, но выбросить нельзя, поскольку нарушится обратная совместимость.
    Какие-то конструкции языка или стандартных библиотек, ранее актуальные, сейчас выглядят неуместно, кажется, логичнее делать эти невостребованные вещи вне стандарта языка.
    Для каких-то стандартных проблем накопилось множество альтернативных решений разного качества. Для новичка всё это — большое количество бесполезных но необходимых знаний в стиле: «Здесь нужно быть особенно осторожным. Здесь у нас ЛУЖА».

    Go создавался гораздо позже и на сегодня в нем присутствует все, что востребовано сейчас и ничего лишнего.
    Share post

    Similar posts

    Comments 277

      +1
      Никогда не писал на яве, но расписано душевно. Спасибо!
      А обработка ошибок приводит к большому количеству однотипного кода. Который, к тому же, можно вовсе забыть написать и оставить ошибку необработанной.

      Да, жаль что непроверенная ошибка это не ошибка компиляции. А способ обработки мне кажется это на любителя, многим наоборот нравится после исключений.
        +2
        В поняшке на стадии компиляции :)
        • UFO just landed and posted this here
            0
            До практики еще потребуется время, поэтому пока для изучения.
          +2
          Да, жаль что непроверенная ошибка это не ошибка компиляции.

          https://github.com/kisielk/errcheck

            0
            Очень интересный инструмент. Вы его пробовали? Как впечатление?
              0

              Успользую уже очень давно. Работает.

                0
                Спасибо. Буду пробовать.
          +20

          В java тоже есть интрумент для анализа производительности и поиска узких мест — Java Mission Control.
          Он идет в составе JVM.
          Причем он при его использовании производительность практически не падает (от 1 до 5%).


          Включается несколькими параметрами:


          -Dcom.sun.management.jmxremote.rmi.port=7091
          -Dcom.sun.management.jmxremote.port=7091
          -Dcom.sun.management.jmxremote.authenticate=false 
          -Dcom.sun.management.jmxremote.ssl=false
          -XX:+UnlockCommercialFeatures 
          -XX:+FlightRecorder

          Дальше можно зайти на сервер по ssh с перенаправлением портов:


          ssh user@host -L7091:127.0.0.1:7091

          Запускаем jmc и подключаемся к 127.0.0.1:7091


          Вместо goroutines можно использовать fibers http://docs.paralleluniverse.co/quasar/

            –2
            Спасибо. Не знал про Java Mission Control. Обязательно попробую.
            Что касается quasar, я сравнивал сами языки, а не экосистему.
              +27

              Без обид, но факт что вы не знаете про инструменты анализа производительности JVM, и как видно не удосужились поискать о них информацию говорит не в пользу вашего профессионализма. Но вы все же беретесь сравнивать платформы, а ведь ваш пост будут читать и за счёт авторетета хабра будут рассматривать ваше мнение так же как авторитетное.
              По мимо этого. Я вижу что написание кода на go в лоб, без профилирования не дало высоких показателей(50 человек онлайн) и только после устранения узких мест был рост до 2500. Возможно на java результат будет не хуже?
              Вы говорите об эффективном параллельной обработке данных на go за счёт мощных встроенных средств. Но JVM в своём арсенале уже содержит множество библиотек и Фреймворков, таких как приведено выше и даже более распространённых и проверенных, как Akka. Акторная модель скорее всего решит ваши проблемы многопоточности, не заставляя радикально менять платформу, а такой сервер как netty или модуль akkaHttp проблемы с масштабированием кол-ва соединений.

                –17
                Как раз про это я и написал.
                Чтобы сделать это на java мне надо было:

                1) Удосужиться поискать информацию (VisualVM? YourKit? Java Mission Control, который был добавлен, начиная с java 7 и, как тут заметили, платный).
                2) Попробовать каждый из них.
                Вы видели, например, VisualVM? По сравнению с инструментами, предлагаемыми go, это — прошлый век.
                3) Далее, я бы обнаружил, что проблемы есть не только в моём коде, но и в серверной библиотеке.
                Что взять? Jetty, Netty, а может VertX или Play?
                Опять масса проб и ошибок.

                Мысль не в том, что на java нельзя сделать сервер быстрее.
                Мысль в том, что на go для этого потребуется намного меньше времени.
                  +23
                  Ваши пункты намекают, что ваши знания java возможно даже хуже чем знания go.
                    +12
                    Выглядит как «я не хочу разбираться и выбирать необходимый инструмент для Java проекта, поэтому возьму мейнстримный Go».
                      –11
                      Я хотел сравнить трудозатраты на решение одной и той же задачи в java и в go.
                      В go они существенно меньше для этой задачи.
                        +9
                        Когда в Go дело доходит до использования сторонних библиотек, то ситуация становится гораздо печальнее, чем в Java. Куча библиотек, которые делают примерно одно и то же, приходится реально вчитываться в код каждой, чтобы сделать адекватный выбор.
                        Да что там библиотеки… Попробуйте для начала веб-фреймфорк выбрать: awesome-go#web-frameworks
                          –4
                          Iris же. Можно делать очень быстрые микросервисы, но можно и подобие монструозного django.
                            +1
                            Фраза «эта прекрасная машина умеет варить суп, жарить мясо и печь пироги» в 102% случаев означает, что все вышеперечисленное эта машина делает отвратительно.
                              –1
                              <sarcasm>Если только под машиной не подразумевается жена</sarcasm>.
                        +5
                        Что взять? Jetty, Netty, а может VertX или Play?

                        Как можно всё это свалить в одну кучу и при этом делать вид что разбираетесь в Java?


                        • Jetty — эффективный контейнер сервлетов. Да у него довольно эффективный IO, но его основное назначение это именно контейнер сервлетов
                        • Netty — фреймворк для эффективного сетевого IO.
                        • VertX — фреймворк для написания эффективных сетевых приложений. Собственно для эффективного IO использует Netty
                        • Play — полноценный веб-фреймворк, которому для работы нужен контейнер сервлетов

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

                    +3

                    Стоит добавить, что для использования JMC и Flight Recorder на приложении в production'е необходимо иметь специальную лицензию от Oracle (Java SE Advanced/Java SE Suite), как и для остальных Commercial Features. Насколько я понял из BCLA, использоваться для разработки её вполне можно.

                      0

                      Я удивлён что вы посылаете человека в достаточно сложный и коммерческий (начиная с 11й бесплатный) jmc, а не в async-profiler — простой и бесплатный.

                      +15
                      В go очень мало языковых конструкций. Например, только один цикл. Go можно выучить за два вечера.

                      Это скорее не простота, а минималистичность. Мне нравится минималистичность, но с ней важно не переборщить (крайний пример — брейнфак. хотя нет, крайний — boolfuck). С учетом повсеместного интернета, когда достачно помнить, что что-то сделать можно, а гугл подскажет как — переборщить очень просто.


                      В go отказались от динамической загрузки библиотек — результат компиляции один большой исполняемый файл

                      Какие у этого плюсы?


                      В go нет warning-ов при компиляции. Любая некорректность или «многословие» — это ошибка компиляции.

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


                      В go встроен автоформат кода на уровне самого языка. Есть только один каноничный вид кода на go

                      И не дай бог мне его неудобно читать — сам виноват.


                      Код на go на 20-30 процентов короче аналогичного на яве (там просто не лишних слов, например, нет точки с запятой в конце каждого предложения, нет круглых скобок в операторах условия или цикла etc)

                      У меня такое ощущение, что где-то в мире сидят программисты, чье единственно ограничение — скорость набора, и вместо книг по программированию они ходят на курсы по скоростной печати. Остальные разницы в 20% не почувствуют, и это с Java — невероятно многословным языком.


                      Короче, то ли реализация принципов сомнительная, то ли примеры.


                      P.S. Пожалуйста, давайте не будем начинать холивар. Меня интересует Go, и это неплохой язык (как и большинство остальных). К сожалению статьи о нем на Хабре зачастую неоднозначные и вызывают кучу срачей.

                        +1
                        Вы все грамотно написали, не холивара ради я лишь хочу варизить одну свою мысль. При сравнении языков программирования все величины относительны. Ничего не удастся привести к единой шкале просто потому что языки различны. Производительность? В какой момент времени, сразу после старта или после прогрева виртуальной машины? В каких условиях, под какой нагрузкой — слишком много условных переменных. Читаемость, понятность, поддерживаемость? Ну это вообще настолько субъективно, насколько возможно. Если бы это было не так, то не существовало столь большого числа языков на сегодняшний день. Кому-то нравится питон, кому-то больше по нраву руби. Кто-то вообще не считает интерпретируемые или выполняющиеся в ВМ языки настоящим языками. Да, возможно, история склонила определенные языки к определенным целям, условно, си — железо, перл — обработка текста, питон — математическое прототипирование и т.д. Но все же, популярность языка обуславливается свойствами, перпендикулярными всем вышеперечисленным. Мне кажется, что для того, чтобы прижиться, язык должен следовать тем же правилам, что и любой другой программный продукт. А для любого программного продукта в первую очередь важен маркетинг. Даже если продукт бесплатный. В первую очередь, важно, кто стоит за языком. Майкрософт, Гугл, Эппл или Гвидо. Здесь играет роль и психология, наверное. Но вообще, я хотел о другом сказать. Есть единственное исключение, позволяющее сравнить языки по-честному. И это — краткость языка. Речь, конечно, не идет об обфускации. Когда я изучил питон после джавы, я был удивлен, насколько короче можно записать то же самое. Почему это важно? Дело, разумеется, не в том, что программист упирается в скорость набора, а в том, что чем меньше связующего кода и лишних абстракций, тем яснее можно увидеть сам алгоритм, тем меньше приходиться тратить внимание на вещи, прямо не связанные с задачей. Да банально уставившись в экран кода, видишь больше, иногда в разы. Взять, например, геттеры-сеттеры явы, больная мозоль для многих и камень преткновения. Факт в том, что даже будучи автогенеренными, они создают огромное количество шума, который нужно учитывать. Или все эти public static final void… зачем они нужны? Короче говоря, для себя я решил, что краткость кода — одна из первостепенных по важности вещей.
                        • UFO just landed and posted this here
                            +1
                            единственное исключение, позволяющее сравнить языки по-честному. И это — краткость языка

                            Вот потому-то и я мечтаю изучить APL — очень красивый и ёмкий язык!
                              +3
                              Я бы сказал, что важна не краткость, а низкий уровень шума и простота восприятия.
                              Мне нравится критерий, который сформулировал Grief — язык тем лучше, чем больше смысла я вижу на одном экране.
                              При том, что код писал не я и я — не гений, а среднестатистический специалист.
                                +1
                                Так перл же тогда! На одном экране можно увидеть всю не самую простую программу! Весь её смысл! Вот только как вы её понимать-то будете после этого?
                                  +1
                                  Именно для этого я уточнил, что условеный «я» — не гений. Не пойму я её.
                                  Как не пойму, например и вот такой код на scala

                                  object IsHCons1 {
                                  
                                    type Aux[L[_], FH[_[_]], FT[_[_]], H0[_], T0[_] <: HList] = IsHCons1[L, FH, FT] { type H[t] = H0[t] ; type T[t] = T0[t] }
                                  
                                    def apply[L[_], FH[_[_]], FT[_[_]]](implicit tc: IsHCons1[L, FH, FT]): Aux[L, FH, FT, tc.H, tc.T] = tc
                                  
                                    implicit def mkIsHCons1[L[_], FH[_[_]], FT[_[_]]]: IsHCons1[L, FH, FT] = macro IsHCons1Macros.mkIsHCons1Impl[L, FH, FT]
                                  
                                  }
                                  


                                  И имено поэтому ни Perl ни Scala по данному критерию будут оценены не очень высоко.
                                    0

                                    Чтобы читать код, не надо быть гением. Надо знать язык.

                                      +1
                                      Чтобы читать такой код с большой скоростью и в промышленных объёмах, надо быть именно гением.
                                      Большинство людей тоже сможет его прочитать, но мы затратим на это слишком много усилий.
                                      Язык — прежде всего инструмент. В идеале, человек должен иметь дело исключительно со сложностью своей задачи, а не с дополнительной сложностью, привносимой языком.
                                      • UFO just landed and posted this here
                                          0
                                          Поэтому у них есть своя ниша. Для которой они — прекрасны.
                                          +2
                                          У scala есть такая проблема. Многие библиотеки, в том числе стандартная, написаны очень непросто. Это или легаси, или описания DSL, удобных для применения сторонними разработчиками. Команда EPFL над этим работает, и потихоньку улучшает ситуацию. Многие вещи переписывают с нуля. Вводят дополнительные правила компиляции не позволяющие творить жесть в коде. Радует то, что во время разработки заглядывать в подобный код приходится крайне редко. А свой код можно держать в абсолютно читаемом виде. То есть работе это не мешает.
                                        +2
                                        «Можно» не означает «Нужно обязательно»
                                        Все пользуются ножами на кухне для резки продуктов.
                                        А ими ведь можно порезать себе пальцы… но как часто реально люди это делают?
                                        Одна из прелестных и сильных сторон Scala, как раз в разделении прикладной разработки и библиотечной.
                                        Для прикладной разработки все эти навороты не нужны.
                                        Эти навороты пишут ребята «семи пядей во лбу» и они их читают в лет.
                                        Они делают библиотеки для не таких опытных разработчиков.
                                        И это очень хорошо, что профи используют хорошие навороченные перфораторы, а не зубило с молотком.
                                        В Go же все вынуждены пользоваться зубилом и молотком. Да, это проще, да, это понятнее.
                                        Но все это напоминает старый анекдот «Пилу точить некогда, пилить надо».
                                          +4
                                          В этом коде, кстати, читать вообще нечего.
                                          Это же из shapeless наверняка. И читается, при знании shapeless, без проблем.
                                          В scala (особенно в shapeless) встречается сложный для понимания код, но это не тот случай.
                                      0
                                      По компактности, с Perl вообще мало что рядом сможет стоять, но как-то на нем пишут в основном администраторы.
                                    +2
                                    Справедливости ради, с недавних пор динамическая загрузка в Go так-таки появилась. Плюс статической компоновки по умолчанию — это то, что получаются самодостаточные бинарники, которые зависят разве что от libc. На практике получается очень приятно, что можно отгрузить куда-то один файл и быть достаточно уверенным, что он не упадёт из-за неудовлетворённой зависимости.

                                    С автоформатом — да, если кто-то предпочитает другой формат, с Go получится неудобно. С другой стороны, приятие формата суть дело привычки. Вообще, в Go много крутилок и кнопочек принесли в жертву богу быстрой командной разработки — там всё сделано ради того, чтобы только что пришедший в команду джуниор или интерн начал быть эффективным на третий день вместо того чтобы неделю лупать глазами на непривычный формат кода, ещё неделю чертыхаться на отвергаемые (отформатируй согласно гайдлайнам проекта и приходи снова!) коммиты и подобные вещи. Я не берусь спорить, правильно это или нет, но определённая логика в этом есть.
                                      0
                                      К слову сказать, писать Go код можно любым удобным для себя форматированием. Главное Git-хук на go fmt поставить.
                                      И тогда гошное форматирование будет на уровне автозамены CRLF.

                                      Читать да, только в каноничной форме :)
                                        0
                                        На практике получается очень приятно, что можно отгрузить куда-то один файл и быть достаточно уверенным, что он не упадёт из-за неудовлетворённой зависимости.

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


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

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

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

                                          А кто-то запретил? В Go есть динамическая компоновка (я вроде бы упомянул ответом выше), статическая там просто по умолчанию.

                                          По поводу форматирования — ну хорошо, чужой код вы прогоните через автоформатирование и будете читать так, как вам нравится. Но писать-то вам код придётся в соответствии с гайдлайнами того проекта, куда вас позовут. Или вы конвертируете и туда и обратно? Переформатируете всё написанное перед коммитом? Кстати, если что, с Go вам тоже никто не мешает так сделать. Просто есть официальный стандарт оформления и есть официальная утилита, которая форматирует. На вашей машине никто вас не заставляет ими пользоваться, дело хозяйское.
                                            +2
                                            А кто-то запретил? В Go есть динамическая компоновка (я вроде бы упомянул ответом выше), статическая там просто по умолчанию.

                                            Я так понял, что изначально ее не было.


                                            Просто есть официальный стандарт оформления и есть официальная утилита, которая форматирует. На вашей машине никто вас не заставляет ими пользоваться, дело хозяйское.

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

                                              0
                                              Изначально не было. Ну так и язык относительно новый, во многих языках изначально много чего не было. Её не запрещали, её просто не сделали сразу. Вопрос приоритетов. Питону необходимость везде тащить рантайм и отсутствие динамических библиотек (хотя вроде уже можно что-то такое с Cython сделать? пусть знающие поправят) не мешает в топе TIOBE висеть и пользоваться народной любовью.

                                              Да, это не требования — не ограничения — а рекомендации. Поэтому я не совсем, признаться, понимаю, откуда ощущение взялось. Тут фокус в другом — есть такая штука как сила умолчаний. Если в языке из коробки есть официально рекомендованный стиль оформления и даже утилита, то в сообществе создаётся тренд, и очень немногие от него отходят. Получается, что и волки сыты (можно форматировать как угодно, если есть желание), и овцы целы (подавляющее большинство кода всё равно в стандартном единообразном стиле). Это просто психологический приём, чтобы большинство разработчиков безболезненно и быстро миновали фазу «так, в каком стиле мне начать писать код» и начали писать собственно код.
                                                +2
                                                Да, это не требования — не ограничения — а рекомендации.

                                                Тогда странно выглядит то, что сначала очень старательно продавали статическую линковку как killer feature. Удивительное будет время, когда найдут какой-нибудь приятный баг где-нибудь в crypto. Сколько народу не пересоберёт (учитывая, что используют glide/gob далеко не везде), а сколько — забьёт?

                                                  0

                                                  И сейчас продают, и, по-моему, правильно продают. Killer feature в общем-то не сама статическая линковка как таковая, а то что она получается сама, по умолчанию, без каких-либо ментальных или физических телодвижений. Это всё та же сила умолчаний — у статической линковки есть плюсы, но чтобы использовать её в других языках, надо поработать, а тут получается бесплатно.


                                                  По поводу багфиксов — это старый спор, и я не думаю, что там есть какая-то правда. Это больше спор о том, кому быть виноватым — майнтайнерам пакетов с библиотеками, майнтайнерам приложений, или вообще нерадивым админам, которые ничего и никогда не обновляют. Если так подумать, то с тем же успехом можно накатить обновление библиотеки с незамеченным zero day (а может и с нарочно внесённым), и моментально все динамически слинкованные приложения становятся уязвимыми. Мне кажется, там проблема вообще в другой плоскости лежит.

                                                    0

                                                    Тут рядом ещё ходит проблема невоспроизводимых билдов благодаря утилите go get, которая местами усиливает (более новая версия в репозитории может оказаться несовместимой и софт оставят необновлённым), местами — ослабляет (go get принесёт последнюю версию зависимости) вышеописанную проблему. Ну и всё это надо помножить на реальное разнообразие: кто-то вендорит зависимости, кто-то говорит "дёрните go get ..." при сборке; кто-то предупреждает о необходимости чистого GOPATH, кто-то предполагает, что он у вас единственный и вы будете использовать те же версии библиотек, что и в других своих проектах.


                                                    Меня лично радует, что glide пошёл в массы, но это очень субъективная штука, т. к. я на go не пишу, то, по сути, рассматриваю проблемы с точки зрения мейнтейнера, а не разработчика.

                                                      0

                                                      Да, это больной момент у всей экосистемы. :( Зря на потом оставили. Я думаю, что вендоринг если не решит проблему, то хотя бы однородной сделает. Кстати, спасибо за наводку на glide, я пользовался gb-vendor, но glide выглядит хорошо (я тоже ничего на Go по большому счёту не пишу, но быть в курсе стараюсь).

                                                        0
                                                        glide и работает хорошо, не только выглядит
                                                      0
                                                      без каких-либо ментальных или физических телодвижений

                                                      Я пишу на С++, телодвижения сводятся к указанию пути к библиотеке и подключению заголовка. Куда уж проще?

                                                        +3

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

                                                          +1
                                                          У вас были программы покрупнее, чем те, которые требуют всего одну библиотеку?

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

                                                          Сколько суток займёт такая задача для C++, я даже не представляю, но явно не менее недели. А в моем проекте на другом языке это дело минуты.
                                                            0

                                                            Были, но они подключались по одной в процессе разработки. Больше получаса на поиск библиотеки с нужным функционалом, её сборку и подключение уходило редко.


                                                            Хотя если их несколько сотен, то и правда уйдет неделя.

                                                          • UFO just landed and posted this here
                                                              +2

                                                              image


                                                              Если серьезно, то на плюсах пишут там, где нужна максимальная производительность. Несмотря на все его недостатки (а каждый находит десяток-другой своих), реальной альтернативы нет. Возможно, ей станет Rust.


                                                              З.Ы. В С++ есть std::array и std::vector, зачем пользоваться сишным массивом?

                                                              • UFO just landed and posted this here
                                                                0
                                                                или язык действительно безнадёжно затянут в бездну обратной совместимости?

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


                                                                В более новых языках типа Rust действительно многое проще (в том плане, что компилятор даст по рукам, если что), но суть остаётся той же: такие решения приходится принимать самому: если нужные виртуальные функции, то используем трейт-объекты и т.д.

                                                                  0
                                                                  Пишу высокопроизводительный код с матаном. Упираюсь при молотиловке чисел в производительность памяти. Хорошо.

                                                                  Размер массива по указателю, впрочем, получать особо не нужно было. Да и как компилятор метки виртуальных функций расставить может, если полной информации о всём дереве наследования в общем случае у него может и не быть?
                                                          +2

                                                          Там всё плохо… Есть динамическая линковка — опция компилятора -dynlink. Это, насколько я понимаю, вызов кода из сторонних so и dll. Но свою динамическую библиотеку создать на Go — нельзя. И также нельзя подгрузить в рантайме произвольную библиотеку и вызвать из неё функцию.


                                                          Другими словами, реализовать плагины в программе просто невозможно. И это главная проблема сейчас, как по мне. Это тормозит развитие http://gogs.io/, чтобы решить эту проблему ребята из http://caddyserver.com/ написали своё решение, которые перекомпилирует исходники с нужными модулями по выбору пользователя...


                                                          Вот, к примеру, один из тасков о динамической загрузке. Закрыт. Заброшен: https://github.com/golang/go/issues/13751

                                                            0

                                                            А -buildmode=c-shared, которая в 1.5 появилась, это не оно? Можно из Go сделать .so, потом использовать откуда угодно, в том числе из Go. Понятно, что не без ограничений по экспортам, но всё же. Вот тут подробнее: http://www.darkcoding.net/software/building-shared-libraries-in-go-part-1/

                                                              +1

                                                              Но можно ли эти so или dll загрузить обратно в Go динамически? Вызвать функцию, а потом выгрузить из памяти?


                                                              Как я могу реализовать систему плагинов к моему приложению на Go без перекомпиляции оного?

                                                                0

                                                                Именно чтобы руками, как с dlopen() или LoadLibrary()? С этим пока не очень просто. В принципе, насколько я понимаю (поправьте, кто это дело ковырял), можно загрузить через cgo. Код получается, мягко говоря, некрасивый, и не уверен, как сделать на не-POSIX платформе, но в целом должно работать. Что-то вроде такого:


                                                                // #cgo LDFLAGS: -ldl
                                                                // #include <dlfcn.h>
                                                                
                                                                import "C"
                                                                
                                                                // ...и дальше по тексту, handle := C.dlopen(...) и прочее.

                                                                Насколько удобно будет так делать развесистую систему плагинов — не знаю, надо пробовать и смотреть. Ну и, понятно, портируемость пострадала.

                                                                  0
                                                                  Можно с помощью стандартного пакета syscall.
                                                      +11
                                                      А я вообще не соглашусь с тем, что код на Go короче. Я пробовал, получилось более многословно, максимально приближено к C в плане последовательности действий, разве что очисткой памяти занимается сам рантайм.
                                                      +2
                                                      >>Но очень быстро все уперлось в производительность.
                                                      >>На одном сервере можно было запустить не более 300 клиентов.

                                                      Я конечно извиняюсь, но думаю после этого можно не читать дальше. А в го у вас сколько клиентов получилось? 310?
                                                        +8
                                                        Статью не читаю, комментарии пишу. Автор же написал что 2500
                                                          +9
                                                          Ну т.е. после того как он стал использовать профилировщик (который никто ему не мешал использовать на джаве) он оптимизировал приложение. Это явно плюс языка go

                                                          Я думаю что го был создан для дешевой раб силы, все его ограничения связаны с низким порогом вхождения дабы не заморачивать светлые умы
                                                            +1
                                                            Автор подробно описал причины почему он использовал профилировщик на го и не использовал на джаве. А еще комментарием выше ему явно указали как он мог бы таки его использовать.
                                                            И то что автор не использовал профилировщик не объясняет почему вы не читаете статью, но оставляете комментарии…
                                                              +6
                                                              Потому что заявления — я написал сервер на джаве и он обрабатывал всего 300 клиентов (без тех. подробностей) это какая-то софистика.
                                                              А я вообще использовал nodejs который обрабатывал пол миллиона клиентов, так что давайте все использовать nodejs )
                                                                +1

                                                                мне как-то скучно было и я на жавоском сервере на домашнем компе поднял 2 миллиона активных соединений, потребовалось 10гб оперативы, но старенький амд осилил ^_^

                                                                  +3
                                                                  Ну а на го вы подняли бы примерно 16млн ;) судя из статьи
                                                                    –5
                                                                    Если там просто пустые соединения, то разницы бы не было.

                                                                    Если сервер имеет сложную логику и «тянет» мало клиентов, то вывести его на нужный уровень производительности в go займет существенно меньше времени, чем выполнение той же задачи в java.

                                                                    (Хотя, разумется, это возможно и в java и вообще на любом языке)
                                                                  0
                                                                  Сервера бывают разные. Ваши полмиллина клиентов — это игровые клиетны в реальном времени, как у меня?

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

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

                                                                    Да ладно? Вы даже не пытались профайлить в джаве, о каких таких «потребовал в разы меньше» можно говорить?
                                                                      0
                                                                      Как я понял, у автора «потребовал в разы меньше усилий» процесс профилирования, собственно.
                                                                        0
                                                                        Не только он. Существенная экономия была достигнута за счёт профилирования и за счёт ловли race conditions.
                                                                        Несущественная — за счет меньшего объема кода.
                                                                          +4
                                                                          Комментарий на который я ответил, как бы подразумевает, что вы не можете сравнивать сколько вы времени сэкономили, потому что профилировать код на Java вы даже не пытались.

                                                                          Поэтому в статье у вас и получилась экономия только на том, что вы быстрее освоили один профайлер, чем другой.
                                                                            0
                                                                            Ответил ниже. Могу. Потому что неоднократно ранее делал это с другими проектами.
                                                                              +7
                                                                              Хм, вот тут я вас не очень понимаю.
                                                                              Если вы уже делали профилирование на других проектах, то у вас уже должны быть достаточные навыки для работы с профилированием в Java, что бы не писать о том, какое оно сложное и не понятное.

                                                                              То вы указываете, что работаете с Java целых 18 лет, но почему-то у вас свеженаписанный сервер не держал больше 300 коннектов, что явно указывает на то, что для его написания не использовались нужные технологии.

                                                                              Так же, непонятки с профилированием, хотя за 18 лет, у вас точно должен был быть опыт профилирования хотя бы одного многопоточного приложения на java, а тулзов для race detector там полно.

                                                                              Так же. вы тут где-то признавались с том, что не работали/не знаете ни одну библиотеку, для работы с серверами на Java, что еще более странно, с 18-летним опытом, если даже я, который впринципе не работает с Java в production, поработал с Netty.

                                                                              Как-то немного многовато нестыковок.
                                                                                0
                                                                                Достаточные навыки в чем-то не противоречат отношению к этом чему-то, как к сложному и неудобному.

                                                                                Про сервер вы правы. Ранее я писал на java что угодно (начиная от web (бизнес системы) и кончая играми, Eclipse RCP или CORBA-SNMP gateway), кроме серверов реального времени, использующих Websocket. Этот сервер (а точнее — прототип) я написал очень быстро и без оглядки на performance. На этом этапе я определял что вообще должен делать этот сервер, по сути — проектировал игру. С технологией (библиотекой) я, кстати, действительно, ошибся.
                                                                                Performance-ом собирался заняться на следующем этапе. Уже «предвкушал» приятную возню с VisualVM. Но наткнулся на описание профайлера в языке go (на который уже давненько с интересом посматривал). Описание понравилось. Решил сделать production вариант на go. Сделал. Опытом более чем удовлетворен.
                                                                        –1
                                                                        Вы путаете две вещи «я не пытался профайлить именно этот проект» (да, не пытался. Примерно знал во что оно выльется) и «я не пытался профайлить в java вообще» (такой опыт был, иначе не о чем было бы говорить)
                                                            +2
                                                            Го задалбывает приведением типов. И функции которые конвертнут из одного типа в другой всегда болтаются в разных библиотеках. Я был бы счастлив если был бы какой-то единый способ приведения стандартных типов. Есть странные вещи, например в условиях нельзя сравнивать целые и дробные, это очень бесит в циклах.
                                                              +21
                                                              Вот это проблемы у людей!

                                                              Нет бесплатного профайлера в Java? Конечно есть, хорош для решения основных пробем с производительностью, имеется куча плагинов, называется VisualVM.

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

                                                              Race conditions — это действительно головная боль писателей многопоточных приложений, но далеко не всех. Некоторые все-таки знают про shared mutable state и избегают его, используя либо стратегию share-nothing (каналы в Go, Akka — в Java), либо функциональное программирование (переход на immutable).

                                                              Стоит ли ява программисту полностью переходить на go? Нет.


                                                              А вот с выводом-то особо и не поспоришь :)
                                                                –12
                                                                Ваша мысль выглядит примерно так «Нельзя удалять гланды автогеном? Конечно, можно! Просто надо делать это через задний проход!»
                                                                Я нигде не сказал, что в яве нет профайлера.
                                                                Я сравнивал производительность инструментов (java + какой-то профайлер) vs (go + встроенный профайлер)
                                                                Go в несколько раз выиграл в моём случае. Работать было быстро, удобно и приятно.
                                                                +7
                                                                Глаз сильно зацепился за это
                                                                Но важно понимать, что этот самый коллектор будет запускаться каждые несколько секунд и заметно притормаживать систему.

                                                                Это ж насколько сильно нужно гадить в хип, чтобы заметить работу GC? Это точно не про Java?
                                                                • UFO just landed and posted this here
                                                                    +2
                                                                    Ну так мы и не про Go1.2 какой-нибудь сейчас говорим, верно? На 1.4 еще помню какие-то задержки на сотни мс, сейчас же на 1.6 даже 10-12 мс — это уже зачем-то много гадили в хип. Типичное время работы GC <= 1мс на наших проектах.
                                                                    –6
                                                                    Нужно завести игровой сервер. Поднять там 2500 клиентов, каждый из которых будет отправлять в среднем 50 сообщений в секунду и получать примерно 750 (через web socket).
                                                                    Работа gc замечается в едва заметных глазу лагах при передвижении игровых объектов.
                                                                      +10
                                                                      Так это не gc скорей всего виноват, а вы с объектами, вероятно, неправильно работаете. Часто инстанциируете, нету пулов и т.п. У нас сервера игровые на java/C#, никаких лагов не наблюдаем связанных с gc.
                                                                        0
                                                                        Что касается объектов, то нет. Мы как раз оптимизировали здесь всё, что только можно было. В куче почти ничего не создаётся. Пулы есть.

                                                                        Возможные причины такой разницы:

                                                                        1) GC в go пока хуже, чем в java. До версии 1.5 был вообще ужасен. Но всё еще заметно хуже.
                                                                        2) Разная нагрузка на сервер. Наш получает от каждого из 2500 клиентов примерно 50 сообщений в секунду. Обратно отсылает примерно 750. Плюс имеет очень много межпоточных коммуникаций.
                                                                        3) Разные требования к серверу, обусловленные устройством самой игры. Если у нас влючить gc, появлется едва заметное дрожание кораблика раз в несколько секунд. Оно трудноуловимо, но создает ощущение, что с игрой что-то не так.
                                                                          +1
                                                                          GC может и похуже, но:
                                                                          • escape analysis позволяет много чего оставить на стеке и уменьшить мусор в хипе;
                                                                          • многие типы нативны и хранятся как есть без лишних косвенных обращений, уменьшая нагрузку на GC при сборке

                                                                          И получается хорошо на больших хипах (десятки ГБ).

                                                                          P.S. У нас на пушилках, рассылающих около миллиарда пушей в сутки каждая (с огромной кучей логики, горутин, каналов, и т.п.), сейчас сборка gc занимает 12мс время от времени (и там даже sync.Pool почти нет).
                                                                          На более оптимизированных (пулы и профилировка наше все) демонах сборка редко когда даже 1мс занимает.
                                                                            +1
                                                                            Update: После перевода проекта на go1.7 проблемы с gc исчезли полностью.
                                                                            Теперь его не отключаем, ибо он и так незаметен.
                                                                              0
                                                                              Ого, уже на 1.7. Я пока опасаюсь переводить прод на него)
                                                                                0
                                                                                У нас еще не было релиза. Поэтому такие смелые.
                                                                                Но плюсы ощутимы. Кроме решения проблемы gc оно еще и процессора есть примерно на 35-30% меньше, чем 1.6
                                                                                Сам файл вместо 6.5мб весит 4.5 (хотя последнее и не важно для нас)
                                                                    +19
                                                                    Смешно наблюдать за этими потугами недоразработчиков.
                                                                    Я из .NET, но тут я с Java.
                                                                    Сколько же вас развелось таких, кто не написав ничего серьезного и не имея за плечами нормального опыта, прыгают с языка на язык и успевают между этим писать поучительные статьи? Другие успевают преподавать с таким «богатым» опытом.
                                                                    Да, чувак, то что ты не умеешь пользоваться инструментами — это Java виновата, совершенно точно. проблема точно в ней!
                                                                      –7
                                                                      Поясните каким образом вы оценивали мой опыт и почему решили, что я прыгаю с языка на язык?

                                                                      Что касается инструментов, то лучшие инструменты остаются лучшими, несмотря на то, что я или вы умеете работать и с плохими.
                                                                        –4
                                                                        Чем больше общаешься в англоязычных коммьюнити, тем страшнее читать вот такие комментарии, которые ещё и кто-то плюсует.

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

                                                                        А вот почему вы считаете, что вы имеете права оскорблять других людей за их труды, мне не ясно. К сожалению, о русскоязычных коммьюнити мнение складывается по вот таким вот зазнавшимся «специалистам, написавшим много серьезного», как вы.
                                                                          0
                                                                          Большое спасибо за ваши добрые слова.
                                                                            +6
                                                                            Я все еще не понимаю, почему вам не нравятся такие комментарии.
                                                                            Они абсолютно справделивы.
                                                                            Go-коммюнити в Рунете уже достало писать такие статьи, где они сравнивают какой-то язык с Go, допуская в сравнении серьезные ошибки.

                                                                            По сути, всю статью можно было назвать: нагуглить инфу про профайлеру в Go проще, чем по профайлеру в Java.
                                                                              +1
                                                                              Если вы не понимаете, почему оскорблять людей это не есть хорошо — я вам не объясню.

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

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

                                                                                Поговорив с автором я вытянул из него, что у него довольно богатый опыт с VisualVM и он от него устал. Это существенно дополнило мое впечатление о статье.


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

                                                                                Можно сказать спасибо "интересным" статьям про Go ранее. Например, ту, в которой у компании крутились микросервисы на Java в Tomcat.

                                                                              +3
                                                                              Если я в тексте вижу фразы — «я тут написал, а оно не работает, наверное такое на Java вообще не возможно написать», и еще приплести сюда какой-то недоразвитый язык и поставить его выше прекрасно зарекомендовавшего себя инструмента, который используют десятки лет, то готов многое высказать такому специалисту.
                                                                              И ведь, какой-нибудь школьник почитав этот «труд» реально подумает, что лучше Go ничего нет, а это уже просто диверсия какая-то.
                                                                              Иногда складывается впечатление, что это какие-то новые маркетинговые войны и реклама идет самыми грязными методами и просто внаглую
                                                                                +3
                                                                                Помню, будучи «школьником», прочитал в книге или статье, уже и не вспомнить одну интересную мысль — «если у вас что-то не получается, или что-то не работает, не ищите проблему во фрэймвоке или библиотеках, ищите проблему в вашем коде».
                                                                                Почему-то мне это прям на подкорку засело.
                                                                                Так вот, за свои 10 лет работы, мне всего лишь один раз вствил палки в колеса IIS7, и то, просто потому, что я не знал одну его особенность по сравнению с IIS6. Мы с товарищем просидели пару дней дебажа ASP.NET.
                                                                                А ведь могли просто сказать — «это слишком сложно, или невозможно».

                                                                                  +2
                                                                                  Это справедливо, если вы ограничены одной технологией в принципе. Но чем больше вы набираетесь опыта, тем больше понимаете, что выбор технологии (языка/базы данных/алгоритма/фреймворка/etc) это тоже часть работы инженера, и едва ли не важнейшая.

                                                                                  Ограничивая свои знания одной технологией, вы повышаете свой knowledge debt, который будете выплачивать тем, что будете менее продуктивны. Вы могли бы точно так же зафанатеть по фортрану и считать, что те, кто предлагают вам другие языки «просто недостаточно хорошо разобрались» в фортране. Нет, нет и нет. Это ваша ответственность максимально объективно владеть ситуацией, знать плюсы и минусы технологий, уметь использовать как-минимум основные из них и уметь выбирать нужный инструмент для нужной задачи.

                                                                                  Религиозный фанатизм тут к добру не приводит и понижает ваш уровень как специалиста очень существенно.
                                                                                    +2
                                                                                    Безусловно, просто го — это гигантский прыжок назад по сравнению с джавой в сегодняшнем мире. Овладевать языком имеет смысл тогда, когда он _лучше_, а не когда он _проще_.

                                                                                    Ну, если, конечно, нет цели устроиться чернорабочим в гугл.
                                                                                      0
                                                                                      Безусловно это только в вашем джава-мире, из которого автор, в отличие от многих комментаторов сумел выглянуть. А субъективные рассуждения про «сложнее значит лучше», с которыми я в корне не согласен, и «чернорабочие в гугл» — это вообще никакой критики не выдерживает.
                                                                                        +3
                                                                                        > субъективные рассуждения про «сложнее значит лучше», с которыми я в корне не согласен

                                                                                        А-а-а-а, у вас с простыми силлогизмами, оказывается, проблемы. Я нигде не утверждал, что «сложнее — значит лучше». Я уж молчу про то, что никогда в жизни не принадлежал джава-миру, и писать код на джаве не стану, даже если от этого будет зависеть моя жизнь.

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

                                                                                      Но чем больше вы набираетесь опыта, тем больше понимаете, что выбор технологии (языка/базы данных/алгоритма/фреймворка/etc) это тоже часть работы инженера, и едва ли не важнейшая.


                                                                                      Знать алгоритмы нужно, понимать разничу между разными типами БД тоже.
                                                                                      Языки и фрэймворки… да какая разница? Вы действительно думаете, что есть хоть какая-то разница между RoR, JavaEE, ASP.NET и Spring? Ну да, некоторые фичи где-то из коробки, а где-то отдельной либой подключить, но по сути это одно и тоже.

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

                                                                                      В это веришь до первого пойманного бага в компиляторе :)

                                                                                        +1
                                                                                        Так в этом и смысл, чем больше вы работаете с чем-то, тем больше вы узнаете.
                                                                                        Ведь любая в любой технологии есть баги и ограничения, с опытом все это узнаешь и это позволяет не вставать на одни и те же грабли.
                                                                                        А если постоянно менять эти технологии, то и на грабли будешь вставать каждый раз.
                                                                                          0

                                                                                          Я вот об этом:


                                                                                          если у вас что-то не получается, или что-то не работает, не ищите проблему во фрэймвоке или библиотеках, ищите проблему в вашем коде

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

                                                                                            0
                                                                                            А, так это совет именно для начинающих, а не тех кто дошел до того, что репортит баги компилатора.
                                                                                            Суть в том, что новички часто пытаются найти какой-то такой идеальный вариант где все хорошо, нет багов и почти не нужно писать код. И часто прыгают от одной технологии к другой. Типа пару лет пописали на .net, потом вышел nodejs и он почему-то лучше всех, теперь появился Go и нужно срочно переходить на него.
                                                                                            Причем все пытаются привести такой аргумента как продуктивность. А по сути, те же яйца, и через пару-тройку лет и пару-тройку сложных проектов точно так-же находятся баги в тулах и компиляторах.
                                                                                      –2
                                                                                      приплести сюда какой-то недоразвитый язык

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

                                                                                      Если бы мне пришлось выбирать из двух кандидатов в свою команду, я бы однозначно выбрал автора статьи, а вас бы сразу в черный список занёс. Автор умеет осваивать новые вещи, умеет учиться, умеет делиться знаниями и не боится почувствовать себя новичком. Это очень ценно. Вы же фанатичны в одной технологии, не умеете адекватно общаться, обвешались в стереотипах и не умеете объективно смотреть на выбор технологии, как на один из важных элементов работы разработчика. По-моему, выбор очевиден.
                                                                                        +6
                                                                                        Вы вроде взрослый человек, а ведетесь на какие-то, очень странные вещи.
                                                                                        Вы видимо, тоже проскочили уровень, где начинаешь смотреть на ващи более трезво.
                                                                                        С чего вы взяли, что человек выше будет учится и делать что--то лучше? Он язык приплетает для технологии, в некоторых случаях, это бывает оправданно. Такие люди будут вас доить, каждый год переписывая свое творчество на очередной язык.
                                                                                        Go хорош для сетевой мелочи и не больше.
                                                                                        Уж называть меня консерватором в технологиях просто смешно.
                                                                                        Просто вы своими (Go) статьями, честно, уже достали.
                                                                                          –7
                                                                                          Просто вы своими (Go) статьями, честно, уже достали.

                                                                                          Вы всегда можете пойти в угол и поплакать, если кто-то пишет статьи про ненавистную вам технологии. Очень взрослый уровень хабра и русскоязычного джава-сообщества в целом.
                                                                                            +3
                                                                                            А вы смеееешноой…
                                                                                            Т.е. увязывание тезисов являющихся явно холиворными в статье — вы называете взрослым поведением? Вы или пропустили их (соглашаясь с авторским фанатским мнением по этим пунктам) или явно троллите. Да и в комментариях автор так и не смог внятно назвать/показать плюсы перехода. И после этого вы его называете новатором? Простите — но в шею гнать таких новаторов!

                                                                                            Для большей ясности процитирую набросы на вентилятор:
                                                                                            «Код на go на 20-30 процентов короче аналогичного на яве (там просто не лишних слов, например, нет точки с запятой в конце каждого предложения, нет круглых скобок в операторах условия или цикла etc)»
                                                                                            Что значит на 20-30% короче? С какой версией сравнивалось? Напомню — лямбды, диамонды позволяют сильно экономить на обязательной выразительности кода. Приведённые же примеры — просто шик! Точка с запятой на конце! Как сложно поставить! Отсутствие скобок на ифе/цикле — опять же вкусовщина. Мне вот скобки нравятся — они визуально помогают выделить блок условия.

                                                                                            «В go очень быстрый компилятор (несколько секунд на компиляцию большого проекта)»
                                                                                            Вообще непонятная фраза. Компилятор в Java тоже очень быстрый. + различные механизмы онлайн подгрузки классов. Нет, если бы была статься "… глазами программиста C++" я бы мог понять… Но Java-то тут причём?

                                                                                            «1) Используя метод пристального взгляда искать в коде неэффективные места, пробовать их исправлять и, после каждого изменения, вновь запускать нагрузочные тесты. Этот способ очевидно неэффективен.»
                                                                                            На !1ом! месте человек рассматривает метод визуального профилиривония… СЕРЬЁЗНО???

                                                                                            «2) Погрузиться в изучение альтернативных серверных библиотек, пробовать разные варианты. Это тоже не дает никаких гарантий — возможно проблемы в моём собственном коде, или вообще в самом языке java.»
                                                                                            Это надо было делать ДО начала написания кода. Потому что с неплохой вероятностью существенный кусок кода будет просто выброшен. И раз уж существующих знаний нужных библиотек нет — это надо было делать ОБЯЗАТЕЛЬНО.

                                                                                            «3) Наконец, я мог купить один или несколько платных профилировщиков и попробовать получить какую-то информацию от них. Но и тут есть проблемы. Если использовать локальный сервер, стоящий у нас в офисе, я не мог создать нужной нагрузки, поскольку у нас в офисе нет нужного количества свободных машин, чтобы запустить несколько тысяч клиентов. Если же использовать внешний сервер, то требовалась довольно сложная конфигурация, чтобы запустить там профилировщик. Наконец, выбор профилировщика сам по себе является нетривиальной задачей.»
                                                                                            Тут сразу несколько шедевров: зачем-то понадобилось покупать профилировщики и пробовать получить информацию от них. Во-первых профилировщиков очень много. И платных и бесплатных. Если человек (программист Java) давно работает в индустрии — ему не надо покупать, необходимый набор у него есть. При этом автор не пожаловался на то, что профилировщики влёгкую могут врать (привет JUG движуха в Питере, которая знает!). Но почему-то пожаловался (кстати, в исходной статье он называл вообще невозможным) на трудности запуска профилировщика на внешнем сервисе. Что ему мешало поднять на своём сервере виртуалку — опять же тайна. Да и просто «сложно создать достаточную нагрузку»… это как? Сервер слишком жирный? Ну так не пускайте за пределы 2х-4х ядер JVM! Да и даже в этом случае — вполне можно было сделать кластер-бота, который легко нужную нагрузку даст. При этом решение с нагрузкой так и не было озвучено. Взяли Go и сразу всё само образовалось?

                                                                                            ну и самое вкусное:
                                                                                            «Go создавался гораздо позже и на сегодня в нем присутствует все, что востребовано сейчас и ничего лишнего.»
                                                                                            Это после жалоб-то на отсутствие механизма исключений («Ужасная — обработка ошибок путем проверки возвращаемого функцией кода.»)?! После жалоб на отсутствие генериков («Плохая — это отсутствие generic-ов.»)?!

                                                                                            Не исповедимы, видимо, не только «пути господни», но и мысли человечьи…

                                                                                            PS корм закончился, больших жирных и зелёных просьба отойти. Готов только к нормальному диалогу.
                                                                                              +6
                                                                                              Не смешной совсем. Это реально не смешно.
                                                                                              divan0 Какой-то ярый, непримиримый фанат Go.
                                                                                              Он приплетает все, что угодно в качестве аргументов против тех, кто сомневается в Go.
                                                                                              При чем технических аргументов очень мало. В основном он скатывается на личности и их качества.
                                                                                              При чем эта черта отмечается многими в разных Go тусовках. Такое ощущение, что в Go так принято.
                                                                                              Любой камент против Go вызывает бурную, просто неадекватную реакцию.
                                                                                                –4
                                                                                                Я, наверное, что-то не понимаю, но я написал выше конкретно про то, что оскорблять людей — это неправильно, и строить дискуссию со слов «недоразвитый язык» не имеет смысла. Если вы в этом видите «любой камент», «неадекватную реакцию» и «скатывается на личности», то мы говорим на разных языках.

                                                                                                Если честно, то я очень рад, что почти не общаюсь в русскоязычном сегменте — очень отвык уже от такого уровня общения. Но автор статьи не заслуживает того, чтобы его оскорбляли. Человек поделился опытом, потратил время, написал пост на техническом ресурсе, и вынужден терпеть оскорбления. Со стороны выглядит дико и мне жаль, что здесь это норма. Мы люди, пишем софт для людей, мы можем находить общий язык, если соблюдать простые базовые правила общения. Во всем мире это работает, кроме рунета.
                                                                                                  +4
                                                                                                  Где-то высказывали мнение, что это во многом из-за того, что Go был создан в Google Робом Пайком. И тут сложились два фактора: все, что делает «корпорация добра» по-умолчанию идеально, и всё, что делает такой человек, как Пайк — тоже идеально и все архитектурные решения, сколь бы нетрадиционными они ни были, по-умолчанию не могут быть подвержены критике из-за личности автора (если почитаете другие комментарии этого товарища, то там часто встречается что-то вроде «вы еще Пайка поучите», «Пайк знает, как правильно» и так далее).

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

                                                                                    JMC и VisualVM умеют подключаться к приложению по tcp. YourKit умеет подключаться удаленно. Какие профайлеры вы видели (и читали документацию к ним, ессно)?

                                                                                      –4
                                                                                      Неаккуатно написал. Имел ввиду существенно различную сложность при использовании профайлеров java и go.
                                                                                      +15
                                                                                      Сначала для многозадачных приложений в языках программирования были придуманы процессы.

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

                                                                                        0
                                                                                        Я думаю, это надо понимать так: сначала для многозадачных приложений приходилось использовать процессы уровня ОС, дергая соответствующий системный вызов.
                                                                                          0

                                                                                          Для создания треда в linux, например, обычно дергается syscall clone, если правильно помню. Создание нового процесса может выпоняться им же, просто с другими флагами, касающимися выделения нового стека, адресного пространства и т. п. Принципиального отличия с точки зрения ядра нет.


                                                                                          Основной недостаток использования процессов — более дорогой IPC (хотя иногда выкручиваются через /dev/shm) по сравнению с использованием общей памяти разными потоками в рамках единого адресного пространства.

                                                                                            –1
                                                                                            Именно так. Спасибо
                                                                                          +1
                                                                                          Автор!!! 300 клиентов на сервер!!! Вот это да!!!
                                                                                          На плюсах писал сервер для ММОРПГ мне в страшном сне не могло такое присниться… минимум 10 000 при использовании самых жестких процедур
                                                                                          .
                                                                                          А хотите а скажу как можно создать эмулятор ЛЮБОГО количества клиентов на ОДНОМ клиенте?
                                                                                          Берете вайршарк, пишете пакеты(еще лучше, свой сниффер), запускаете клиент, делаете нужные действия, пишете пакеты.
                                                                                          А потом те же пакеты размножаете любым доступным способом. Вплоть до забивания пропускного канала :-) Так как вы автор, вы знаете где у вас в пакете хранятся уникальные для каждого пакета id и знаете как легко их можно поменять. Так что — это реально легко и просто :-)
                                                                                          Почему свой сниффер лучше — понятно?

                                                                                          Дайте, я еще угадаю: положение игроков рассылается не каждому по запросу, а от каждого каждому? В смысле, пришел пакет на изменение положения, это изменение разослали всем в зоне?

                                                                                          П.с. это не в смысле «блин… какой дурак», а в плане «ооо!!! И я таким же молодым был» :-)
                                                                                            0
                                                                                            В смысле, пришел пакет на изменение положения, это изменение разослали всем в зоне?

                                                                                            А как правильно? игры ни разу не делал
                                                                                              0
                                                                                              У нас было так — в зоне храниться лог обработанных событий за последнюю минуту(т.е. не юзер2 жмет влево, а персонаж такой-то изменяет координаты на столько-то). Приходит пакет и говорит: «я хочу лог зоны с такой-то секунды и такой-то миллисекунды». Ему в ответ: «вот тебе родной», и сервером передается лог событий. Клиент, соответственно, запрашивает состояние зоны каждый раз, как поймал ответ, но не чаще чем через 250 мс от отправки предыдущего пакета, и не реже чем раз в четыре секунды(udp-пакеты могут теряться). Т.е. что пинг 50, что пинг 250 — без разницы.
                                                                                              Почему это лучше? Потому что у клиента пинг может достигать до трех-четырех секунд… и он все равно будет видеть все, что происходило.
                                                                                              У нас время жизни клиента без ответа было 15 секунд. Т.е. если от клиента не было ни одного пакета за 15 секунд, он вышел и должен заново проходить авторизацию. Этого хватало на самые плохие пинги(вроде, на Камчатке был клиент, но сейчас уже не уверен, где-то в дальних гребенях со стабильным пингом в три секунды).
                                                                                              При этом, когда идет рассылка любых изменений всем в зоне, количество пакетов растет квадратично в зависимости от количества клиентов.
                                                                                                0
                                                                                                Как вы представляете многопользовательский шутер с временем жизни клиента без ответа в 15 секунд?
                                                                                                  0
                                                                                                  А что вы делаете, если от пользователя перестали приходить пакеты, но корректно он не вышел?
                                                                                                  За 15 секунд пользователь, если у него проблемы, успевает перезагрузиться и снова запустить клиент.

                                                                                                  И да, его за это время могут даже не убить. Если он успел заныкаться или находится на стартовой позиции.
                                                                                                    0
                                                                                                    Если от него перестали приходить пакеты, его коннект убивается сервером (примерно, через секунду)
                                                                                                    Думаю, наши игры очень разные. Моя больше всего похожа на agar.io/slither.io.
                                                                                                    Там всё очень быстро происходит. 15 секунд — неприемлемо огромный интервал
                                                                                                      0
                                                                                                      Да, я, с моими пингами, не смог поиграть ни в одну ни в другую :-)
                                                                                              +1
                                                                                              Позвольте спросить у вас, почему вы выбрали способ именно «пересылки/повторении» трафика на свой сервер?

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

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

                                                                                              Спасибо за ответ.
                                                                                                +1
                                                                                                Во-первых, судя по статье, я подумал, что автор не очень опытный разработчик. И потому я посоветовал самый просто способ. Ну, на мой взгляд :-)
                                                                                                Во-вторых, исследование СВОЕГО трафика — это одна из вещей, которой нужно заниматься при оптимизации клиента, о которой мало кто помнит.
                                                                                                В-третьих, инструмент генерации пакетов так же нуждается в поддержке. Я понимаю, что в идеале правильнее всего было бы сделать «идеального бота» — выбирающего рандомные направления и жмущего рандомные кнопки из числа осознанных комбинаций. И соответственно, советовать писать его с нуля молодому(как я думал) программисту — не надо.

                                                                                                Ну и в-последних: описанная мною фигнулька пишется часа за два-три в худшем случае… А вот с пакетогенераторам придется повозиться.

                                                                                                Вот где-то так вот.
                                                                                              +12

                                                                                              Что я понял из статьи: "Мне было нечем заняться, так что я решил выбросить шмат работы и переписать сервер на Go, потому что там есть встроенный профилировщик".
                                                                                              Изначально у вас на Go получилось 20 клиентов, после профилирования 2500, то есть, на минутку, в 125 раз (!) больше.
                                                                                              Вы не думали, что осиль вы профилировщик на джаве, у вас бы могло выйти ~37500 клиентов? Ну, или даже если бы вышло 2500, что всего в 8 раз больше первоначального (с таким размахом в Go-коде я не удивился бы), усилий пришлось бы приложить заметно меньше.


                                                                                              Да, никогда от хороших java-разработчиков не слышал "ява".

                                                                                                –2
                                                                                                Что я хотел сказать статьёй. «Написание определенных приложений занимает на go в несколько раз меньше времени и усилий чем на java. В том числе за счет более удобных инструментов.»
                                                                                                  +2
                                                                                                  Я считаю это больше зависит от опыта и знания платформы. Т.к. по сути Go и Java языки одного уровня. Понятно, что на Go писать веб-сервер удобнее чем на Assembler.
                                                                                                  А то, что встроены инструменты или нет, это уже не имеет большого значения.
                                                                                                    –1
                                                                                                    Согласился бы. Но вот на java я пишу 18 лет, а на go к тому моменту не писал вообще.
                                                                                                    Но на go таки вышло быстрее. Причем очень существенно.
                                                                                                      +2
                                                                                                      Так именно это и вызывает сомнения.
                                                                                                      Вот например у меня чуть больше 10 лет опыта в .NET, и как-бы мне ни нравился какой-либо новый язык, я не могу быть на нем продуктивным. Т.к. дело-то не в языке, а в платформе, экосистеме, библиотеках и доступных инструментах, плюс мой опыт и знание всего этого.
                                                                                                      Я все это время занимаюсь веб-разработкой, причем примерно 90/10 если говорить backend/frontend, так даже по прошествии 10 лет я не могу сказать, что я хороший фротэндер (хотя последние пол года делаю проект на Angular2, и думаю еще через пол года, год у меня будет очень хороший уровень).

                                                                                                      Не важно какой язык выбрать (C#, Java, Python, Kotlin, Go и т.д, я имею ввиду языки одного уровня), важны ваши знания того, что сформировалось вокруг этого языка/платформы.

                                                                                                      Я хочу подчеркнуть, не язык вас делает продуктивным, а опыт и знания, и не только ваши, а еще и тех людей которые потратили годы для развития «экосистемы».
                                                                                                        –4
                                                                                                        Продуктивность складывается из вашего опыта и знаний и удобства и мощности языка (в том числе, применительно к конкретной задаче).
                                                                                                        Это легко можно увидеть на примере — человек X потратил много лет на изучение ассемблера.
                                                                                                        У него стоит задача написания веб сайта.
                                                                                                        Что будет для него эффективнее — писать сайт на ассемблере или на .NET?
                                                                                                        Я думаю, .NET будет лучшим выбором.
                                                                                                        Здесь я столкнулся с похожей ситуацией — увидел класс задач, который решается на go настолько удобнее, что несмотря на мой опыт на java я теперь предпочитаю для таких задач go.
                                                                                                          +1
                                                                                                          Это легко можно увидеть на примере — человек X потратил много лет на изучение ассемблера.
                                                                                                          У него стоит задача написания веб сайта.


                                                                                                          Это понятно, и про это я уже писал. Но Go и Java суть одно и тоже, просто синтаксис разный.

                                                                                                          Просто все ваши ответы на вопрос «Чем же Go лучше», вы отвечаете «Лучше чем другие языки». Согласитесь, что это сомнительный аргумент.
                                                                                                          В свою очередь хочу заметить, что ходить в джинсах синего цвета гораздо удобнее, чем в красных)))
                                                                                                            0
                                                                                                            Но Go и Java суть одно и тоже, просто синтаксис разный.


                                                                                                            Не соглашусь. Иначе не было бы смысла вообще создавать go.
                                                                                                            Каждый язык имеет свои сильные и слабые стороны. Один хорош для одних целей, другой предпочтительнее для других. Каждый имеет свою нишу.
                                                                                                              0
                                                                                                              Вообщето, вопрос «зачем было создавать Go» не стоит.

                                                                                                              Why are you creating a new language?
                                                                                                              Go was born out of frustration with existing languages and environments for systems programming…

                                                                                                              Go is a programming language designed by Google to help solve Google's problems, and Google has big problems. Полный текст тут.

                                                                                                              Просто Google нужен был свой. Чтобы решать свои задачи.

                                                                                                              Я считаю, что у Go, Java, C#, Python, Ruby почти одна и таже ниша.

                                                                                                              Могли бы вы привести конкретный пример, в решении какой задачи Go так продуктивнее Java?
                                                                                                              Здесь я столкнулся с похожей ситуацией — увидел класс задач, который решается на go настолько удобнее, что несмотря на мой опыт на java я теперь предпочитаю для таких задач go.

                                                                                                              Мне бы хотелось понять, что это за задачи.

                                                                                                              Т.к. в вашей статье есть раздел «Инструменты повышения производительности», и указаны там только профилировщик и race detector.
                                                                                                              Согласитесь, что в Java таких инструментов предостаточно?
                                                                                                                +1
                                                                                                                Просто Google нужен был свой. Чтобы решать свои задачи.


                                                                                                                Из этого можно сделать вывод, что есть какие-то задачи, для которых go подходит лучше других языков. (Ну или, что google таки создал его зря, как следует не разобравшись).
                                                                                                                А раз так, значит go отличается от других не только синтаксисом.

                                                                                                                Мне бы хотелось понять, что это за задачи.


                                                                                                                Цитирую свою же статью: Какие задачи лучше всего решать на go? Создание многопоточных высоконагруженных серверных решений, в которых потоки много коммуницируют между собой.

                                                                                                                Согласитесь, что в Java таких инструментов предостаточно?


                                                                                                                Соглашусь. Предостаточно. Здесь речь скорее о философии языка. О том, что с точки зрения того или иного языка важно (а значит включено в набор стандартных инструментов, хорошо продумано и документировано) или просто есть (и, чаще всего создано третьими сторонами).
                                                                                                                На любом современном языке можно сделать всё что угодно.
                                                                                                                Разница в том, на чем язык предлагает сосредоточиться в первую очередь. В go профилирование и борьба с race conditions это, если хотите — first class citizens. В java — просто часть огромной экосистемы.
                                                                                                                  +1
                                                                                                                  > Из этого можно сделать вывод, что есть какие-то задачи, для которых go подходит лучше других языков

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

                                                                                                                  Сеньор в _любом_ другом языке решит _любую_ задачу лучше, чем на го. Джуниор на го решит любую задачу лучше, потому что ему язык надает по рукам в нужных местах. Но за все нужно платить: пока у вас не пятьсот тысяч сотрудников, го — обуза.
                                                                                                            +4
                                                                                                            >>Что будет для него эффективнее — писать сайт на ассемблере или на .NET?
                                                                                                            Подмена понятий.

                                                                                                            >>Я думаю, .NET будет лучшим выбором.
                                                                                                            Не верно, ибо подмена понятий.

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

                                                                                                            Подлог заключается в том, что вы сравниваете пацана с .net, который на 99% состоит из готового веб-рантайма и пацана с асм, у которого рантайма нет. Но ведь .net-пацан этот рантайм не писал — точно так же асм-пацан может его написать, либо взять готовое.

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

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

                                                                                                              А само явление заключается в том, что есть много языков программирования и раз каждый жив, значит у него есть ниша, где он лучше других.
                                                                                                                +3
                                                                                                                В любой форме это сравнение не имеет смысла, ибо не является правдивым. Чистейшей воды подмена понятий «средства языка» с «готовые средства рантайма для реализации какого-то функционала». В данном случае в .net средства для веб есть по умолчанию, а у асм«а нет. И средства эти не уровня языка.

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

                                                                                                                А далее уже удобство использования самого языка и чьи-то синтаксические предпочтения. Кому-то нравится $i, а кому-то нет. Кому-то нравится экосистема одного языка, а кому-то другого. В целом при равной мощи рантайма разница между языками в „запилить быстро и удобно“ мало различима.

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

                                                                                                                Лучше в смысле как язык, то тут не всё так просто. Лучше в одном — хуже в другом.
                                                                                                                  0
                                                                                                                  В данном случае в .net средства для веб есть по умолчанию, а у асм«а нет. И средства эти не уровня языка.

                                                                                                                  Можно предположить нереальную вещь: кто-то задался целью написать «сайт» (т.е. генератор страниц) на этих языках, используя только базовые библиотеки (доступ к сети через сокеты и доступ к диску). Тогда такое сравнение имело бы смысл.
                                                                                                                  0
                                                                                                                  Конечно подмена понятий, я изначально написал несколькими комментариями выше:
                                                                                                                  Я считаю это больше зависит от опыта и знания платформы. Т.к. по сути Go и Java языки одного уровня. Понятно, что на Go писать веб-сервер удобнее чем на Assembler.
                                                                                                            +1
                                                                                                            Очень спорный аргумент. Перевести приложение с одного языка на другой почти всегда проще, чем писать его с нуля.
                                                                                                      0
                                                                                                      Интересная статья, спасибо.
                                                                                                      Довольно адекватно расписаны возможности языка. Однако Go для совсем новичков я бы никогда не рекомендовал, учиться программировать на Go гораздо тяжелее, чем на Java, в силу того, для чего он разрабатывался и какие задачи должен выполнять, имхо.
                                                                                                        +1
                                                                                                        Однако Go для совсем новичков я бы никогда не рекомендовал, учиться программировать на Go гораздо тяжелее, чем на Java

                                                                                                        Можно тут чуть подробнее? Почему «гораздо тяжелее»? Давно интересуюсь темой Go как первого языка программирования, и интересны мнения со стороны.
                                                                                                          0
                                                                                                          Go не прививает, скажем, правильное ООП, и подвержен некоторым крайне сомнительным практикам, например, хранение метаданных в комментариях или кодогенерации.
                                                                                                            –4
                                                                                                            правильное ООП

                                                                                                            Что это такое? И почему «неправильное ООП» сложнее новичкам, чем «правильное ООП».

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

                                                                                                            Принимаю аргумент про «сомнительные практики» — в других языках это действительно были хаки и сомнительные практики, но в чём проблема у новичков с этим?

                                                                                                              0
                                                                                                              Что это такое? И почему «неправильное ООП» сложнее новичкам, чем «правильное ООП».

                                                                                                              Скажу проше. В Go — нет ООП. Go — это процедурный язык. И то, что в Go можно писать в ООП-стиле не делает его OOP языком. Аналогичная ситуация в Java, никто не назовет Java функциональным языком, но писать в таком стиле там можно. А как показывает практика, процедурников крайне сложно научить потом ООП.


                                                                                                              Принимаю аргумент про «сомнительные практики» — в других языках это действительно были хаки и сомнительные практики, но в чём проблема у новичков с этим?

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

                                                                                                                0
                                                                                                                > как показывает практика, процедурников крайне сложно научить потом ООП

                                                                                                                То есть, история вопроса нам как бы сообщает: в семидесятые годы прошлого века, когда мир вокруг состоял сплошь из процедурников, к нам явились марсиане и научили ООП. Так?

                                                                                                                  –2

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

                                                                                                                  +2

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


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

                                                                                                                    –1
                                                                                                                    Вообще, есть ли смысл абсолютных новичков учить объектно-ориентированной парадигме?

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


                                                                                                                    Справедливости ради, Алан Кей изначально вроде бы не думал о полиморфизме и наследовании как неотъемлемых свойствах ООП.

                                                                                                                    Википедия, с ссылкой на книгу Т. Бадда (isbn 5887822708 в русском переводе) дает такой список правил, которые оговаривал Алан Кей:


                                                                                                                    1. Всё является объектом.
                                                                                                                    2. Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия.
                                                                                                                    3. Каждый объект имеет независимую память, которая состоит из других объектов.
                                                                                                                    4. Каждый объект является представителем класса, который выражает общие свойства объектов (таких, как целые числа или списки).
                                                                                                                    5. В классе задаётся поведение (функциональность) объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.
                                                                                                                    6. Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определённого класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве.

                                                                                                                    Тут есть наследование.

                                                                                                                      +1
                                                                                                                      В чем принципиальная проблема нагуглить первоисточник, вместо каких-то «Вика сказала, что Бадд написал»?

                                                                                                                      ✓ http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
                                                                                                                      ✓ http://www.c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

                                                                                                                      Не было там ни полиморфизма, ни наследования.
                                                                                                                        0

                                                                                                                        Очевидно, от глупости, лени и не хватки времени.


                                                                                                                        Большое спасибо за первоисточник :)

                                                                                                                        0

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

                                                                                                                          0
                                                                                                                          Детский Scratch — учит Объектно-Ориентированному Программированию.
                                                                                                                          Детский Logo — учит Функциональному Программированию.
                                                                                                                          — и то и другое дети вполне понимают.
                                                                                                                            0

                                                                                                                            Лого вроде мультипарадигменный, нет? Тут скорее интерес с точки зрения опыта. Scratch — да, хороший пример.

                                                                                                                  0
                                                                                                                  Только если изначально считать ООП парадигму единственно верной. Более того, высказанный ниже тезис о «тяжести» перехода к ООП (если принять переход сам по себе за необходимость) требует какого-либо обоснования. Точно такой же аргумент применяют при обсуждении функционального п. («очень сложно тех, что начал изучать программирование с процедурных и ООП языков, научить ФП»).
                                                                                                                0
                                                                                                                Я правильно понимаю, что у вас был опыт наблюдения за новичком, который пытался начинать с go?
                                                                                                                Если это так, расскажите подробнее, пожалуйста.
                                                                                                                Я никаких проблем не вижу, но поскольку к моменту изучения go новичком не был, то мог что-то важное пропустить.
                                                                                                                А вопрос для меня, действительно важный — думаю о более широком применении go в нашей компании.
                                                                                                                В том числе и для юниоров.
                                                                                                                  0
                                                                                                                  Есть небольшой опыт обучения совсем новичка в программировании. Сначала выбрали Go, но как-то сразу не пошло (я не говорю, что я очень хороший учитель, но очень старался).
                                                                                                                  Начали с самых основ, без языка по сути. Рассказал основы, порисовал немного. Вроде бы можно было приступать к первым шагам.
                                                                                                                  Долго продвигались через такие понятия как переменная и функция.
                                                                                                                  Первой же большой проблемой стало объявление переменных в Go и два варианта присваивания (это для начала решили пропустить и взяли только один вариант).
                                                                                                                  Когда дошли до структур, столкнулись с тем, что человек не понимал как их создавать. Попытки объяснить проблему не решали.
                                                                                                                  С методами было совсем плохо, просто было не возможно объяснить разницу между обычной функцией и методом.
                                                                                                                  Про интерфейсы я совсем молчу.
                                                                                                                  Через месяц решили не мучатся.

                                                                                                                  Расчехлили Java, и буквально на второй день человек освоил классы, методы, и принципы ООП. Даже по глазам стало видно, что товарищь теперь все понимает, а не «тупит». Ну, вы же знаете этот горящий взгляд и желание быстрее что-нить накодить.

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

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

                                                                                                                      Ну и если почитать Роба Пайка и посмотреть его выступленя, становится понятно, что он человек очень спицефичный. Мне показалось, что ему гораздо важнее решить задачу правильно, чем решить задачу в принципе.
                                                                                                                        0
                                                                                                                        Мне Go показался простым. Хотя привлёк не этим, а сдвигом «фокуса». Его авторы переосмыслили, что сегодня является важным в языке, а что — не очень. на мой взгляд, их вариант лучше подходит для решения актуальных задач.

                                                                                                                        А вот смог бы я осилить Go первым или нет — фиг его знает. Именно поэтому очень инетересен опыт тех, кто пробовал.

                                                                                                                        ему гораздо важнее решить задачу правильно, чем решить задачу в принципе.

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

                                                                                                                    И приподносится этот материал по странному. В плане если в Java/C#/C++, когда разговор доходит о многопоточности первым делом говорится для чего это нужно и когда используется, в Go же это одна из основных концепций, и тем самым для совсем новичков это осложняет дело еще сильнее.

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

                                                                                                                    Если у человека есть опыт программирования даже просто в плане обучения на каком-нибудь Ruby/Python/Java, ему будет в этом разобраться будет не так уже тяжелее. Имел опыт общения с Go после C++, и в целом неплохо.
                                                                                                                    Go в целом язык ничего так, но не прям уж для запихивания во все дырки и не для совсем новичков. Это лично мое мнение.
                                                                                                                  –3
                                                                                                                  Спасибо за четкую, и по делу статью.
                                                                                                                  Как вы думаете, Go ориентирован только на серверное использование, или на нем можно забацать приложение с окнами, графикой, и еще какими то финтифлюшками?
                                                                                                                    –1
                                                                                                                    Сделать на go можно что угодно.
                                                                                                                    Мысль в том, что серверные многопоточные приложения быстрее и удобнее делать на go.
                                                                                                                    А для остальных особых преимуществ нет — дело вкуса.
                                                                                                                      –2
                                                                                                                      Спасиб.
                                                                                                                      Имею некоторый опыт работы с java, поэтому статья очень в тему.
                                                                                                                    +5
                                                                                                                    Открой для себя JNI
                                                                                                                      +1
                                                                                                                      Зачем?
                                                                                                                        0
                                                                                                                        Перформанс. Статья ведь об этом.
                                                                                                                          0
                                                                                                                          Но ведь это не жава? С таким же успехом можно писать на си и вызывать из го, не?
                                                                                                                            0
                                                                                                                            Статья не об этом. Она о продуктивности разработчика.
                                                                                                                              0
                                                                                                                              А мне показалось, что вы уперлись в потолок производительности и решили поменять инструмент. Пойду перекрещюсь.
                                                                                                                        0
                                                                                                                        Для решения этой проблемы используются внешние инструменты — менеджеры пакетов.
                                                                                                                        Один из лучших на сегодняшний день — glide.

                                                                                                                        Зачем использовать стороннюю утилиту, если данная проблема уже решена на уровне языка — используйте директорию vendor (v1.5 experimental, v1.6 default)
                                                                                                                        Кстати, директория vendor решила и ещё одну проблему о которой вы не упомянули, локальные импорты.
                                                                                                                          0
                                                                                                                          glide её использует
                                                                                                                          Просто он позволяет не хранить сторонние пакеты в своей системе контроля версий.
                                                                                                                          Каждый член команды может при помощи glide поместить в свою директорию vendor нужные версии сторонних пакетов.
                                                                                                                          +8
                                                                                                                          Судя по приведенным аргументам, все-таки остается впечатление, что выбор сделали скорее эмоциональный, нежели рациональный. Новый язык всегда изучать весело.

                                                                                                                          Если требуется поддерживать несколько тысяч клиентов одновременно, особенно при высокой частоте запросов как в онлайн игре, понятно что скорее всего придется использовать асинхронный ввод-вывод вместо традиционной модели «один поток на соединение». Тут, как говорится, и к гадалке (профайлеру) не ходи. Да, в Го это работает из коробки путем использования «горутин», ну а в Java можно использовать Netty.

                                                                                                                          Проблема с запуском профилировщика удаленно в Java совершенно надумана. Достигается добавлением пары опций в JVM.

                                                                                                                          Проблема с запуском нескольких тысяч клиентов тоже надумана. Зачем запускать настоящие клиенты, если можно с помощью того же Netty/NIO написать относительно несложную программу для нагрузочного тестирования, которая буквально с одного компьютера создаст достаточную нагрузку?

                                                                                                                          И в конце концов, в Го вы все равно можете упереться в сборщик мусора или, скажем, странное поведение планировщика горутин. И что тогда, снова все бросить и переписать на C++?

                                                                                                                          По-моему, шило на мыло. Выбросили существующий код и проверенную временем JVM ради «модного» языка из-за каких-то странных доводов.
                                                                                                                            –4
                                                                                                                            > а в Java можно использовать Netty.

                                                                                                                            Или VertX или Play или много чего еще.

                                                                                                                            > Проблема с запуском профилировщика удаленно в Java совершенно надумана.

                                                                                                                            Тут вы правы. Я неверно расставил акценты. На самом деле надо было сказать о простоте и удобстве работы со штатным профилировщиком go. По мощности он превосходит VisualVM и сравним с YourKit. По удобсвту работы — лучшее, что я видел вообще. Экономит много времени.

                                                                                                                            > написать относительно несложную программу для нагрузочного тестирования

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

                                                                                                                            > в Го вы все равно можете упереться в сборщик мусора

                                                                                                                            Да. Его пришлось отключить вовсе. Точнее перевести в ручной режим. Сначала код был переписан так, чтобы минимизировать использование кучи. Потом автоматический gc был отключен и заменен на код, который запускает его вручную, если свободной памяти на сервере осталось немного. Перед таким ручным запуском все клиенты принудительно ставятся на паузу. Происходит это редко и для игрока такое поведение много луше частых небольших лагов.

                                                                                                                            > Выбросили существующий код и проверенную временем JVM ради «модного» языка из-за каких-то странных доводов.

                                                                                                                            Ради опыта. Я знал сколько времени занимает решение подобной задачи на java. Я подозревал, что на go потребуется меньше. Я убедился, что да, меньше. Раза в два. И теперь я буду решать такие задачи на go и экономить свое время.
                                                                                                                            Этим вот опытом и поделился.
                                                                                                                              +7
                                                                                                                              Или VertX или Play или много чего еще.
                                                                                                                              Ну странно наличие вариантов рассматривать как минус. Так же можно было вместо Го использовать Rust, node.js или много еще чего.

                                                                                                                              Я подозревал, что на go потребуется меньше. Я убедился, что да, меньше. Раза в два.
                                                                                                                              Верю с трудом, особенно в долгосрочной перспективе, и тем более если есть опыт подобных проектов на Java.

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


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

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


                                                                                                                                Здесь сложно что-то возразить. У меня оно было так. Но каков в этом результате вес самого языка, моего проекта и моих личных предпочтений мне сказать трудно. Если есть опыт разработки таких проектов на java и если вас не раздражают VisualVM или YourKit, то, возможно, у вас будет другой результат.

                                                                                                                                Единственное, на чем я настаиваю — если взять двух новичков и один станет изучать java + экосистему, а второй go, то проект, подобный моему, быстрее получится у второго при прочих равных.
                                                                                                                                  +2
                                                                                                                                  Наличие вариантов имеет свои минусы (порог вхождения) и плюсы (можно подобрать наиболее оптимальный).
                                                                                                                                  Если говорить о продуктивности разработки, то наличие ровно одного хорошего способа сделать что-то будет плюсом, так как сэкономит время.
                                                                                                                                  Отсутствие альтернатив во все времена приводило к монополии. Наличие конкурентов/альтернатив вынуждает авторов библиотек совершенствовать свои продукты.

                                                                                                                                  Единственное, на чем я настаиваю — если взять двух новичков и один станет изучать java + экосистему, а второй go, то проект, подобный моему, быстрее получится у второго при прочих равных.
                                                                                                                                  А если взять профессионала, то тот выберет java, так как на ней лучше писать долгоживущие проекты?
                                                                                                                                    –1
                                                                                                                                    Отсутствие альтернатив во все времена приводило к монополии. Наличие конкурентов/альтернатив вынуждает авторов библиотек совершенствовать свои продукты.


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

                                                                                                                                    А если взять профессионала, то тот выберет java, так как на ней лучше писать долгоживущие проекты?


                                                                                                                                    А если взять профессионала, тот изучит проект и будет выбирать инструмент исходя из требований.
                                                                                                                            +8
                                                                                                                            «я слепил чего-то там на java и оно держало всего 300 коннектов, переписал на go — стало держать 2.5к» (с)
                                                                                                                            Ничего не имею против Go, но давайте поговорим о Ваших опытах с Java.
                                                                                                                            Есть куча суццесс стори задач схожих с вашей — сверера для мультиплеерных игр. Возьмем на пример Riot Games и их League of Legends, где на секундочку, онлайн в пики достигает 5 миллионов юзеров. Понятное дело там у них маштабирование и прочее, но если бы у них сервер держал 300 коннектов, то никаких денег бы не хватило, будь Ваши слова хотя бы отчасти правдой.

                                                                                                                            Если уж Вы пытаетесь продвинуть мысль того, что go производительнее java в разрезе вашей задачи, то пишите подробности реализации, сравнения, бенчмарки в конце концов. Насколько мне известно, Netty вообще одна из самых производительных штук в разрезе данного юзкейса и сдается мне, что Вы либо писали свои костыли либо просто не умеете в Netty…

                                                                                                                            Из всей статьи полезный и осмысленный только вывод…
                                                                                                                              +1
                                                                                                                              Если уж Вы пытаетесь продвинуть мысль того, что go производительнее java в разрезе вашей задачи


                                                                                                                              Вы неправильно поняли. В разрезе моей задачи производительнее не go, а программист, пишущий на go.
                                                                                                                              Он справится с такой задачей быстрее, даже если ранее имел опыт программирования на java и не имел на go.
                                                                                                                                +2
                                                                                                                                Т.е. в конторах пишущих игры ААА класса сидят дурачки, которые не знают, о том что программист на Go производительнее программиста на Java?! Тогда уж «в разразе Вашей задачи Вы пишущий на Go произовдительнее себя же пишущего на Java».
                                                                                                                                  0
                                                                                                                                  Т.е. в конторах пишущих игры ААА класса сидят дурачки, которые не знают, о том что программист на Go производительнее программиста на Java?!


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

                                                                                                                                  в разразе Вашей задачи Вы пишущий на Go произовдительнее себя же пишущего на Java


                                                                                                                                  Если говорить совем строго, то да. Именно так. Но я рискну расширить это утверждение до следующего «в разразе моей задачи человек с 18летним опытом программирования на java и нулевым опытом на Go, пишущий на Go произовдительнее себя же пишущего на Java»
                                                                                                                                    +11
                                                                                                                                    человек, который 18 лет разрабатывает на java и не знает о существовании возможности удаленного подключения профилировщика, вызывает подозрения
                                                                                                                                      –2
                                                                                                                                      Вы то точно разрабатываете на java со вчера и уже знаете абсолютно все, мы не сомневаемся =)
                                                                                                                                        +2
                                                                                                                                        Сомнения — признак критического мышления, а то, в свою очередь, признак здравомыслия
                                                                                                                                        0
                                                                                                                                        Вы правы. Не пойму, как я написал такое. На эмоциях, наверное. Очень раздражает меня VisualVM. Трудно найти что-то более неудобное.
                                                                                                                                          +3
                                                                                                                                          Согласен с тем, что не всё в мире java идеально и в эпоху перемен хочется свежего воздуха, я и сам внимательно смотрю на котлин. Здорово, что этот глоток свежего воздуха пришелся вам по душе, но все-таки статья скорее эмоциональный выплеск об этом, нежели что-то полезное в техническом смысле. Было бы интереснее, если бы вы описали какие аналогичные средства вы использовали в обоих реализациях и что именно было удобнее, возможно рассказать об архитектуре серверной части игры, а такой холиварный формат неизбежно вызывает раздражение у читающих
                                                                                                                                            –1
                                                                                                                                            Это всё от лени. Я просто взял и опубликовал собственный рассказ на корпоративном семинаре.
                                                                                                                                            По уму для хабра статью надо было перделать и писать примерно так: Вот уже 14 лет мы пробуем новые языки, чтобы не пропустить технологическую волну. До сих пор, ни один язык не выигрывал у явы в главном для нас параметре — в скорости разработки. Так было, пока не появился go.
                                                                                                                                            Этот самый go выиграл по этому параметру на таком-то проекте. Если ваш проект похож, обратите внимание на go.
                                                                                                                                            Тогда бы и холивара было бы поменьше.
                                                                                                                                              +7
                                                                                                                                              Холивара было бы поменьше, если такие статьи (саксес стори) по Go были более объективными.
                                                                                                                                              А так они все как под копирку. Одни досужие домыслы и притягивания за уши. Без какой либо конкретики.
                                                                                                                                              Добавьте сюда, по вкусу: вранье, передергивание или откровенное нубство в сравниваемой технологии (в данной статье про Java).
                                                                                                                                              И получите типичный холивар.
                                                                                                                                              Напишите нормальную статью. С примерами похожих задач.
                                                                                                                                              Вот так делали на Java (и это должен быть реальный пример на современных подходах и библиотеках).
                                                                                                                                              А вот так мы сейчас делаем на модном Go.
                                                                                                                                              С описанием и цифрами. Что улучшилось в процессах. Что улучшилось в коде. Что там с багами и поддержкой. Что с рефакторингом и т.д.
                                                                                                                                              Все вам огромное спасибо скажут.
                                                                                                                                              А то вот таких вот домыслов «вилами по воде» в каждом бложике миллион.
                                                                                                                                              Они ничего не улучшают, а только хуже делают.
                                                                                                                                              Ибо оставляют больше вопросов, чем дают ответов.
                                                                                                                                              А в отсутствии реальных фактов, люди начинают сплетничать и фантазировать на тему как оно там может быть…
                                                                                                                                                –1
                                                                                                                                                Вы пишите о вранье, передергивании и нубстве и тут же требуете цифр, примеров и фактов.
                                                                                                                                                Допустим я скажу, что аналогичная задача на яве заняла у меня X дней, а на go — Y (где Y<X), вас это убедит?

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

                                                                                                                                                Проблема совсем не в фактах, а в неаккуратном позиционировании моей статьи. Многие тут посчитали, что я хвалю go и ругаю java, приводя в качестве (слабого) аргумента некую сомнительную, как вы сказали «success story». Я сам дал повод так понять эту статью неаккуратной расстановкой акцентов.

                                                                                                                                                Где-то уже писал, что статья не про то. Она про: «ребята, смотрите, go гораздо менее требователен к вашему времени и усилиям по крайней мере на некоторых видах задач. Если ваши задачи схожи, то Go стоит попробовать. Возможно, вы получите некоторый profit.»
                                                                                                                                                  +4

                                                                                                                                                  Оставьте цифры. Дайте пример с кодом или описанием архитектуры на Java и, соответсвенно на Go.


                                                                                                                                                  Без этого создается впечатление именно нубства (может это и не так) из-за 300 клиентов, неспособности запустить профайлер, а также довольно спорного описания самого языка. О проекте при этом ни слова кроме того, что у вас получилось на Go лучше чем на Java.

                                                                                                                                                    0
                                                                                                                                                    Вы хотите от меня доказательств заведомо ложного тезиса вида «На java нельзя создать такой же быстрй сервер, как на go». Можно. Я думаю, он даже будет поддерживать несколько бОльшее количество клиентов.
                                                                                                                                                    Я утверждал лишь, что создание такого сервера на go занимает меньше времени и сил.
                                                                                                                                                    Как наличие (плохого) кода на java и хорошего на go может подтвердить или опровергнуть моё утверждение?
                                                                                                                                                      +2
                                                                                                                                                      Я утверждал лишь, что создание такого сервера на go занимает меньше времени и сил.

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


                                                                                                                                                      Как наличие (плохого) кода на java и хорошего на go может подтвердить или опровергнуть моё утверждение?

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

                                                                                                                                                        0
                                                                                                                                                        на Go разрабатывать проще и быстрее, чем на Java, потому что я плохо знаю Java


                                                                                                                                                        А go не знаю совсем. Это не меняет дело?

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


                                                                                                                                                        Но у меня нет хорошего кода на ява, который делает то же самое. Он мне не был нужен.
                                                                                                                                                          +2
                                                                                                                                                          А go не знаю совсем. Это не меняет дело?

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

                                                                                                                                                            –3
                                                                                                                                                            Я просто не вижу смысла спорить с вами о своём профессиональном уровне.
                                                                                                                                                            По двум причинам. Во-первых, вы уже все для себя решили, а во-вторых меня не интересует профессиональное мнение человека, который родился в тот год, когда я написал свой первый профессиональный код — часть АСУТП для Сургутской ГРЭС.
                                                                                                                                                              0

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

                                                                                                                                                                0
                                                                                                                                                                Это я на случай, что кто-то почитает комменты и согласится с вашим посылом про «нубы, перебирайте языки...» только потому, что я ничего не возразил.
                                                                                                                                                                +6
                                                                                                                                                                О, пошел в ход возраст. Это много говорит о вас.

                                                                                                                                                                P.S. Это случайно не та самая ГРЭС где 2 раза крупные аварии были? Совпадение? ))
                                                                                                                                                      +3
                                                                                                                                                      > Допустим я скажу, что аналогичная задача на яве заняла у меня X дней, а на go — Y (где Y<X), вас это убедит?

                                                                                                                                                      Вы вообще не понимаете, что такое «объективность» чтоли?

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

                                                                                                                                                      Менее требователен по сравнению с чем? Как сравнивали, чем мерили и т.д.
                                                                                                                                                      Эта фраза и есть «досужие домыслы».
                                                                                                                                                      Вы даже поправляя «позиционирование» статьи, лучше не делаете. Даже в этих каментах вы не понимаете, что делаете и продолжаете разжигать холивар на ровном месте.