Comments 39
Ну, раз вы предлагаете:
С бенчмарков вообще принято сравнивать.
Принято не значит правильно. Бенчмарки это сферические кони в вакууме, которыми приятно мерятся, но которые очень плохо соотносятся с реальностью. Сколько пишу код, очень часто код упиратся в базу и в том же https://www.techempower.com если глянуть на single/multiply то пора переходить на java/rust. Но даже в этом случае это синтетика, если у вас в коде запрос к БД выполняется 200мс, то влияние от кода и платформы становится довольно незначительным.
Но мы можем попробовать использовать multiprocessing в Python.
А почему не multiprocessing.shared_memory? Даже в доке по python написано, что Manager медленее
Беда в том, что не все функции не блокирующие.
Поправьте меня, если я не прав, но если в том же go взять не pure-go либу то она тоже будет блокирующей, и заблокирует один из воркеров, разве нет?
Больше того, Select в Go еще крут тем, что мы хотим читать сразу из 5 разных потоков.
"Когда у вас в руках молоток, все кажется гвоздями". Но всегда можно взять aiochan.
И в этот момент выясняется, что то, что вы сделаете, может получиться в разы быстрее, чем в библиотеке Python, причём вы не сильно напрягались.
Учитывая, что все эти либы написаны на C или C++, а python выступает просто удобным интерфейсом, потому что его синтаксис несколько проще для всяких казуалов? Не уверен, что будет существенный профит в производительности.
Берём библиотеки Python и выясняем, что мажорная версия ломает обратную совместимость, причем ломает так, что это чинить неоправданно дорого.
Потому что ввели два новых ключевых слова. Изменение имен переменных так неоправданного дорого, что кошмар.
Golang все зависимости складывает в общий кэш для пользователя и там их версианирует, подписывает с ключиками. Можно не бояться того, что мейнтейнер возьмет и перепишет что-нибудь, потому что это будет видно по контрольным суммам.
Думаю, в 2100 Go дойдет до общего регистра пакетов с корпоративным зеркалами, где помимо контрольных сумм еще будет запрещена возможность залить версию пакета повторно.
Кодировки. Это забавная штука, в Go сразу UTF-8, а в Python с 3.7 тоже сразу UTF-8, но на практике не все утилиты/библиотеки об этом догадываются.
Эм… с 3.0 же, или вы о чем?
От блока про туллинг меня, конечно, довольно серьезно бобмит :) Как будто, если программистам не совать в лицо тем, что в языке есть профилирование, они его не будут использовать. Может не в программистах дело?
Ну и вообще, python в основном предлагает вам выбор, хотите, можно построить себе обработку ошибок через монаду Result и общение между корутинами через aiochan и оно все будет довольно просто работать.
Модель же go предлагает вам рабочую лошадку, из которой как только вы начинаете вырастать, язык приходится выкидывать и искать более гибкий язык. А там где "интересные задачи и highload" я так понимаю, из go вырастаю довольно часто :(
Думаю, в 2100 Go дойдет до общего регистра пакетов с корпоративным зеркалами
Уже есть https://proxy.golang.org/, а для зеркал https://github.com/gomods/athens. Добро пожаловать в 2100!
Но ведь передеплоить пакет в прокси все еще можно вроде, разве нет? То есть это, скорее всего, вызовет просто бугурт, так как чексуммы есть, но осадочек останется.
Не получится, там всё очень жестко.
Т.е. если вы задеплоили пакет v1.0.1 (по сути сделав git tag v1.0.1), то изменить или удалить его невозможно. Да и деплой происходит не явно, никто в прокси ничего не пушит, просто тегают новую версию в системе контроля версий и всё автоматически подтягивается при первой загрузке.
Есть sum.golang.org, можно почитать описание, если кратко, это проверяемый прозрачный лог хешей для модулей.
Ну, я же могу в github удалить тег и тегнуть другой коммит? Или прокси навсегда кеширует у себя значение? В таком случае, там хотя бы можно сделать yanked релиз (удалить пакет из прокси)?
Или прокси навсегда кеширует у себя значение?
Прокси сохраняет значение в sum.golang.org, который по сути дерево Меркла, и сейчас там изменить хеш версии невозможно. Зато можно криптографически проверить все изменения версий :) Кстати, это всё работает по умолчанию в гошном тулинге начиная с версии 1.13, дополнительно устанавливать ничего не нужно.
удалить пакет из прокси
В общем случае невозможно, только если вручную мейнтейнером прокси в очень исключительных случаях.
UPD: забыл сказать, сам пакет прокси тоже хранит вечно, т.е. если даже удалить репо из гитхаба, пакет останется.
Речь о хранении большого развесистого объекта. Поэтому Manager.
>если в том же go взять не pure-go либу то она тоже будет блокирующей
Нет. Вернее, она блокирует тред, но не блокирует работу ≤GOMAXPROCS активных горутин. Отдельно, в Go не-pure либы куда реже встречаются, и общий тренд на переписывание C-либ на pure Go.
>Но всегда можно взять aiochan.
В программировании можно всё. Но не всё удобно. Как я понимаю, с aiochan надо колдовать вокруг merge, чтобы различать разные источники сообщений.
>вы о чем?
Часть библиотек и тулов не готовы к UTF-8 исходному коду.
>как только вы начинаете вырастать, язык приходится выкидывать и искать более гибкий язык
>«интересные задачи и highload»… из go вырастаю довольно часто
Это очень странное утверждение. Практика отказа от Go есть, но все мне известные кейсы либо про недостаточную производительность, либо про неумение архитектуры («текут горутины»), либо про смену менеджмента. К гибкости языка это отношения не имеет.
В программировании можно всё. Но не всё удобно. Как я понимаю, с aiochan надо колдовать вокруг merge, чтобы различать разные источники сообщений.
Нет, там есть select.
Часть библиотек и тулов не готовы к UTF-8 исходному коду.
Часть старых тулзов, которые еще работают на исключительно python2? Или вы про какие-то другие тулзы?
К гибкости языка это отношения не имеет.
Поправьте меня, если я не прав, но мне кажется, что на go довольно неудобно будет строить архитектуру отличную от горутины + CSP? Я это имел ввиду под гибкостью.
Речь о хранении большого развесистого объекта. Поэтому Manager.
Хм… я же правильно понимаю, что это ваш бенч? Если да, то можно исходники?
Ну и вообще, python в основном предлагает вам выбор, хотите, можно построить себе обработку ошибок через монаду Result и общение между корутинами через aiochan и оно все будет довольно просто работать.
Это если все самому писать. А берешь, к примеру, socket из стандартной библиотеки — connect() кидает исключение, recv()/send() кидают исключения. И тебе надо все это не забыть отловить. Отдельная боль, когда автор либы изменил тип исключения, а ты сразу этого не заметил. А тут if err != nil и спишь спокойно.
Ловите тапочки: автор доклада по фене ботает, вдобавок "расшифровщик" такого нарасшифровал, что сидишь и расшифровываешь что там автор доклада зашифровал и что там расшифровщик перезашифровал.
В итоге очень тяжело читать.
Начал читать с интересом (как питонист, приглядывающийся к Go), но примерно к трети очень устал и плюнул — глаза слезятся от такого текста.
Очень тяжело.
Не зашло.
Вы можете поправить пост. Он находится на Github. https://github.com/patsevanton/russian-conferences-articles/blob/master/Go-vs-Python-Виталий-Левченко.md
Предлагаю вместе расшифровывать интересные доклады.
Мне лично нравится и python и go, последний даже больше как то :)
Python, Node.js, Clojure языки для быстрой разработки(быстрой не значит некачественной).
Равносильное по количеству бизнес логики приложение на Go или Java, писать долго и дорого. Соответственно если есть задачи требующие высокой производительности Go будет адекватным инструментом, но писать весь прикладной код на Go это мягко говоря странно, если вы не уровня Google где любой сервис это миллионы пользователей, трудозатраты перекроют любые плюсы по уменьшению потребления ресурсов железа.
В целом на мой взгляд Go подойдет для ПО промежуточного — между прикладным и системным, где не так много бизнес логики, но уже важна скорость работы, скорость запуска и т.д.
Равносильное по количеству бизнес логики приложение на Go или Java, писать долго и дорого.
По моему скромному опыту, начиная с не самого большого проекта (над которым работает одновременно 10-20 человек уже достаточно) поддержка кода на динамических становится чуть ли не сложнее, чем на языках вроде Go (у меня больше всего опыта с PHP и Go, но судя по тому, что происходит с Ruby/Python/etc, там ситуация не лучше).
Связано это в первую очередь с тем, что зачастую очень сложно/невозможно отследить все использования каких-либо функций или методов, или же это требует скрупулезной работы по проставлению phpdoc-аннотаций, которое по сути делает из PHP типизированный язык, только с не самым удобным синтаксисом и без строгой проверки типов.
Я уже не говорю про производительность: на Go многие алгоритмы не требуется оптимизировать, чтобы получить приемлемую производительность (например, для одной задачи мне нужно было парсить отдаваемый HTML, изменять какие-то атрибуты и собирать всё обратно, и в Go это можно было не особо заботясь о производительности и поэтому не требовалось кешировать содержимое, что сильно упрощало архитектуру).
Единственное, что меня до сих пор смущает в Go это то, что относительно высокая производительность также позволяет навертеть очень сложную архитектуру (там, где это не требуется), которая тоже будет работать с приемлемой скоростью, и при этом поддерживать её сильно сложнее, чем альтернативное решение на том же PHP, потому что на PHP такая архитектура никогда бы не «взлетела» из-за того, что PHP относительно медленный. К сожалению, это тоже встречается в реальности достаточно часто, в основном когда люди приходят с других языков (гхм, Java например, ...)
Сможешь выделить кейс об этом? У меня все кейсы переусложённой архитектуры диктовались требованиями к производительности и стабильности во взаимодействии с внешним миром, т.е. совсем не про язык.
на Go многие алгоритмы не требуется оптимизировать, чтобы получить приемлемую производительность
В общем случае это утверждение должно быть ложным, всё-таки временная сложность не зависит от языка. Полагаю, в вашем случае та самая константа сыграла решающую роль.
поддержка кода на динамических становится чуть ли не сложнее, чем на языках вроде GoТолько в Go простейшая типизация, а в некоторых динамических даже дженерики возможны.
и без строгой проверки типовс помощью отдельных инструментов, но тем не менее, это уже стандартный подход в Python/PHP и в своём роде (Type)Javascript и давно (по моему опыту на бэкенде по крайней мере).
Впрочем, я не про дженерики, а про то, что сравнивать по этому параметру мало смысла. Большие кодовые базы нуждались в контрактах и они их получили.
По моему опыту, для веб сервисов особой разницы нет. Если не нужно подтягивать монстров типа JMS, код пишется сравнимое время, отлаживается нередко быстрее альтернатив. Другой вопрос, что обычно при замене условной Java на Go в компании есть огромная экспертиза в Java, и очень слабая в Go — что вызывает проблемы с качеством архитектуры и скоростью разработки.
Сравнение в духе «кто круче, слон или кит».
Лучше бы Go с Crystal сравнили. Это было бы куда как интереснее.
Когда начинал переходить на Go, тоже был в восторге, какой простой, понятный язык и для всего есть готовые библиотеки. Но потом оказывается, что за простоту приходится платить и в нем нет многих вещей к которым привык в других языках. Библиотеки на все случаи жизни оказываются не доделаны и многое ещё не реализовано. В итоге пришось написать dll на другом языке, чтобы обойти узкие места в Go. В общем разочарован, возможно нужно глубже копать, но хочется писать код, а не искать как же всё-таки заставить его работать
Кубики vs Пластилин — надо сравнить!
Причём в результаты поиска на втором скрине попали и вакансии, не имеющие отношения к Go, у которых просто сочетание букв «go» встречается в названии или ещё где-нибудь. Так что разница ещё больше. Грубо говоря, зарплаты немного больше, но получать их намного сложнее.
Кроме того, Go вакансии в общем случае интереснее ввиду больших нагрузок и обрабатываемых данных, где производительность и удобной параллельной обработки становятся актуальными.
Ну на самом деле, если посмотреть вакансии Go то там все таки больше про веб-сервисы а не машинное обучение (то что приводит автор про машинное обучение и Go это все таки скорее из разряда забивание шурупов молотком, аналога того же юпитера в связки с тем же аналогом пандаса я не видел). Так вот, если убрать из вакансий по Python -> Data Science то число вакансий думаю будет сопоставимо.
Был в аналогичной ситуации. Первый месяц go вызывает недоумение и ненависть. Но где-то через полгода становится понятно что в этом есть смысл. А через год уже видится в этом гениальность. При этом go и python как бы перпендикулярны друг другу, для одних задач удобнее писать python для других на go. И хорошо если знаете оба.
Go vs Python. Виталий Левченко