Почему язык Go стал стандартом для DevOps-инженеров

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

    В 1960-е годы Кен Томпсон — легенда программирования — написал компьютерную игру Space Travel для операционной системы Multics. Система была проектом компании Bell Lab, где он работал вместе с Денисом Ритчи. Позже проект закрыли, и чтобы продолжать играть в свою Space Travel, Томпсон решил портировать ее на компьютер PDP-7. Инструменты, которые он создал для порта, затем легли в основу операционной системы Unix. 

    Томпсон написал в одиночку первые три версии. Для Unix был нужен системный язык — так появился B. Позже Денис Ритчи, коллега и друг Томпсона, подхватил разработку и написал язык C. Вот так в основе почти всего, на чем построены современные технологии, лежало желание поиграть в компьютерную игру и пет-проекты для забавы.

    Кен Томпсон построил блестящую карьеру исследователя в области computer science. В середине 2000-х он устроился в Google, где вместе с Робом Пайком и Робертом Грейсмером создал Golang — один из самых популярных языков последнего времени.


    Go придумывали как простой язык для всего

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

    Мы все сошлись на том, что ненавидим C++, и решили, что ни одна фича не попадает в язык, пока каждый из нас троих не будет убежден в ее необходимости — и тогда язык не обрастет лишним мусором, появившимся непонятно зачем.

    Кен Томпсон

    Создатели хотели решить проблемы медленной сборки программ, неконтролируемых зависимостей, сложной разработки инструментов и проблем межъязыкового взаимодействия. За основу языка они взяли C, Pascal и Oberon и попытались собрать из них все лучшее. В итоге они стали делать язык с очень простым синтаксисом, строгой статической типизацией, автоматической сборкой мусора и простыми средствами для управления многопоточностью.

    Golang анонсировали в 2009 году, в 2012 состоялся релиз. Язык быстро стал набирать популярность, но и сталкивался с критикой. Ключевую фишку языка — простоту — многие разработчики посчитали и главным минусом. 

    «Из-за стремления к простоте в Go отсутствуют конструкции, которые в остальных языках воспринимаются как что-то естественное. Вначале это может показаться хорошей идеей, но на практике выходит многословный код, — писал Гэри Уилоуби. — Go был разработан, чтобы быть простым, и он преуспел в этой цели. Он был написан для слабых программистов, используя в качестве заготовки старый язык. Поставляется он в комплекте с простыми инструментами для выполнения простых вещей. Его просто читать и просто использовать. Он крайне многословный, невыразительный и плох для умных программистов».

    Но такая критика была и не совсем критикой для создателей языка. Сам Роб Пайк описывал язык почти также, но в отличие от критиков, не говорил о невыразительности как о чем-то плохом:

    Ключевой момент здесь, что в гугле работают не исследователи. Они, как правило, молоды, идут работать после учебы, где, возможно, изучали Java, или C/C++, или Python. Они не смогут сразу разобраться в навороченном языке, но в то же время мы хотим, чтобы они создавали хорошее ПО. Именно поэтому язык должен быть прост для понимания и изучения.

    Тем не менее, уже в 2012 году многие разработчики увидели перспективы Go в тех областях, для которых его изначально не задумывали. В своем твиттере Дерек Коллисон писал:

    * Прогноз: в течение следующих двух лет Go станет доминирующим языком для IaaS, PaaS и оркестрации. 

    Так и произошло — почти в то же время, когда создавали язык, в IT начала стремительно развиваться культура DevOps, в которой Go почти сразу стал стандартом.

    19% в DevOps планируют использовать Go в будущем, около 10% уже используют Go
    19% в DevOps планируют использовать Go в будущем, около 10% уже используют Go

    DevOps придумывали как agile для инфраструктурщиков

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

    Рано или поздно ошибку устраняли (или нет), и все начиналось заново.

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

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

    В 2008 году администратор баз данных Патрик Дебуа поехал на конференцию Agile Toronto, где познакомился с другим админом — Андрю Клэй Шафером. Оба интересовались аджайлом и тем, как бы получше внедрить его в сисадминское дело. На той же конференции они увидели выступление, где один из спикеров говорил, как в его команде разработчики и админы пытаются работать вместе. 

    Из всех этих дискуссий Дебуа и Шафер вынесли идею провести отдельную конференцию, посвященную только этим вопросам. 

    В то время еще не было термина Devops — была только идея. Я написал в твиттере, что было бы здорово провести конференцию в Европе и обсудить саму идею. Agile System Administrators — так себе название для мероприятия, поэтому мне предложили назвать его DevOpsDays — с этого и началось движение Devops.

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

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


    Почему Go и DevOps идеально подошли друг другу

    Когда в Google начали разрабатывать Kubernetes — у команды уже накопилось огромное наследие инструментов для контейнеризации. Но Кубер начали писать с нуля, поэтому встал вопрос выбора языка. Джо Беда, основной разработчик сервиса, рассказывал, что в Гугле используются многие языки — не только свои разработки — и они выбирали между С/С++, Java и Python. 

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

    Java не подошла, потому что разработчики стремились сделать установку простой на как можно более широком количестве платформ. Python откинули из-за динамической типизации.

    А вот Go по словам Беды был «и не слишком высокоуровневым, и не слишком низкоуровневым». Список причин, почему команда Kubernetes выбрала его, довольно широк:

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

    • Быстрые инструменты. «С ними мы подсели на скорость разработки», — пишет Беда.

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

    • Анонимные функции.

    • Сборка мусора, о которой не надо задумываться.

    • Строгая типизация.

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

    Три основные причины

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

    • У него самая простая для использования многопоточность. Горутины и Каналы — фичи, которые хвалят даже те, кто невзлюбил Go. 

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

    «По сравнению с Python, Ruby или Node.js, установка единственного исполняемого файла — мечта инженеров по эксплуатации. Конечно, это вовсе не такая большая проблема с учетом все более широкого использования Docker, но отдельные исполняемые файлы еще и уменьшают размер контейнеров», — пишет Сильвиан Валлез.

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

    Что вы сами думаете про Go? Как и почему используете? Заходите к нам в сообщество — там мы постоянно разбираем различные проблемы и задачи из сферы Devops, обсуждаем вещи, которые пригодятся и на собеседованиях, и в работе. 

    Ребреин
    REBRAIN: Онлайн-практикумы для Инженеров

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

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

      Так и есть, а ещё все всегда корректно обрабатывают nil ресивер в методах, а зубные феи существуют

        –1
        Не вижу противоречий с автором вашем комментарии
        +22
        s/Oberton/Oberon/
      • НЛО прилетело и опубликовало эту надпись здесь
          –7

          Т.е. для микросервисов вполне применимо

            +12

            Пока вы будете писать


            res, err := makeSomething()
            if(err != nil) {
                ....
            }
            ...

            Проекты на спрингбуте или кваркусе уже будут в продакшене :)))

              +13

              … будут в продакшене рестартовать от NPE и OOM (потому что JVM на пару со спрингом съели всю память задолго до выполнения хоть какой-то бизнес логики)

                –3

                Только не под GraalVM

                  +4

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

                    0

                    Вам выше quarkus предлагали, там и graalvm и memory footprint и время старта отличные)

                      +1

                      Отлично. Осталось все переписать со спринга на кваркус и потом пытаться как-то это собрать на GraalVM. Не проще ли тогда на Go?

                        0

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

                          –6

                          Так на Go скорость разработки выше :)

                          • НЛО прилетело и опубликовало эту надпись здесь
                              +13
                              Не знаю, качественный и безопасный код на Го писать одновременно дольше и сложнее. А в процессе ещё и жутко противно, потому что от мысли «а из какой криокамеры достали тех злодеев, которые выкатили ЭТО на-гора во второй половине нулевых» избавиться совершенно невозможно.
                                +3

                                Что значит из какой криокамеры?
                                Это же Томпсон и Пайк из белл-лабс, авторы юникса и си.
                                Пайк ещё и соавтор систем план-9 (названной в честь трешового фильма ужасов) и инферно (названной понятно в честь какой локации).
                                Так что он вполне мог кричать АХАХАХ, оживляя гошечку.

                                  –2

                                  Вы можете обосновать свое утверждение? Оно несколько не очевидно. Особенно что касается concurrency — реализация в Go позволяет писать намного более качественный и безопасный код

                                    +3

                                    После STM в других языках гошные каналы — это таки шаг назад.

                                      –1
                                      STM это куда, извините?
                                        +1

                                        Это software transactional memory.

                                      +1

                                      После вот этой статьи утверждения о простоте concurrency в Go воспринимаются с большим подозрением…

                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          +1
                                          Вообще-то ещё у Янга в книге «Алгоритмические языки реального времени. Конструирование и разработка» (русский перевод выпущен в 1985 году) разбирается модель рандеву, реализованная в Ada-80, и делается вывод о её небезопасности. Возможно, конечно, что в последующих стандартах что-то поменялось…

                                          Рандеву в Ada построено на черновике CSP Хоара — с безымянными каналами и именованными получателями, тогда как в основе Go финальная редакция книги — с именованными каналами и безымянными получателями.
                                            0
                                            А есть еще Erlang, по сравнению с которым гошная concurrency — детский сад.

                                            Вот по сравнению с Erlang с единственным входным каналом на процесс таки пусть будет лучше Go. Go ещё и компилируемый с доступной статической типизацией. Штатно добавить обёртку "послать сообщение о панике" и можно будет строить схему супервизоров, как в OTP. Что ещё нужно?

                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                –1

                                                Горячее обновление — да, согласен, это одна из хотелок. Это то, что в Go не предвидится — они идут путём наоборот. С другой стороны, индустрия наработала множество методов обойтись без этого горячего обновления через разделение хранилища состояния и кода обработки, и контейнеризации каждого; если 99% загоняют код в образы докера/кубера/etc., их горячее обновление на месте не волнует. Его ещё и совместить с нынешними devop-средствами, мягко говоря, непросто.


                                                Отказоустойчивость — как уже сказал, обёртка типа "свистнуть супервизору про панику" плюс простой супервизор (пара сотен строчек) и получим то же самое в Go. Если никто не делает — наверно, в таком виде оно не нужно?


                                                "Простое и эффективное построение распределенных систем" — если речь про кластеризацию Erlang, то она только сейчас становится похожей на что-то более-менее приличное, и то со средствами не из коробки. В каком там релизе начали понимать, что нодовый heartbeat надо отделить от межнодового обмена данными? И почему global рвётся от любой проблемы кластера?


                                                "Мягкого реального времени" — да они, считай, все такие сейчас. И Go тут улучшают с каждым релизом.


                                                "простой парсинг протоколов" — о чём речь? О binary matching? Это очень вспомогательная фича, которая неспособна решить, например, JSON (строки в виде списков в 2021 уже не смешны, а страшны… а с бинаркой слишком многое неудобно).
                                                Ещё что-то?

                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    Докеры с куберами — костыли и ненужная прослойка, когда все, что нужно для комфортной работы уже есть в языке.

                                                    И в язык входит компиляция, разлив файлов по системам, корректировка конфигов, раздача опций, синхронизация рестартов и т.п.? Тогда это уже не Erlang/OTP, а какие-то супернавески над ним (равномощные куберу), я таких не видел. Назовите.


                                                    Я писал на Go 2 года и устал материться и плеваться с этого убожества. Сейчас пишу на Erlang, Standard ML и F* и мне ништяк.

                                                    Ну а я писал на Erlang 5 лет. На Go не пишу, косо посматриваю, но случая пока не было, всё по чужим отзывам (которых тысячи). По Erlang отзыв я дал — чем дальше, тем больше его отсталость начинает мешать. Если Go убожество (не спорю), то Erlang такое же вдвое.


                                                    Если хотели поспорить, то не с тем начали — мне плевать на чужое мнение.

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

                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        +2

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

                                          +4
                                          Скорость разработки выше для относительно простых задач, а вот с ростом сложности проекта уже начинают мешать ограничения языка и скорость разработки падает, зачастую вместе с читаемостью кода. Например, пресловутое отсутствие дженериков затрудняет написание обобщенного кода. А невозможность перегрузки операторов вынуждает, например, вместо «z := x + y» писать плохо читаемый ужас вроде z.Add(&x, &y). Но радует, что язык развивается и постепенно избавляется от шероховатостей.

                                            +1
                                            Скорость разработки выше для относительно простых задач

                                            что в вашем понимании относительно простая задача?

                                              +1

                                              Задача, простая относительно более сложных задач %)

                                        0

                                        К сожалению в плане библиотек и их качества го пока еще в догоняющих

                                  +10

                                  Как будто приложения на Go не падают от null nil pointer dereference

                                    +22

                                    Но это ведь nil, а не null, значит совершенно другое!

                                  –1
                                  if err != nil { } писать долго, вот на java писать быстро

                                  Как-то очень странно слышать такую критику в контексте java, где без автоматической генерации сотен конструкций (throws — у методов, конструкторов, get/set-методов, лямбд и многого-многого другого) жизни вообще нет? На go можно писать вообще без IDE, и если делать это не двумя пальцами, if err != nil {} вообще не замечаются.


                                  Почему условный jetbrains с java, в котором на каждое второе нажатие на клавиатуру генерируется какой-то код — это хорошо, а условный jetbrains с go — это плохо?

                                    +1
                                    На go можно писать вообще без IDE

                                    А зачем?


                                    где без автоматической генерации сотен конструкций

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


                                    а условный jetbrains с go — это плохо?

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

                                      –5
                                      Для меня Го не плохо, а шаг назад. Я должен писать тонны однотипного кода, вместо сосредоточения на бизнес логике.

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


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

                                      А у меня код на go выглядит чисто и просто так просто потому, что он на go. И тот же goland умеет автоматически скрывать однотипные if err != nil { return nil, err } (точно так же, как idea скрывает сотни других однотипных конструкций в java). Что дальше?

                                        +1
                                        Скорость написание кода для меня упирается в скорость мыслительного процесса

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


                                            @Incoming("fruit-in")
                                            @Outgoing("fruit-out")
                                            fun makeSomething(item: Fruit): Fruit {
                                                ...clean logic
                                            }

                                        можно теперь пример кода на Го, который затмит сие творение?


                                        А у меня код на go выглядит чисто и просто так просто потому, что он на go.

                                        опять же можно пример такого чистого кода?


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


                                        Flux.just(url1, url2, ...)
                                            .flatMap(url -> getContent(url).onErrorReturn("default value"), 5)
                                            .reduce("", (accum, content) -> accum + content)

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


                                        скрывает сотни других однотипных конструкций в java

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

                                          0
                                          можно теперь пример кода на Го, который затмит сие творение?

                                          Конечно, абсолютно так же скрыв весь support-code, я напишу так:


                                          func (fr *fruitConsumer) OnMessage(item Fruit) error { ... }


                                          .onErrorReturn("default value")

                                          Отличный пример, почему обработка ошибок в go вынуждает писать нормальный код. А если сеть на сервере совсем упала? Вместо результата будет тыква. Жесть какая-то.

                                            0
                                            func (fr *fruitReader) OnMessage(item Fruit) error { ... }

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


                                            Отличный пример, почему обработка ошибок в go вынуждает писать нормальный код. А если сеть на сервере совсем упала? Вместо результата будет тыква.

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


                                            .onErrorReturn(ConnectTimeoutException.class, "default value")

                                            так где же ваш чистый код? и сотни скрывающихся конструкций в Джаве?

                                              0
                                              а я всю обвязку с кафкой

                                              Нет. Это не вся обвязка. Incoming и Outgoing откуда-то дожны взяться. Формат сериализации тоже нигде не указан. Вот выложите минимальный пример проекта, читающий/пишущий фрукты — я напишу аналогичное на go. Да, библиотека для go более низкоуровневая и содержит меньше сахара, но нужно учитывать, что обвязки один раз под проект пишутся и много раз используются.


                                              .onErrorReturn(ConnectTimeoutException.class, "default value")

                                              Это как пример был

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

                                                0
                                                Формат сериализации тоже нигде не указан

                                                вот сериализатор


                                                import io.quarkus.kafka.client.serialization.ObjectMapperDeserializer;
                                                
                                                public class FruitDeserializer extends ObjectMapperDeserializer<Fruit> {
                                                    public FruitDeserializer(){
                                                        super(Fruit.class);
                                                    }
                                                }

                                                Incoming и Outgoing откуда-то дожны взяться.

                                                # Configure the Kafka source (we read from it)
                                                mp.messaging.incoming.fruit-in.connector=smallrye-kafka
                                                mp.messaging.incoming.fruit-in.topic=fruit-in
                                                mp.messaging.incoming.fruit-in.value.deserializer=com.acme.fruit.jackson.FruitDeserializer
                                                
                                                # Configure the Kafka sink (we write to it)
                                                mp.messaging.outgoing.fruit-out.connector=smallrye-kafka
                                                mp.messaging.outgoing.fruit-out.topic=fruit-out
                                                mp.messaging.outgoing.fruit-out.value.serializer=io.quarkus.kafka.client.serialization.ObjectMapperSerializer

                                                вот и все готовое приложение на кваркусе.


                                                теперь ваша очередь.


                                                Да, без них это будет страница кода, но это будет страница кода, безупречно отрабатывающая во всех ситуациях без неопределенного поведения и тихого заглатывания ошибок

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

                                                  0
                                                  mp.messaging.outgoing.fruit-out.connector=smallrye-kafka
                                                  mp.messaging.outgoing.fruit-out.topic=fruit-out
                                                  mp.messaging.outgoing.fruit-out.value.serializer=io.quarkus.kafka.client.serialization.ObjectMapperSerializer

                                                  Жесть. go так не может, считайте это своей победой, если хотите, лол.

                                                    0
                                                    Что го не может? Использовать properties-файлы? Да вроде прекрасно может.
                                                      0

                                                      ну да, лучше на Го потратить неделю и написать Войну и Мир для этой простой задачи :)

                                                        –2

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

                                                          +2
                                                          Куда большая проблема — то, что эта вся “простота” пожирает память и ядра процессора, как не в себя.

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

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

                                                          Каждому — своё, конечно.
                                                            –1

                                                            Да, все абсолютно так же, как с тем примером, который кидали выше. Вроде все очень просто, но когда начинаешь отвечать на сложные вопросы, вроде:


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

                                                            Возвращаясь к примеру "опросить большой список URL": тот java код создает только иллюзию завершенности. На деле при эксплуатации возникнет просто нереальное количество проблем, которые хорошо, если заметят. На одной из моей прошлых работ это было целым тестовым заданием, и неспроста: учеть все возможные случаи непросто, как и написать код, на который ты реально сможешь полагаться в продашконе (особенно, если highload).

                                                              –1
                                                              Вроде все очень просто, но когда начинаешь отвечать на сложные вопросы, вроде

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


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

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

                                                              0
                                                              Куда большая проблема — то, что эта вся “простота” пожирает память и ядра процессора, как не в себя.

                                                              Предположим, что ваше утверждение верно и наше джава приложение жрет память — вот цена в Орегоне на EC2 инстансы:
                                                              t3.nano 0,5 ГиБ 0,0052 USD за час
                                                              t3.micro 1 ГиБ 0,0104 USD за час


                                                              получаем разницу в 40 долларов в год, это меньше чем час работы среднего джависта в штатах!!!

                                                                0
                                                                Некоторое время назад статья от яндекса была, по упаковке python приложений, и они хотели от докера перейти к упаковке в бинарники или что-то такое. Вобщем причина «когда приложение запущено на 10к серверов, то эти пара процентов выливаются в приичную сумму», а тут приезжают джависты на белом коне «Гуляем, я плачу»=)
                                                                Вобщем вопрос, платить то кто будет за 10к инстансев, программист который решил «Да чем там той памяти, она ж дешевая»? или Джава годится только для приложений которые в одном эксзщемпляре запускаются на 1гб памяти? спору нет, чеб тогда не транжирить ресурсы=)
                                                                  0
                                                                  1. Те разницу по времени в разработке вы успешно пропустили и расходы посчитали только на память???


                                                                  2. слышали You Are Not Google или во вашему весь мир запускает 10К серверов???


                                                                  3. Если мне надо микросервис на 10К инстансов и считать каждый мегабайт и цикл цпу то я возьму Раст.


                                                            0

                                                            Кажется, дискуссия из обсуждения проблем языка переросла в обсуждение наличия библиотек и фреймворков для конкретных языков. Есть тот же go-kit далёкий от идеала, но имеет некоторое количество реализованных транспортов, и спрятать реализацию за интерфейсом в go вполне себе можно. Хотя это не отменяет основных проблем go: многословность и невыразительность. В том же go-kit в некоторых местах используется interface{}, считай, void*, что на корню убивает все прелести статической типизации, а иначе сделать не выйдет, потому что нет обобщений. Отсюда и проблемы с библиотеками, которые по определению нельзя реализовать по типу stl, и это печалит. Либо генерировать код, как предлагает Пайк, что странно в 2021, когда все другие языки давно умеют в дженерики, либо — копипастить одни и те же алгоритмы, подставляя свои значения, либо использовать интерфейсы и ломать типизацию, используя на входе и выходе interface{}, и это ужасно. Вот нашелся в интернете человек, скажем, который реализовал нужный алгоритм и выложил в виде пакета. Все классно, но у него, к примеру, используется int32, а мне нужен int64, все, баста карапузики, только копипаста. Некоторые, конечно, заморачиваются и пилят генераторы кода с инструкциями по использованию, но это же очевидный костыль. Есть ещё масса других проблем поменьше, о которых уже выше сказали, типа тех же ошибок, присваивания, nil и приведения типов. Прошу прощения за объем — наболело за два года использования go. Как-то пришлось делать свою реализацию каналов amqp, потому что общедоступная никак не реагирует на разрыв соединения и такого навалом.

                                            –1
                                            где без автоматической генерации сотен конструкций (throws — у методов,

                                            Это цивилизованный аналог if err != nil {} для явного проброса исключений. При сравнении с другими языками можно холиварить насколько это нужно, но при сравнении с го странно ставить это в минус


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

                                            Они необязательные, автогнереить их ненадо если не используешь


                                            get/set-методов,

                                            Сейчач в джаве есть рекорды(если говорим про современную джаву). Или мы сравниваем старую джаву с новой версией го?


                                            лямбд

                                            Вот тут непонял, а где там автогенреция иде нужна?


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

                                              –3
                                              Это цивилизованный аналог if err != nil {} для явного проброса исключений. При сравнении с другими языками можно холиварить насколько это нужно, но при сравнении с го странно ставить это в минус

                                              Я с этим не согласен и считаю, что система в go удобнее и более гибкая. Особенно с тех пор, как error wrapping завезли в стандартную библиотеку. В go практически любая функция может вернуть ошибку и это 1) соответствует действительности 2) позволяет добиться чрезвычайной гибкости. Аналогичный код на java писать практически невозможно: либо throws Exception, либо throws over9000 different exceptions во всей цепочке методов.


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

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


                                              Начал кстати смотреть, что там завезли с records, нашел статью: "Одной из проблем Java является ее многословность и объем необходимого стандартного кода. Это общеизвестно.". Ну т.е. даже люди, пишушие на java это особо не отрицают.


                                              Они необязательные, автогнереить их ненадо если не используешь

                                              Не использовать конструкторы в java — это как?

                                                +2
                                                В go практически любая функция может вернуть ошибку

                                                Начнем с того что ошибка в го ничем не отличается от значения. И их очень легко пропустить и пойти дальше с ошибочным значением.
                                                res, err := makeSomething() мы забили на ошибку и пошли дальше с результатом res — ни в джаве, ни в расте такого уродства вы не получите


                                                Аналогичный код на java писать практически невозможно:

                                                на джаве вы можете писать


                                                • используя checked exceptions
                                                • unchecked exceptions
                                                • взять vavr и гонять везде Either
                                                • сделать такую же фигню как и в Го и возвращать Pair

                                                и не забываем что в Го вы так же можете получить Panic

                                                  0
                                                  И их очень легко пропустить и пойти дальше с ошибочным значением.

                                                  Нет, не просто. Есть линтеры errcheck и ineffassign (которые, кстати, полезны во всех ситуациях, не только в ошибочных). В продакшон-коде такие ошибки не допускаются.


                                                  и не забываем что в Го вы так же можете получить Panic

                                                  И?

                                                    0
                                                    Нет, не просто

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


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

                                                      Тогда концепция java "плохая", потому что позволяет делать пустые обработчики exception.


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

                                                      И? Оно не используется как exception в java. RTFM

                                                        +1
                                                        Тогда концепция java "плохая", потому что позволяет делать пустые обработчики exception.

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


                                                        Оно не используется как exception в java.

                                                        серьезно? Почитайте про парсер json имплементацию в Го, там оно во всю использовалось.


                                                        или вот наугал взяв https://github.com/golang/go/issues/30489
                                                        отличное поведение паниковать когда не можешь разпарсить жсон :))))

                                                          –1
                                                          или вот наугал взяв https://github.com/golang/go/issues/30489

                                                          А слабо было прочитать, что по ссылке написано? Панику вызывает не encoding/json, а клиентский код.


                                                          в Го же вы получаете ошибку и результат одновременно

                                                          И это в некоторых ситуациях чуть ли не обязательно. Особенно при работе с i/o.


                                                          Пустой обработчик это тоже обработчик. просто вы решили что вам эта ошибка не нужна.

                                                          И в чем тогда суть претензии? В go можно сделать пустой обработчик, в java можно сделать пустой обработчик.

                                                            0
                                                            И это в некоторых ситуациях чуть ли не обязательно. Особенно при работе с i/o.

                                                            А можно какой-нибудь (пусть и абстрактный) пример? Где можно осмысленно использовать и результат и ошибку.


                                                            И в чем тогда суть претензии? В go можно сделать пустой обработчик, в java можно сделать пустой обработчик.

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

                                                              0
                                                              А можно какой-нибудь (пусть и абстрактный) пример? Где можно осмысленно использовать и результат и ошибку.

                                                              io.Reader, io.Writer

                                                                0

                                                                Больше интересно, что как выглядит логика поверх такого интерфейса. Особенно если ошибка не EOF, а что-то другое.

                                                                  +1
                                                                  Например short read/short write, которые часть POSIX-a

                                                                  Было записано/считано N bytes, дальше ошибка. Приложение должно уметь это обрабатывать, но в этом месте очень часто баги. Не берусь судить, из-за того что разработчики такого не знали, или изначально работали с языком который завернул им все в «либо ошибка либо результат»

                                                                  И в этом месте очень часто баги
                                                                    0

                                                                    Спасибо, любопытный пример.

                                                                      0
                                                                      Например short read/short write, которые часть POSIX-a
                                                                      А не расскажите, где и как они возникают?

                                                                      Потому что всякие read/write именно что возвращают либо результат, либо ошибку.

                                                                      Не берусь судить, из-за того что разработчики такого не знали, или изначально работали с языком который завернул им все в «либо ошибка либо результат»
                                                                      А ничего что именно так устроены системные вызовы в Linux? И они в принципе не могут вернуть одновременно и ошибку и что-то ещё?

                                                                      P.S. И нет, я могу себе представить другой POSIX, в другой, параллельной, вселенной… но вроде как вы говорите про нашу… или нет?
                                                                  0

                                                                  Посмотрел кстати на rust std:io::Read — и что-то не очень ясно, как они обрабатывают эту ситуацию ("что-то пошло не так, но считать n байт успели"). Возвращает ошибку только на следующий вызов read()?

                                                                    0

                                                                    Там же написано в документации:


                                                                    Errors

                                                                    If this function encounters any form of I/O or other error, an error variant will be returned. If an error is returned then it must be guaranteed that no bytes were read.
                                                                      0
                                                                      Возвращает ошибку только на следующий вызов read()

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

                                                                        +1
                                                                        If an error is returned then it must be guaranteed that no bytes were read.

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

                                                                          +1

                                                                          Это имеет смысл и реализация в rust мне нравится больше, io.Reader/io.Writer в go, на самом деле, проблематичны и по ряду многих других причин (особенно, если копать глубоко).

                                                                            0
                                                                            Я думаю не только мне будет интересно узнать про проблемы io.RW подробнее. Расскажите пожалуйста.
                                                            +1
                                                            то что в нутрях го это нормальный подход — паник/рекавери и это ни что иное как джава ексепшены.

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

                                                        0
                                                        Я с этим не согласен и считаю, что система в go удобнее и более гибкая. Особенно с тех пор, как error wrapping завезли в стандартную библиотеку. В go практически любая функция может вернуть ошибку и это 1) соответствует действительности 2) позволяет добиться чрезвычайной гибкости. Аналогичный код на java писать практически невозможно: либо throws Exception, либо throws over9000 different exceptions во всей цепочке методов.

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


                                                        Начал кстати смотреть, что там завезли с records, нашел статью: "Одной из проблем Java является ее многословность и объем необходимого стандартного кода. Это общеизвестно.". Ну т.е. даже люди, пишушие на java это особо не отрицают.

                                                        Так я тоже согласен, но в джаве как раз это активно меняется. Из примеров что было сделано за последние пару лет-новый switch, records, instanceOf, var. В работе primitives(хотя тут цель другая), destructuring.
                                                        Ваш пример попал как раз на то что уже изменено. Да, куча легаси проектов не будут использовать это, но если мы говорим в целом про язык-в джаве этот уже можно писать без этого бойлерелплейта.
                                                        Ну и го тоже довольно многословный, из лаконичных языков пример для меня это python.


                                                        Не использовать конструкторы в java — это как?

                                                        Типичный код на джаве


                                                        public class HelloWorld{
                                                        
                                                             public void doSmth(){
                                                                System.out.println("Hello World");
                                                             }
                                                        }

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

                                                          0
                                                          Если он не нужен то объявлять его нет необходимости.

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

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

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

                                                              –1
                                                              Я возможно непонимаю, но нехотите — неиспользуйте конструкторы совсем

                                                              И что использовать вместо них? Так-то можно и классы совсем не использовать, в теории. На практике — с трудом.

                                                    0
                                                    Ну, можно писать
                                                    res, _ = makeSomething()
                                                    ...


                                                    А ошибки обрабатывать методом перезапуска упавшей программы. Многие так и делают, и вполне счастливы :-)
                                                      0

                                                      так как вы написали вы успешно проглотили ошибку но у вас есть результат а дальше вы пошли работать с результатом. а вот в джаве с ее эксепшенами у вас все успешно упадет и реквест завершится с 500 ошибкой

                                                      –2

                                                      Не будут, на спрингбуте в это же время будут писать очередной совершенное ненужный AbstractFactoryFactory, XXXService, XXXProvider и прочий говнокод

                                                    +6
                                                    Пишу на Go больше 2х лет — одно удовольствие. Haters gonna hate, ain'ters gonna ain't.
                                                      +2

                                                      А на чём ещё вы писали? Вам есть, с чем сравнивать?

                                                        0
                                                        В основном C/C++
                                                          +1

                                                          Примерно всё, что угодно, лучше C и C++.

                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                          0
                                                          Не вижу ничего плохого в том, что человек использует, то что ему нравится и еще деньги за это получает. Мне не понятны нападки на конкретный язык. Какой язык по-вашему мнению «правильный» и над которым вы не будете насмехаться?
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                              +1

                                                              Аналогично, по моему мнению — Rust для низкоуровневой ерунды, Agda или Idris для доказательств, Haskell для всего остального.

                                                        –2

                                                        Потому что запихать в докер что-то другое невероятно сложно

                                                          +1

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


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

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

                                                            Ещё сейчас у нас, например, в виндовом контейнере работает агент тимсити, собирает плюсовый и шарповый код.
                                                            +6

                                                            Настолько популярный, что на вакансию middle на 150-200к никто не откликается. В отличии от условного ts/react =)

                                                              +2
                                                              Вероятнее всего в вашей вакансии требуется не только Go и опыт коммерческой разработки наверняка от 3 лет. Может просто стоит немного снизить требования. При этом можно будет снизить и зарплату. И поднять ее тогда, когда человек дорастет до требуемого уровня.
                                                              Откуда браться мидл разработчикам, если все хотят только мидлов? Нашел только одну более менее вменяемую вакансию для джуна на весь Питер. На тот же TS/React джунов берут с большей охотой. Поэтому и проблем с ними нет.
                                                                +2
                                                                Откуда браться мидл разработчикам, если все хотят только мидлов?
                                                                В случае с Go — свитчиться с других языков. Как показывает практика, те же сишники и плюсовики осваивают Go чуть ли не за день и вообще без каких-либо сложностей, при этом отдыхая душой и мозгом как в санатории.
                                                                  –1

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

                                                                    +3
                                                                    Как правило, 90% пунктов в вакансиях означает не «must have», а «неплохо бы иметь, но если не, то все равно обсудим варианты» :)
                                                                    А в случае с Go и наличием большого опыта на других языках, всегда можно показать какой-нибудь пет-проектик — мне несколько рекрутеров стучались, увидев небольшую утилитку на Go в гитхабе, и даже когда я в ответ говорил что кроме этой утилитки на Go я в жизни ничего не писал на тот момент, все равно предлагали пособеседоваться.
                                                                      0

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

                                                                    0
                                                                    Это понятно, что с других языков можно быстро переключиться. Но часто в вакансиях требуют не просто опыт программирования, а опыт программирования именно на определенном языке, а то и в определенном стеке технологий. И это сильно сужает круг тех, кто мог бы откликнуться на вакансию. Тем более если человек уже является мидлом и имеет сравнимый доход, то стимулов куда-то перебегать у него не особо много. То что проще писать, сомнительный плюс. Людям обычно проще писать на том, к чему они привыкли, даже если объективно их родной язык достаточно сложный. Переучиваться бывает тупо лень.
                                                                    Вот для новичков в программировании перспектива подобной зарплаты и востребованность — это стимул и большой стимул. Только, получается, что все равно придется через другие языки заходить, так как джуны на Go никому не нужны. Сам готов изучать Go, но куда с ним потом идти без опыта, вопрос.
                                                                      +1
                                                                      Сам готов изучать Go, но куда с ним потом идти без опыта, вопрос.

                                                                      Я не гошник, но, кажется, сейчас с вакансиями на Го проблем нет. Да и большие компании его активно используют (Яндекс, Касперский, Авито и т.д.). И в целом есть ощущение, что на Го сейчас пишутся интересные и современные проекты, в отличии от того же C++, где хорошие деньги, как правило, предлагают в основном за ковыряния в legacy.
                                                                        0

                                                                        Там ключевое "без опыта"

                                                                          +1
                                                                          Перечитайте мой пост выше. Нашел лишь одну вакансию, куда я могу кинуть резюме, не имея опыта коммерческой разработки на Go и где не требуют знания еще пары языков в придачу. В принципе это приемлемо, если полагать, что я буду единственным человеком в городе, решившим изучать Go, и если эта вакансия будет открыта и через полгода, когда я буду уверено себя чувствовать с самим Go, gRPC, который нужен практически в обязательном порядке и PostgreSQL. Но надежда на такое стечение обстоятельств стремиться к 0.
                                                                          Вы правы, что проблем с вакансиями Go нет проблем, но просто посмотрите требования, 99,99% из них точно не для начинающих или тех, кто решил с фротенда перейти в бэкенд.
                                                                        0
                                                                        при этом отдыхая душой и мозгом как в санатории

                                                                        Это аргумент! :) Нужно будет при случае почитать документацию по этому Go. :)

                                                                      0

                                                                      ну мы ж не знаем, может у вас там филиал сималенда

                                                                        +2

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


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

                                                                          –1
                                                                          как-то маловато для миддла
                                                                            0
                                                                            Можно ссылочку на вакансию?
                                                                            –12
                                                                            спс за статью
                                                                              +2
                                                                              Go — хороший язык. Действительно простой. Среди нового поколения языков {Go, Rust, Swift}, переосмысливающих наследие C/C++, пожалуй самый простой (а Rust самый сложный).
                                                                              А скоро наконец-то добавят дженерики, которых так не хватало программистам (если я правильно понимаю, это основная претензия к Go).
                                                                                +28
                                                                                А скоро наконец-то добавят дженерики

                                                                                … и вот уже язык не такой уж и простой.

                                                                                  0

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

                                                                                    +2

                                                                                    Сложность языку придаёт добавление в него ЛЮБЫХ языковых конструкций. Или у вас какое-то другое мерило сложности языка?

                                                                                      +25

                                                                                      В brainfuck восемь команд, это простой язык?

                                                                                        –2

                                                                                        Почему вы отвечаете вопросом на вопрос?

                                                                                          +21

                                                                                          А вы антисемит?

                                                                                            0

                                                                                            2:5030! ©

                                                                                          0

                                                                                          Я говорю: 2 меньше чем 4.
                                                                                          Вы спрашиваете: 2 — это мало?
                                                                                          Я без понятия. Я не знаю что вы понимаете под "мало".

                                                                                            +7

                                                                                            Вы этого не говорили, а я этого не спрашивал.

                                                                                              +8
                                                                                              Почему вы отвечаете вопросом на вопрос?

                                                                                              Видимо у вас сложно с элементарными логическими цепочками. Неудивительно, что вам нравится Го.


                                                                                              Потому объясню. Рассмотрим вашу гипотезу:


                                                                                              1. Вы утверждаете, что "Сложность языку придаёт добавление в него ЛЮБЫХ языковых конструкций"
                                                                                              2. Следовательно чем больше языковых конструкций — тем сложнее язык.
                                                                                              3. Следовательно чем меньше языковых конструкций — тем проще язык

                                                                                              Вашу гипотезу можно проверить. Берём полный по Тьюрингу язык с малым количеством языковых конструкций. Идеально подходит Brainfuck, как язык всего с 8 конструкциями. Но, увы, он сильно сложнее других языков с большим количество конструкций.


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

                                                                                                +8
                                                                                                Идеально подходит Brainfuck, как язык всего с 8 конструкциями.

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

                                                                                                  –8
                                                                                                  вот это поворот!
                                                                                                  «Вашу гипотезу можно проверить. Берём полный по Тьюрингу язык с малым количеством языковых конструкций. Идеально подходит Brainfuck, как язык всего с 8 конструкциями. Но, увы, он сильно сложнее других языков с большим количество конструкций.»
                                                                                                  Вы так лихо придали ему сложности — только одним простым своим утверждением об этом, противореча вами же установленному п.1
                                                                                                  Видимо это у Вас сложности с логическими причинно-следственными связями.
                                                                                                    0

                                                                                                    Доказательство того, что брейнфак — сложный нужно смотреть на странице 74.

                                                                                                    +3
                                                                                                    Неудивительно, что вам нравится Го.

                                                                                                    Го мне отвратителен, и вообще это ad hominem.


                                                                                                    Рассмотрим вашу гипотезу

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


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

                                                                                                    Вы утверждаете что он сложнее, но так и не привели ваше определение сложности языка.

                                                                                                      0
                                                                                                      Го мне отвратителен, и вообще это ad hominem.

                                                                                                      Это была очевидная шутка, а не ad hominem.


                                                                                                      Вы утверждаете что он сложнее, но так и не привели ваше определение сложности языка

                                                                                                      Сложность — определение комплексное и субъективное. Я, к сожалению, не могу привести свою метрику, но напрямую оценивать сложность в количестве конструкций ошибочно.

                                                                                                        +2
                                                                                                        Сложность — определение комплексное и субъективное.

                                                                                                        Тогда какого простите чёрта вы объявляете МОЁ субъективное определение ошибочным?


                                                                                                        И я вообще не понимаю как определение термина может быть ошибочным.

                                                                                                      +1

                                                                                                      Как язык Brainfuck абсолютно тривиален, сложность в написании на нём отличных от "Привет, мир!" программ.


                                                                                                      Хотя тут, конечно, возникает вопрос: а что есть сложность языка, если не сложность работы с ним?

                                                                                                        0

                                                                                                        Да можно углубиться еще сильнее, mov — тьюринг-полный оператор, который может все. Всего один оператор! В 8 раз меньше чем у брейнфака!

                                                                                                      0

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

                                                                                                +5
                                                                                                Среди нового поколения языков {Go, Rust, Swift}, переосмысливающих наследие C/C++, пожалуй самый простой (а Rust самый сложный).

                                                                                                Мне нравится, что Rust много подчерпнул из мира ФП и продолжает продвижение в эту сторону, пусть и немного косо (GAT'ы). Но он сильно системный. Не думаю, что для прикладного программирования всякого веба так необходимо управлять временм жизни каждого объекта, GC is fine too. Какой-нибудь Rust с GC (абсурдно, да) был бы очень крутым языком для этих целей.


                                                                                                ЗЫ. Линейные типы (ну или почти линейные типы) в Rust помимо управления памятью еще и безопасную конкруентность обеспечивают.

                                                                                                  +1
                                                                                                  Какой-нибудь Rust с GC (абсурдно, да) был бы очень крутым языком для этих целей.

                                                                                                  Rust с GC был бы не Rust.

                                                                                                    +1

                                                                                                    Изначально в Rust был встроенный GC, и есть разные варианты GC для Rust.

                                                                                                      +1
                                                                                                      Изначально в Rust был встроенный GC...

                                                                                                      А также зелёные потоки. Но до выхода Rust 1.0 их все выпилили.


                                                                                                      … и есть разные варианты GC для Rust.

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

                                                                                                      0

                                                                                                      Можно иметь два типа указателей, одни мусоросборные, другие без. Как в мелкомягком c++/cli… а какие-нибудь другие языки с такой фичей есть?

                                                                                                      –1
                                                                                                      Какой-нибудь Rust с GC (абсурдно, да) был бы очень крутым языком для этих целей.

                                                                                                      D (Dlang)

                                                                                                      Но сравнивая с go, GC там будет блокировать на порядки дольше. И серьезные вещи на D пишутся переписывая стандартные библиотеки, что бы не использовать GC
                                                                                                        +1
                                                                                                        И серьезные вещи на D пишутся переписывая стандартные библиотеки, что бы не использовать GC

                                                                                                        А на Rust уже есть куча библиотек, которым не нужен GC ¯\_(ツ)_/¯

                                                                                                          0
                                                                                                          Я так понимаю имелось в виду на D
                                                                                                          Кому надо — делают… как мы.

                                                                                                          Есть достаточно большая наша библиотека(в основном реактор и все вокруг), которую мы недавно передали в dlang-community
                                                                                                          Нам для файловой системы GC ну никак не нужен. И с кернел-ом разговаривать нужно только ну в крайнем случае.
                                                                                                          github.com/dlang-community/mecca

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

                                                                                                          Мы правда не все туда перенесли, большАя часть того что могло быть вынесено не вынесли, но решили отдать как есть. Еще месяц назад она сидела на нашем github аккаунте, сейчас перенесли в dlang-community, так как появились желающие подхватить.
                                                                                                        +1
                                                                                                        Какой-нибудь Rust с GC (абсурдно, да) был бы очень крутым языком для этих целей.

                                                                                                        Хаскель?


                                                                                                        А, не, хаскель ленивый. Идрис? Хаскель с -XStrict?

                                                                                                          0
                                                                                                          Идрис?

                                                                                                          Хорош, но банально не готов. И экосистема, считай, нулевая.


                                                                                                          Хаскель с -XStrict?

                                                                                                          Вот когда нормально линейные типы завезут (и желательно вариант Prelude с ними) — тогда и поговорим.

                                                                                                            +2
                                                                                                            Хорош, но банально не готов. И экосистема, считай, нулевая.

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


                                                                                                            Вот когда нормально линейные типы завезут (и желательно вариант Prelude с ними) — тогда и поговорим.

                                                                                                            9.0.1 недавно зарезилизся. Там вроде нормально сделано (но я ещё всерьёз не ковырял).


                                                                                                            Prelude вообще выкинуть к хренам надо, а не завозить её линейную копию, но этого, увы, не будет. Поезд «avoid (success at all costs)» уехал.

                                                                                                        +1

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

                                                                                                          +1

                                                                                                          Это смотря с чем сравнивать. Там система типов более сильная, чем во всяких C++ и прочих C#. Имхо, конечно, я даже не знаю, можно ли это как-то формально обосновать. Ну, хотя бы отсутствие неявного null.

                                                                                                            0
                                                                                                            отсутствие неявного null

                                                                                                            Я, конечно, на Go писал совсем чуть-чуть, но разве все эти бесконечные if err != nil не противоречат сказанному?..

                                                                                                              0

                                                                                                              Возможно, я не туда ответил (комментарии с телефона не так удобны), но выше я говорил про Rust

                                                                                                                0

                                                                                                                Прошу прощения, значит, не так понял (комментарий товарища 0xd34df00d относился, кмк, к Go, а не к Rust).

                                                                                                              0

                                                                                                              Система типов считается "сильнее", если с её помощью можно выразить больше свойств и инвариантов. В этом плане система типов Go не может быть сильнее ни C++, ни C#. Добавление дженериков поправит ситуацию, но отставание всё равно останется. Особенно с учётом костыля type lists вместо добавления интерфейсов-констрейнтов для встроенных операций и встроенных типов.

                                                                                                          +12
                                                                                                          Достали статьи про «простой Go». Надо понимать, что Python сложный в сравнении с ним?

                                                                                                          Про легко читается — я вообще не понимаю как эту кашу можно осмыслить. Да и судя по количеству публикаций пик популярности Go уже пройден года полтора назад. Кто сейчас какой нибудь Groove вспомнит? Тоже самое с Go уже скоро будет.
                                                                                                            +3
                                                                                                            Python'у бы не мешало хотя-бы работу с переменными у Go позаимствовать:) Один лишний символ (операция := вместо =) и сразу объявление новой переменной становится отличимым от использования ранее определенной. Куча проблем исчезает сразу же.
                                                                                                              +2
                                                                                                              Прям как будто Паскаля нет
                                                                                                                +3
                                                                                                                В Паскале для объявления переменных требуется отдельный блок, то есть там нет важнейшего достижения С++ и множества языков, перенявших эту возможность — объявления переменных в любом месте программы.
                                                                                                                Операция := действительно применялась в Паскале как присваивание, но внешний вид — это все что у нее общего с одноименной операцией в Go:) В Go это именно моментальное создание объекта с автовыведением типа почти в любом месте программы.
                                                                                                                a:=10; // объявление
                                                                                                                b:=20; // еще объявление
                                                                                                                x:=a+b; // объявление и использование
                                                                                                                a=30; // использование ранее определенной перменной
                                                                                                                y:=a+b;// снова объявление и использование
                                                                                                                x:=40;// ОШИБКА, переменная уже определена ранее
                                                                                                                z=50; // ОШИБКА, переменная не определена
                                                                                                                

                                                                                                                Кстати, будь разработчики Go посмелее, они могли бы пойти еще дальше и разрешить объявление переменных прямо внутри выражений. Получилось бы весьма по-хакерски:
                                                                                                                x:= a * (s := b + c);
                                                                                                                  0
                                                                                                                  $x = $a * ( $s = $b + $c );

                                                                                                                  Совершенно корректный код в PHP.
                                                                                                                  Есть некие сомнения, что это можно сделать легко и дешево в языке со статической типизацией, но нет сомнений, что в принципе возможно.
                                                                                                                    0
                                                                                                                    Существенно то, что в PHP первое объявление переменной и ее использование не отличаются — а символ $ просто обозначает что это переменная. Вот если бы $ использовался только при первичном объявлении, а далее переменная использовалась бы без $, это было бы гораздо лучше, т.к. позволяло бы моментально находить опечатки в именах переменных.

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

                                                                                                                      А чем тут типизация мешает? Это исключительно вопрос синтаксиса.

                                                                                                                      +5
                                                                                                                      Кстати, будь разработчики Go посмелее, они могли бы пойти еще дальше и разрешить объявление переменных прямо внутри выражений.
                                                                                                                      Отсутствие у выражений побочных эффектов — один из принципов написания надёжного кода.

                                                                                                                      Так что очень хорошо, что ничего подобного в Go нет. И ещё лучше, что авторы Go выбросили из языка всё C-style трюкачество, порождающее UB. В Go все виды присваивания, инкремент, декремент — операторы (как в Pascal), а не операции (как в большинстве C-style языков), и потому они не могут быть использованы внутри выражений.

                                                                                                                        –2

                                                                                                                        Что за безграмотный коммент.
                                                                                                                        В большинстве C-style языков (Java, C#) инкременты-декременты не вызывают никакого UB, потому что порядок вычисления регламентирован (слева направо). В C/C++ просто хотели оставить максимальную свободу для реализации компилятора и оптимизатора.

                                                                                                                          +7
                                                                                                                          Предельно упрощенный пример:
                                                                                                                          int q = 5, r = 5;
                                                                                                                          q += q++;
                                                                                                                          r += ++r;
                                                                                                                          Чему равны значения q и r? В разных языках программирования мы получим разные ответы и все они будут полностью обоснованными.

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

                                                                                                                            +1

                                                                                                                            это да, но к UB — Undefined behavior — не имеет никакого отношения

                                                                                                                        –1
                                                                                                                        x:= a * (s := b + c);

                                                                                                                        Да да! А потом стрелочные функции, краткие if условия..., которыми надо затыкать любую дыру. И, конечно, больше скобок! Весь код должен умещаться в одну строку… Привет, js, ололо

                                                                                                                          0
                                                                                                                          Я бы согласился насчет того, что это огого как круто (про объявление), но не получается.
                                                                                                                          Вот это объявление в любом месте — компилятору на него плевать, оно только для людей же. Место-то он выделит там же, где и паскаль, при входе в блок (ну ок, у нас — в функцию), нет?
                                                                                                                          А проблему человека, которому не хочется откатываться наверх, легко решает IDE, shift-ctrl-c на необъявленной переменной — и объявление переменной автоматически уезжает в ближайший var, в зависимости от типа того, что ты ей присваиваешь.
                                                                                                                            0
                                                                                                                            и объявление переменной автоматически уезжает в ближайший var, в зависимости от типа того, что ты ей присваиваешь.
                                                                                                                            И возникают две проблемы:
                                                                                                                            1. Оно оттуда не исчезает, даже если переменная не нужна.
                                                                                                                            2. Переменную можно легко поиспользовать до инциализации.
                                                                                                                            И да, конечно, можно в IDE накостылить ещё и ещё решений для этих проблем… но зачем, если можно от этого избавиться на уровне языка?

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

                                                                                                                            Различие между a := foo(…) и a = foo(…) очень пользительно в Go именно для человека.

                                                                                                                            Первое — это просто сохранение значения в переменную. Простая операция, думать не о чем. Второе — это изменение переменной… операция более сложная, опасная и сразу привлекает внимание.
                                                                                                                        0
                                                                                                                        Философия Питона отличается.
                                                                                                                        Динамическая типизация, объявление переменных — суть одна, упрощение.
                                                                                                                        Ругать или хвалить бесмыссленно.
                                                                                                                          +1
                                                                                                                          На Питоне не писал, но писал немного на PHP — там такая же философия. И для меня это самое неудобное и постоянно приводившее к ошибкам — опечатки в именах переменных или просто забывчивость. Никакого упрощения, одно усложнение — нужно СУПЕР ВНИМАТЕЛЬНО смотреть код, буквально вчитываясь в каждую букву и удерживая в голове всё то, о чем в компилируемых языках просто не задумываешься, чтобы понять почему работает не так как ожидалось.
                                                                                                                          Ну фиг с ней, с типизацией. Но явное объявление имен переменных должно быть!
                                                                                                                            –3

                                                                                                                            Вот ты где, любитель засрать весь код final / const кейвордами. Я долго тебя искал

                                                                                                                              0
                                                                                                                              Вообще не любитель такого:)
                                                                                                                                +3
                                                                                                                                Ну если язык не даёт то же самое лаконичнее сделать — то да, будут final и const
                                                                                                                                +1

                                                                                                                                Современные статанализаторы, включая встроенные в IDE и работающие без явного запуска, такие ошибки отлавливают на ура.

                                                                                                                                  0
                                                                                                                                  А я не профессионал, а любитель. И писал что-то по быстрому для себя, или может изучал и экспериментировал. Среда разработки вроде была Notepad++ :)
                                                                                                                              +1
                                                                                                                              У присваивания "=" есть только один минус — он может случайно использоваться в условии. Но современные IDE сразу об этом предупреждают. Вирт, когда об этом писал полвека! назад, таких редакторов не имел.
                                                                                                                              В Go присваивание ":=", но при этом можно осуществлять переопределение переменных во внутренних блоках, — а все потому что кое-кто думал задницей, а не головой. В результате теперь можно совершенно случайно объявить новую переменную в внутреннем блоке, вместо присваивания. Ошибка совершается часто, а искать ее очень муторно, IDE ее не показывают, т.к. выглядит это как сознательное решение программиста.
                                                                                                                              +15
                                                                                                                              Да, Python — в сравнении с Go — очень сложный язык.

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

                                                                                                                              P.S. Значительная часть конструкций Python — синтаксический сахар, не добавляющий языку никаких новых свойств. То, что язык позволяет одно и то же делать десятью разными способами — это не достоинство, а недостаток.
                                                                                                                                +2

                                                                                                                                Несмотря на наличие кучи сахара, питон легко освоить, а код на нем легко писать. На мой взгляд, рост скилла питониста касательно именно самого языка, заключается в каких-то подкапотных особенностях а не в освоении синтаксиса и стандартной библиотеки. А свои нюансы есть от Си до C#, про тот же Go на хабре в комментах читал тред про UB, в котором Go'шник аргументировал "ну, этот момент нужно знать".


                                                                                                                                Из того, что прям люто-бешено не люблю в Python — это динамическая типизация и интерпретируемость. С другой стороны, есть C#, который в выразительности не сильно уступает питону, если речь не заходит про всякую математику, потому что numpy, scipy, pandas и прочий matplotlib в экосистеме C# не хватает. И слайсов.

                                                                                                                                  0

                                                                                                                                  Слайсы давно же есть. Numpy портировали как минимум дважды(нативно, обёртка вокруг питона), как и pandas.

                                                                                                                                    0

                                                                                                                                    О, спасибо.

                                                                                                                                    +4
                                                                                                                                    Да, писать на Python легко. Но искать ошибки в написанном коде — сложно. И даже понять, что была допущена ошибка, бывает сложно.

                                                                                                                                    Качественный код — это, в том числе, код, который легко читать. Но чаще бывает так, что чем легче код писать, тем сложнее его потом читать.

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

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

                                                                                                                                    P.S. Любители ставить знак равенства между краткостью и выразительностью почему-то забывают, что написанный код будут читать и модифицировать другие люди. И чем больше используется трюков (в том числе и синтаксического сахара) для уменьшения длины кода, тем сложнее этот код понимать. Чтобы понять 3 строчки APL-кода (а это самый «выразительный» из существующих языков) может понадобиться несколько часов.
                                                                                                                                      0

                                                                                                                                      А сколько лет надо читать Go код, чтоб мозг начал фильтровать if err != nil блоки через каждую значимую строку логики? )

                                                                                                                                        0
                                                                                                                                        err != nil — это не «через каждую значимую строку логики», а завершитель «значимой строки логики»:
                                                                                                                                        if res, err = функция_реализующая_этап_логики(params); err != nil {
                                                                                                                                        И это отлично читается. Куда проще и быстрее, чем разбирательство по коду, откуда именно в данный catch будет приходить исключение, когда оно генерируется 10 уровнями вложенности глубже.
                                                                                                                                          0
                                                                                                                                          Куда проще и быстрее, чем разбирательство по коду, откуда именно в данный catch будет приходить исключение
                                                                                                                                          Ctrl+Click по типу исключения в кэтч-блоке, смотрю использования в коде проекта, радуюсь. А ещё есть Either и прочие радости жизни.
                                                                                                                                            –1
                                                                                                                                            Полагаю, вам никогда не приходилось читать напечатанные на бумаге листинги хотя бы на тысячу строк кода? IDE — это очень удобно. Но есть она далеко не везде и не всегда.
                                                                                                                                              +4
                                                                                                                                              Если вам нужно без IDE и тем более по распечатке не только читать код, а ещё и искать источники исключений, то менять надо не ЯП, а работу (на ту, где такого трэшака не происходит), мне кажется.

                                                                                                                                              Если чуть менее ехидно, то такая необходимость — это такой эдж-кейс, что использовать его в общем обсуждении как аргумент кажется крайне странным. С тем же успехом можно сказать «Х — плохой язык, потому что вот в моей компании СБ его ещё не одобрила».
                                                                                                                                                0
                                                                                                                                                Если я могу за разумное время разобраться в коде на языке X только используя IDE, то X — плохой язык.

                                                                                                                                                Повторю свою мысль другими словами: бывают ситуации, когда доступа к IDE нет, а код править необходимо — причём срочно. И если из-за отсутствия IDE время на анализ и исправление кода увеличивается на порядок — в топку такой язык.
                                                                                                                                                  +2
                                                                                                                                                  1. за все свое время я ни разу не был без доступа к коду. Я понимаю ситуацию есть доступ к коду но нет к проду, но наоборот это бред.
                                                                                                                                                  2. Хочу я посмотреть как вы без ИДЕ будете искать кто реализует данный интерфейс, когда в Джаве вы легко через имплемент найдете.
                                                                                                                                                    –1
                                                                                                                                                    1. Какое отношение «доступ к коду» имеет к наличию IDE? Речь идёт только о невозможности использовать IDE здесь и сейчас. Например, в отпуске на Android-планшете. А с доступом к коду — по SSH — всё в порядке.

                                                                                                                                                    2. Причём здесь интерфейсы и Java? Речь идёт только о сравнении немедленной обработки ошибки-значения в Go и пробросе прерывания через десяток уровней вложенных вызовов (без какой-либо привязки к конкретному языку). Именно в последнем случае приходится вести раскопки в файлах.
                                                                                                                                                      +4
                                                                                                                                                      Речь идёт только о невозможности использовать IDE здесь и сейчас.

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

                                                                                                                                                      сравнении немедленной обработки ошибки-значения в Go и пробросе прерывания через десяток уровней вложенных вызовов
                                                                                                                                                      Вы-таки знаете, пока я работал Го-девелопером (полтора года) и много шарился по чужим — включая крупный опенсорс — исходникам, в 9 случаях из 10 так называемая «немедленная обработка ошибки-значения» выглядит, как
                                                                                                                                                      if (err != nil) return nil, err // и так глубиной в 10 вызовов в библиотеке 
                                                                                                                                                      То есть тот самый «проброс», за который вы хаете джаву. И да, трай-кэтч никто не мешает тоже так же тут же сделать.

                                                                                                                                                      Причём здесь интерфейсы и Java?
                                                                                                                                                      Притом, что сравнивали вы с бросанием исключений в джаве, а сравнение это использовали, как аргумент вот для этого:
                                                                                                                                                      И если из-за отсутствия IDE время на анализ и исправление кода увеличивается на порядок — в топку такой язык.
                                                                                                                                                      И на что вам сказали, что из-за убожества интерфейсов Го ещё хуже подходит для разбора без ИДЕ.
                                                                                                                                                        0
                                                                                                                                                        Вам того же искренне советую, решит выдуманную вами проблему на корню.
                                                                                                                                                        То, что я привёл абсолютно реалистичный сценарий, вы, разумеется, «не заметили».
                                                                                                                                                        Притом, что сравнивали вы с бросанием исключений в джаве, а сравнение это использовали, как аргумент вот для этого:
                                                                                                                                                        У вас слишком богатая фантазия. В этой ветке обсуждения я название «Java» не использовал. От слова «совсем». Так что вы выдумали у себя в голове картинку, не имеющую никакого отношения к моим текстам и теперь эту воображаемую картинку пытаетесь «опровергнуть».
                                                                                                                                                          0
                                                                                                                                                          Вы привели абсолютно реальный сценарий, который всего-то лишь значит, что если вы можете в нём оказаться, надо иметь с собой ноутбук, да. Потому что Го для описанного сценария подходит так же плохо, как любой другой язык, см. всё остальное сообщение и всю ветку выше.

                                                                                                                                                          Хорошо, про джаву я действительно ошибся, извините. Проассоциировал ваше упоминание catch с ней.
                                                                                                                                                          Подставьте название другого языка, использующего try/catch, суть не изменится. То, что я упомянул проблемы конкретно го-кода, которые в рамках ваших же утверждений делают Го «плохим» языком, вы, разумеется, «не заметили». :)
                                                                                                                                                    0

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

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

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

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