Кому и зачем все-таки нужен Go?

image
Здарова! Короче, последнее время на хабре было много срачей вокруг Go: хороший-плохой, нужен-ненужен, много сравнивали с питоном, много сравнивали с растом, divan0 даже додумался перевести высер «Go vs Haskell» ну и в таком ключе. У меня сложилось ощущение, что из-за хайпа и агрессивного маркетинга языка некоторыми Иванами Данилюками очень мало кто понял, кому и зачем вообще Go может пригодиться, зачем его делали и стоит ли вообще его учить. Я тоже долгое время участвовал в этих срачах, принимая посменно сторону «фанов» языка и сторону оппозиции, но в конце-концов допер, в чем фокус. Сегодня немного потупил у дивана в посте и решил написать вот эту заметочку.

Давайте, пацаны, проходим в пост.

Кому нужен Go?


Я только сегодня понял, что почти никто толком-то и не понимает, зачем вообще Go нужен. Если коротко, то Go нужен для того, чтобы проектировать robust software. Я не знаю, как правильно перевести это слово на русский, но это скорее всего что-то вроде «надежный». Так вот, Go сделали, потому что гуглу нужен был инструмент для написания надежного кода. На самом деле не сколько гуглу, сколько Робу Пайку, который последние две декады, как минумум, одержим идеей сделать сишку с каналами и зелеными потоками. Так получилось, что Роб Пайк попал в нормальную компашку с другими штрихами из Bell Labs, крутейшим Russ Cox, Фицпатриком и т.д. Этим ребятам несложно было убедить гугл, что им нужен новый язык и вобщем-то, бабосики они на него выбили.

Так, это было небольшое лирическое отступление, давайте вернемся к теме. Да, зачем же все-таки гуглу был нужен новый язык? Ну, тут все понятно, давайте послушаем слова самого Роба Пайка:
Фишка в том, что наши программисты гуглеры, а не ученые. Это обычно молодые, только выпустившиеся пацаны, которые возможно выучили Java, возможно даже C/C++ и может быть Python. Они не в состоянии понимать пробздетый язык, но мы все равно хотим, чтобы они делали хороший софт. Таким образом, мы даем им легкопонимаемый язык, к которому они быстро привыкнут.

А теперь давайте попытаемся понять, что же он имел ввиду. Если грубо говоря, то он сказал, что в гугле работают не самые умные ребята («не способные понимать крутой язык»), так что они придумали такой язык, который просто невозможно не понять. Это на самом деле очень круто для менеджмента. Посудите: можно нанять 100 посредственных программистов, дать им в руки Go и эта армия обезьян будет генерить вам много «неплохого» и очень даже поддерживаемого кода! Go это фантастический инструмент для менеджмента, лучше не придумать: моментально загоняем всех программистов в рамки go-fmt (никто не сможет пропихнуть свой стиль форматирования), забираем у них любые абстракции сложнее интерфейса и получается такой конвеер кода, в котором developer is just another brick in the wall. По-моему, очень круто! Ну, программистам скорее всего такой расклад не очень понравится — мало кто любит быть винтиком в системе.

Так вот, Go нужен корпорациям. Если у вас в компании работает много людей, большие проекты и все такое, то Go это идеальный вариант! Но для того, чтобы понять, действительно ли вам нужен Go, надо разобраться ЗАЧЕМ его все-таки стоит использовать. Давайте узнаем.

Зачем нужен Go?


С технической стороны, ниша у Go довольно скромная: сеть, утилиты, бэкенды. Если у вас сложные сети или много нод, которые надо как-то навороченным образом оркестрировать, то Go это хороший выбор (судя по опыту CloudFlare). Если вы хотите сделать какую-то классную консольную утилиту, вроде докера или консула, то Go тоже нормульок подойдет (судя по опыту оных). Я вот сейчас тоже делаю интересную утилиту и пишу ее на Go, потому что вписывается. Ну и в конце-концов. Если вам нужен быстрый и в принципе, эффективный бэкенд, то тоже можно выбрать Go. Я не представляю, как народ пишет бизнес-логику на Go, но как-то пишут же! Короче, тут все довольно сложно. С одной стороны, делать CRUD в Go это достаточно болезненно, с другой стороны есть 350 разных роутеров и фреймворков, которые здорово облегчают работу.

Что касается других ниш, то я с уверенностью могу вас заверить: полная профанация. Если Go где-то всерьез и используется, то в консольных утилитах, на сетях и бэкендах. Больше юскейсов нет. И давайте не будем их выдумывать. Go изначально язык, который сделали в гугле, чтобы студенты могли придти и писать код для навороченной сетевой инфраструктуры гугла. Тут можно сформировать своеобразный rule of thumb: "Если ты не пишешь софт для сети, консольную утилиту или хайлоад бэкенд, то Go тебе скорее всего не нужен". Тем не менее, полно народу продолжает писать софт на Go ради собственно говоря, самого Go.

Cтоит ли учить Go?


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

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

Для тех, кто прямо не могут сдерживаться и УЖЕ выпригивают из трусов, сразу кидаю несколько ссылок на материалы:

  • tour.golang.org — оф. тур по языку, разжевывают
  • gobyexample.com — примеры разных частоиспользуемых сниппетов
  • www.reddit.com/r/golang — сабреддит, посвященный Go; там часто классные вещи постят

Дерзайте, Go вам точно не навредит. Ну может будете потом скучать по gofmt, но это не очень страшно на самом деле.

Заключение


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

