Довольно часто звучит эта самая обесценивающая формулировка — «всего-лишь аннотации».
Но что это значит? Да, у нас нет прям полноценного «вывода типов» (термин, который связан со статической типизацией, насколько я понимаю), но mypy делает очень неплохой статический анализ и типы всё таки анализирует. В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
А ещё исследования статической типизации часто предвзяты и некорректны, когда клонят все в преимущества статической типизации над динамической.
Т.е. получается и нет четких доказательств, что статическая типизация доминирует как и нет доказательств, что аннотации ей чем-то уступают. Так что я бы не стал их обесценивать, т.к. нет доказательств того, что они хоть чем-то плохи.
Мое субъективное мнение такое: Gradual typing — лучшее от обоих миров. Я считаю, что Python и TypeScript пошли по правильному пути, избрав эту концепцию.
Ключевое преимущество языков с динамической типизацией — скорость разработки. Мы просто быстро пишем код, а аннотации стоят рядом и позволяют сделать из этого кода — очень надежный код. Это именно то, что идеально вписывается в agile мир.
Python за аннотации можно было бы накинуть в другом направлении — mypy все ещё не идеальный инструмент.
Это моя рефлексия, не хотел бы создать неверное впечатление о питонистах. Я вижу, что язык в дискуссиях любят приложить, поэтому высказался, это мое видение проблемы. Могу ошибаться.
Большинство из питонистов, насколько мне известно, не испытывают проблем и не чувствуют себя ущемленными. И правильно, язык то замечательный (кто о чём, а я всё о том же) :)
Я как раз в статье пишу про аннотации типов, они снижают накал этой проблемы. Они завозят gradual typing в python, у нас даже алгебраические типы есть. Ну и дженерики всякие, файналы. Type guards, type narrowing появился вот в mypy. Проблема уже решаемая, инфраструктура питона прокачалась. Там не всё ещё идеально (вспоминаю stubs, typeshed, type-*), но очень неплохо сейчас.
Мы покрываем ими весь код и рекомендуем всем людям в community делать так же.
Да травли то особой нет, питон почти все любят. Но имидж не самый лучший сложился. Поэтому я люблю транслировать свою обратную позицию и на этой теме ловить тухлые помидоры.
Отчасти со школами, кажется, так. Но я вот что думаю: неофиты всегда несут проблемы, но это и благо тоже. Да, конечно, на имидже языка сказывается, но зато есть приток новых способных людей, которые рано или поздно создадут что-то стоящее. В конечном счёте, это хорошо, что школ много.
Про специалистов back-front не поддержу, т.к. я за дружбу фронтов и беков, я сам фуллстек, начинал в 2005 году с верстки сайтов, поэтому для меня бек и фронт — не два разных человека, а голоса у меня в голове :)
TypeScript мне очень нравится, сам пишу фронтенд на нём, можно сказать, мой второй язык. Считаю связку python + annotations + mypy + typescript — очень рабочей.
Но в его системе типов я пока не очень силен, честно говоря, type challenge пока не шибко хорошо идет.
Про валидацию: у нас все схемы написаны на zod, он мне больше почему-то понравился. Наверное, я его в начале потащил из-за safeParse, я прям очень-очень не люблю try-catch в js, а в ts меня от него совсем плохо.
Pypy — сторонний проект, его другие люди делают, поэтому это их личный фан, конечно. Да и, потом, интерпретатор языка на языке — это же просто круто :)
А снизится ли их мотивация после запиливания jit в cpython — вопрос, конечно.
Я полагался на вот эту статью 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) могу лишь только предложить в будущих релизах сделать поддержку и его тоже (а как разработчик пакета вы наверняка скажете "присылай мержреквест" — и будете правы :).
Довольно часто звучит эта самая обесценивающая формулировка — «всего-лишь аннотации».
Но что это значит? Да, у нас нет прям полноценного «вывода типов» (термин, который связан со статической типизацией, насколько я понимаю), но mypy делает очень неплохой статический анализ и типы всё таки анализирует. В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
А ещё исследования статической типизации часто предвзяты и некорректны, когда клонят все в преимущества статической типизации над динамической.
Т.е. получается и нет четких доказательств, что статическая типизация доминирует как и нет доказательств, что аннотации ей чем-то уступают. Так что я бы не стал их обесценивать, т.к. нет доказательств того, что они хоть чем-то плохи.
Мое субъективное мнение такое: Gradual typing — лучшее от обоих миров. Я считаю, что Python и TypeScript пошли по правильному пути, избрав эту концепцию.
Ключевое преимущество языков с динамической типизацией — скорость разработки. Мы просто быстро пишем код, а аннотации стоят рядом и позволяют сделать из этого кода — очень надежный код. Это именно то, что идеально вписывается в agile мир.
Python за аннотации можно было бы накинуть в другом направлении — mypy все ещё не идеальный инструмент.
Это моя рефлексия, не хотел бы создать неверное впечатление о питонистах. Я вижу, что язык в дискуссиях любят приложить, поэтому высказался, это мое видение проблемы. Могу ошибаться.
Большинство из питонистов, насколько мне известно, не испытывают проблем и не чувствуют себя ущемленными. И правильно, язык то замечательный (кто о чём, а я всё о том же) :)
Понимаю.
Я как раз в статье пишу про аннотации типов, они снижают накал этой проблемы. Они завозят gradual typing в python, у нас даже алгебраические типы есть. Ну и дженерики всякие, файналы. Type guards, type narrowing появился вот в mypy. Проблема уже решаемая, инфраструктура питона прокачалась. Там не всё ещё идеально (вспоминаю stubs, typeshed, type-*), но очень неплохо сейчас.
Мы покрываем ими весь код и рекомендуем всем людям в community делать так же.
Да травли то особой нет, питон почти все любят. Но имидж не самый лучший сложился. Поэтому я люблю транслировать свою обратную позицию и на этой теме ловить тухлые помидоры.
Отчасти со школами, кажется, так. Но я вот что думаю: неофиты всегда несут проблемы, но это и благо тоже. Да, конечно, на имидже языка сказывается, но зато есть приток новых способных людей, которые рано или поздно создадут что-то стоящее. В конечном счёте, это хорошо, что школ много.
Про специалистов back-front не поддержу, т.к. я за дружбу фронтов и беков, я сам фуллстек, начинал в 2005 году с верстки сайтов, поэтому для меня бек и фронт — не два разных человека, а голоса у меня в голове :)
TypeScript мне очень нравится, сам пишу фронтенд на нём, можно сказать, мой второй язык. Считаю связку python + annotations + mypy + typescript — очень рабочей.
Но в его системе типов я пока не очень силен, честно говоря, type challenge пока не шибко хорошо идет.
Про валидацию: у нас все схемы написаны на zod, он мне больше почему-то понравился. Наверное, я его в начале потащил из-за safeParse, я прям очень-очень не люблю try-catch в js, а в ts меня от него совсем плохо.
Мне кажется, что никто не знает пока, т.к. это только декларация о намерениях.
В теории можно полагаться на это: https://docs.google.com/presentation/d/1_cvQUwO2WWsaySyCmIy9nj9by4JKnkbiPCqtluLP3Mg/edit#slide=id.gd63e3f4a32_0_173 «Probably more like luajit than JVM, but I’m just guessing at this stage»
Pypy — сторонний проект, его другие люди делают, поэтому это их личный фан, конечно. Да и, потом, интерпретатор языка на языке — это же просто круто :)
А снизится ли их мотивация после запиливания jit в cpython — вопрос, конечно.
Я полагался на вот эту статью 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) могу лишь только предложить в будущих релизах сделать поддержку и его тоже (а как разработчик пакета вы наверняка скажете "присылай мержреквест" — и будете правы :).