Здарова! Короче, последнее время на хабре было много срачей вокруг 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, пацаны, оно того стоит.
Спасибо за твое внимание,
Илья.
Комментарии (237)
sergeylanz
27.12.2015 00:11Надо только добавить что на нем легко делать и потдерживать микросервисы. Это все из за легкий деплоев и маленкий требываний к ресурсам. Так что есть много стартапов которым это очень нравится(меньше возни с серверами и меньше серверов)
imanushin
27.12.2015 00:32Непонятно про deployment… В случае Java/.Net всё можно свести к схеме: копируем бинарники в новую папку, далее меняем конфиг сервера, чтобы смотрел уже в новое место. А как в Go? Там получается проще, чем копирование файлов?
khim
27.12.2015 00:57+13Там получается проще, чем копирование файлов?
Проще копирования файлов может быть только копирования файла. Одного. Ваш КО.imanushin
27.12.2015 12:33А конфиг вшит в исполняемый файл? Например, на какой порт будет смотреть прога, в случае веба?
khim
27.12.2015 18:36+10Укажите в командной стоке. Как вы думаете, зачем Goggle лет пять (или семь?) назад добавил в ядро Linux'а patch, который отменил ранее действовашее жёствое окраничение на длину командной строки в жалкие 131072 символов?
mirrr
28.12.2015 15:51+1Еще можно использовать переменные окружения, например указать их в systemd сервисе или любом супервизоре.
sergeylanz
27.12.2015 01:40+2я говорил в сторону Rails например.Там целая наука что и как unicorn puma и другие представители зоопарка. Как на Java делать обновления кода (не важно сколько) с gracefull restart?
VolCh
27.12.2015 08:40+2Чтобы изменить конфиг сервера нужно сначала поднять сервер и создать для него конфиги.
vayho
27.12.2015 11:33В java уже можно не поднимать сервер вручную, встраивайте сервер в jar и все. Всякие Spring Boot это делают из коробки.
konsoletyper
27.12.2015 12:19-2Никогда не понимал, зачем всё это, если Eclipse WTP (или какие там альтернативы в других IDE) сам поднимет хотите Tomcat, хотите Jetty, да ещё и будет автоматом редеплоить приложение в запущенный прогретый контейнер, вместо того, чтобы каждый раз вручную запускать веб-сервер в непрогретой JVM.
vayho
27.12.2015 13:09я говорю о продакшн деплое, сейчас уже вполне можно обходиться встроенным контейнером не скачивая какой нибудь tomcat, для разработки понятное дело в той же идее можно отдельные классы в рантайме редеплоить
konsoletyper
27.12.2015 15:47ИМХО, как раз в контейнер сервлетов гораздо удобнее деплоить, чем копиировать 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.
elw00d
28.12.2015 00:21+1Мой опыт показывает, что деплоить war намного менее удобно, чем запускать jar со встроенным сервлет-контейнером. По пунктам.
1. Редеплой часто бывает не production-ready. Например, в jboss as в своё время редеплой хоть и работал, но периодически глючил.
2. Деплой через cargo — медленный и неудобный для разработки, а безопасность его под вопросом в продакшене. Медленный — потому что копируются все ресурсы приложения, а потом вся эта штука разворачивается контейнером. При использовании встроенного сервлет-контейнера достаточно лишь перезапустить процесс. Ничего копировать и распаковывать не нужно. Это что касается окружения разработки. А чтобы не велосипедить на скриптах при деплое в продакшене, можно сделать deb-пакет, например, или использовать контейнеры. Дополнительный плюс такого подхода будет в том, что не придётся долго рассказывать админам, как выполняется деплой. Обновил пакет — и всё работает. Что же касается безопасности деплоя через сокет в продакшене, достаточно отметить, что были эксплоиты для различных серверов приложений, которые эксплуатировали дырки в админках. Конечно, эти порты наружу не будут открыты, но в случае эмбеддед сервера этой проблемы вообще нет.
3. Не в курсе про томкат, может быть там все действительно хорошо с zero downtime, но я бы поостерёгся редеплоить приложения в продакшене (см первый пункт).
Сравнить скорость cargo и ембеддед можно легко, если есть в наличии проект, war которого занимает мегабайт 70. cargo будет деплоить эту штуку сильно дольше, чем просто запустится новый java-процесс. А высокая скорость рестарта при разработке — высокая производительность программистов, то есть наше всё.
grossws
28.12.2015 00:32Стоит добавить, что частый редеплой приложения при не очень удачных библиотеках и/или сервлет-контейнере/аппсервере может приводить к OOM по permgen/metaspace. Получается такой «zero» downtime, что лучше уж как-нибудь без него. Как минимум, регулярно ловим на jboss as 7.
konsoletyper
28.12.2015 10:25Хочу сразу оговориться, что 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.sergeylanz
29.12.2015 02:58После того как я это прочитал
Рад что в GO деплой одни бинарным файлом и рестарт на лету без потери запросов
Только ваше обьяснения тут хватит чтоб это понятьkonsoletyper
29.12.2015 08:09+1В Java деплой одним файлом, и имя ему — war. И рестартует без потери запросов. А главное — без того, чтобы заходить на сервер по какому-нибудь ssh.
Каким образом go рестартует веб-приложения без потери запросов? Ссылку можно?
Shoonoise
27.12.2015 11:53ну да, а JVM уже на каждой машине стоит, ага
konsoletyper
27.12.2015 12:21+1Можно подумать, ОС на каждой машине стоит. А так, вот пара вариантов:
1. sudo yum install
2. docker-образ, причём либо просто с предустановленной JVM, либо сразу с приложением
imanushin
27.12.2015 00:28+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, все пока неудачно…
edeldm
27.12.2015 01:19-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? Почему?
Я не говорю в данном комментарии о преимуществах или недостатках языка, а задаю вам вопросы, ответы на которые вы дадите для себя.
И сами все поймете.
creker
27.12.2015 01:23+6Он не закрытый, в отличие от .NET
У .Net есть открытый Roslyn вообще-то.
Что нельзя реализовать в Go имеющимся набором стандартных и дополнительных библиотек?
С учетом CGO это вообще отпадает по определению. Вкомпилить можно что угодно. Даже для C++ есть вариант.
Если средства, созданные на языке распространяются в _официальном_ дистрибутиве Linux (Red Hat, Fedora и др.), говорит ли это о популярности? Есть ли в этих дистрибутивах хоть что-то, созданное на .NET, Java? Почему?
В данном случае GO не имеет к этому никакого отношения. А .Net и Java всегда будут иметь проблему в виде рантайма.
grossws
27.12.2015 02:51+1Если средства, созданные на языке распространяются в _официальном_ дистрибутиве Linux (Red Hat, Fedora и др.), говорит ли это о популярности? Есть ли в этих дистрибутивах хоть что-то, созданное на .NET, Java? Почему?
Ни о чём не говорит. В репозиториях той же федоры можно легко найти софт на java, .net (mono), go, d, haskell и даже более экзотических языках. Или вы неспособны вызватьrepoquery --whatrequires java-1.8.0-openjdkи посмотреть какие пакеты зависят от него?
grossws
27.12.2015 02:37если нужен GC, то подойдет и Java Card
Там в большинстве случаев нет GC. Есть object deletion, который не всегда поддерживается и не рекомендуется.
всё на уровне java, которая на уровне .Net
Тесты по java (сравнение с .net) в статье, на которую вы ссылаетесь, некорректны. Усреднять прогоны на непрогретой jvm — глупость. Не считая того, что hotspot с улучшениями из jrockit несколько отличается от 6u24, которая была в 2011.
stack_trace
27.12.2015 02:42+5обещанной производительности нет, всё на уровне java
По-моему, у джавы проблемы не с производительностью, а с диким потреблением памяти. Как с этим у Go?
0xd34df00d
27.12.2015 01:17+9Спойлер: комментарий полон пафоса, самолюбования и немножко вульгарщины.
О, какой шикарныйопусвбросопус-то я пропустил-то, со сравнением с хаскелем-то.
Причины шедевральны, конечно, что здесь (цитируемые слова Пайка), что там — «Хаскель сложный, я чо-т ниасилил, а вот Go — это просто и понятно». Моё социопатическое восприятие ещё постоянно улавливает «учите Go, пацаны, разработчики потекут в ваш опенсорс коммитами, вы станете социальным, Go — это новый тренд».
Только не хочу я быть социальным. И я не хочу опенсорс ради коммитов. Я хочу опенсорс (и программирование вообще) ради челленджей. Решить на хаскеле задачи к курсу на курсере по биоинформатике — это небольшой челлендж. Написать аналитическое дифференцирование в компилтайме на C++ для научной работы — это челлендж (на самом деле очень забавный и мощный челлендж, я закончил это позавчера, а ментальные оргазмы до сих пор накрывают). Написать на C++ ORM с минимальными пользовательскими аннотациями — это челлендж. Или написать ещё одну плюсовую библиотеку с функторами, аппликативными функторами и монадами, написать в её рамках Either и радоваться типобезопасной обработке ошибок вместо уродливых сырых возвращаемых значений и не менее уродливых экзепшонов. Тоже челлендж, хотя и не особо большой. Или написать парсер языка разметки без всяких спецификаций на Parsec, а потом переписать на Attoparsec, и добиться исключительной производительности при константном потреблении памяти. И при этом ещё убедиться, что система типов ведёт тебя за ручку, и все нужные преобразования этого языка разметки выполняются максимально обоснованно и доказанно.
И я не хочу в корпорации, стартапы и петакластеры. Я хочу общаться с умными, образованными людьми, с которыми можно говорить в терминах левых и правых сверток, влияния этого на ленивость и рекурсивность, и комбинаторов неподвижной точки для функций, отвечающих морфизмам в категории графов. А эти люди почему-то скорее знают что-то ML-подобное (и зачастую сделали свой собственный прувер/язычок по мотивам).
Так что я пока не очень понимаю, какое именно «того» имеется в виду в «Учите Go, пацаны, оно того стоит.»stack_trace
27.12.2015 02:46+19И я не хочу в корпорации, стартапы и петакластеры. Я хочу общаться с умными, образованными людьми, с которыми можно говорить в терминах левых и правых сверток, влияния этого на ленивость и рекурсивность, и комбинаторов неподвижной точки для функций, отвечающих морфизмам в категории графов.
Значит, вы по складу ума больше не инженер, а учёный. Ваше — это, скорее, информатика, а не разработка. Статья, очевидно, направлена разработчикам.0xd34df00d
27.12.2015 02:59+1Только я слишком глуп, чтобы быть полноценным учёным и фокусироваться лишь на научной карьере, поэтому приходится максимизировать свой вклад в этот мир, занимаясь и разработкой. Пусть и, надеюсь, немножко наукоёмких вещей.
А статья-то и мне интересна. Всегда ж интересно, по крайней мере, почитать о новом языке!
salas
27.12.2015 10:41-1аналитическое дифференцирование в компилтайме на C++ для научной работы
А, кстати, правда, что основной челлендж в эзотеричности метаязыка — ну т.е. что нельзя просто так взять и нафигачить макрос, как на лиспе или хотя бы как на Template Haskell? И, если да — почему никто за все эти десятилетия не придумал какой-нибудь Template C++ (наверно, он должен как-то по-другому называться, да)? Это практически невозможно или никому не нужно?0xd34df00d
27.12.2015 22:48+2Да, никакого доступа к AST, и это печально.
Почему никто не придумал — хороший вопрос. Вероятно, дело в том, что C++ — слишком базовый инструмент, и форкать компиляторы и потом ожидать, что форком легко воспользуются, странно. Посмотрите, насколько распространён c++0x concepts branch в gcc, например.
В случае того же Haskell есть всякие Haskell98 и Haskell03, а есть ghc, являющийся стандартом де-факто для значительной части сообщества, вместе со всеми своими синтаксическими сахарками и расширениями системы типов. Аналогов в рамках всей экосистемы C++ нет. Есть, условно, cl.exe со своими расширениями, есть специфичные для gcc штуковины, но они все достаточно «мелкие».
Я видел пропозалы на стандартизацию API для доступа к AST, впрочем. Можно надеяться, что когда-нибудь это будет реализовано.
andyN
27.12.2015 01:20Илья, в чем преимущества Go по сравнению с Python (раз уж Вы на нем пишете)? Кроме быстродействия. Не холивора ради, с Go мы просто плохо знакомы.
khim
27.12.2015 01:34Дык эта. Статическая типизация, нэ? Это, понятно, палка о двух концах, как обычно: мешает писать маленькие прототипы, но помогает при написании больших программ. Если у вас в проекте один-два человека задействованы — то это скорее минус, если хотя бы десяток — уже скорее плюс.
namespace
27.12.2015 01:37Вот этот все правильно написал ^
andyN
27.12.2015 02:02Можно писать на подмножестве Cython, получив кстати как приятный бонус возросшую производительность. Что еще, помимо типизации? Которая не «преимущество», а все-таки «палка о двух концах». Интересуют именно преимущества, а не отличия.
namespace
27.12.2015 02:23Помимо типизации есть один жирный минус питону: читабельность. Я всего года полтора на питоне писал и за это время не видел ни одного плюс-минус большого и при этом, читабельного проекта. Чего только monkey patching стоит, не разобраться вообще. Язык еще порой бывает через чур выразительный. С зависимостями, конечно, все не очень хорошо. Я так до конца и не понял, как у меня pip работает, что где и лежит и как что. В Go с зависимостями в этом плане, конечно, круче.
grossws
27.12.2015 02:54В Go с зависимостями в этом плане, конечно, круче.
Те же яйца, вид сбоку. Кто-то вендорит, кто-то собирается против edge-версий библиотек, притаскивая какую-то версию go get, кто-то тащит godep. А то и всё вместе.
ts_taiye
27.12.2015 04:40+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 действительно интересный язык который имеет свои плюсы, но стоит так же адекватно его оценивать и понимать что это не серебряная пуля.MacIn
27.12.2015 18:01например решение разграничивать область видимости сущности по ее названию. Например у меня после ряда языков уже сложился шаблон что если это объявление сущности- то пишем с большой буквы, а если ее инстанс — c маленькой.
«Венгерская нотация же» — скажет кто-то.
khim
27.12.2015 03:35+2Интересуют именно преимущества, а не отличия.
А в чём разница? Нет, я не издеваюсь, я серьёзно. Потому что я просто не верю, что вы сможете взять два любых, более-менее распространённых, языка и при их сравнении найти вообще хоть что-то, что не было бы «палкой о двух концах».
Отступы в питоне делают код более компактым и более читабельным, но могут приводить к губительным ошибкам при копировании. Шаблоны в C++ дают возможность делать черезывачайно быстрый код, но чреваты сложностью и «разбуханием» бинарников. Дженерики в Джава удобны, но чреваты вылетанием «странных» исключений в весьма неожиданных местах. И т.д. и т.п.
«Чистые» преимущества разве что в каких-нибудь эзотерических языках бывают.andyN
27.12.2015 17:12Пример абстрактных, сферических преимуществ в вакууме (не Go vs. Python, а для любого языка):
1) высокая производительность (еще никому не мешала),
2) более короткие названия функций и классов из стандартной библиотеки, что позволяет банально быстрее писать код,
3) большое разнообразие стандартной библиотеки,
4) наличие большого числа мощных IDE,
5) широкое комьюнити, большое количество re-usable кода.
Дальше продолжать смысла нет, но думаю все согласятся, что выше перечислены явные преимущества, а не просто особенности.khim
27.12.2015 18:47+3Пример абстрактных, сферических преимуществ в вакууме (не Go vs. Python, а для любого языка):
«Сферические кони в вакууме» меня не волнуют. Пожалуйста примеры двух языков — можно будет говорить.
1) высокая производительность (еще никому не мешала),
Мешает. Причём очень сильно. Не видел ни одного языка который бы не платил за высокую производительность сложностью синтаксиса и/или безопасностью. А зачастую и тем и другим.
2) более короткие названия функций и классов из стандартной библиотеки, что позволяет банально быстрее писать код,
Но затрудняет чтение оного кода. Сможете скезать без заглядывания в mac что делает какая-нибудь функция strxfrm?
3) большое разнообразие стандартной библиотеки,
Зачастую приводит к тому, что есть несколько несовместимых способов сделать что-либо.
4) наличие большого числа мощных IDE,
Тут, пожалуй, соглашусь, хотя замечу что подобное преимущество зачастую используется разработчиками языка для того, чтобы сложный, многословный и запутанный код всё-таки как-то можно было писать. Типичный пример — Java. После появляния «большого числа мощных IDE» там появилась куча библиотек, которые без IDE пользоваться практически невозможно, да и с IDE — проблематично.
5) широкое комьюнити, большое количество re-usable кода.
Та же самая проблема, что и с «большим разнообразием стандартной библиотеки». Наличие 100500 несовместимых версий одного и того же «велосипеда». Бич, собственно, С и C++.
Дальше продолжать смысла нет, но думаю все согласятся, что выше перечислены явные преимущества, а не просто особенности.
В «сферически-вакуумном» смысле — может быть. На практике — все эти «явные преимущества» тянут за собой «паровозом» соответствующие недостатки.
nwalker
27.12.2015 21:47+2> А в чём разница?
Разница между Python и Go в рантайме. Multicore green thread scheduler решает. Это строго преимущество.
khim
27.12.2015 04:12-3Кстати вспомнил про одно преимущество, которое на первый взгляд кажется недостатком: в Go нет почти никакой поддежки юникода в языке. Единственное место, где Go хоть что-то знает про юникод — это range loop.
Почему это преимущество, а не недостаток? Потому что подход языков типа Java или Python'а — это «идеальный мир». Где, скажем, имена файлов — записаны в известной кодировке и могут быть преобразованы в последовательность Unicode'ных codepoint'ов. Но поскольку сие неверно ни в Windows, ни в Linux (хотя и по разным причинам), то нормальная работа с файлами требует специальной поддержки во всех библиотеках… а их разработчики, разумеется, всем этим не заморачиваются.
На практике оказывается, что спецподдержка Юникода в языке часто приводит к проблемам, не помогая при этом решить ни одной практически важной задачи. А мир python'а из-за этого оказался ещё и расколот надвое: есть python2, где юникод просто мешает и есть python3, где работа с ним сделана так, что хочется найти того, кто это придумал и что-нибудь ну очень нехорошее сделать.
Насколько конкретно для вас это важно — опять-таки, зависит от ваших задач.
И это — типичная ситуация при обсуждениях Go. Как правило те, кто «не понимают зачем он нужен» хотят в нём увидеть какую-то «киллер-фичу», не понимая что «киллер-фича» Go — это скорее не список возможностей (которые могут кому-то помочь), а скорее список невозможностей (которые иногда мешают решать какие-то сиюминутные проблемы, но помогают в среднесрочной перспективе). Go достаточно гибок для того, чтобы его загнуть в такую дугу, которая позволит вам решить задачу, но недостаточно гибок для того, чтобы вы смогли случайно сделать для себя удавку на шею (при должном старании всё возможно, конечно, но для этого обычно приходится действительно постараться).
Как то же отсутствие monkey patching'а: да, человеку привыкшему что любой косяк в интерфейсе можно исправить за счёт его исправления «на лету» из другого куска кода тяжело с этим смириться, но очень скоро понимаешь что взамен ты получаешь более продуманные интерфейсы и меньшее число странных ошибок.
Собственно об этом и вся статья…
andrewsch
27.12.2015 10:06+11> На практике оказывается, что спецподдержка Юникода в языке часто приводит к проблемам, не помогая при этом решить ни одной практически важной задачи.
Я в шоке… то-то я мучался с кодировками 15 лет назад при поддержке десятка языков в ASCII сборках Win32.
Теперь, когда у меня во всем стеке прозрачный Юникод и я просто могу работать со строками не заморачивась, даже когда у меня арабский с английским перемешан, я думал, что у меня все в порядке.
А оказывается, я только себе проблемы создаю, и лучше вернуться к однобайтным строкам?!?!
Что я не так понимаю в жизни? :-)
vintage
27.12.2015 10:36Это типичный приём евангелистов — выдавать недостатки за преимущество.
andrewsch
27.12.2015 10:46+5простите, но я не понимаю вашего ответа — без аргументации он не имеет смысла
я знаю про кучу проблем, которые я в прошлом имел с однобайтными кодировками, когда половина текста могла состоять из вопросиков (потому что кодировки были и близко не совместимы), клиенты ругались на потерянные названия файлов и т.п.
Я и сейчас зачастую имею такие проблемы, когда я получаю здоровые Shapefile из ArcGIS с полигонами, которые по незнанию клиенты сохраняют в локальной кодировке, и я ее должен угадывать, тыкая пальцем в небо (так как клиенты понятия не имеют о кодировках).
С UTF-8 и Unicode у меня таких проблем нет.
Что я делаю не так? Почему вы меня убеждаете, что я евангелист, и моя жизнь с однобайтными кодировками должна улучшиться? Я честно не понимаю…vintage
27.12.2015 11:37+11Всё вы правильно делаете :-) Евангелисты — те два с половиной человека, что без конца пиарят го на хабре. Сейчас они с пеной у рта доказывают, что «это вам не нужно!», а когда это таки реализуют, то будет новый виток хвалебных статей в духе «теперь это есть и у нас! как мы без этого раньше жили? срочно обновляться!»
divan0
27.12.2015 22:17-2По вашей логике выходит, что вы (и еще два с половиной хабраюзера) — антиевангелисты? Ок. )
VolCh
27.12.2015 13:09+1Вы путаете вопрос поддержки кодировок внешних данных и вопрос поддержки Unicode ядром языка. Как правило, языки, якобы поддерживающие Unicode на уровне синтаксиса ядра («у нас все строки хранятся как Unicode»), поддерживают его весьма ограниченно, например, сравнение производится всё равно побайтово, а не с помощью UCA и результаты могут быть неправильными, или поддерживается только устаревший UCS-2.
Unicode сам по себе не очень удачный стандарт, и вряд ли в мэйнстримовых языках в обозримом будущем будет его полноценная поддержка.andrewsch
27.12.2015 14:05-1Согласитесь, даже устаревший UCS-2 и сравнение строк, не учитывающее умляуты/лигатуры/акценты, все же лучше работы с потоком байт. Просто если язык худо-бедно поддерживает Unicode, от стандартные UI виджеты его тоже поддерживают. В старых VC++ и Delphi, в неюникодных исполняемых файлах, это были просто танцы с песнями.
А для правильной нормализации/сортировки можно ICU прикрутить.
Альтернативы Юникоду, при всех его недостатках, не будет — слишком много переписывать.VolCh
28.12.2015 09:16+3Вот в «худо-бедно» проблемы и кроются, имхо. Как по мне то лучше пускай на уровне ядра языка объявлено что-то вроде «строки для нас просто последовательность байт/слов, мы не делаем каких-то предположений об их кодировке, для этого есть библиотеки», чем «мы используем Unicode в кодировке UTF-16 со следующими ограничениями: (список на 4 листа)».
vintage
27.12.2015 14:39Даже не полная поддержка всех 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), хотя в идеале строки должны автоматически выбирать оптимальную ширину символов при создании, ведь они же всё равно в большинстве реализаций являются неизменяемыми.
khim
27.12.2015 18:34+4Нет никакого практического смысла иметь в памяти суррогатные пары — это замедляет и усложняет алгоритмы работы со строками, не принося никакого профита.
Это вы что-то с чем-то спутали. Практический смысл есть и он, как бы, очень простой: данные приходящие в вашу программу их могут содержат и вам что-то с этим нужно делать.
Подход Go: нас это не волнует, все библиотеки с ними работают настолько хорошо, насколько возможно, программист сам решает — хочет он работать с такими строками или нет.
Подход Python'а: действие по-умолчанию при обнаружении подобной строки — завалить нафиг всю программу. Если человек ну очень хочет, что программа всё-таки не падала — он может это сделать, но для этого ему нужно добавить обработику данных в соотвествии с PEP 383 во все библиотеки, которые он использует.
Собственно потому в Python 3.1 поддержку суррогатов потому и добавили, что иначе языком просто пользоваться было нельзя. Если бы всё было так, как вы говорите, то никакого PEP 383 не было бы.
Вот объясните мне: чем подход Python'а лучше?
Все используемые сейчас символы укладываются в кодовое пространство UCS-2.
Все используемые символы — да, все испольуемые данные — и близко нет.
Так что поддержка юникода в мейнстримовых языках весьма не плоха — быстрая и покрывает большую часть практических нужд.
То есть умение программы запуститься и что-то там сделать не вылетая с UnicodeEncodeError — уже не относится к «практическим нуждам»? Ню-ню.
Мне почему-то кажется что «показать крякозябры» вместо надписи «Установка завершена» всё-таки лучше, чем откатываие нафиг всю установки системы из-за того, что кто-то где-то перепутал указание кодировки в одном месте (реальный, невыдуманный пример: так ведёт себя текстовая установка одной из версий Fedora'ы… в последней версии вроде поправили).vintage
27.12.2015 20:14-4Собственно, описанная вами проблема как раз и проистекает из языков типа го и си, которые не видят разницы между строками и массивами байт и позволяют писать в имена файлов всякое непотребство. Другое дело, что программы на питоне могли бы поступать более дружелюбно и, например, тут же предлагать исправлять бардак в файловой системе. Но и ругать их за то, что они не игнорируют проблемы, а сигнализируют о них как можно раньше — странно.
khim
27.12.2015 20:28+4Другое дело, что программы на питоне могли бы поступать более дружелюбно и, например, тут же предлагать исправлять бардак в файловой системе.
«Более дружелюбно»? Нет уж, guile, который тихо и незаметно корёжит «неправильный» UTF-8 — это ещё хуже, чем Python. Python можно худо-бедно использовать, а с Guile лучше вообще никогда не связываться. Так как вылетающее исключение можно поймать и обработать (неприятно, могут быть финансовые потери, но не смертельно), а испорченные данные зачастую восстановить просто нельзя, если вы узнаёте о том, что в «борьбе за юникод» они безнадёжно испорчены, слишком поздно.
Но и ругать их за то, что они не игнорируют проблемы, а сигнализируют о них как можно раньше — странно.
С какого перепугу вдруг? «Непарные суррогаты» (под Windows) и «испорченный UTF-8» (под Linux) — это данность. Вам может это дизайнерское решение не нравится, и вы можете стонать по этому поводу сколько угодно, но правильно написанная программа должна с ними работать. API так устроен. Извольте соответствовать. Пользователя не волную глубинные идеи — ему нужна программа, которая работает. А не падает.
И вот на Go написать подобную программу проще, чем на Python'е. Вот и всё.
Как я уже сказал: возможно в каком-то другом мире, где используется особая файловая система, не допускающая «испорченных» строк в виде имён файлов, Python и будет удобен, но в нашем мире на операционках Linux, MacOS и Windows Python3 из-за идиотски реализованной поддержки юникода является чем-то, что… лучше просто не использовать. Python2 — в этом смысле ещё не так ужасен. Там вы хотя бы должны прилагать усилия, чтобы выстрелить себе в ногу. Python3 — по умолчанию (без специальных извращений) порождает просто-напросто неработающие программы.vintage
28.12.2015 09:38Кривой софт независимо от поддержки юникода может натворить дел. А тот, который не валидирует ввод и вывод — точно натворит.
Мне, как пользователю, не нужна программа, генерирующая непарные суррогаты, из-за которых половина софта начинает неправильно работать (от показа крякозябр и превращения символов в вопросики до падения и форматирования диска), а другая половина молчаливо суёт эти непарные суррогаты во все места, где не проверяется валидность кодировки. Когда вам потребуется записать имя файла в базу данных, вы засунете в базу непарные суррогаты? Отдавая пользователю страничку со списком файлов, вы тоже предложите ему работать с непарными суррогатами?VolCh
28.12.2015 09:58То есть вам, как пользователю, не нужны современные операционные системы? Получаются ведь, что это прежде всего они не валидируют ввод и не экранируют вывод.
vintage
28.12.2015 11:50-1Мне не нужен бардак. И если «современные» операционные системы не валидируют имена, то этим должен заниматься прикладной софт.
khim
28.12.2015 12:10+4Вы уж меня извините, но решать за меня как мне называть файлы — это последнее, чего я хотел бы от прикладного софта.
Особенно когда файлы уже есть, а прикладной софт отказывается их открывать, а вместо этого падает с какими-то неясными сообщениями об ошибках…
VolCh
28.12.2015 12:59+1Прикладной софт должен выдавать имена в виде, принимаемом ОС. Если ОС принимает имя файла от одного прикладного софта и отдаёт ему его без «кернел паник», то и другой софт не должен падать от таких имён.
khim
28.12.2015 12:07+2Посмотрите на поведение Windows Explorer'а. Он все эти случаи вполне себе нормально обрабатывает. И да, делается это путём засовывания суррогатов в том виде в каком они есть в файлы и показа пользователю. А почему нет?
vintage
28.12.2015 13:49Вы специально что ли называете файлы с непарными суррогатами? :-D
Приложение как бы и не должно работать с некорректными данными. А то накосячит ещё. А замалчивание ошибок — очень дурная практика.
У меня нет файлов с именами в кривой кодировке. И у меня нет софта, который такие создаёт. А если такой и будет обнаружен — он будет удалён и заменён на аналог, таким делом не промышляющий.
А то, что ОС позволяет насрать по среди комнаты вовсе не означает, что это надо делать, и что все, кто проходит мимо должны равномерно это дерьмо по комнате размазывать.
khim
27.12.2015 18:16+1Я и сейчас зачастую имею такие проблемы, когда я получаю здоровые Shapefile из ArcGIS с полигонами, которые по незнанию клиенты сохраняют в локальной кодировке, и я ее должен угадывать, тыкая пальцем в небо (так как клиенты понятия не имеют о кодировках).
И вы будете иметь их и в дальнейшем. Вот только разрулить их в Python'е на порядок сложнее, чем в Go.
Оттого, что Python3 «издал указ» и объявил что отныне и вовеки текст должен быть только и исключительно в Юникоде мир не изменился. В нём по прежнему существуют разные кодировки, по прежнему используются протоколы, смешивающие ASCII-текст и бинарные данные — и со всем этим нужно как-то работать.
namespace
27.12.2015 13:56+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 можно придираться очень долго, но строки в нем сделаны очень даже неплохо.khim
27.12.2015 19:26+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'е устроили помогает решать — и будет о чём поговорить.vintage
27.12.2015 21:18Пожалуйста:
1. У вас есть шаблон, написанный в кодировке UTF-8.
2. У вас есть база данных в кодировке UTF-16.
2. К вам пришёл HTTP запрос с данными в кодировке windows-1251
3. Вам нужно по запросу пользователя найти записи в базе данных, подставить в шаблон и вернуть пользователю, не запутавшись в кодировках.khim
27.12.2015 22:23И в каком же месте «суперпрогрессивная поддержка юникода», требующая обязательно везде и всюду знать кодировку заранее, вам поможет?
Вот где она помешает — я вам скажу: если в пункте 3 к вам пришёл «запрос с данными в кодировке windows-1251», но при этом у него в заголовке написано «text/html; charset=UTF-8» (это — законный вариант, читайте спецификацию), то вы, скорее всего, обрушите всю вашу программу ещё до того, как у вас появится шанс узнать, что документ всё-таки в windows-1251, а не в utf-8.
Также ваша база может вернуть вам данные с суррогатами (если кто-то использовать UCS-2, а не UTF-16). И тут вы тоже можете «словить» проблем.
Так что вреда от поддержки юникода в вашем примеры будет вагон. А вот где эта поддержка вам поможет… я даже и не знаю. Не просветите — какое конкретно действие она сделает в этой цепочке проще? Или надёжнее? Или вообще хоть чем-нибудь поможет?
Да, Python содержит много разных вещей, которые помогают сделать работу со строками не такой болезненной (ссылки я уже давал). Но если бы строки изначально не знали ничего про юникод, то работать с ними было бы проще!vintage
28.12.2015 00:26+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. Именно он, емнип, и используется в питоне с третьей версии.
khim
28.12.2015 12:35+31. Сетевой драйвер получает запрос, по заголовкам понимает, что запрос в кодировке 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.
Но это ровным счётом ничего не изменило: данные при преобразовании из последовательности байт во внутреннюю кодировку как терялись, так и теряются, избежать этого можно — но этого не происходит по умолчанию, от «полноценной поддержки юникода» по прежнему нет никакой пользы, но есть куча вреда. Об этом уже многие писали. Вот тут, например.
youlose
27.12.2015 22:49Ну как примеры задач:
— регистронезависимый поиск подстроки в строке
— перевод из одного регистра символов в другой
— определение валидности UTF-8 строки перед записью в базу, чтобы мусор не записатьgrossws
28.12.2015 01:05Как только возникнет несколько вариантов представления одной и той же строки в юникоде — начнутся проблемы.
Использование регулярных выражений и изменение регистра зависит не только от самих строк, но и от языка, на котором они написаны, что является внешней информацией по отношению к самой строке. В любом случае, эти операции мало когда имеют смысл на unicode-строках до нормализации в NFD/NFC/NFKD/NFKC, если не затаскивать всю мощь icu в каждую библиотеку.
Проверка валидности utf-8 (как кодировки) делается на массиве байт. Если говорить о более высоком уровне понимания корректности, то оно сильно зависит от приложения. Кто-то может требовать определенную форму нормализации, например. Или collate в определённое представление.
khim
28.12.2015 12:38— регистронезависимый поиск подстроки в строке
А ничего, что это делается по разному в разных языках? Уж если вы знаете язык строки, то указать ещё и её кодировку — не проблема.
— перевод из одного регистра символов в другой
— определение валидности UTF-8 строки перед записью в базу, чтобы мусор не записать
Совершенно непонятно чем функция, получащая «набор байт» и проверяющая его хуже «юникодных строк»
0xd34df00d
27.12.2015 22:56Я не знаю ужаса со строками в Python, как-то не пользуюсь им, но индексация символов нужна, например, для того, чтобы строить n-граммные индексы. Логично иметь триграмму, например, из трёх глифов, а не из трёх байт.
Хотя в своё время я в подобной задаче (на C++, да, причём очень голом, без QString/ICU/whatever) почесал голову и решил, что можно попробовать оперировать с байтовыми n-граммами. В итоге результат получился очень неплох, но мне всё равно как-то интуитивно не нравится.khim
28.12.2015 12:45+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('a?a')
3
Проблема в том, что индексация символов не помогает работать с глифами. Perl6 вроде умеет работать с глифами, но не Java и не Python.
khim
27.12.2015 18:13+2Что я не так понимаю в жизни? :-)
Да. Вы не понимаете, что речь идёт не об неиспользовании Юникода, а о том, что ни язык, ни стандартная библиотека не форсируют его использование.
В Go используется (по соглашению) UTF8. Но все утилиты, которые могут осмысленно работать со строкой как с последовательностью байт работают со строкой как с последовательностью байт. Если вы хотите где-то форсировать Юникод (проверить UTF-8 строку на валидность) — вы можете это сделать, соответствующие утилиты вполне имеются. Но это ваш выбор, язык Go его не форсирует.
Вы можете получить кусок, состоящий из смеси текста и бинарных данных (HTTP, SMTP, далее везде) и спокойно его обработать. В Питоне для этого вам нужно совершать весьма странные телодвижения. А такая простая вещь, как посмотреть на формат HTML-файла, найти там тегhttp-equivи если нужно перекодировть — превращается в танцы с бубнами.
areht
27.12.2015 13:57То есть в Go я могу создать файл с не-юникодным названием, и эта возможность выстрелить в ногу (причём, скорее не себе, но всем вокруг) считается за преимущество?
khim
27.12.2015 18:061. Ды, вы можете. И в Питоне вы тоже можете, что характерно, так что в этом у них полный паритет.
2. Преимуществом является не тот факт, что вы можете создать файл с не-юникодным названием, а тот факт, что появление такого файла не приводит к тому, что ваши пользователи не могут войти в систему.
В мире где все и всегда используют только и исключительно Юникод для имён файлов подход Питона, возможно, был бы оправдан. В нашем мире, где файлы с неюникодными названиями могут возникать без вашего ведома — это недостаток, причём существенный.
Причём для этого не нужно какой-то экзотики. Пример, с которым я сталкивался лично: CygWin при создании под Windows файлаApp::Cpan.3perl.gzпородит имя файла в котором будут непарные суррогаты. Go с этим отлично справится, Python — скорее всего сойдёт с ума, потому что мало какие библиотеки работают с файлами так, как предписывает PEP 383.areht
27.12.2015 19:54-6Вы же понимаете, что это проблемы пользователей CygWin? У меня не появляется файлов с неюникодными именами. ЧЯДНТ?
Да и выбирать язык по недостаткам, напоминающими анекдот «а вы попробуйте на шкаф залезьте!» несколько странно.khim
27.12.2015 20:17+1Вы же понимаете, что это проблемы пользователей CygWin?
С какого перепугу? Это проблемы пользователей, у которых не работает ваша программа — чините.
У меня не появляется файлов с неюникодными именами. ЧЯДНТ?
Возможно не используете Python? Или довели борьбу с фатальным недостатком до совершенства. Не знаю. Я с разного рода проблемами, возникающими из-за кривой поддержки юникода в Python'е борюсь регулярно. В Python2 это относительно несложно (игнорируйте все эти юникодный строки — и будет вам большое такое «щастя»), в Python3 — это стало просто катастрофой.
Да и выбирать язык по недостаткам, напоминающими анекдот «а вы попробуйте на шкаф залезьте!» несколько странно.
Почему нет? Чем странней ситуация, в которой обваливается ваша программа тем выше шанс того, что у вас она работать будет, а у заказчика — рухнет. После чего он вас «пошлёт» с вашими идеями что неработоспособность вашей программы — это не ваша проблема. И будет, ЧСХ, прав.areht
27.12.2015 22:20Да, я не использую ни питон, ни цугвин. И мои программы внезапно работают. Явно надо что-то менять. Осталось придумать зачем использовать то, от чего у пользователей файлы не такие создаются (если не просить при этом биткоинов за удаление, конечно).
> И будет, ЧСХ, прав.
Да, надо бы в дистриб деинсталятор цугвина с питоном запилить (а что, цугвину можно мне свиней подклыдывать, а мне — нет? я «чиню свою программу», ага). И антивирус, заодно. Это же моя проблема, что пользователь по порносайтам лазает всякую фигню скачивает?
Хотя нет, проще сразу компы с вшитым своим маркетом продавать.
Вообще, интересно много ли заказчиков готовы платить за цугвин.khim
27.12.2015 22:26Вообще, интересно много ли заказчиков готовы платить за цугвин.
Они не платят «за цугвин». Они платят, вы не поверите, за программы. Решающие (или обещающие решить) их задачи. Которые, внезапно, не работают если на компьютере есть CygWin и он насоздавал «неправильные» файлы.
При этом CygWin может и не ставиться явно, а быть компонентом другой системы. Но свалится-то Ваша программа! А значит Вашей техподдержке придётся это расхлёбывать.
«Чудесная поддержка юникода» вам эти проблемы насоздаёт, «грубый и неправильный Go» — нет. Так кто из них лучше?areht
28.12.2015 06:49-1> При этом CygWin может и не ставиться явно, а быть компонентом другой системы
Если Вы отвечаете именно на то, что процитировали — у вас не получилось.
Я цугвин видел только в каком то наколеночном опенсорсе, который на рабочий комп попасть не мог. А значит у техподдержки есть корректный ответ «переустановить винду». Тем более, если у вас нормальной обработки ошибок и так не задумано.
Что характерно, когда у пользователя крешиться весь софт, кроме написанного на благословенном Go, пользователя такой ответ даже не отпугнет.
> Так кто из них лучше?
Лучше цугвин починить, а не строить костыли вокруг теоретически возможного пользовательского окружения.khim
28.12.2015 12:04+2Я цугвин видел только в каком то наколеночном опенсорсе, который на рабочий комп попасть не мог.
А я его видел как часть интернет-магазина. Или, скажем, Google'ового SDK.
Что характерно, когда у пользователя крешиться весь софт, кроме написанного на благословенном Go, пользователя такой ответ даже не отпугнет.
В том-то и дело что «весь софт» не крешится. FAR это отлчино отрабатывает. Explorer, разумеетя, тоже. Проблемы — только с софтом на Python'е и Java. Вроде бы даже .NET'овские поделия к этому нормально относятся.
grossws
28.12.2015 01:12В 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)khim
28.12.2015 12:05Если какая-нибудь библиотека прислала unicode-строку
Если какая-нибудь библиотека выдёт вам юникодную строку, то нужно либо постараться убедить её этого не делать, либо придётся-таки в этом конкретном места мучиться, да.
Большинство библиотек в python2 никакого юникода не порождают и сложностей, с этим связанных, не создают.grossws
28.12.2015 13:02-1Если правильно помню, развлечение было после ner, где приходится работать уже со строками.
0xd34df00d
27.12.2015 01:45+2Так она помогает, если она мощная.
khim
27.12.2015 03:28Закон Парето никто не отменял. От самых тупых ошибок типа засовывания строки туда, где хотят число или наоборот спасёт любая.
lexfrei
27.12.2015 01:24+24Отличная заметка, спасибо! Если не познавательная, то как минимум новая точка зрения. Но язык (Ваш, не Go) делает мне больно.
namespace
27.12.2015 02:11-11Тот язык, дизайн которого я сейчас потихоньку разрабатываю? Так это даже не альфа — так, наброски.
namespace
27.12.2015 02:29-10Ааааа, ты про мою речь. Так это просто авторская подача, мне так нравится писать, живой текст получается.
KIVan
27.12.2015 01:44Как насчет литературы? Если опытный разраб хочет прочесть 1 книгу (на английском), чтоб полностью освоить Go (за редельку свободного времени), то что вы порекомендуете?
mirrr
29.12.2015 06:06+1Книги никто не отменял конечно, но советую пройти официальный Тур go, ещё очень класный ресурс gobyexample.com. Опытный разраб может выучить Go до приличного уровня за пару дней.
Ivan_83
27.12.2015 03:40+3Автор, ты частично озвучил мои мысли :)
Есть ещё одно правило секты: нужен свой язык, чтобы человеку было сложнее общаться с обычными людьми за пределами и он не мог так просто взять и уйти.
Но этим грешит много кто, вот, например, цыска уже давно практикует свою вселенную терминов.
«Тем не менее, полно народу продолжает писать софт на Go ради собственно говоря, самого Go.» —
С одной стороны это те кто уже в гугле есть/был/хочет туда, с другой сейчас очень много людей «ищет себя» и ищет «серебряную пулю», кто то из интереса кто то хочет найти средство которое сделает за него почти всё, разве что деньги вместо него получать не станет :)
Это не обязательно язык, это ещё и всякие либы, фреймворки и пр.
Моё отношение к этому такое же как к обычным языкам: язык = инструмент, он необходим но не достаточен чтобы решать задачи, если только ты не работаешь переводчиком и твоя задача переводить с одного языка на другой.
Самой яркой иллюстрацией тут можно привести абсолютно любой язык и криптографию: нет смысла соваться в крипту не имея хотя бы представления о ней, налабать можно на любом языке но результат будет плачевным. В качестве примера можно вспомнить сколько лет авторы шифровальщиков не могли осилить правильно применять крипту, хотя чего то там прогать они умели.
Аналогично с сетями и кучей других областей, где роль самого языка второстепенна и он по сути просто как клей который соединяет потоки данных в требуемой последовательности через разные алгоритмы/апи.
Я люблю Си, и пишу в основном на нём.
Иногда приходится писать на чём то другом. Не потому что кто то заставляет, а потому что на Си это будет сильно дольше и потом вряд ли найдутся люди из целевой аудитории чтобы смогли хотя бы заюзать или подправить под себя.
Те это вполне объективные причины.
Сейчас (последние лет 15) появилось много разных новых языков.
Я думаю они не жильцы: ничего особенного они не привнесли, решили какую то одну очень специфичную проблему и на этом всё, распространение у них не значительное потому что проблемы эти не глобальные и кроме них есть ещё сотни других проблем.
С другой стороны языки живут долго (по компьютерным меркам) по естественным причинам: язык жив пока живы его носители — люди.
Ещё один фактор который тесно связан с успешностью того или иного языка это его место рождения и среда обитания.
Языки рождённые в сообществе и обитающие в нём более живучие, потому что в сообществе много людей с разными целями и потребностями, всё это попадает в язык, язык становится разнообразнее и востребованнее, ведь с его помощью решают множество разных задач, при этом различные ограничения очень плохо приживаются.
Языки рождённые в корпорациях или проектах напротив, создаются для решения узкого круга задач узким кругом людей с очень близкими взглядами, целями и идеями, потому впитывать языкам особо нечего.
Си, пхп, перл, джава, питон — там же полно всего наросло (хотя бы и либами/фреймворками), при этом сохранено довольно много свободы.
Руст — многопоточность для ФФ
Го — манки сейв кодинг для гугля
.NET, повершелл, асп — проганье под винду и её АПИ во славу МС
1с — тут как в русте: язык одного продукта
лего маинд шторм — :)
И всегда встаёт один и тот же вопрос: зачем мне ещё один язык? чего ради мне его изучать/использовать?
Безопасная многопоточность имени руста — я и сам могу подумать и сделать заведомо правильную архитектуру, в определённых масштабах.
Го? — я вроде пока дееспособный, зачем он мне? (почему то среди адептов ГО много людей патологически боящихся делать ошибки и считающих что на го невозможно накосячить)
В общем, я предпочитаю думать над тем как лучше решить задачу, и если мой любимый инструмент оказывается не оптимальным то я думаю чем был его заменить.
А народ похоже думает: какой же инструмент за меня всё сделает сам. И разводит балаган.creker
27.12.2015 05:50+6Зачем Go? Меня лично привлекает совокупность его особенностей:
1. Компиляция под любую платформу одной строчкой. GOOS, GOARCH и вперед — винда, макось, айфон, андроид.
2. Натив код + сборщик мусора
3. Один бинарник и ноль зависимостей от компонентов ОС. Это просто прекрасно, когда ты открываешь в IDA импорт секцию и видишь пустой список. Бинарнику нужны только syscall'ы и больше ничего. Есть исключения разве что на винде и iOS. И то, это зависимости от API ОС.
4. Огромная стандартная библиотека + простейшая процедура подключения сторонних библиотек
5. Горутины
Все остальное так или иначе вносит сложности. С/С++ — ад с кроссплатформенностью, компиляцией, сторонними библиотеками, асинхронностью и т.д. .Net/Java — все хорошо, но рантайм за собой тянуть как зависимость и его оверхед по памяти как минимум. Скриптовые языки — тянуть за собой интерпретатор + оверхед по всему подряд.
Go расположился во всем аккурат между С/С++ и C#/Java и этим он привлекает. И тут скорее не язык сам интересен, а инфраструктура вокруг него, которая, впрочем, благодаря особенностям языка и стала возможна.areht
27.12.2015 14:08> .Net/Java — все хорошо, но рантайм за собой тянуть
Microsoft .NET Nativecreker
27.12.2015 14:47Честно, не пробовал. Ну и проблема не в том, что рантайм прям мешает — на винде ради бога. Но вот у меня линукс на арме. Какие у меня там варианты с дотнетом кроме сборки руками моно или .net core?
dordzhiev
27.12.2015 18:48На подходе еще один проект под название LLILC. Это компилятор MSIL -> IR (который LLVM).
github.com/dotnet/llilc
grossws
28.12.2015 00:27+2Компиляция под любую платформу одной строчкой. GOOS, GOARCH и вперед — винда, макось, айфон, андроид.
mips-none-eabi? arm-none-eabi? Не собирается почему-то.
Один бинарник и ноль зависимостей от компонентов ОС.
Ага, разогнались.ldd /usr/bin/docker linux-vdso.so.1 (0x00007fff2698f000) libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007ffa846f9000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007ffa84384000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007ffa84180000) libdevmapper.so.1.02 => /usr/lib/libdevmapper.so.1.02 (0x00007ffa83f24000) libc.so.6 => /usr/lib/libc.so.6 (0x00007ffa83b80000) libcap.so.2 => /usr/lib/libcap.so.2 (0x00007ffa8397c000) librt.so.1 => /usr/lib/librt.so.1 (0x00007ffa83774000) libm.so.6 => /usr/lib/libm.so.6 (0x00007ffa83476000) libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007ffa8325f000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007ffa83039000) liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007ffa82e27000) libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007ffa82b45000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007ffa82931000) /lib64/ld-linux-x86-64.so.2 (0x00007ffa845a1000) libudev.so.1 => /usr/lib/libudev.so.1 (0x00007ffa846d5000) libattr.so.1 => /usr/lib/libattr.so.1 (0x00007ffa8272c000)creker
28.12.2015 00:46+1mips-none-eabi? arm-none-eabi? Не собирается почему-то.
MIPS вроде и не поддерживает, а арм. А какой именно арм то? Под armv7 я собирал — linux версия работает на андроиде и кастомной плате с cortex-A8 процессоре. armv7 версия под darwin при условии external linkining и CGO работает на iOS, но зависит от парочки системных API, которые не делают погоды. Речь естественно о сборке Go проектов, а не самого Go.
Ага, разогнались.
Это не лучший пример. Если посмотреть исходный код, то там вовсю используется CGO, а там можно накрутить кучу зависимостей, что они и сделали. Сам по себе Go на моих проектах выдает бинарники, которые ни от чего не зависят. Сейчас проверил gitlab раннер для их CI под макось gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/osx.md — опять пустая импорт секция. Что не удивительно, ибо это одно из преимуществ GO.grossws
28.12.2015 01:24-1Под armv7 я собирал — linux версия работает на андроиде и кастомной плате с cortex-A8 процессоре.
Кроме arm-linux-gnueabi существуют и другие target'ы, которые не всегда поддерживают linux или darwin. На cortex-a/r arm-мир не заканчивается: есть cortex-m, есть разные arm7/9/11. Так что утверждение «Компиляция под любую платформу одной строчкой» выглядит чересчур самоуверенно.
Не говоря уже о том, что под bare metal (собственно *-none-eabi) на го нужно переписывать ощутимую часть стандартной библиотеки. Это та ниша, где живут c/c++/rust, хотя последний не из коробки и не в полном объёме (только libcore, а не libstd). Про go видел только PoC для запуска на bare metal (без goroutine/channel, ессно).
Это не лучший пример.
Ок, принято, docker довольно сложная система. Когда я пробовал писать простейшие программы использующие goroutine'ы и каналы у меня по умолчанию ldd показывал, как минимум libc и pthread. Для получения статичного бинарника надо прилагать некоторые усилия. Возможно, сейчас поведение по умолчанию изменилось.creker
28.12.2015 04:33Так что утверждение «Компиляция под любую платформу одной строчкой» выглядит чересчур самоуверенно.
Тут скорее то, чтоимеет значениераспространено, а как уже в одной статье говорилось, мир захватили x86-x64 и arm. С первым проблем нет, со вторым покрыты архитектуры armv5-armv8, что дает ощутимый кусок. Вот на этом всем go скорее всего без проблем будет работать при условии, что там ОС стоит совместимая.grossws
28.12.2015 05:18-1mips (в огромном количестве сетевого оборудования), arm cortex-m (который тоже описан в armv6-armv8), arm7tdmi, pic, avr куда более распространены чем всякие x86/amd64. В современном ноутбуке на amd64 обычно не менее 3-4 arm cortex-m.
mirrr
29.12.2015 14:27+1Все усилия сводятся к прибавлению к go build флагов:
-ldflags "-linkmode external -extldflags -static"
Но да, можно было флаг покороче придумать.grossws
29.12.2015 15:59Да, это только даёт статическую линковку.
Это не даёт сборку под большинство embedded target, отсутствие syscall'ов и т. п., что утверждалось квантором «любую», насчёт которого и было моё замечание, которая обсуждается в остальной части ветки, оказавшейся под прицелом вашего плюсомёта.mirrr
29.12.2015 17:46Да я вобщем мимо пробегал, ответил на:
Для получения статичного бинарника надо прилагать некоторые усилия.
В остальное не вдавался, потому как моя работа связана с одной платформой.
insekt
27.12.2015 15:32+3Могли бы пояснить подробнее, что подразумеваете под
> С технической стороны, ниша у Go довольно скромная: сеть
Что значит сеть?
psylosss
27.12.2015 15:48+5За этот вопрос в slack'e гоферов я был поднят на смех. До сих пор не знаю что именно имели в виду проффесора
namespace
27.12.2015 16:17-6Ну, сеть. Любой софт, который отвечает за оркестрирование и коммуникацию компьютеров (серверов) связаных сетью.
VioletGiraffe
27.12.2015 16:16-5Ну наконец-то дельная заметка о Go. Спасибо!
Как С++ програмист, я стал ненавидеть Go чуточку меньше :)stack_trace
02.01.2016 10:28+3Как С++ программист не могу не спросить, а чем именно вызвана ваша ненависть?
VioletGiraffe
02.01.2016 11:41-4Тем, что надо выбрать один кросс-платформенный компилируемый язык, и на нём сконцентрироваться, а не создавать по 2 новых языка в год. На мой взгляд, С++ — лучший язык в своём классе, и под него уже написано огромное количество библиотек, а эти ваши Go только распыляют внимание программистов и тормозят прогресс.
stack_trace
02.01.2016 13:56+41. Go — язык явно другого класса для решения других задач. Хотя, может быть мы говорим о разных классах задач?
2. То, что С++ лучший в своём классе не значит, что нужно останавливать прогресс. Когда-то и ассемблер был лучшим в своём классе. Если бы никто не стал делать новых языков С++ так никогда и не появился бы. Прогресс и конкуренция — всегда хорошо, а много языков лучше чем один.
3. ИМХО, тормозят прогресс как раз те, кто предлагает отбросить всё новое и заниматься только тем, что всем хорошо знакомо. Развиваться лишь в одном направлении и отрицать всё, что не укладывается в привычную схему — это тупик и квинтэссенция ограниченности.
creker
02.01.2016 16:21+2C++ лучший в своем классе скорее вопреки, а не благодаря. И я буду очень рад, если его заменит что-то, что нормально умеет в модули, быструю компиляцию, простую кросс компиляцию без бубнов и мегабайтных мейкфайлов. Это как минимум. Где-то его Go уже вытесняет отчасти именно благодаря упомянутым вещам, но хотелось бы вообще забыть об этом языке в пользу чего-то более умного с умной и быстрой инфраструктурой.
VioletGiraffe
02.01.2016 16:34-2М-м. Компиляция весьма быстрая, с кросс-платформенной компиляцией проблем нет (проект собирается безо всяких бубнов и мегабайтных makefile под Мак и iOS — clang, Линукс и Андроид — GCC, и Винду — MSVC). Модули — да, беда, но должно стать полегче, когда их стандартизуют (сейчас над этим идёт работа).
creker
02.01.2016 17:01+3Весьма быстрая компиляция? Просто нет.
Если бы все было так замечательно, то мы бы жили в прекрасном мире. На деле же даже сборка маленькой библиотеки с makefile и autoconf это пытка. Я недавно собирал под виндой с помощью кросскомпилятора libevent. Я задолбался вручную патчить сгенерированные мне makefile и configuration. В итоге еще и пришлось патчить хедеры openssl, но собралось. А должно собираться в один клик — git clone, build и все, все работает. Можно сказать — винда, проблемы вечные. Я потом пытался собрать crosstools-ng под макосью — я так и не смог это сделать под yosemite. Постоянные ошибки, которые кое как решались. Но в конце появилась одна, которую решить так и не получилось. Никакие решения в интернетах не помогали. Большое спасибо, что хоть кто-то выкладывает готовые сборки хотя бы для макоси. Кто-то еще понимает, что make это не так просто и безболезненно. Даже под теми ОС, под которыми это типа должно без проблем собираться.
Благо все таки есть проекты, которые умеют собираться. OpenSSL у меня оставил вполне хорошие впечатление будь это сборка под windows для linux arm или iOS. Да, я сейчас в основном упомянул С проекты. Но тут разницы мало в этом контексте.
А про модули знаю, но это не решит проблему legacy кода.VioletGiraffe
02.01.2016 17:48Виндовые проекты часто собираются без проблем, проблемы как раз с линуксовыми / кросс-платформенными, в основном. Потому что make, configure и вот эта вся гадость. С библиотеками огромная проблема, я ж не спорю. Но проблема эта не только в языке, но и в криворуких девелоперах.
Все проекты, над которыми я работаю — личные и коммерческие — собираются в один клик как минимум на 3 разных осях (Вин / Линукс / Мак), и никаких особых усилий я для этого не прикладывал, просто нормально писал проект с самого начала.
vintage
02.01.2016 16:47Вы сейчас практически описали язык D. Там есть всё это и даже больше.
stack_trace
03.01.2016 11:20Честно говоря, мне не совсем ясна ниша D. Для системного программирования он слабо пригоден из-за рантайма и GC, для написания модулей к управляемым языкам — по той же причине, а для бэкэндов есть специализированные языки, тот же Go.
vintage
03.01.2016 13:29GC опционален. Да, многие модули его всё же требуют, но вы не обязаны их использовать.
Не понял в чем проблема писать на нём модули для управляемых языков.
D, конечно, не идеал, но всяко лучше примитивного Go.stack_trace
03.01.2016 14:20ИМХО, Go примитивен, потому что его именно таким и сделали. Именно в этом его основное достоинство. Он предназначен для ниши, в которой ничего сложного и не надо. В этом смысле, сложность D — скорее недостаток при сравнении с Go. Не думали, что Go набирает популярность, именно потому, что для некоторых проектов нужен именно простой язык, с простой сборкой, с простым деплоем одним бинарником и с мощной стандартной библиотекой?
vintage
03.01.2016 14:58+2У Go простоя реализация и спецификация, программы же получаются переусложнёнными из-за необходимости велосипедить. D же позволяет сделать интерфейс, который реально прост в использовании. Ну, банально, как отсортировать массив в Go? В D я это делаю так с любым объектом реализующим интерфейс диапазона со случайным доступом:
import std.algorithm.sorting; auto x = [2,1,3]; x.sort!q{ a < b }; // эквивалентно x.sort(); writeln( x );
Если бы D пиарили хотябы в половину меньше, чем го, то все переходили именно на него. И плюсовики в первую очередь, ибо в D сделано хорошо, всё, что в C++ сделано плохо.
В D тоже простая сборка, простой деплой одним бинарником и стандартная библиотека по мощнее будет. Основной недостаток D — маленькое комьюнити, которое не наклепало ещё кучу модулей на все случаи жизни.creker
03.01.2016 15:08Ну, банально, как отсортировать массив в Go?
Открыть документацию golang.org/pkg/sort и скопипастить пару строчек для реализации интерфейса сортировкиvintage
03.01.2016 22:09Вы покажите эквивалентный код :-) Там как минимум 4 строчки надо скопипастить на каждую комбинацию типа_элемента+функции_сортировки. И это не просто реализация интерфейса, это создание отдельного подтипа, в котором зашивается алгоритм сортировки.
creker
04.01.2016 00:00По ссылке пример боевого кода с пользовательским типом, зачем мне абстрактные бессмысленные примеры. Все выглядит вполне нормально и обыденно. Реализуем для нашего типа интерфейс сортировки и вперед. Мериться строчками в данном случае неблагодарное дело, которое не имеет никакого значения к реальным преимущества языков. Код Go элементарен и не настолько сильно больше. Я вспоминаю C#, где не сильно меньше надо делать — для каждого пользовательского типа нужно реализовать интерфейс сравнения, чтобы он сортировался. Обыденный паттерн нынче.
vintage
04.01.2016 11:58+1Go:
package main import ( "fmt" "sort" ) // A couple of type definitions to make the units clear. type earthMass float64 type au float64 // A Planet defines the properties of a solar system object. type Planet struct { name string mass earthMass distance au } // By is the type of a "less" function that defines the ordering of its Planet arguments. type By func(p1, p2 *Planet) bool // Sort is a method on the function type, By, that sorts the argument slice according to the function. func (by By) Sort(planets []Planet) { ps := &planetSorter{ planets: planets, by: by, // The Sort method's receiver is the function (closure) that defines the sort order. } sort.Sort(ps) } // planetSorter joins a By function and a slice of Planets to be sorted. type planetSorter struct { planets []Planet by func(p1, p2 *Planet) bool // Closure used in the Less method. } // Len is part of sort.Interface. func (s *planetSorter) Len() int { return len(s.planets) } // Swap is part of sort.Interface. func (s *planetSorter) Swap(i, j int) { s.planets[i], s.planets[j] = s.planets[j], s.planets[i] } // Less is part of sort.Interface. It is implemented by calling the "by" closure in the sorter. func (s *planetSorter) Less(i, j int) bool { return s.by(&s.planets[i], &s.planets[j]) } var planets = []Planet{ {"Mercury", 0.055, 0.4}, {"Venus", 0.815, 0.7}, {"Earth", 1.0, 1.0}, {"Mars", 0.107, 1.5}, } // ExampleSortKeys demonstrates a technique for sorting a struct type using programmable sort criteria. func main() { // Closures that order the Planet structure. name := func(p1, p2 *Planet) bool { return p1.name < p2.name } mass := func(p1, p2 *Planet) bool { return p1.mass < p2.mass } distance := func(p1, p2 *Planet) bool { return p1.distance < p2.distance } decreasingDistance := func(p1, p2 *Planet) bool { return !distance(p1, p2) } // Sort the planets by the various criteria. By(name).Sort(planets) fmt.Println("By name:", planets) By(mass).Sort(planets) fmt.Println("By mass:", planets) By(distance).Sort(planets) fmt.Println("By distance:", planets) By(decreasingDistance).Sort(planets) fmt.Println("By decreasing distance:", planets) }
D:
import std.stdio; import std.algorithm; // A couple of type definitions to make the units clear. alias real earthMass; alias real au; // A Planet defines the properties of a solar system object. struct Planet { string name; earthMass mass; au distance; } Planet[] planets = [ {"Mercury", 0.055, 0.4}, {"Venus", 0.815, 0.7}, {"Earth", 1.0, 1.0}, {"Mars", 0.107, 1.5}, ]; // ExampleSortKeys demonstrates a technique for sorting a struct type using programmable sort criteria. void main() { // Sort the planets by the various criteria. planets.sort!q{ a.name < b.name }; writeln("By name:", planets); planets.sort!q{ a.mass < b.mass }; writeln("By mass:", planets); planets.sort!q{ a.distance < b.distance }; writeln("By distance:", planets); planets.sort!q{ a.distance > b.distance }; writeln("By decreasing distance:", planets); }
Видимо я что-то не понимаю в этой жизни.creker
04.01.2016 17:17Замечательно конечно, но я не вижу тут большого практического преимущества у Д. Просто потому что в реальной задаче я не буду этим заниматься — этим будет заниматься база данных скорее всего, а с учетом позиционирования Go именно так и будет. А если будет иначе, то не будет 100500 вариантов сортировки. Go отчего и поднялся, потому что он нашел свою нишу, в которую его силами гугл и заталкивает. В этой нише ему это все не особенно нужно — подготовкой массивов данных в сервисах обычно занимаются другие части системы. А D, будучи языком общего назначения, возможно как раз и нужно, чтобы покрывать намного больший круг задач. Но даже в этом случае данный конкретный пример не показывает мне практических преимуществ, чисто теоретическая мерка цифрами.
А если уж прям так хочется сделать короче, не знаю зачем вообще, то первая ссылка в гугле даст достаточно решений stackoverflow.com/questions/28999735/what-is-the-shortest-way-to-simply-sort-an-array-of-structs-by-arbitrary-field В том числе практически идентичное тому, что представили вы.vintage
04.01.2016 22:17+3Почему же это такого простого и лаконичного решения как "практически идентичное" нету в официальной документации?
Ответ прост:
1. Это решение использует interface{}, то есть статическая типизация идёт лесом.
2. В рантайме это решение использует рефлексию, что бьёт по производительности.
stack_trace
03.01.2016 17:06+1D — не вариант для плюсовиков из-за GC, говорю как плюсовик. То что его можно отключить — вообще не аргумент, и вы сами знаете почему. Вариантом для плюсовиков пока что выглядит Rust. Go — компромисс между Java и python, а вот ниши для D не вижу. Он слишком сложный для веба (сложнее джавы), при этом его достоинства по сравнению с ней не очевидны.
creker
03.01.2016 20:05+1Ох не знаю про раст. Каждый раз при виде кода мне становится страшно. Выглядит и читается это все намного сложнее С++ и по описанию его возможностей похоже намутить непонятных в будущем никому конструкций на нем будет еще проще, чем на плюсах
vintage
03.01.2016 22:25Даже не представляю почему. Поддержка GC оскверняет язык? Но я согласен, что поддержка владения на уровне языка — куда более привлекательная для системного программирования штука, чем GC.
А в чём он сложнее явы?
sectronix
27.12.2015 16:35+13Прочитав пост, ожидал что в комментариях divan0 будет рассказывать, что эту статью написал школьник и что подобные статьи сообществу только вредят. А так же что Go няша и Роб Пайк тоже няша. И вообще, какое право имеет какой-то там школьник упоминать Пайка в негативном контексте.
Ожидания не оправдались.
Поэтому, теперь жду статьи-разоблачения с заголовком «И всё же, кто и зачем использует Go», в которой мы прочитаем красочную историю как всё стало круто в тех компаниях, которые используют Go заменив им язык X (тут можно рандомно подставить любое название языка программирования). А те кто выскажут свои сомнения будут автоматически зачислены в олигофрены, которые не могут разглядеть всю красоту, силу и мощь языка Go.sectronix
27.12.2015 16:41+11Посудите: можно нанять 100 посредственных программистов, дать им в руки Go и эта армия обезьян будет генерить вам много «неплохого» и очень даже поддерживаемого кода!
Да забыл сказать, что в этой статье должно быть упоминание о том, что программисты выбирающие Go — это не обезьяны, а высококвалифицированные специалисты мирового уровня, иначе они бы не выбрали Go.sectronix
27.12.2015 16:58+19А что касается Пайка, то он разводила еще тот. Знакомый из гугла жаловался, что Пайк написал какую-то внутреннюю систему запросов, которая просто лохотрон полный и теперь им это все поддерживать надо и никто от этого не в восторге. Короче говоря, среди гуглеров у Пайка репутация далеко не однозначная.
Такие набросы на Пайка просто не могут остаться без ответа. Поругана честь предводителя.divan0
27.12.2015 22:14+5Да ну, этот, забаненный во всех Go-коммьюнити, школьник мечется между любовью и ненавистью к Go уже давно, и никак не может отпустить двач из своего сердца. Общаться там бесполезно, лишь повод для очередной пачки попкорна ) Вышеприведённая байка была рассказана знакомым знакомого одного из ребят в чате, которому лично не понравился Sawzal (именно так назывался тот инструмент). Теперь эта история обрела окрас «просто лохотрон полный», «никто не в восторге», «репутация неоднозначная». К слову, Sawzal свою работу в Google выполнял много лет более чем отлично, но сейчас уступил место Go в Google, где-то был paper на эту тему.
Так что, вы, конечно, сами выбирайте, как фильтровать что вам рассказывают и кто рассказывает. Слушайте больше не что вам говорят, а почему вам это говорят.sectronix
27.12.2015 23:03Я как раз в такие истории не верю. Просто интересно наблюдать ваши баталии в комментариях. Прочитав этот пост уже приготовил попкорн, а баталий что-то и нет :) По прошлому опыту решил что вы уже готовите хороший пост, так что попкорн пока далеко не убираю.
divan0
27.12.2015 23:20Нет, мне такое не интересно )
sectronix
27.12.2015 23:22Ок, прячу попкорн до следующего вброса :)
divan0
27.12.2015 23:23До перевода вот этой статьи, наверное )
sectronix
27.12.2015 23:29+1Я её давно прочитал и вот уже потерял надежду что она появится на Хабре. Всё-таки, почти две недели прошло с момента её публикации. Причём, наткнулся на неё случайно и только после прочтения решил посмотреть кто её написал :)
namespace
28.12.2015 02:12-6забаненный во всех Go-коммьюнити
В неофициальной golang bridge слаке, где погоняют неадекватные феминистки и в вашем русскоязычном слак-бомжатнике? С каких пор это все Go сообщество? Короче, чет у тебя больная фантазия разыгралась, остывай.
Вышеприведённая байка была рассказана знакомым знакомого одного из ребят в чате, которому лично не понравился Sawzal
Эта история (про то, что Пайка мало кто в гугле любит) была рассказана мне топовым инженером гугла за кружкой пива, лол. Короче, кончай выдумывать факты. Иии я кстати не уверен, что это именно Sawzal был.
x88
27.12.2015 17:20+7Делал несколько высоконагруженных бэкендов на Go (баннерокрутилки, RESTful апи и т. д.). Не могу даже представить альтернативных языков для столь быстрой и качественной разработки надежных, шустрых приложений.
vintage
27.12.2015 17:25+21А с какими ещё языками вы знакомы?
x88
28.12.2015 11:16+2Знаком со многими, основной стек разработки:
С/С++, Go, Java, C# ну и всякие там PHP+JS+etc
webkumo
31.12.2015 10:02+2И вы хотите сказать, что реально глубоко знаете кучу этих языков? (особенно мне нравится запись c/c++)
stack_trace
02.01.2016 14:10Мне, как С++ программисту, вообще не нравится запись C/C++. C — вообще язык простой, почти элементарный, тогда как плюсы — намного запутанней. Ставить их в один ряд, когда говоришь о знании этих языков — как минимум странно.
SOLON7
27.12.2015 17:39По сути так и есть, для разработки рест и работы с бд много не надо! чисто инструмент который было бы удобно использовать и не заморачиваться с кодом и деплоем! нет и джава тоже корпоративные штуки! еще один язык от большой корпорации не есть зло! просто еще один взгляд на бакенд! Самое главное чтобы порог вхождения для новичков был небольшим! А там кому понравится те и подтянуться @
faost
27.12.2015 18:22В моем случае Go отлично подошел для написания бэкенда с несложной логикой. В качестве веб-фреймворка используется gin, для сохранения/получения промежуточных данных key-value хранилище bolt. Если взять для примера запрос, для обработки данных которого использутеся простая логика из цикла с парой вложенных условий с сохранением состояния через mutex, на отдачу ответа уходит ~40-50µs.
sectronix
27.12.2015 18:31-1Возможно для вашей задачи вообще не нужен был бекенд на Go. Посмотрите на связку Nginx + Tarantool.
faost
27.12.2015 19:28+2Спасибо за наводку!
1) В этом запросе логика простая, но в сервисе уже появились несколько сложных запросов, которые активно используют стандартную библиотеку, а она в Go весьма богатая.
2) У нас 32 ядра в процессоре и когда прилетит одновременно 32 запроса их выполнение распределится по всем ядрам и суммарно выполнятся за те же ~40-50µs если конечно по логике приложения не нужен будет лок на запись или сборщик не начнет работу.
3) Скорость работы очень радует, тесты просто роута, возвращающего json были близки к ретурну nginx-а:
location /test_json { return 200 '{"message": "Hello, world!"}'; }
dennis777
27.12.2015 19:25-1Ребята, раз уж я здесь, подскажите, насколько юзабелен может оказаться Go для написания веб сервиса по изучению английского языка?) Нужны всевозможные драг энд дроп перетаскивания, тесты, вставки слов и прочие грам упражнения, обернутые в красивую оболочку.
Никогда в жизни не прогал под веб, уровень относительно низок (все на голом энтузиазме), но есть хорошая идея, реализация на PC и желание портировать это все в веб. Ищу самую быструю в изучении связку фронтэнда плюс бекэнда, чтоб прямо на ходу учится. Буду крайне благодарен любым советам.
Может кто-то может подсказать какие-то хорошие книги/туториалы по написанию веб приложений step by step?dennis777
27.12.2015 19:34P.S. Я тут немножко посмотрел в сторону Angular JS + Ruby on rails — это нормальная комбинация? Angular с первого взгляда, достаточно простой, по поводу всего остального не знаю)
sectronix
27.12.2015 19:53+5Рискую оказаться непонятым. Возможно, вам подошла бы эта книга, если бы существовала. Просто все остальные советы взорвут вам мозг, сколько всего придётся изучить, если вы говорите, что «Никогда в жизни не прогал под веб».
Кому-то всё-таки стоит задуматься о выпуске такой книги, вот и аудитория уже подбирается :)dennis777
27.12.2015 20:46но если серьезно, я good learner, и прога мне очень нравится, поэтому могу выделять по 3-4 часа в день 7 дней в неделю без напряга. Поэтому и было бы здорово узнать, в какую сторону лучше всего копять.
f0rk
27.12.2015 23:23-1Копать в сторону получения образования с последующим трудоустройством, потом в сторону набора опыта в роли джуна, а дальше… как повезет…
dennis777
28.12.2015 06:29Вы меня не совсем поняли. Мне нужно программирование, ради работы на какую-то компанию, чтобы повезло. Я выучил Делфи с нуля для того, чтобы осуществить свою идею, и смог выйти на уровень порядка 1000 долларов пассивного дохода благодаря худо-бедной реализации. Теперь я хочу попробовать выйти на новый уровень, также самостоятельно, потому что мне это интересно.
Я понимаю, что здесь сидят профи, и каждый считает должным минусануть карму или комментарий за нубо-вопрос, но я не претендую на звание профи. Я понимаю, что программирование не для лошпедов, и с нуля никто ничего толкового не напишет. НО. Мне это интересно, и я люблю бросать вызовы в первую очередь себе. Поэтому я искренне надеялся получить небольшой толчок в сторону того, на что изначально обратить внимание и в какую степь копать. Ни стеб, снобизм, а просто обычный человеческий совет.dennis777
28.12.2015 09:59*Мне не нужно программирование, ради работы на какую-то компанию, чтобы повезло
eugzol
28.12.2015 11:33По твоему описанию, Go будет лишним. Изучи фронтент технологии (HTML+CSS+JS), посмотри, что из JS-фреймворков пригодится и будет проще изучить (Angular, Ember, React, etc.). Для бэкенда посоветую Ruby on Rails, он лёгок в освоении и всё нужное сразу найдёшь в том или ином пакете, а мега-быстрая скорость и 10к коннектов на сервер для сервиса изучения английского вряд ли будет определяющим для выбора языка качеством :)
VolCh
28.12.2015 09:48Красивую оболочку в вебе вы будете писать на HTML/CSS/JS (или обертках над ними). Если задачи сервера сводятся к передаче заданий из базы данных, проверке соответствия ответа правильному и ведению статистики, то почти без разницы на каком из популярных языков писать сервер.
dennis777
28.12.2015 10:00Спасибо, уже затарился попкорном, и смотрю курсы на Линде по Javascript, code efficiency и web services.
PavelMSTU
27.12.2015 22:31+26Сейчас будут минусовать, но я все равно выскажусь.
namespace, поймите меня правильно, заходя на хабр я не хочу увидеть текст, имеющий художественную ценность уровня Толстого, Стейнбека или хотя бы Драйзера…
Но можно все-таки если и употреблять слова «срач», «высер», «воротить жопу» то как-то со смыслом что-ли…
А не начинать и завершать ими статью для эффекта Черчилля…namespace
27.12.2015 23:25-18Да ты просто зануда!
poxu
28.12.2015 11:05+10Уважаемый автор.
Хрен с ними со срачами и высерами
Но цитату из Роба Пайка
They’re not capable of understanding a brilliant language but we want to use them to build good software.
Вы перевели как:
Они не в состоянии понимать пробздетый язык, но мы все равно хотим, чтобы они делали хороший софт.
С каких пор, brilliant переводится как пробздетый? Что вообще означает это странное слово?
После такого перевода вопрос, что автор имел в виду звучит особенно издевательски.namespace
28.12.2015 11:10-17Как хочу — так и перевожу. «Пробздетый» означает «крутой», «продвинутый», можно было догадаться. Хотя если ты унылый старпер (что вероятно, иначе вопросов бы не возникало), то это не моя забота.
Miklos
28.12.2015 11:31+5По-моему, ты ресурсом ошибся.
namespace
28.12.2015 11:59-13Я тут в четыре раза дольше тебя сижу, будешь мне еще рассказывать. Обтекай.
psylosss
28.12.2015 12:55+5Апелляция к возрасту детектед.
namespace
28.12.2015 14:19-8Апелляция к возрасту это когда Данилюк меня в каждом втором своем посте называет школьником. Я же просто показал пацану, где его место.
psylosss
28.12.2015 14:24+3Вот правильно люди говорят — тщательно выбирай себе врага, рано или поздно ты станешь на него похожим. Я сейчас вижу что namespace и divan0 действуют по идентичной схеме, пользуются одинаковыми техниками убеждения и манипуляции, отличие только в стиле подачи (первый — пьяная гопота, второй — унылый «мама сказала в бидоне»).
poxu
28.12.2015 12:05+6Ну дело не в том, что я унылый старпёр. Дело в том, что Роб Пайк — унылый старпёр, и переводить его надо, как унылого старпёра, а не как молодёжного хипстера. Потому, что так уж он говорит. Или писать, как хотите, но тогда убрать цитирование и добавить пометку, что так уж вы слышите мир :)
namespace
28.12.2015 14:41-7Это мой перевод и мой пост. Я как хочу, так и оформляю его. Огромное спасибо за твой совет, но я оставлю все как есть — мне так больше по душе.
poxu
28.12.2015 16:39+7Ты ведь не только оформляешь свой пост как хочешь, ты ещё приписываешь Робу Пайку слова, которых он не говорил. Одумайся!
PavelMSTU
28.12.2015 17:59+2Нуичточтоонприписываетпайкусловакоторыеоннеговорил.
Явоттожепишукомментарийинехочуставитьпробелы.
Потомучтоэтомойкоментарийкакхочутакиоформляюего.
Авыстарыйстарпер.
Иястарыйстарперхотямнедвадцатьпятьлет.
Новидимоужестардлянемспейса.namespace
28.12.2015 19:24-7Ну тогда ты не старпер, а просто лошара.
PavelMSTU
28.12.2015 21:48+1Это был сарказм ;)@namespace комментарий:
Как хочу — так и перевожу. «Пробздетый» означает «крутой», «продвинутый», можно было догадаться. Хотя если ты унылый старпер (что вероятно, иначе вопросов бы не возникало), то это не моя забота.
EvilShadow
29.12.2015 15:35-1Вчитайтесь в пост внимательнее: ничего не напоминает? Да, это он, неповторимый и незабываемый стиль журнала «Хакер» начала нулевых. Так уже лет десять никто не пишет. Так что тема старпёрства раскрыта не полностью.
kolok2
03.01.2016 00:47Коллеги, а чем вызвано столь бурное обсуждение языка go. Неужто действительно хорош?
creker
03.01.2016 01:14Не настолько, насколько вокруг него бурлит. Но настолько, чтобы ознакомиться и оценить его пользу для своих задач
stack_trace
03.01.2016 11:24ИМХО, потому что прикладных языков не так уж и много и появление практически любого нового вызывает бурные обсуждения в соответствующих сообществах.
deniskreshikhin
Роб Пайк одержим идеей создания простого и легкого concurent language и Go это не первая попытка, были еще Limbo, Squeak, Newsqueak.
Т.к. все эти языки по дизайну мало чем отличаются, то трудно представить что создавая Go он создавал язык для корпораций. Скорее всего он просто развел Google на выдление денег под свои личные идеи.
По мне Go это хороший язык для маленьких, упорных команд которые ставят амбициозные задачи перед собой. Как корпоративный язык он плох, т.к. качество кода на Go зависит исключительно от самомотивации разработчиков. В Go ничто не мешает скатиться до низкоуровневого императивного кода и писать в стиле C.
namespace
Я как бы немного да в курсе, да. «Простой и легкий concurrent язык» это по сути своей и есть сишка без арифметики над указателями и каналами и зелеными потоками, не более.
Ну во-первых, никто не куда не скатывается: в Go принято писать низкоуровневую императивную лапшу в стиле С, это идиоматика языка и она очень классно работает. Во-вторых, gofmt && gometalinter просто не позволяют писать отвратительный код, он так или иначе будет «неплох», ничего не поделаешь. Я не понимаю, зачем маленьким и амбициозным командам нужен такой убогий язык, как Go. Куда круче для «маленьких» работает выразительный питон, например, для которого кучу всего уже написано.
namespace
s/не куда/никуда
А что касается Пайка, то он разводила еще тот. Знакомый из гугла жаловался, что Пайк написал какую-то внутреннюю систему запросов, которая просто лохотрон полный и теперь им это все поддерживать надо и никто от этого не в восторге. Короче говоря, среди гуглеров у Пайка репутация далеко не однозначная.
deniskreshikhin
Если у вас ограниченный бюджет, то с Go можно охватить аудиторию в несколько раз большую чем с Python/Ruby/Node.js чисто из-за быстродействия. Для маленьких команд и стартапов это значимый фактор. При это сам Go не слишком сложнее Python. Т.е. не надо тратить деньги на высококвалифицированных спецов.
PS.
Что касается самого Пайка, то все правильно делает. Google это зло, а Go, Plan 9 и гоферы это добро -))
taliban
ну, если мало денег, то можно и на пхп писать, а со временем переписывать, это быстро и дешево, на старте быстродействие редко важно так как быстрота разработки
deniskreshikhin
Допустим вы делаете стартап у которого аудитория 1 млн. пользователей, которые ежесекундно отправляют какое-то сообщение вам с данными, вы обрабатываете эти данные с помощью какого-то алгоритма, например spectral-norm
benchmarksgame.alioth.debian.org/u64q/performance.php?test=spectralnorm
Решение на golang получается быстрее примерно в 12 раз. А значит, если представить что хостинг вычислительных мощностей для PHP будет составлять 5.000$ в месяц, то на golang то же решение будет стоить 340$.
Если учесть, что даже в США pre-seed финансирование обычно около 20.000$, то это фундаментальная разница.
taliban
У стартапа априори нет аудитории, стартап стартует без аудитории, и затем аудиторию набирают. Да и 1 млн пользователей не так уж и много для пхп, он выдержит и больше, хостинг будет дешевле, разработчиков больше, которые уже знают язык хорошо, и не будут лезть в мануал чтоб узнать как же это увеличить словарь, ато размер подошел к концу, или как залить файл на сервер.
Если нужно что-то сделать быстро, то лучше подойдет язык который уже известен, с граблями которые уже известны. А если нужно что-то сделать надежно, то это не стартап, и не го, увы. Для каждого свое время и место.
mirrr
И тут, внезапно, go — быстр в изучении, быстр в разработке, быстр в работе, требует меньше дорогих серверов для обслуживания того же объема трафика.
vintage
Очень быстр в работе:
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%
Очень быстр в разработке: постоянное написание велосипедов, вместо реиспользования кода (привет, дженерикам) очень этому способствует.
mirrr
Данные как минимум устарели, не вижу fasthttp в списке. А он в 10(десять) раз быстрее стандартного net/http в go по результатам бенчмарков.
О дженериках я с вами спорить не буду, не понимаю, как люди вообще могут что-то без них писать, сплошные велосипеды.
vintage
Не поленитесь и добавьте реализацию на fasthttp :-)
Реквесты они вполне себе принимают, правда обновляют результаты лишь раз в пол года.
Я вот пол года назад добавил туда vibe.d: vibe.d (D) 27,974 7.0%
Тот ещё тормоз. Хотя, он запускается там в дебаг режиме, ибо в релизном банально падает.
taliban
Давайте напишем одно и то же приложение, вы на го а я на пхп, и мы сравним у кого это выйдет быстрей? Не нравится пхп? Возьмите питон, руби или ноду, тоже языки отличные для старта, где можно найти хорошего программиста, который быстро все сделает что нужно. А ресурсы в наше время не дорогие, этот аргумент давно уже ушел на второй план. Человеко-часы на много дороже, а опытного гофера еще попробуй найди.
mirrr
Хахаха, хорошая шутка. Ну, кто подкинет ТЗ? Но условимся, что это не будет сайт-визитка, а какой-нибудь полноценный веб-сервис с парой тысяч условных посетителей в секунду.
Я на php потратил лет 7, и здорово представляю, что там да как. На ноде тоже написал несколько полноценных SaaS, и в целом несколько последних лет это была нода и изредка c/c++ для нативных модулей.
Go же я использую пару месяцев. Но потягаться, думаю, смог бы, будь в Вашем предложении хоть капля здравого смысла.
taliban
Ок, в то время пока гофер будет делать свой «суперпупербыстрыйсайт», пхп-шник/подставьте свой язык популярный, уже будет на этом сайте первых клиентов получать и деньги иметь. Никто не спорит что го выдержит больше нагрузку, а нужна она на старте? У вас есть уже эти пата тысяч посетителей? Я смотрю здесь много стартаперов собралось, все прекрасно понимают как все работает, создают сайт и сразу бабло течет рекой. Дело в скорости разработки, пхп прекрасно выдерживает нагрузки в сотни конектов в секунду, этого для старта более чем с головой достаточно, но скорость разработки у пхп в разы быстрей чем на го, особенно у человека который 7 лет потратил на пхп. То что вы напишете на го за неделю, на пхп потратите от силы пару дней, и на пхп оно будет стабильней и продуманней с точки зрения архитектуры на будущее.
mirrr
Вот как «популярность» языка влияет на скорость разработки?
Сайт-визитку с формой заказа я сделаю на go за 15 минут, ровно как и на php. Конечно в Go у меня совсем мало опыта, гораздо меньше чем в php, но он гораздо проще, потому скорость разработки будет примерно равна.
Так-же и с бoльшими проектами.
А еще его простота дает возможность любому опытному php/js/python/… программисту за пару-тройку вечеров освоить go до уровня самостоятельного написания проектов.
taliban
Нет, ты очень преувеличиваешь свои силы насчет сайта визитки на го за 15 минут. А вот на пхп, с опытом в 7 лет, это действительно ближе к реальности. Вот как влияет скорость от популярности языка. Одна фраза «как сделать ХХХ на языке УУУ» приведет с большей вероятностью к решению проблемы на популярном языке. Вы не будете гуглить решения простейших проблем на пхп, вы это все уже знаете, это вьелось в подкорку с опытом работы, с го у вас такого нет, разница в скорости у вас будет на порядок (именно в прямом смысле, десяток и более), а то что вы спорите, лишь добавляет мне уверенности что с го вы не работали нормально, поэтому разница в скорости разработки еще увеличивается. Нет на го хороших разработчиков, а если и есть, то их на сколько мало, что ими можно пренебречь (как в математике). Отсюда и скорость разработки.
mirrr
У меня ушло 20, с версткой. Go ~40 строк с простейшей валидацией формы и сохранением в бд. Надеюсь вопрос закрыт? github.com/mirrr/kkk
ps. минус за «тыканье»
taliban
Это не сайт визитка, это кусок говна, уж извините за выражение, мы про стартапы говорили или про одну функцию для сохранения строки в базе? Вы действительно так туго соображаете или издеваетесь? Я вам про полноценный сайт говорю, а не про страничку на пару строк. Давайте еще сравним как быстро вы напишете хелло ворлд? Это просто гениально было! Аплодирую!
mirrr
Уж извините, если сайт-визитка на go умещается в пару строк. Но думаю это не повод переходить на оскорбления.
RPG18
Если убрать каналы, то получится Erlang.
0xd34df00d
В голове сама собой загорелась надпись «Haskell».
deniskreshikhin
Если что у меня там написано «упорных», а не «упоротых» -)))
lexfrei
Восхитительно! До этого читал именно как «упоротых» и всё отлично складывалось, спасибо за комментарий!
0xd34df00d
А теперь в голове представились упорные амбициозные задачи по написанию тонн микросервисов, только и делающих, что взаимодействующих между собой.
mirrr
И что мешает писать монолит, состоящий из маленьких, законченых модулей?