Спасибо за твое внимание,
Илья.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 251
  • +18
    Роб Пайк одержим идеей создания простого и легкого concurent language и Go это не первая попытка, были еще Limbo, Squeak, Newsqueak.

    Т.к. все эти языки по дизайну мало чем отличаются, то трудно представить что создавая Go он создавал язык для корпораций. Скорее всего он просто развел Google на выдление денег под свои личные идеи.

    По мне Go это хороший язык для маленьких, упорных команд которые ставят амбициозные задачи перед собой. Как корпоративный язык он плох, т.к. качество кода на Go зависит исключительно от самомотивации разработчиков. В Go ничто не мешает скатиться до низкоуровневого императивного кода и писать в стиле C.
    • +8
      Роб Пайк одержим идеей создания простого и легкого concurent language и Go это не первая попытка, были еще Limbo, Squeak, Newsqueak.

      Я как бы немного да в курсе, да. «Простой и легкий concurrent язык» это по сути своей и есть сишка без арифметики над указателями и каналами и зелеными потоками, не более.

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

      Ну во-первых, никто не куда не скатывается: в Go принято писать низкоуровневую императивную лапшу в стиле С, это идиоматика языка и она очень классно работает. Во-вторых, gofmt && gometalinter просто не позволяют писать отвратительный код, он так или иначе будет «неплох», ничего не поделаешь. Я не понимаю, зачем маленьким и амбициозным командам нужен такой убогий язык, как Go. Куда круче для «маленьких» работает выразительный питон, например, для которого кучу всего уже написано.
      • +7
        s/не куда/никуда

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

          Если у вас ограниченный бюджет, то с Go можно охватить аудиторию в несколько раз большую чем с Python/Ruby/Node.js чисто из-за быстродействия. Для маленьких команд и стартапов это значимый фактор. При это сам Go не слишком сложнее Python. Т.е. не надо тратить деньги на высококвалифицированных спецов.

          PS.
          Что касается самого Пайка, то все правильно делает. Google это зло, а Go, Plan 9 и гоферы это добро -))
          • 0
            ну, если мало денег, то можно и на пхп писать, а со временем переписывать, это быстро и дешево, на старте быстродействие редко важно так как быстрота разработки
            • +3
              Допустим вы делаете стартап у которого аудитория 1 млн. пользователей, которые ежесекундно отправляют какое-то сообщение вам с данными, вы обрабатываете эти данные с помощью какого-то алгоритма, например spectral-norm

              benchmarksgame.alioth.debian.org/u64q/performance.php?test=spectralnorm

              Решение на golang получается быстрее примерно в 12 раз. А значит, если представить что хостинг вычислительных мощностей для PHP будет составлять 5.000$ в месяц, то на golang то же решение будет стоить 340$.

              Если учесть, что даже в США pre-seed финансирование обычно около 20.000$, то это фундаментальная разница.
              • 0
                У стартапа априори нет аудитории, стартап стартует без аудитории, и затем аудиторию набирают. Да и 1 млн пользователей не так уж и много для пхп, он выдержит и больше, хостинг будет дешевле, разработчиков больше, которые уже знают язык хорошо, и не будут лезть в мануал чтоб узнать как же это увеличить словарь, ато размер подошел к концу, или как залить файл на сервер.
                Если нужно что-то сделать быстро, то лучше подойдет язык который уже известен, с граблями которые уже известны. А если нужно что-то сделать надежно, то это не стартап, и не го, увы. Для каждого свое время и место.
              • +1
                И тут, внезапно, go — быстр в изучении, быстр в разработке, быстр в работе, требует меньше дорогих серверов для обслуживания того же объема трафика.
                • 0
                  Очень быстр в работе:
                  http://www.techempower.com/benchmarks/#section=data-r11&hw=ec2&test=plaintext
                  rapidoid (Java) 397,666 100.0%
                  go-raw (Go) 50,295 12.6%

                  Очень быстр в разработке: постоянное написание велосипедов, вместо реиспользования кода (привет, дженерикам) очень этому способствует.
                  • 0
                    Данные как минимум устарели, не вижу fasthttp в списке. А он в 10(десять) раз быстрее стандартного net/http в go по результатам бенчмарков.
                    О дженериках я с вами спорить не буду, не понимаю, как люди вообще могут что-то без них писать, сплошные велосипеды.
                    • 0
                      Не поленитесь и добавьте реализацию на fasthttp :-)
                      Реквесты они вполне себе принимают, правда обновляют результаты лишь раз в пол года.
                      Я вот пол года назад добавил туда vibe.d: vibe.d (D) 27,974 7.0%
                      Тот ещё тормоз. Хотя, он запускается там в дебаг режиме, ибо в релизном банально падает.
                  • 0
                    Давайте напишем одно и то же приложение, вы на го а я на пхп, и мы сравним у кого это выйдет быстрей? Не нравится пхп? Возьмите питон, руби или ноду, тоже языки отличные для старта, где можно найти хорошего программиста, который быстро все сделает что нужно. А ресурсы в наше время не дорогие, этот аргумент давно уже ушел на второй план. Человеко-часы на много дороже, а опытного гофера еще попробуй найди.
                    • 0
                      Хахаха, хорошая шутка. Ну, кто подкинет ТЗ? Но условимся, что это не будет сайт-визитка, а какой-нибудь полноценный веб-сервис с парой тысяч условных посетителей в секунду.

                      Я на php потратил лет 7, и здорово представляю, что там да как. На ноде тоже написал несколько полноценных SaaS, и в целом несколько последних лет это была нода и изредка c/c++ для нативных модулей.
                      Go же я использую пару месяцев. Но потягаться, думаю, смог бы, будь в Вашем предложении хоть капля здравого смысла.
                      • 0
                        Ок, в то время пока гофер будет делать свой «суперпупербыстрыйсайт», пхп-шник/подставьте свой язык популярный, уже будет на этом сайте первых клиентов получать и деньги иметь. Никто не спорит что го выдержит больше нагрузку, а нужна она на старте? У вас есть уже эти пата тысяч посетителей? Я смотрю здесь много стартаперов собралось, все прекрасно понимают как все работает, создают сайт и сразу бабло течет рекой. Дело в скорости разработки, пхп прекрасно выдерживает нагрузки в сотни конектов в секунду, этого для старта более чем с головой достаточно, но скорость разработки у пхп в разы быстрей чем на го, особенно у человека который 7 лет потратил на пхп. То что вы напишете на го за неделю, на пхп потратите от силы пару дней, и на пхп оно будет стабильней и продуманней с точки зрения архитектуры на будущее.
                        • 0
                          Вот как «популярность» языка влияет на скорость разработки?
                          Сайт-визитку с формой заказа я сделаю на go за 15 минут, ровно как и на php. Конечно в Go у меня совсем мало опыта, гораздо меньше чем в php, но он гораздо проще, потому скорость разработки будет примерно равна.
                          Так-же и с бóльшими проектами.
                          А еще его простота дает возможность любому опытному php/js/python/… программисту за пару-тройку вечеров освоить go до уровня самостоятельного написания проектов.
                          • –2
                            Нет, ты очень преувеличиваешь свои силы насчет сайта визитки на го за 15 минут. А вот на пхп, с опытом в 7 лет, это действительно ближе к реальности. Вот как влияет скорость от популярности языка. Одна фраза «как сделать ХХХ на языке УУУ» приведет с большей вероятностью к решению проблемы на популярном языке. Вы не будете гуглить решения простейших проблем на пхп, вы это все уже знаете, это вьелось в подкорку с опытом работы, с го у вас такого нет, разница в скорости у вас будет на порядок (именно в прямом смысле, десяток и более), а то что вы спорите, лишь добавляет мне уверенности что с го вы не работали нормально, поэтому разница в скорости разработки еще увеличивается. Нет на го хороших разработчиков, а если и есть, то их на сколько мало, что ими можно пренебречь (как в математике). Отсюда и скорость разработки.
                            • +1
                              У меня ушло 20, с версткой. Go ~40 строк с простейшей валидацией формы и сохранением в бд. Надеюсь вопрос закрыт? github.com/mirrr/kkk

                              ps. минус за «тыканье»
                              • 0
                                Это не сайт визитка, это кусок говна, уж извините за выражение, мы про стартапы говорили или про одну функцию для сохранения строки в базе? Вы действительно так туго соображаете или издеваетесь? Я вам про полноценный сайт говорю, а не про страничку на пару строк. Давайте еще сравним как быстро вы напишете хелло ворлд? Это просто гениально было! Аплодирую!
                                • +2
                                  Уж извините, если сайт-визитка на go умещается в пару строк. Но думаю это не повод переходить на оскорбления.
                                  • +2
                                    Добавлю, что о стартапах здесь говорили только Вы. Никогда не занимался стартапами в вашем понимании этого слова, потому об этом ни слова не написал. Мой хлеб — проекты, которые на старте имеют больше посетителей в минуту, чем многие стартапы в год.
                                    И код, который вы назвали говном, не просто «функция сохранения в базу». А полностью рабочий сайт, который выводит вебстраницу с текстом и формой обратной связи, а так же обрабатывает ее, с валидацией и выводом сообщений пользователю, что собственно вполне попадает под описание сайта-визитки.
                                    Потому, прежде чем что-то писать, советую ознакомится с предметом обсуждения, а не выставлять себя дураком.
                                    • –5
                                      Я уже понял что ваш хлеб — хелоуворды недоделаные (да, снова личности, увы, не могу по другому обьяснить свои слова). То что вы показали не «полностью рабочий сайт», а именно поделка, функция сохранения в базу. полностью рабочий сайт предусматривает наличие редактируемых текстов, вывод их, админку для этих текстов итд. Но если вы в таком виде отдаете сайты заказчику (это я сделал вывод из слов «полностью рабочий сайт»), то у нас разные мнения по этому поводу. А насчет больше или меньше посетителей, то это, опять же, понятие относительное, некоторым и страница с формой — полноценный сайт, другим и 100 пользователей в секунду высокие нагрузки.

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


                                          Вы путаете сайт и CMS. За 15 минут CMS с нуля, без использования фреймворков, не написать пехепешнику даже с 15 годами опыта. А разворачивание готовой CMS и настройка её через админку к разработке мало отношения имеет.
                                          • –2
                                            Я не путаю ничего, цмс подразумевает не просто фронтенд с админкой, она предполагает некий набор стандартный возможностей. В любом случае в полноценном сайте человек (заказчик) должен иметь возможность хотябы просмотреть то что сайт предполагает сохранять. Ту же поделку, тот же человек на пхп (учитывая его опыт) смог бы сделать на много быстрей с валидацией и простейшей админкой хотябы на просмотр оставленного посетителями). Об этом и речь, скорость разработки, а мне тут расказывают как они быстро хеловорлд напишут. Я говорю про разницу во времени, а мне в скорости го приложения. Научитесь слушать собеседника для начала.
                                            • +3
                                              В любом случае в полноценном сайте человек (заказчик) должен иметь возможность хотябы просмотреть то что сайт предполагает сохранять
                                              … смог бы сделать на много быстрей с валидацией и простейшей админкой хотябы на просмотр оставленного посетителями). Об этом и речь, скорость разработки, а мне тут расказывают как они быстро хеловорлд напишут. Я говорю про разницу во времени....


                                              Омг, окей, добавил админку, с авторизацией и просмотром записей.

                                              Это было болью, заняло полдня
                                              admin := r.Group("/admin")
                                              admin.Use(gin.BasicAuth(map[string]string{"admin": "secret"}))
                                              admin.GET("/", func(c *gin.Context) {
                                              	fbks := []feedback{}
                                              	session.DB("mydb").C("feedbacks").Find(gin.H{}).All(&fbks)
                                              	c.HTML(200, "admin.html", gin.H{"feedbacks": fbks})
                                              })
                                              


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


                                          И вы, конечно же, такое чудо создадите с нуля за 15 минут, да:
                                          на го за 15 минут. А вот на пхп, с опытом в 7 лет, это действительно ближе к реальности


                                          ?
                                          • 0
                                            http://www.yiiframework.com/doc/blog/1.1/ru/prototype.scaffold
                                            это рас
                                            миграции — куча библиотек, с ошикарной документацией
                                            это два
                                            пхп сам по себе шаблонизатор, с довольно таки высокими возможностями обработки в шаблонах
                                            это три
                                            не нужно цепляться за слова, хело ворлд на всех языках пишется очень быстро, другое дело что я со всем вышеперечисленным работал и хорошо знаю, это значительно ускоряет время разработки, в го такого пока нет, а если и есть, то возможностей меньше, придется очень много самому писать, это значительно снижает скорость разработки.
                                            Чего только стоит загрузка файла на сервер, на пхп это реально за 5 минут делается, а на го? По памяти кто-то напишет код загрузки файла?
                                            Я могу еще продолжать, и самое интересное все прекрасно понимают что на то они и популярные языки, скорость разработки на них велика, в ущерб другим вещам, но как же так, я написал хелловорлд за 40 минут, поэтому ты неправ!, и плевать что я вообще о другом говорил.
                                            • +2
                                              пхп сам по себе шаблонизатор

                                              Ну так и в Go есть родной шаблонизатор, в чем преимущество?

                                              Чего только стоит загрузка файла на сервер, на пхп это реально за 5 минут делается, а на го?

                                              На go это занимает целых 5 секунд:

                                              file, _, err := c.Request.FormFile("file")
                                              


                                              хелловорлд за 40 минут, поэтому ты неправ!, и плевать что я вообще о другом говорил.

                                              Да хрен вас поймешь, уважаемый, о чем Вы говорите. Я говорил о времени разработки, вы о какой-то «популярности», стартаперах, сайт-визитку упорно называете хелоувордом. А вместо аргументации оскорбления и истерика.
                                              • 0
                                                Давайте с другой стороны: вы утверждаете что скорость разработки и цена затрат на пхп и го одинаковы для среднестатистического сайта? Вот я считаю что нет, на пхп будет дешевле и быстрей, исходя из тонны существующий библиотек, тонны существующих ответов и тонны людей знающих пхп. Вот и все. То что вы сделали страничку с формой за 40 минут, не поменяет ничего, вы же сделаете на пхп это быстрей, и чем больше функционала, тем больше будет пропасть между пхп и го, у вас же. Об этом я говорю.
                • –10
                  «Простой и легкий concurrent язык» это по сути своей и есть сишка без арифметики над указателями и каналами и зелеными потоками, не более.

                  Если убрать каналы, то получится Erlang.
                • +4
                  язык для маленьких, упорных команд которые ставят амбициозные задачи перед собой

                  В голове сама собой загорелась надпись «Haskell».
                  • +96
                    Если что у меня там написано «упорных», а не «упоротых» -)))
                    • +17
                      Восхитительно! До этого читал именно как «упоротых» и всё отлично складывалось, спасибо за комментарий!
                      • 0
                        А теперь в голове представились упорные амбициозные задачи по написанию тонн микросервисов, только и делающих, что взаимодействующих между собой.
                        • +1
                          И что мешает писать монолит, состоящий из маленьких, законченых модулей?
                  • 0
                    Надо только добавить что на нем легко делать и потдерживать микросервисы. Это все из за легкий деплоев и маленкий требываний к ресурсам. Так что есть много стартапов которым это очень нравится(меньше возни с серверами и меньше серверов)
                    • 0
                      Непонятно про deployment… В случае Java/.Net всё можно свести к схеме: копируем бинарники в новую папку, далее меняем конфиг сервера, чтобы смотрел уже в новое место. А как в Go? Там получается проще, чем копирование файлов?
                      • +13
                        Там получается проще, чем копирование файлов?
                        Проще копирования файлов может быть только копирования файла. Одного. Ваш КО.
                        • 0
                          А конфиг вшит в исполняемый файл? Например, на какой порт будет смотреть прога, в случае веба?
                          • +3
                            • +10
                              Укажите в командной стоке. Как вы думаете, зачем Goggle лет пять (или семь?) назад добавил в ядро Linux'а patch, который отменил ранее действовашее жёствое окраничение на длину командной строки в жалкие 131072 символов?
                              • +1
                                Еще можно использовать переменные окружения, например указать их в systemd сервисе или любом супервизоре.
                          • +2
                            я говорил в сторону Rails например.Там целая наука что и как unicorn puma и другие представители зоопарка. Как на Java делать обновления кода (не важно сколько) с gracefull restart?
                            • 0
                              В rails сейчас как и везде деплой делается перезапуском докер контейнера
                            • +2
                              Чтобы изменить конфиг сервера нужно сначала поднять сервер и создать для него конфиги.
                              • 0
                                В java уже можно не поднимать сервер вручную, встраивайте сервер в jar и все. Всякие Spring Boot это делают из коробки.
                                • –2
                                  Никогда не понимал, зачем всё это, если Eclipse WTP (или какие там альтернативы в других IDE) сам поднимет хотите Tomcat, хотите Jetty, да ещё и будет автоматом редеплоить приложение в запущенный прогретый контейнер, вместо того, чтобы каждый раз вручную запускать веб-сервер в непрогретой JVM.
                                  • 0
                                    я говорю о продакшн деплое, сейчас уже вполне можно обходиться встроенным контейнером не скачивая какой нибудь tomcat, для разработки понятное дело в той же идее можно отдельные классы в рантайме редеплоить
                                    • 0
                                      ИМХО, как раз в контейнер сервлетов гораздо удобнее деплоить, чем копиировать jar-файл, потому что:

                                      1. Когда мы деплоим war-файл, наше веб-приложение автоматом перезапускается. В случае с jar-файлом надо изобретать велосипед на скриптах.
                                      2. Для деплоя war-файлов есть уже куча готовых утилит (cargo, который доступен через maven и через jenkins), в случае jar-файлов приходится поднимать ftp или ssh и велосипедить на скриптах.
                                      3. В случае war-файла из коробки в том же tomcat есть zero downtime deployment, в случае jar-файла приходится… ну вы поняли.

                                      В общем, embedded сервер полезен когда вы делаете совсем уж маленькую утилитку на <1000 строк за пару дней, и настройка WTP, Tomcat, Cargo и т.п. занимает больше, чем разработка самого приложения. Сам недавно так делал. В любом другом случае war-файл во всех отношениях удобнее.

                                      Единственный контраргумент — это докер, но моя практика с ним показала, что это пока ещё не совсем зрелый инструмент и тот же нормальный zero downtime deployment делается костылями и велосипедами на скриптах. Да и не очень хорошо docker дружит с java, т.к. каждый контейнер — это своя изолированная JVM, а много мелких служб гораздо экономнее по памяти поднимать в одной JVM.
                                      • +1
                                        Мой опыт показывает, что деплоить war намного менее удобно, чем запускать jar со встроенным сервлет-контейнером. По пунктам.

                                        1. Редеплой часто бывает не production-ready. Например, в jboss as в своё время редеплой хоть и работал, но периодически глючил.
                                        2. Деплой через cargo — медленный и неудобный для разработки, а безопасность его под вопросом в продакшене. Медленный — потому что копируются все ресурсы приложения, а потом вся эта штука разворачивается контейнером. При использовании встроенного сервлет-контейнера достаточно лишь перезапустить процесс. Ничего копировать и распаковывать не нужно. Это что касается окружения разработки. А чтобы не велосипедить на скриптах при деплое в продакшене, можно сделать deb-пакет, например, или использовать контейнеры. Дополнительный плюс такого подхода будет в том, что не придётся долго рассказывать админам, как выполняется деплой. Обновил пакет — и всё работает. Что же касается безопасности деплоя через сокет в продакшене, достаточно отметить, что были эксплоиты для различных серверов приложений, которые эксплуатировали дырки в админках. Конечно, эти порты наружу не будут открыты, но в случае эмбеддед сервера этой проблемы вообще нет.
                                        3. Не в курсе про томкат, может быть там все действительно хорошо с zero downtime, но я бы поостерёгся редеплоить приложения в продакшене (см первый пункт).

                                        Сравнить скорость cargo и ембеддед можно легко, если есть в наличии проект, war которого занимает мегабайт 70. cargo будет деплоить эту штуку сильно дольше, чем просто запустится новый java-процесс. А высокая скорость рестарта при разработке — высокая производительность программистов, то есть наше всё.
                                        • 0
                                          Стоит добавить, что частый редеплой приложения при не очень удачных библиотеках и/или сервлет-контейнере/аппсервере может приводить к OOM по permgen/metaspace. Получается такой «zero» downtime, что лучше уж как-нибудь без него. Как минимум, регулярно ловим на jboss as 7.
                                          • 0
                                            Хочу сразу оговориться, что cargo я упомянул только в контексте production, разумеется, делать деплой с его помощью при разработке — это слишком долго, с этим гораздо лучше справляется IDE.

                                            Теперь почему запускать jar-файл — это долго. Потому что при запуске jar-файла стартует новая JVM, которая все методы, как самого embedded-контейнера, так и вашего приложения, интерпретируются, до тех пор пока они не выполнятся очень много раз. Далее, скорость запуска контейнера — фигня, т.к. вот типичное такое приложение на 200 LOC стартует следующим образом:

                                            1. Запускает миграции БД или хотя бы удостоверяется, что все существующие миграции уже применены.
                                            2. Читает Spring-конфигурацию и сканирует classpath, собирает бины.
                                            3. Читает JPA-конфигурацию, строит мапперы и т.п.

                                            Опять же, всё это на непрогретой JVM. В итоге — 30-60 секунд. Экономия в 2-3 секунды на деплой (именно столько получается у меня — ЧЯДНТ?) — капля в море. Реально спасти тут может не embedded-сервер, а какой-нибудь jrebel.

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

                                            И что я с этим deb/rpm-пакетом буду делать? scp && ssh (yum install && systemctl restart)? А можно как-нибудь автоматизированно? Тот же cargo — это нажатие одной кнопочки в jenkins, а то и вовсе проставление специально именованного тега в git.
                                            • 0
                                              После того как я это прочитал
                                              Рад что в GO деплой одни бинарным файлом и рестарт на лету без потери запросов
                                              Только ваше обьяснения тут хватит чтоб это понять
                                              • +1
                                                В Java деплой одним файлом, и имя ему — war. И рестартует без потери запросов. А главное — без того, чтобы заходить на сервер по какому-нибудь ssh.

                                                Каким образом go рестартует веб-приложения без потери запросов? Ссылку можно?
                              • 0
                                ну да, а JVM уже на каждой машине стоит, ага
                                • +1
                                  Можно подумать, ОС на каждой машине стоит. А так, вот пара вариантов:

                                  1. sudo yum install
                                  2. docker-образ, причём либо просто с предустановленной JVM, либо сразу с приложением
                            • +11
                              Корпорациям часто требуется решение, которое удовлетворяет следующим пунктам:
                              1. Поддержка (дали монету — починили багу)
                              2. Возможность смены вендора (например, для Java, если Oracle откажется от поддержки, можно работать с IBM, похожее с базами данных, хоть и не настолько легко, для .Net есть открытый CoreCLR, а также Mono).
                              3. Зрелость (присутсвие языка на рынке N лет, наличие библиотек)
                              4. Наличие опытных разработчиков (причем как с опытом в этом решении, так и с опытом работы в предметной области)
                              5. Наличие формальных преимуществ, по сравнению с используемыми решениями.

                              У Go есть проблема с пунктом 5 (ибо обещанной производительности нет, всё на уровне java, которая на уровне .Net, кроме математики, которую сейчас логичнее делать на GPU и OpenCL, который может дать ускорение на порядки). Упрощение по сравнению с С тоже сомнительное, ибо под старичка есть море компиляторов, а если нужен GC, то подойдет и Java Card, .Net Micro Framework и еще куча известных технологий.

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

                              Потому и получается, что несмотря на попытки гугла войти в Enterprise Development, все пока неудачно…
                              • –18
                                Насчет пп2. Исходный код компилятора Go написан на Go, вы сможете пересобрать и доработать его сами. Он не закрытый, в отличие от .NET, Java и пр.

                                Насчет пп3. Это можно проверить только контр-примерами. Что нельзя реализовать в Go имеющимся набором стандартных и дополнительных библиотек?

                                Насчет удач-неудач и пп5, что вам известно про Docker? ( hub.docker.com/_/golang )
                                Он тоже написан на Go (исходы github.com/docker/docker )

                                С ноября 2013 года частичная поддержка Docker включена в дистрибутив Red Hat Enterprise Linux версии 6.5[3] и полная — в 20-ю версию дистрибутива Fedora.
                                wiki

                                Если средства, созданные на языке распространяются в _официальном_ дистрибутиве Linux (Red Hat, Fedora и др.), говорит ли это о популярности? Есть ли в этих дистрибутивах хоть что-то, созданное на .NET, Java? Почему?

                                Я не говорю в данном комментарии о преимуществах или недостатках языка, а задаю вам вопросы, ответы на которые вы дадите для себя.
                                И сами все поймете.
                                • +6
                                  Он не закрытый, в отличие от .NET

                                  У .Net есть открытый Roslyn вообще-то.

                                  Что нельзя реализовать в Go имеющимся набором стандартных и дополнительных библиотек?

                                  С учетом CGO это вообще отпадает по определению. Вкомпилить можно что угодно. Даже для C++ есть вариант.

                                  Если средства, созданные на языке распространяются в _официальном_ дистрибутиве Linux (Red Hat, Fedora и др.), говорит ли это о популярности? Есть ли в этих дистрибутивах хоть что-то, созданное на .NET, Java? Почему?

                                  В данном случае GO не имеет к этому никакого отношения. А .Net и Java всегда будут иметь проблему в виде рантайма.
                                  • +1
                                    Если средства, созданные на языке распространяются в _официальном_ дистрибутиве Linux (Red Hat, Fedora и др.), говорит ли это о популярности? Есть ли в этих дистрибутивах хоть что-то, созданное на .NET, Java? Почему?
                                    Ни о чём не говорит. В репозиториях той же федоры можно легко найти софт на java, .net (mono), go, d, haskell и даже более экзотических языках. Или вы неспособны вызвать repoquery --whatrequires java-1.8.0-openjdk и посмотреть какие пакеты зависят от него?
                                  • 0
                                    если нужен GC, то подойдет и Java Card
                                    Там в большинстве случаев нет GC. Есть object deletion, который не всегда поддерживается и не рекомендуется.

                                    всё на уровне java, которая на уровне .Net
                                    Тесты по java (сравнение с .net) в статье, на которую вы ссылаетесь, некорректны. Усреднять прогоны на непрогретой jvm — глупость. Не считая того, что hotspot с улучшениями из jrockit несколько отличается от 6u24, которая была в 2011.
                                    • +5
                                      обещанной производительности нет, всё на уровне java

                                      По-моему, у джавы проблемы не с производительностью, а с диким потреблением памяти. Как с этим у Go?
                                      • +1
                                        отлично!
                                        play! hello world 600MB
                                        revel hello world 3MB
                                    • +9
                                      Спойлер: комментарий полон пафоса, самолюбования и немножко вульгарщины.

                                      О, какой шикарный опус вброс опус-то я пропустил-то, со сравнением с хаскелем-то.

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

                                      Только не хочу я быть социальным. И я не хочу опенсорс ради коммитов. Я хочу опенсорс (и программирование вообще) ради челленджей. Решить на хаскеле задачи к курсу на курсере по биоинформатике — это небольшой челлендж. Написать аналитическое дифференцирование в компилтайме на C++ для научной работы — это челлендж (на самом деле очень забавный и мощный челлендж, я закончил это позавчера, а ментальные оргазмы до сих пор накрывают). Написать на C++ ORM с минимальными пользовательскими аннотациями — это челлендж. Или написать ещё одну плюсовую библиотеку с функторами, аппликативными функторами и монадами, написать в её рамках Either и радоваться типобезопасной обработке ошибок вместо уродливых сырых возвращаемых значений и не менее уродливых экзепшонов. Тоже челлендж, хотя и не особо большой. Или написать парсер языка разметки без всяких спецификаций на Parsec, а потом переписать на Attoparsec, и добиться исключительной производительности при константном потреблении памяти. И при этом ещё убедиться, что система типов ведёт тебя за ручку, и все нужные преобразования этого языка разметки выполняются максимально обоснованно и доказанно.

                                      И я не хочу в корпорации, стартапы и петакластеры. Я хочу общаться с умными, образованными людьми, с которыми можно говорить в терминах левых и правых сверток, влияния этого на ленивость и рекурсивность, и комбинаторов неподвижной точки для функций, отвечающих морфизмам в категории графов. А эти люди почему-то скорее знают что-то ML-подобное (и зачастую сделали свой собственный прувер/язычок по мотивам).

                                      Так что я пока не очень понимаю, какое именно «того» имеется в виду в «Учите Go, пацаны, оно того стоит.»
                                      • +19
                                        И я не хочу в корпорации, стартапы и петакластеры. Я хочу общаться с умными, образованными людьми, с которыми можно говорить в терминах левых и правых сверток, влияния этого на ленивость и рекурсивность, и комбинаторов неподвижной точки для функций, отвечающих морфизмам в категории графов.

                                        Значит, вы по складу ума больше не инженер, а учёный. Ваше — это, скорее, информатика, а не разработка. Статья, очевидно, направлена разработчикам.
                                        • +1
                                          Только я слишком глуп, чтобы быть полноценным учёным и фокусироваться лишь на научной карьере, поэтому приходится максимизировать свой вклад в этот мир, занимаясь и разработкой. Пусть и, надеюсь, немножко наукоёмких вещей.

                                          А статья-то и мне интересна. Всегда ж интересно, по крайней мере, почитать о новом языке!
                                        • –1
                                          аналитическое дифференцирование в компилтайме на C++ для научной работы

                                          А, кстати, правда, что основной челлендж в эзотеричности метаязыка — ну т.е. что нельзя просто так взять и нафигачить макрос, как на лиспе или хотя бы как на Template Haskell? И, если да — почему никто за все эти десятилетия не придумал какой-нибудь Template C++ (наверно, он должен как-то по-другому называться, да)? Это практически невозможно или никому не нужно?
                                          • +2
                                            Да, никакого доступа к AST, и это печально.

                                            Почему никто не придумал — хороший вопрос. Вероятно, дело в том, что C++ — слишком базовый инструмент, и форкать компиляторы и потом ожидать, что форком легко воспользуются, странно. Посмотрите, насколько распространён c++0x concepts branch в gcc, например.

                                            В случае того же Haskell есть всякие Haskell98 и Haskell03, а есть ghc, являющийся стандартом де-факто для значительной части сообщества, вместе со всеми своими синтаксическими сахарками и расширениями системы типов. Аналогов в рамках всей экосистемы C++ нет. Есть, условно, cl.exe со своими расширениями, есть специфичные для gcc штуковины, но они все достаточно «мелкие».

                                            Я видел пропозалы на стандартизацию API для доступа к AST, впрочем. Можно надеяться, что когда-нибудь это будет реализовано.
                                        • 0
                                          Илья, в чем преимущества Go по сравнению с Python (раз уж Вы на нем пишете)? Кроме быстродействия. Не холивора ради, с Go мы просто плохо знакомы.
                                          • 0
                                            Дык эта. Статическая типизация, нэ? Это, понятно, палка о двух концах, как обычно: мешает писать маленькие прототипы, но помогает при написании больших программ. Если у вас в проекте один-два человека задействованы — то это скорее минус, если хотя бы десяток — уже скорее плюс.
                                            • 0
                                              Вот этот все правильно написал ^
                                              • 0
                                                Можно писать на подмножестве Cython, получив кстати как приятный бонус возросшую производительность. Что еще, помимо типизации? Которая не «преимущество», а все-таки «палка о двух концах». Интересуют именно преимущества, а не отличия.
                                                • 0
                                                  Помимо типизации есть один жирный минус питону: читабельность. Я всего года полтора на питоне писал и за это время не видел ни одного плюс-минус большого и при этом, читабельного проекта. Чего только monkey patching стоит, не разобраться вообще. Язык еще порой бывает через чур выразительный. С зависимостями, конечно, все не очень хорошо. Я так до конца и не понял, как у меня pip работает, что где и лежит и как что. В Go с зависимостями в этом плане, конечно, круче.
                                                  • 0
                                                    В Go с зависимостями в этом плане, конечно, круче.
                                                    Те же яйца, вид сбоку. Кто-то вендорит, кто-то собирается против edge-версий библиотек, притаскивая какую-то версию go get, кто-то тащит godep. А то и всё вместе.
                                                    • +1
                                                      Я всего года полтора на питоне писал и за это время не видел ни одного плюс-минус большого и при этом, читабельного проекта.

                                                      Возможно вопрос гайдлайнов, практик по организации кода и структуры проекта и их соблюдения на код ревью? У нас почти весь веб, за исключением пару erlang проектов на python стеке (django, falcon+sqlalchemy). Вопрос с пониманием не возникал.
                                                      Субъективно в golang есть тоже свои нюансы с читабельностью, например решение разграничивать область видимости сущности по ее названию. Например у меня после ряда языков уже сложился шаблон что если это объявление сущности- то пишем с большой буквы, а если ее инстанс — c маленькой. Или например обработка ошибок, когда четверть кода состоит из конструкций if err != nil {}

                                                      Чего только monkey patching стоит, не разобраться вообще.

                                                      А зачем вы его используете? Субъективно, редко где он нужен кроме моков в тестах, и его применение должно быть обоснованно. Да, он позволяет делать очень злые, неявные вещи, но с другой стороны unsafe в go тоже позволяет выстрелить себе в ногу.

                                                      В Go с зависимостями в этом плане, конечно, круче.

                                                      Да, «круче», особенно когда появляется необходимость использовать конкретные версии зависимостей. И тут начинается —
                                                      разработчики не вдохновились гайдлайном держать мажорные версии по разным репозиториям, а значит нужно использовать различные обертки поверх go get или gopkg сервис с конструкциями вида cat requirements | xargs go get.

                                                      P.S. Go действительно интересный язык который имеет свои плюсы, но стоит так же адекватно его оценивать и понимать что это не серебряная пуля.
                                                      • 0
                                                        например решение разграничивать область видимости сущности по ее названию. Например у меня после ряда языков уже сложился шаблон что если это объявление сущности- то пишем с большой буквы, а если ее инстанс — c маленькой.

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

                                                      Отступы в питоне делают код более компактым и более читабельным, но могут приводить к губительным ошибкам при копировании. Шаблоны в C++ дают возможность делать черезывачайно быстрый код, но чреваты сложностью и «разбуханием» бинарников. Дженерики в Джава удобны, но чреваты вылетанием «странных» исключений в весьма неожиданных местах. И т.д. и т.п.

                                                      «Чистые» преимущества разве что в каких-нибудь эзотерических языках бывают.
                                                      • 0
                                                        Пример абстрактных, сферических преимуществ в вакууме (не Go vs. Python, а для любого языка):

                                                        1) высокая производительность (еще никому не мешала),

                                                        2) более короткие названия функций и классов из стандартной библиотеки, что позволяет банально быстрее писать код,

                                                        3) большое разнообразие стандартной библиотеки,

                                                        4) наличие большого числа мощных IDE,

                                                        5) широкое комьюнити, большое количество re-usable кода.

                                                        Дальше продолжать смысла нет, но думаю все согласятся, что выше перечислены явные преимущества, а не просто особенности.
                                                        • +3
                                                          Пример абстрактных, сферических преимуществ в вакууме (не Go vs. Python, а для любого языка):
                                                          «Сферические кони в вакууме» меня не волнуют. Пожалуйста примеры двух языков — можно будет говорить.

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

                                                          2) более короткие названия функций и классов из стандартной библиотеки, что позволяет банально быстрее писать код,
                                                          Но затрудняет чтение оного кода. Сможете скезать без заглядывания в mac что делает какая-нибудь функция strxfrm?

                                                          3) большое разнообразие стандартной библиотеки,
                                                          Зачастую приводит к тому, что есть несколько несовместимых способов сделать что-либо.

                                                          4) наличие большого числа мощных IDE,
                                                          Тут, пожалуй, соглашусь, хотя замечу что подобное преимущество зачастую используется разработчиками языка для того, чтобы сложный, многословный и запутанный код всё-таки как-то можно было писать. Типичный пример — Java. После появляния «большого числа мощных IDE» там появилась куча библиотек, которые без IDE пользоваться практически невозможно, да и с IDE — проблематично.

                                                          5) широкое комьюнити, большое количество re-usable кода.
                                                          Та же самая проблема, что и с «большим разнообразием стандартной библиотеки». Наличие 100500 несовместимых версий одного и того же «велосипеда». Бич, собственно, С и C++.

                                                          Дальше продолжать смысла нет, но думаю все согласятся, что выше перечислены явные преимущества, а не просто особенности.
                                                          В «сферически-вакуумном» смысле — может быть. На практике — все эти «явные преимущества» тянут за собой «паровозом» соответствующие недостатки.
                                                        • +2
                                                          > А в чём разница?
                                                          Разница между Python и Go в рантайме. Multicore green thread scheduler решает. Это строго преимущество.
                                                        • –3
                                                          Кстати вспомнил про одно преимущество, которое на первый взгляд кажется недостатком: в Go нет почти никакой поддежки юникода в языке. Единственное место, где Go хоть что-то знает про юникод — это range loop.

                                                          Почему это преимущество, а не недостаток? Потому что подход языков типа Java или Python'а — это «идеальный мир». Где, скажем, имена файлов — записаны в известной кодировке и могут быть преобразованы в последовательность Unicode'ных codepoint'ов. Но поскольку сие неверно ни в Windows, ни в Linux (хотя и по разным причинам), то нормальная работа с файлами требует специальной поддержки во всех библиотеках… а их разработчики, разумеется, всем этим не заморачиваются.

                                                          На практике оказывается, что спецподдержка Юникода в языке часто приводит к проблемам, не помогая при этом решить ни одной практически важной задачи. А мир python'а из-за этого оказался ещё и расколот надвое: есть python2, где юникод просто мешает и есть python3, где работа с ним сделана так, что хочется найти того, кто это придумал и что-нибудь ну очень нехорошее сделать.

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

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

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

                                                          Собственно об этом и вся статья…
                                                          • +11
                                                            > На практике оказывается, что спецподдержка Юникода в языке часто приводит к проблемам, не помогая при этом решить ни одной практически важной задачи.

                                                            Я в шоке… то-то я мучался с кодировками 15 лет назад при поддержке десятка языков в ASCII сборках Win32.
                                                            Теперь, когда у меня во всем стеке прозрачный Юникод и я просто могу работать со строками не заморачивась, даже когда у меня арабский с английским перемешан, я думал, что у меня все в порядке.
                                                            А оказывается, я только себе проблемы создаю, и лучше вернуться к однобайтным строкам?!?!

                                                            Что я не так понимаю в жизни? :-)
                                                            • 0
                                                              Это типичный приём евангелистов — выдавать недостатки за преимущество.
                                                              • +5
                                                                простите, но я не понимаю вашего ответа — без аргументации он не имеет смысла

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

                                                                С UTF-8 и Unicode у меня таких проблем нет.

                                                                Что я делаю не так? Почему вы меня убеждаете, что я евангелист, и моя жизнь с однобайтными кодировками должна улучшиться? Я честно не понимаю…
                                                                • +11
                                                                  Всё вы правильно делаете :-) Евангелисты — те два с половиной человека, что без конца пиарят го на хабре. Сейчас они с пеной у рта доказывают, что «это вам не нужно!», а когда это таки реализуют, то будет новый виток хвалебных статей в духе «теперь это есть и у нас! как мы без этого раньше жили? срочно обновляться!»
                                                                  • +1
                                                                    ok, дошло.
                                                                    я неправильно понял ваш предыдущий комментарий…
                                                                    • –2
                                                                      По вашей логике выходит, что вы (и еще два с половиной хабраюзера) — антиевангелисты? Ок. )
                                                                    • +1
                                                                      Вы путаете вопрос поддержки кодировок внешних данных и вопрос поддержки Unicode ядром языка. Как правило, языки, якобы поддерживающие Unicode на уровне синтаксиса ядра («у нас все строки хранятся как Unicode»), поддерживают его весьма ограниченно, например, сравнение производится всё равно побайтово, а не с помощью UCA и результаты могут быть неправильными, или поддерживается только устаревший UCS-2.

                                                                      Unicode сам по себе не очень удачный стандарт, и вряд ли в мэйнстримовых языках в обозримом будущем будет его полноценная поддержка.
                                                                      • –1
                                                                        Согласитесь, даже устаревший UCS-2 и сравнение строк, не учитывающее умляуты/лигатуры/акценты, все же лучше работы с потоком байт. Просто если язык худо-бедно поддерживает Unicode, от стандартные UI виджеты его тоже поддерживают. В старых VC++ и Delphi, в неюникодных исполняемых файлах, это были просто танцы с песнями.

                                                                        А для правильной нормализации/сортировки можно ICU прикрутить.

                                                                        Альтернативы Юникоду, при всех его недостатках, не будет — слишком много переписывать.
                                                                        • +3
                                                                          Вот в «худо-бедно» проблемы и кроются, имхо. Как по мне то лучше пускай на уровне ядра языка объявлено что-то вроде «строки для нас просто последовательность байт/слов, мы не делаем каких-то предположений об их кодировке, для этого есть библиотеки», чем «мы используем Unicode в кодировке UTF-16 со следующими ограничениями: (список на 4 листа)».
                                                                        • 0
                                                                          Даже не полная поддержка всех 30 спецификаций консорциума юникода — это несоизмеримо лучше полного отсутствия поддержки хотя бы одной, но самой важной — Unicode Standart (http://www.unicode.org/versions/Unicode8.0.0/). В которую UCA как бы не входит. UCS-2 отличается от UTF-16 лишь наличием суррогатных пар у последней (https://ru.wikipedia.org/wiki/UTF-16). Нет никакого практического смысла иметь в памяти суррогатные пары — это замедляет и усложняет алгоритмы работы со строками, не принося никакого профита. Все используемые сейчас символы укладываются в кодовое пространство UCS-2. В тех же специфичных случаях, когда требуется работать с древнекитайскими иероглифами имеет смысл использовать UCS-4 (он же UTF-32), но не UTF-16. Так что поддержка юникода в мейнстримовых языках весьма не плоха — быстрая и покрывает большую часть практических нужд. В некоторых языках даже есть выбор какую ширину символа использовать (1,2,4), хотя в идеале строки должны автоматически выбирать оптимальную ширину символов при создании, ведь они же всё равно в большинстве реализаций являются неизменяемыми.
                                                                          • +4
                                                                            Нет никакого практического смысла иметь в памяти суррогатные пары — это замедляет и усложняет алгоритмы работы со строками, не принося никакого профита.
                                                                            Это вы что-то с чем-то спутали. Практический смысл есть и он, как бы, очень простой: данные приходящие в вашу программу их могут содержат и вам что-то с этим нужно делать.

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

                                                                            Подход Python'а: действие по-умолчанию при обнаружении подобной строки — завалить нафиг всю программу. Если человек ну очень хочет, что программа всё-таки не падала — он может это сделать, но для этого ему нужно добавить обработику данных в соотвествии с PEP 383 во все библиотеки, которые он использует.

                                                                            Собственно потому в Python 3.1 поддержку суррогатов потому и добавили, что иначе языком просто пользоваться было нельзя. Если бы всё было так, как вы говорите, то никакого PEP 383 не было бы.

                                                                            Вот объясните мне: чем подход Python'а лучше?

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

                                                                            Так что поддержка юникода в мейнстримовых языках весьма не плоха — быстрая и покрывает большую часть практических нужд.
                                                                            То есть умение программы запуститься и что-то там сделать не вылетая с UnicodeEncodeError — уже не относится к «практическим нуждам»? Ню-ню.

                                                                            Мне почему-то кажется что «показать крякозябры» вместо надписи «Установка завершена» всё-таки лучше, чем откатываие нафиг всю установки системы из-за того, что кто-то где-то перепутал указание кодировки в одном месте (реальный, невыдуманный пример: так ведёт себя текстовая установка одной из версий Fedora'ы… в последней версии вроде поправили).
                                                                            • –4
                                                                              Собственно, описанная вами проблема как раз и проистекает из языков типа го и си, которые не видят разницы между строками и массивами байт и позволяют писать в имена файлов всякое непотребство. Другое дело, что программы на питоне могли бы поступать более дружелюбно и, например, тут же предлагать исправлять бардак в файловой системе. Но и ругать их за то, что они не игнорируют проблемы, а сигнализируют о них как можно раньше — странно.
                                                                              • +4
                                                                                Другое дело, что программы на питоне могли бы поступать более дружелюбно и, например, тут же предлагать исправлять бардак в файловой системе.
                                                                                «Более дружелюбно»? Нет уж, guile, который тихо и незаметно корёжит «неправильный» UTF-8 — это ещё хуже, чем Python. Python можно худо-бедно использовать, а с Guile лучше вообще никогда не связываться. Так как вылетающее исключение можно поймать и обработать (неприятно, могут быть финансовые потери, но не смертельно), а испорченные данные зачастую восстановить просто нельзя, если вы узнаёте о том, что в «борьбе за юникод» они безнадёжно испорчены, слишком поздно.

                                                                                Но и ругать их за то, что они не игнорируют проблемы, а сигнализируют о них как можно раньше — странно.
                                                                                С какого перепугу вдруг? «Непарные суррогаты» (под Windows) и «испорченный UTF-8» (под Linux) — это данность. Вам может это дизайнерское решение не нравится, и вы можете стонать по этому поводу сколько угодно, но правильно написанная программа должна с ними работать. API так устроен. Извольте соответствовать. Пользователя не волную глубинные идеи — ему нужна программа, которая работает. А не падает.

                                                                                И вот на Go написать подобную программу проще, чем на Python'е. Вот и всё.

                                                                                Как я уже сказал: возможно в каком-то другом мире, где используется особая файловая система, не допускающая «испорченных» строк в виде имён файлов, Python и будет удобен, но в нашем мире на операционках Linux, MacOS и Windows Python3 из-за идиотски реализованной поддержки юникода является чем-то, что… лучше просто не использовать. Python2 — в этом смысле ещё не так ужасен. Там вы хотя бы должны прилагать усилия, чтобы выстрелить себе в ногу. Python3 — по умолчанию (без специальных извращений) порождает просто-напросто неработающие программы.
                                                                                • 0
                                                                                  Кривой софт независимо от поддержки юникода может натворить дел. А тот, который не валидирует ввод и вывод — точно натворит.

                                                                                  Мне, как пользователю, не нужна программа, генерирующая непарные суррогаты, из-за которых половина софта начинает неправильно работать (от показа крякозябр и превращения символов в вопросики до падения и форматирования диска), а другая половина молчаливо суёт эти непарные суррогаты во все места, где не проверяется валидность кодировки. Когда вам потребуется записать имя файла в базу данных, вы засунете в базу непарные суррогаты? Отдавая пользователю страничку со списком файлов, вы тоже предложите ему работать с непарными суррогатами?
                                                                                  • 0
                                                                                    То есть вам, как пользователю, не нужны современные операционные системы? Получаются ведь, что это прежде всего они не валидируют ввод и не экранируют вывод.
                                                                                    • –1
                                                                                      Мне не нужен бардак. И если «современные» операционные системы не валидируют имена, то этим должен заниматься прикладной софт.
                                                                                      • +4
                                                                                        Вы уж меня извините, но решать за меня как мне называть файлы — это последнее, чего я хотел бы от прикладного софта.

                                                                                        Особенно когда файлы уже есть, а прикладной софт отказывается их открывать, а вместо этого падает с какими-то неясными сообщениями об ошибках…
                                                                                        • +1
                                                                                          Прикладной софт должен выдавать имена в виде, принимаемом ОС. Если ОС принимает имя файла от одного прикладного софта и отдаёт ему его без «кернел паник», то и другой софт не должен падать от таких имён.
                                                                                      • +2
                                                                                        Посмотрите на поведение Windows Explorer'а. Он все эти случаи вполне себе нормально обрабатывает. И да, делается это путём засовывания суррогатов в том виде в каком они есть в файлы и показа пользователю. А почему нет?
                                                                                        • 0
                                                                                          Вы специально что ли называете файлы с непарными суррогатами? :-D

                                                                                          Приложение как бы и не должно работать с некорректными данными. А то накосячит ещё. А замалчивание ошибок — очень дурная практика.

                                                                                          У меня нет файлов с именами в кривой кодировке. И у меня нет софта, который такие создаёт. А если такой и будет обнаружен — он будет удалён и заменён на аналог, таким делом не промышляющий.

                                                                                          А то, что ОС позволяет насрать по среди комнаты вовсе не означает, что это надо делать, и что все, кто проходит мимо должны равномерно это дерьмо по комнате размазывать.
                                                                            • +1
                                                                              Я и сейчас зачастую имею такие проблемы, когда я получаю здоровые Shapefile из ArcGIS с полигонами, которые по незнанию клиенты сохраняют в локальной кодировке, и я ее должен угадывать, тыкая пальцем в небо (так как клиенты понятия не имеют о кодировках).
                                                                              И вы будете иметь их и в дальнейшем. Вот только разрулить их в Python'е на порядок сложнее, чем в Go.

                                                                              Оттого, что Python3 «издал указ» и объявил что отныне и вовеки текст должен быть только и исключительно в Юникоде мир не изменился. В нём по прежнему существуют разные кодировки, по прежнему используются протоколы, смешивающие ASCII-текст и бинарные данные — и со всем этим нужно как-то работать.
                                                                          • +2
                                                                            Да поддерживает Go юникод, поддерживает. Возможно они не осилили PEP 0393 и решили использовать массив байт (0-225) для экономной записи, я не знаю. Тем не менее, for-range цикл в Go при индексации оперирует не байтами, а рунами (code point), так что не надо паниковать, Go полностью поддерживает юникод. Они говорят, что string позволяет хранить строки в любой кодировке, но обычно, повторяю, обычно это именно юникод. Том Кристинсен делал доклад на тему поддержки юникода в разных языках программирования (тыц) и сказал вот такую вещь: «Of all the languages I played around with for this talk, Go was hands down the easiest — and possibly the most pleasurable — to use UTF‐8 with.»

                                                                            Юникод сложно, юникод ооочень сложно сделать правильно, потому что есть такая вещь как нормализация. И большинство ЯП ее делают неправильно из-за своих же ошибок. Короче, к Go можно придираться очень долго, но строки в нем сделаны очень даже неплохо.
                                                                            • +2
                                                                              Возможно они не осилили PEP 0393 и решили использовать массив байт (0-225) для экономной записи, я не знаю.
                                                                              Строка в Go — это просто последовательность байтов, не более того. Есть range loop (про который я говорил), который как бы «рассчитан на UTF-8» но все языковые конструкции (в том числе пресловутый range loop) вполне корректно обрабатывают невалидные UTF-8 строки.

                                                                              Короче, к Go можно придираться очень долго, но строки в нем сделаны очень даже неплохо.
                                                                              Ну дык. И главное их преимущество — то, что они не юникодные!

                                                                              Я работал с массой систем, которые имеют специальную поддержку Юникода в строках — от Win32 API до Python'а с Java'ой. Я видел массу проблем, которые этот подход создаёт, но я не знаю ни одной задачи, которую бы эта поддержка решала.

                                                                              Часто в качестве примера приводится возможность обратиться «к символу» по индексу или быстро узнать количество «символов» в строке. Отлично — но для чего вам это нужно? Чтобы проверить впишется ли строка в поле ввода? Не поможет даже с моноширинным шрифтом — вспомните про halfwidth and fullwidth forms, диакритику и разнообразные спецсимволы. Для того, чтобы понять — влезет ли строка в поле базы данных? А зачем вам это? Используйте UTF-8 в базе данных — и у вас не будет этих проблем.

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

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

                                                                              Покажите мне пример хотя бы одной практической задачи, которую весь тот ужас, который со строками в python'е устроили помогает решать — и будет о чём поговорить.
                                                                              • 0
                                                                                Пожалуйста:
                                                                                1. У вас есть шаблон, написанный в кодировке UTF-8.
                                                                                2. У вас есть база данных в кодировке UTF-16.
                                                                                2. К вам пришёл HTTP запрос с данными в кодировке windows-1251
                                                                                3. Вам нужно по запросу пользователя найти записи в базе данных, подставить в шаблон и вернуть пользователю, не запутавшись в кодировках.
                                                                                • 0
                                                                                  И в каком же месте «суперпрогрессивная поддержка юникода», требующая обязательно везде и всюду знать кодировку заранее, вам поможет?

                                                                                  Вот где она помешает — я вам скажу: если в пункте 3 к вам пришёл «запрос с данными в кодировке windows-1251», но при этом у него в заголовке написано «text/html; charset=UTF-8» (это — законный вариант, читайте спецификацию), то вы, скорее всего, обрушите всю вашу программу ещё до того, как у вас появится шанс узнать, что документ всё-таки в windows-1251, а не в utf-8.

                                                                                  Также ваша база может вернуть вам данные с суррогатами (если кто-то использовать UCS-2, а не UTF-16). И тут вы тоже можете «словить» проблем.

                                                                                  Так что вреда от поддержки юникода в вашем примеры будет вагон. А вот где эта поддержка вам поможет… я даже и не знаю. Не просветите — какое конкретно действие она сделает в этой цепочке проще? Или надёжнее? Или вообще хоть чем-нибудь поможет?

                                                                                  Да, Python содержит много разных вещей, которые помогают сделать работу со строками не такой болезненной (ссылки я уже давал). Но если бы строки изначально не знали ничего про юникод, то работать с ними было бы проще!
                                                                                  • +1
                                                                                    А вот так:
                                                                                    1. Сетевой драйвер получает запрос, по заголовкам понимает, что запрос в кодировке WIN-1251, декодирует во внутреннее представление UCS-2 и передаёт управление коду приложения.
                                                                                    2. Работаем с данными не задумываясь о кодировках.
                                                                                    3. Делаем запрос к базе, драйвер базы кодирует данные в кодировку базы — UTF-16 и декодирует ответ от неё в UCS-2.
                                                                                    4. Грузим шаблон, драйвер файловой системы автоматически определяет (BOM, xml-pi и тп), что шаблон в кодировке UTF-8, декодирует во внутреннее представление — UCS-2 и передаёт управление коду нашего приложения.
                                                                                    5. Формируем страницу не задумываясь о кодировках.
                                                                                    6. Отдаём страницу сетевому драйверу, он по заголовкам запроса понимает, что клиент ожидает ответ в кодировке WIN-1251, и кодирует ответ именно в эту кодировку.

                                                                                    В результате само приложение ничего не знает о кодировках, при этом взаимодействие с разными системами происходит в разных кодировках. А вот как вам поможет язык, который ничего не знает о кодировках? Вставит UTF-16 данные в UTF-8 шаблон и не поперхнётся? А потом вы будете возмущаться чего это программа на питоне падает при работе с полученными таким образом данными?

                                                                                    Я вам, наверно, открою глаза, но сетевые библиотеки работают не со строками, а с потоками байт, анализируя их они определяют кодировку, декодируют поток байт в нативные строки (сразу или лениво — не важно) и передают управление пользовательскому коду, которому по барабану в какой кодировке пришёл запрос. А даже если у пользователя в запросе написано, что запрос в кодировке UTF-8, а прислал он WIN-1251, то упадёт не вся программа, а ему резонно будет выдана ошибка 400 Bad Request ещё на подлёте к приложению.

                                                                                    Если есть основания полагать, что в базе могут оказаться суррогатные пары, то я буду использовать UCS-4. Именно он, емнип, и используется в питоне с третьей версии.

                                                                                    • +3
                                                                                      1. Сетевой драйвер получает запрос, по заголовкам понимает, что запрос в кодировке WIN-1251, декодирует во внутреннее представление UCS-2 и передаёт управление коду приложения.
                                                                                      Ещё раз: этого — недостаточно, так как кодировка указанная «внутри» перебивает кодировку, указанную в заголовках.

                                                                                      2. Работаем с данными не задумываясь о кодировках.
                                                                                      Программа «сворачивается в трубочку» и оседает на пол.

                                                                                      3. Делаем запрос к базе, драйвер базы кодирует данные в кодировку базы — UTF-16 и декодирует ответ от неё в UCS-2.
                                                                                      Но как, сэр? В UTF-16 отдельно стоящие суррогаты запрещены, в UCS-2 — разрешены!

                                                                                      4. Грузим шаблон, драйвер файловой системы автоматически определяет (BOM, xml-pi и тп), что шаблон в кодировке UTF-8, декодирует во внутреннее представление — UCS-2 и передаёт управление коду нашего приложения.
                                                                                      Никаких BOM'ов в реальных XML'ях нету.

                                                                                      6. Отдаём страницу сетевому драйверу, он по заголовкам запроса понимает, что клиент ожидает ответ в кодировке WIN-1251, и кодирует ответ именно в эту кодировку.
                                                                                      И снова «старая песня о главном». По заголовках запроса ничего понять нельзя, так как там написано UTF-8. Настоящая кодировка задана внутри документа через <meta charset="windows-1251">. Это — законный и корректный запрос.

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

                                                                                      А вот как вам поможет язык, который ничего не знает о кодировках?
                                                                                      Очень просто: этот язык не будет мне мешать. У меня будет модуль, который определит кодировку документа, а когда мне захочется перегнать данные из USC-2 в UTF-16 — то я сам смогу решить что мне делать с суррогатами и стоит ли с ними что-либо делать вообще.

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

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

                                                                                      А даже если у пользователя в запросе написано, что запрос в кодировке UTF-8, а прислал он WIN-1251, то упадёт не вся программа, а ему резонно будет выдана ошибка 400 Bad Request ещё на подлёте к приложению.
                                                                                      Но ему-то нужна не ошибка 400 Bed Request, а полноценный ответ. Он ведь ничего плохого не сделал и правильно указал кодировку в документе.

                                                                                      Если есть основания полагать, что в базе могут оказаться суррогатные пары, то я буду использовать UCS-4. Именно он, емнип, и используется в питоне с третьей версии.
                                                                                      Изменяет, изменяет. UCS-4 (вернее хитрожопое представление, которое «снаружи» выглядит как USC-4) появилось только python3.3.

                                                                                      Но это ровным счётом ничего не изменило: данные при преобразовании из последовательности байт во внутреннюю кодировку как терялись, так и теряются, избежать этого можно — но этого не происходит по умолчанию, от «полноценной поддержки юникода» по прежнему нет никакой пользы, но есть куча вреда. Об этом уже многие писали. Вот тут, например.
                                                                                      • 0
                                                                                        Ещё раз: этого — недостаточно, так как кодировка указанная «внутри» перебивает кодировку, указанную в заголовках.
                                                                                        И вот с чего это вы взяли? Ссылка на алгоритм извлечения кодировки из мета-тега не доказательство. Само определение кодировки описано в главе
                                                                                        http://www.w3.org/TR/html5/syntax.html#determining-the-character-encoding
                                                                                        и там кодировка из http-заголовка (4. If the transport layer specifies a character encoding, and it is supported…) выигрывает у мета-тега до которого доходит только при парсинге документа.
                                                                                        • +1
                                                                                          Стоит учитывать, что реальный мир отличается от спек w3c.

                                                                                          Реальный мир содержит json с невалидным utf8 или смесью cp1251 и utf8 в разных полях json object'а, документы с неправильной кодировкой в заголовках (или с заголовком Content-Encoding: gzip и несжатым текстом в body) и многие другие прелести, которых не ощутишь, пока работает со своими или просто нормальными API, но которые ощущаются, как только ступишь на выжженные пустоши реального мира, где стаи ракопауков носятся в воздухе.
                                                                                • 0
                                                                                  Ну как примеры задач:
                                                                                  — регистронезависимый поиск подстроки в строке
                                                                                  — перевод из одного регистра символов в другой
                                                                                  — определение валидности UTF-8 строки перед записью в базу, чтобы мусор не записать
                                                                                  • 0
                                                                                    Как только возникнет несколько вариантов представления одной и той же строки в юникоде — начнутся проблемы.

                                                                                    Использование регулярных выражений и изменение регистра зависит не только от самих строк, но и от языка, на котором они написаны, что является внешней информацией по отношению к самой строке. В любом случае, эти операции мало когда имеют смысл на unicode-строках до нормализации в NFD/NFC/NFKD/NFKC, если не затаскивать всю мощь icu в каждую библиотеку.

                                                                                    Проверка валидности utf-8 (как кодировки) делается на массиве байт. Если говорить о более высоком уровне понимания корректности, то оно сильно зависит от приложения. Кто-то может требовать определенную форму нормализации, например. Или collate в определённое представление.
                                                                                    • 0
                                                                                      — регистронезависимый поиск подстроки в строке
                                                                                      — перевод из одного регистра символов в другой
                                                                                      А ничего, что это делается по разному в разных языках? Уж если вы знаете язык строки, то указать ещё и её кодировку — не проблема.

                                                                                      — определение валидности UTF-8 строки перед записью в базу, чтобы мусор не записать
                                                                                      Совершенно непонятно чем функция, получащая «набор байт» и проверяющая его хуже «юникодных строк»
                                                                                    • 0
                                                                                      Я не знаю ужаса со строками в Python, как-то не пользуюсь им, но индексация символов нужна, например, для того, чтобы строить n-граммные индексы. Логично иметь триграмму, например, из трёх глифов, а не из трёх байт.

                                                                                      Хотя в своё время я в подобной задаче (на C++, да, причём очень голом, без QString/ICU/whatever) почесал голову и решил, что можно попробовать оперировать с байтовыми n-граммами. В итоге результат получился очень неплох, но мне всё равно как-то интуитивно не нравится.
                                                                                      • +1
                                                                                        Я не знаю ужаса со строками в Python, как-то не пользуюсь им, но индексация символов нужна, например, для того, чтобы строить n-граммные индексы. Логично иметь триграмму, например, из трёх глифов, а не из трёх байт.
                                                                                        Согласен. Но объясните мне, пожалуйста, как вот такие вот строки вам в этом помогут:
                                                                                        $ python3
                                                                                        Python 3.4.3 (default, Oct 14 2015, 20:28:29)
                                                                                        [GCC 4.8.4] on linux
                                                                                        Type «help», «copyright», «credits» or «license» for more information.
                                                                                        >>> len('ää')
                                                                                        3
                                                                                        Я вот, честно, не вижу никакого выигрыша.

                                                                                        Проблема в том, что индексация символов не помогает работать с глифами. Perl6 вроде умеет работать с глифами, но не Java и не Python.
                                                                                        • 0
                                                                                          Так я в начале комментария и сказал, что про Python не знаю.
                                                                                  • +2
                                                                                    Что я не так понимаю в жизни? :-)
                                                                                    Да. Вы не понимаете, что речь идёт не об неиспользовании Юникода, а о том, что ни язык, ни стандартная библиотека не форсируют его использование.

                                                                                    В Go используется (по соглашению) UTF8. Но все утилиты, которые могут осмысленно работать со строкой как с последовательностью байт работают со строкой как с последовательностью байт. Если вы хотите где-то форсировать Юникод (проверить UTF-8 строку на валидность) — вы можете это сделать, соответствующие утилиты вполне имеются. Но это ваш выбор, язык Go его не форсирует.

                                                                                    Вы можете получить кусок, состоящий из смеси текста и бинарных данных (HTTP, SMTP, далее везде) и спокойно его обработать. В Питоне для этого вам нужно совершать весьма странные телодвижения. А такая простая вещь, как посмотреть на формат HTML-файла, найти там тег http-equiv и если нужно перекодировть — превращается в танцы с бубнами.
                                                                                  • 0
                                                                                    То есть в Go я могу создать файл с не-юникодным названием, и эта возможность выстрелить в ногу (причём, скорее не себе, но всем вокруг) считается за преимущество?
                                                                                    • –1
                                                                                      Ты можешь, но для этого надо будет очень постараться.
                                                                                      • 0
                                                                                        1. Ды, вы можете. И в Питоне вы тоже можете, что характерно, так что в этом у них полный паритет.
                                                                                        2. Преимуществом является не тот факт, что вы можете создать файл с не-юникодным названием, а тот факт, что появление такого файла не приводит к тому, что ваши пользователи не могут войти в систему.

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

                                                                                        Причём для этого не нужно какой-то экзотики. Пример, с которым я сталкивался лично: CygWin при создании под Windows файла App::Cpan.3perl.gz породит имя файла в котором будут непарные суррогаты. Go с этим отлично справится, Python — скорее всего сойдёт с ума, потому что мало какие библиотеки работают с файлами так, как предписывает PEP 383.
                                                                                        • –6
                                                                                          Вы же понимаете, что это проблемы пользователей CygWin? У меня не появляется файлов с неюникодными именами. ЧЯДНТ?

                                                                                          Да и выбирать язык по недостаткам, напоминающими анекдот «а вы попробуйте на шкаф залезьте!» несколько странно.
                                                                                          • +1
                                                                                            Вы же понимаете, что это проблемы пользователей CygWin?
                                                                                            С какого перепугу? Это проблемы пользователей, у которых не работает ваша программа — чините.

                                                                                            У меня не появляется файлов с неюникодными именами. ЧЯДНТ?
                                                                                            Возможно не используете Python? Или довели борьбу с фатальным недостатком до совершенства. Не знаю. Я с разного рода проблемами, возникающими из-за кривой поддержки юникода в Python'е борюсь регулярно. В Python2 это относительно несложно (игнорируйте все эти юникодный строки — и будет вам большое такое «щастя»), в Python3 — это стало просто катастрофой.

                                                                                            Да и выбирать язык по недостаткам, напоминающими анекдот «а вы попробуйте на шкаф залезьте!» несколько странно.
                                                                                            Почему нет? Чем странней ситуация, в которой обваливается ваша программа тем выше шанс того, что у вас она работать будет, а у заказчика — рухнет. После чего он вас «пошлёт» с вашими идеями что неработоспособность вашей программы — это не ваша проблема. И будет, ЧСХ, прав.
                                                                                            • 0
                                                                                              Да, я не использую ни питон, ни цугвин. И мои программы внезапно работают. Явно надо что-то менять. Осталось придумать зачем использовать то, от чего у пользователей файлы не такие создаются (если не просить при этом биткоинов за удаление, конечно).

                                                                                              > И будет, ЧСХ, прав.

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

                                                                                              Вообще, интересно много ли заказчиков готовы платить за цугвин.
                                                                                              • 0
                                                                                                Вообще, интересно много ли заказчиков готовы платить за цугвин.
                                                                                                Они не платят «за цугвин». Они платят, вы не поверите, за программы. Решающие (или обещающие решить) их задачи. Которые, внезапно, не работают если на компьютере есть CygWin и он насоздавал «неправильные» файлы.

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

                                                                                                «Чудесная поддержка юникода» вам эти проблемы насоздаёт, «грубый и неправильный Go» — нет. Так кто из них лучше?
                                                                                                • –1
                                                                                                  > При этом CygWin может и не ставиться явно, а быть компонентом другой системы

                                                                                                  Если Вы отвечаете именно на то, что процитировали — у вас не получилось.

                                                                                                  Я цугвин видел только в каком то наколеночном опенсорсе, который на рабочий комп попасть не мог. А значит у техподдержки есть корректный ответ «переустановить винду». Тем более, если у вас нормальной обработки ошибок и так не задумано.

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

                                                                                                  > Так кто из них лучше?

                                                                                                  Лучше цугвин починить, а не строить костыли вокруг теоретически возможного пользовательского окружения.
                                                                                                  • +2
                                                                                                    Я цугвин видел только в каком то наколеночном опенсорсе, который на рабочий комп попасть не мог.
                                                                                                    А я его видел как часть интернет-магазина. Или, скажем, Google'ового SDK.

                                                                                                    Что характерно, когда у пользователя крешиться весь софт, кроме написанного на благословенном Go, пользователя такой ответ даже не отпугнет.
                                                                                                    В том-то и дело что «весь софт» не крешится. FAR это отлчино отрабатывает. Explorer, разумеетя, тоже. Проблемы — только с софтом на Python'е и Java. Вроде бы даже .NET'овские поделия к этому нормально относятся.
                                                                                              • 0
                                                                                                В Python2 это относительно несложно (игнорируйте все эти юникодный строки — и будет вам большое такое «щастя»)
                                                                                                Тоже не всегда. Если какая-нибудь библиотека прислала unicode-строку, то вывести её в stdout уже нетривиально, т. к. поведение print u"фыва" отличается в зависимости от того, перенаправлен ли вывод.

                                                                                                Если перенаправлен, то будет выглядеть так:
                                                                                                Traceback (most recent call last):
                                                                                                  File "t.py", line 2, in <module>
                                                                                                    print u"фыва"
                                                                                                UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordinal not in range(128)
                                                                                                • 0
                                                                                                  Если какая-нибудь библиотека прислала unicode-строку
                                                                                                  Если какая-нибудь библиотека выдёт вам юникодную строку, то нужно либо постараться убедить её этого не делать, либо придётся-таки в этом конкретном места мучиться, да.

                                                                                                  Большинство библиотек в python2 никакого юникода не порождают и сложностей, с этим связанных, не создают.
                                                                                                  • –1
                                                                                                    Если правильно помню, развлечение было после ner, где приходится работать уже со строками.
                                                                                  • +2
                                                                                    Так она помогает, если она мощная.
                                                                                    • 0
                                                                                      Закон Парето никто не отменял. От самых тупых ошибок типа засовывания строки туда, где хотят число или наоборот спасёт любая.
                                                                                • +24
                                                                                  Отличная заметка, спасибо! Если не познавательная, то как минимум новая точка зрения. Но язык (Ваш, не Go) делает мне больно.
                                                                                  • –11
                                                                                    Тот язык, дизайн которого я сейчас потихоньку разрабатываю? Так это даже не альфа — так, наброски.
                                                                                    • –10
                                                                                      Ааааа, ты про мою речь. Так это просто авторская подача, мне так нравится писать, живой текст получается.
                                                                                      • +22
                                                                                        Дело твоё, но мне после прочтения захотелось настроить фильтр и больше такого не получать в ленту. Просто потому что.
                                                                                        • –9
                                                                                          Кому как. Товарищу комментом ниже, например, понравилось.
                                                                                    • +4
                                                                                      Ни дыры не понял, но почитал бы этого автора еще.
                                                                                      • +13
                                                                                        Такая же фигня с исходниками на гоу))