Я полагался на вот эту статью https://wiki.python.org/moin/GlobalInterpreterLock, «The GIL can cause I/O-bound threads to be scheduled ahead of CPU-bound threads, and it prevents signals from being delivered» и не очень хорошо перевел/записал, думаю.
http://www.dabeaz.com/python/GIL.pdf для себя я понял, что речь о 18, 23, 25, 26 слайде вот тут. Мне показалось, что говорится конкретно о 25, а остальные больше контекста дают.
Т.е. в целом, ощущение, что это опасность связана с юникс сигналами и кейсом смешения I/O-bound, CPU-bound и все это на тредах/считай с GIL.
По-моему, дело обстояло так. Гвидо долго говорил, что хотите быстрый python — возьмите pypy, в котором jit и который действительно дает значительное ускорение.
Зашел прочесть, что такого крутого Райф сделал в бэкенде на Python... и не увидел. Плохо смотрел, ткните пожалуйста? Кликбейтный заголовок, по моему скромному ИМХО, нужно делом подтверждать, рассказывая, что на Python написано в бэке.
Ну не такой он уж кликбейтный, ведь Python — серьезный язык! Ну, разве чуть-чуть, простите уж за такую шалость :)
Так уж вышло, вот эту статью мне удалось доредактировать чуть раньше. Сейчас я пишу о сообществе и начал писать о нем раньше этой статьи. И та статья должна была выйти раньше, став первой. А вышла эта, поэтому она немного вырвалась вперед, создав вот это громкое (я хотел бы верить) впечатление.
Про подтверждать делом — всецело разделяю, мы будем стараться, не всегда просто рассказывать про внутренние продукты.
https://conf.python.ru/moscow/2021/abstracts/7746 (тут рассказываем о нашем сервисе вебсокетов, это чисто бекенд, python, zeromq, k8s — я надеюсь, что у нас там довольно интересный доклад получился, т.к. сам сервис я считаю очень любопытным и довольно технологичным; видео пока не вышло, но есть презентация).
Про решение больше расскажу. Мы с командой (не community — в нем куда больше людей) пишем чат-систему, довольно большую, на Python и TypeScript, а так же чат-бота на Python (там тоже очень много всего). Весь бекенд продуктов — 100% Python, мы используем k8s, микросервисную архитектуру, покрываем все аннотациями, активно используем pytest, hypothesis, mypy, pylint, sonar, у нас автоматизированный code-style (про него статью я тоже пишу) и много чего ещё.
Так же у нас есть ещё несколько команд (community), делающих разные продукты, но я не знаю могу ли я про них говорить. Может быть их участники смогут что-то рассказать, если у них есть аккаунты, я спрошу. Мы постараемся больше рассказывать в будущем о python решениях в банке.
Также предлагаю не париться на тему о "серьезности/несерьезности" языка в чьих бы то ни было глазах - какое Вам дело до чужого мнения, если вам нравиться Ваш любимый инструмент и Вы умеете с его помощью давать бизнесу ценность, отраженную в вашей зарплате?
Спасибо! В целом, понимаю и отчасти принимаю эту философскую позицию и даже считаю её очень умной. Но я решил высказаться, потому что наболело. Плюс, я работаю с сообществом, общаюсь с множеством разных людей, команд, бизнесом и довольно часто в дискуссиях при выборе языка мы чувствуем стигму «не очень серьезного языка». Для меня, словом, это важный вопрос, я не лукавлю. Если бы это касалось меня одного, я бы никогда не решился написать такую статью и высказаться по этой теме, ибо просто бы следовал вашему совету.
Немного из другой оперы, но мне нравиться статья английской википедии о полноте по Тьюрингу языков программирования - там даже Minecraft и Excel упомянуты как "непреднамеренно полные по Тьюрингу" :-)
Если бы вы сделали сравнительный анализ языков, было бы полезно.
Я думаю, у меня знаний не хватит сравнить со многими другими. Не хочется вести как обычно в таких сравнениях случается — поверхностно погружаться в другие языки и так же поверхностно о них судить. Я бы все равно, как разработчик на python, клонил бы в свою сторону, было бы неизбежно. Плюс это бы вызвало негатив у их поклонников и это было бы заслужено.
А что вы пытаетесь доказать в этой статье - не ясно. Что питон хороший? А кто-то сомневается?
Да, хотел сказать, что он хороший, серьезный. Сомневаются, даже тут в комментариях. Очень часто эти вещи, о которых пишу в статье, я слышу. Поэтому и написал статью, наболело.
Полно хороших языков, включая упомянутые здесь уже Assembler, c, c++, java, c#.
Я не хотел «набрасывать» на другие хорошие языки, а хотел рассказать про один, который я хорошо знаю. Поэтому и пишу, что он для конкретно для меня «лучший».
Но, чтоб нахваливать какие-то фичи, неплохо бы знать как то же решается в других экосистемах.
Кое-что про другие экосистемы я знаю, но мне кажется, что не в таком масштабе, чтобы устроить большое сравнение. Идея мне понравилась, спасибо! Я о ней подумаю, может быть правда когда-нибудь найду силы и знания написать такое сравнение.
Очень хорошая статья и довольно известная! Спасибо :)
От нас такой именно статьи не будет, потому что мы учитываем чужой опыт и почти 100% кода покрываем аннотациями типов и массово используем mypy. Я очень верю в механизм аннотаций и очень люблю gradual typing.
Я не манипулировал, честно скажу. Поэтому приложил поэтому широкий список разных топов, которые веду не я и не я за них отвечаю. Судить об их объективности я не стал, и написал свои оценочные суждения о самих рейтингах.
У нас тоже аналитики пишут и очень любят язык.
> Второе важен момент производительности
Согласен, поэтому я про это и написал. Асинхронный питон вполне быстрый для I/O нагрузки. Я ориентируюсь в оценках на techempower, как самый известный. FastAPI там звезд с неба не хватает, fastify, fasthttp, tokio — обходят, конечно. Но ведет себя достойно. Доверять ли этому бенчмарку или нет — судить не берусь.
> Вы очень смелые велосипедисты из Райфайзена.
Про нас скажу так: у нас очень интересные люди работают и пишут правда качественный код на Python, велосипеды пишем только в крайней необходимости, т.е. редко.
> Знаете есть еще С++ и ASM очень клевые языки, тоже не проходите мимо
Знаем! Ассемблер — хороший язык (или, скорее, семейство языков), но на нём сложновато писать и не очень нужно в большинстве случаев. Но если понадобилась бы супер производительность в каких-то ситуациях, наверное, им бы могли воспользоваться. Правда, о таком я не слышал.
Про С++ тоже много все вспоминают, язык для индустрии известный и важный. Я так понимаю консенсус наших архитекторов и разработчиков, что мы этот язык не очень поддерживаем тут внутри и от него уходим. Но тут я всей полнотой информации не обладаю, может кто-то из коллег придет и расскажет больше, я скорее просто слышал.
Иногда, в некоторых сценариях, на C++ могут писаться Python модули, но мы у себя тоже не практикуем, хотя банк большой, может кто-то и пишет, за всех говорить не возьмусь.
Data science, devops, парсеры — это тоже, во многом, частные случаи бекенда или вещей рядом с ним, я бы так сказал. Конечно, не всё это, но многое применяется в бекендах.
Про неоднозначность позиции в глобальном смысле можно спорить. Я поэтому и написал, что он для меня номер 1.
А у вас есть какой-то язык, который вы считаете доминантным в бекендах?
Спасибо! А тут так вышло — текст писался как пересказ доклада на конференции и там, в видео, ирония была. При переносе в текст, казалось, что она останется, но куда-то в итоге испарилась. Этот кусок текста явно из прошлого. Так сказать, баг в продакшене :)
Я точно не собирался и не собираюсь учить кого-то жизни и расстановке приоритетов (ну разве в разработке). Если возникло ощущение такое от статьи — значит я не очень хорошо донес свои мысли, сорри.
Отлично!
Могу только как активный пользователь django-suit (к которому я больше тяготею, чем к grappelli) могу лишь только предложить в будущих релизах сделать поддержку и его тоже (а как разработчик пакета вы наверняка скажете "присылай мержреквест" — и будете правы :).
От саблайма уже пора отказываться, господа и дамы.
Его разработка ужасно замедлилась.
Я купил его и сидел год на 3 ветке. Как она была дев, так и осталась. На линуксе дерево файлов просто не работало — большие директории постоянно делали вид, что загружаются, а консоль молчала. Плюс память, он сжирал гигабайт по 6 в легкую, с парой плагинов. И всё это никак не исправлялось, а новые релизы появляются очень очень редко.
Его практически забросили, на мой вкус. А это основной инструмент, да ещё и платный.
Для себя я выбрал атом — это такой же саблайм, только у него уже встроенный пакетный менеджер, все возможности по стилизации (cssом) интерфейса, миллион пакетов, которые легко сделать самому, опенсорс и всё такое.
А чего ж она в десантники тогда не записалась? Ну или в шпалоукладчицы?
Есть личности с «тонкой душевной организацией», но зачем тогда идти и работать с такого рода контентом?
Девушка сама себе злобный буратино. И проблемы, очевидно, у неё не от работы и не от порно.
Я полагался на вот эту статью https://wiki.python.org/moin/GlobalInterpreterLock, «The GIL can cause I/O-bound threads to be scheduled ahead of CPU-bound threads, and it prevents signals from being delivered» и не очень хорошо перевел/записал, думаю.
http://www.dabeaz.com/python/GIL.pdf для себя я понял, что речь о 18, 23, 25, 26 слайде вот тут. Мне показалось, что говорится конкретно о 25, а остальные больше контекста дают.
Т.е. в целом, ощущение, что это опасность связана с юникс сигналами и кейсом смешения I/O-bound, CPU-bound и все это на тредах/считай с GIL.
Могу ошибаться и/или неправильно понимать.
Большое спасибо! :)
Отличная мысль!
По-моему, дело обстояло так. Гвидо долго говорил, что хотите быстрый python — возьмите pypy, в котором jit и который действительно дает значительное ускорение.
Но в прошлом году Гвидо надоело быть, так сказать, на отдыхе и Microsoft выделил денег и поэтому случилось невероятное — https://mail.python.org/archives/list/python-dev@python.org/message/WVURDCWRH7F5UDLU5ZLT5P35ZO6TIBYA/
https://www.python.org/dev/peps/pep-0659/
https://github.com/faster-cpython/ideas
https://github.com/markshannon/faster-cpython/blob/master/plan.md — тут есть план, что python 3.12 принесет нам jit!
Мы очень сдержанно сидим и радуемся этим выдающимся новостям :)
Ну не такой он уж кликбейтный, ведь Python — серьезный язык! Ну, разве чуть-чуть, простите уж за такую шалость :)
Так уж вышло, вот эту статью мне удалось доредактировать чуть раньше. Сейчас я пишу о сообществе и начал писать о нем раньше этой статьи. И та статья должна была выйти раньше, став первой. А вышла эта, поэтому она немного вырвалась вперед, создав вот это громкое (я хотел бы верить) впечатление.
Про подтверждать делом — всецело разделяю, мы будем стараться, не всегда просто рассказывать про внутренние продукты.
https://habr.com/ru/company/raiffeisenbank/news/t/586976/ мы немного рассказывали вот тут с командой и https://habr.com/ru/company/raiffeisenbank/blog/552734/ вот тут (но там про Python довольно мало). На code/r https://habr.com/ru/company/raiffeisenbank/blog/586042/ вот тут я выступал с докладом, который и лег в основу статьи.
https://habr.com/ru/company/raiffeisenbank/news/t/566370/ вот тут у нас был открытый митап (есть на ютубе).
Вот тут мы выступаем на конференциях:
https://www.youtube.com/watch?v=4zjj1aHJoko
https://www.youtube.com/watch?v=_nl1e4TWQ0Q
https://conf.python.ru/moscow/2021/abstracts/7746 (тут рассказываем о нашем сервисе вебсокетов, это чисто бекенд, python, zeromq, k8s — я надеюсь, что у нас там довольно интересный доклад получился, т.к. сам сервис я считаю очень любопытным и довольно технологичным; видео пока не вышло, но есть презентация).
Про решение больше расскажу. Мы с командой (не community — в нем куда больше людей) пишем чат-систему, довольно большую, на Python и TypeScript, а так же чат-бота на Python (там тоже очень много всего). Весь бекенд продуктов — 100% Python, мы используем k8s, микросервисную архитектуру, покрываем все аннотациями, активно используем pytest, hypothesis, mypy, pylint, sonar, у нас автоматизированный code-style (про него статью я тоже пишу) и много чего ещё.
Так же у нас есть ещё несколько команд (community), делающих разные продукты, но я не знаю могу ли я про них говорить. Может быть их участники смогут что-то рассказать, если у них есть аккаунты, я спрошу. Мы постараемся больше рассказывать в будущем о python решениях в банке.
Спасибо! В целом, понимаю и отчасти принимаю эту философскую позицию и даже считаю её очень умной. Но я решил высказаться, потому что наболело. Плюс, я работаю с сообществом, общаюсь с множеством разных людей, команд, бизнесом и довольно часто в дискуссиях при выборе языка мы чувствуем стигму «не очень серьезного языка». Для меня, словом, это важный вопрос, я не лукавлю. Если бы это касалось меня одного, я бы никогда не решился написать такую статью и высказаться по этой теме, ибо просто бы следовал вашему совету.
Занимательнная ссылка, спасибо! :)
Может быть! Давайте будем следить, это точно будет интересно :)
Я думаю, у меня знаний не хватит сравнить со многими другими. Не хочется вести как обычно в таких сравнениях случается — поверхностно погружаться в другие языки и так же поверхностно о них судить. Я бы все равно, как разработчик на python, клонил бы в свою сторону, было бы неизбежно. Плюс это бы вызвало негатив у их поклонников и это было бы заслужено.
Да, хотел сказать, что он хороший, серьезный. Сомневаются, даже тут в комментариях. Очень часто эти вещи, о которых пишу в статье, я слышу. Поэтому и написал статью, наболело.
Я не хотел «набрасывать» на другие хорошие языки, а хотел рассказать про один, который я хорошо знаю. Поэтому и пишу, что он для конкретно для меня «лучший».
Кое-что про другие экосистемы я знаю, но мне кажется, что не в таком масштабе, чтобы устроить большое сравнение. Идея мне понравилась, спасибо! Я о ней подумаю, может быть правда когда-нибудь найду силы и знания написать такое сравнение.
Очень хорошая статья и довольно известная! Спасибо :)
От нас такой именно статьи не будет, потому что мы учитываем чужой опыт и почти 100% кода покрываем аннотациями типов и массово используем mypy. Я очень верю в механизм аннотаций и очень люблю gradual typing.
У нас тоже аналитики пишут и очень любят язык.
> Второе важен момент производительности
Согласен, поэтому я про это и написал. Асинхронный питон вполне быстрый для I/O нагрузки. Я ориентируюсь в оценках на techempower, как самый известный. FastAPI там звезд с неба не хватает, fastify, fasthttp, tokio — обходят, конечно. Но ведет себя достойно. Доверять ли этому бенчмарку или нет — судить не берусь.
> Вы очень смелые велосипедисты из Райфайзена.
Про нас скажу так: у нас очень интересные люди работают и пишут правда качественный код на Python, велосипеды пишем только в крайней необходимости, т.е. редко.
> Знаете есть еще С++ и ASM очень клевые языки, тоже не проходите мимо
Знаем! Ассемблер — хороший язык (или, скорее, семейство языков), но на нём сложновато писать и не очень нужно в большинстве случаев. Но если понадобилась бы супер производительность в каких-то ситуациях, наверное, им бы могли воспользоваться. Правда, о таком я не слышал.
Про С++ тоже много все вспоминают, язык для индустрии известный и важный. Я так понимаю консенсус наших архитекторов и разработчиков, что мы этот язык не очень поддерживаем тут внутри и от него уходим. Но тут я всей полнотой информации не обладаю, может кто-то из коллег придет и расскажет больше, я скорее просто слышал.
Иногда, в некоторых сценариях, на C++ могут писаться Python модули, но мы у себя тоже не практикуем, хотя банк большой, может кто-то и пишет, за всех говорить не возьмусь.
Про неоднозначность позиции в глобальном смысле можно спорить. Я поэтому и написал, что он для меня номер 1.
А у вас есть какой-то язык, который вы считаете доминантным в бекендах?
Спасибо! А тут так вышло — текст писался как пересказ доклада на конференции и там, в видео, ирония была. При переносе в текст, казалось, что она останется, но куда-то в итоге испарилась. Этот кусок текста явно из прошлого. Так сказать, баг в продакшене :)
Спасибо!
Я точно не собирался и не собираюсь учить кого-то жизни и расстановке приоритетов (ну разве в разработке). Если возникло ощущение такое от статьи — значит я не очень хорошо донес свои мысли, сорри.
Извините, я из МИРЭА (в прошлом) :)
Но основы то знать, конечно, стоит. Вообще спрос на программистов с крепким базовым образованием всегда выше.
Могу только как активный пользователь django-suit (к которому я больше тяготею, чем к grappelli) могу лишь только предложить в будущих релизах сделать поддержку и его тоже (а как разработчик пакета вы наверняка скажете "присылай мержреквест" — и будете правы :).
Его разработка ужасно замедлилась.
Я купил его и сидел год на 3 ветке. Как она была дев, так и осталась. На линуксе дерево файлов просто не работало — большие директории постоянно делали вид, что загружаются, а консоль молчала. Плюс память, он сжирал гигабайт по 6 в легкую, с парой плагинов. И всё это никак не исправлялось, а новые релизы появляются очень очень редко.
Его практически забросили, на мой вкус. А это основной инструмент, да ещё и платный.
Для себя я выбрал атом — это такой же саблайм, только у него уже встроенный пакетный менеджер, все возможности по стилизации (cssом) интерфейса, миллион пакетов, которые легко сделать самому, опенсорс и всё такое.
Если есть претензии к картинке, советую писать куда-то туда.
Есть личности с «тонкой душевной организацией», но зачем тогда идти и работать с такого рода контентом?
Девушка сама себе злобный буратино. И проблемы, очевидно, у неё не от работы и не от порно.