Комментарии 99
Читать интересно, понятно, что язык Вам нравится, но не понял, о какой иронии говорили в начале
Про неоднозначность позиции в глобальном смысле можно спорить. Я поэтому и написал, что он для меня номер 1.
А у вас есть какой-то язык, который вы считаете доминантным в бекендах?
Лучше не мешать эти вещи. И считать backend-ом то на чём пишут серверные решения. Т.е. когда есть сервер, который слушает запросы по сети и даёт свои на них ответы. То что он под капотом использует (почти всегда) базы данных, не делает что же базы данных backend-ом?! А если я числодробилку в WebWorker-е подключу в браузерной вкладке будет ли это frontend-ом? Едва ли. Просто косвенное задействование сопутствующих технологий.
А у вас есть какой-то язык, который вы считаете доминантным в бекендах?
Кажется раньше это был PHP :)
о что он под капотом использует (почти всегда) базы данных, не делает что же базы данных backend-ом?!
А почему нет? БД — часть бекенда. Если ты пишешь свою БД — написанный тобой бекенд.
А если я числодробилку в WebWorker-е подключу в браузерной вкладке будет ли это frontend-ом?
Так это фронтенд. Можно сказать, что бекенд фронтенда, если так удобнее. Но код будет крутится на клиенте и формально попадать под определение фронтенд. Даже написан он будет на JS. И заниматься им будут фронтендеры.
Едва ли. Просто косвенное задействование сопутствующих технологий.
Вот тут речь о терминологии. Обычно она размытая, но БД расположена на беке, а вебворкер на фронте.
Про бекенд — у нас бекенд на питоне, делает ML предикшены. Чат-бот. Вот он бек, он слушает рэббит, там весь код нами написан. Я считаю его бекендом и это нормально. При том что на клиентов смотрит сервис перед ним. Все эти термины — про разделение проблем. Ну то есть можно назвать это «глубоким бекендом», можно как угодно, но факт в том, что это крутится в наших контейнерах, пишется нами и деплоится тоже нами. Более того, я общаюсь с нашими датасайентистами и мы пишем общие продукты. Для нас проблемы даже общие зачастую.
Если бы мы называли только front-faced сервисы бекендом, то в этом мире не существовало такого явления как tracing, например!
Более того, термины всё таки неточно определены, они про разделение концептов. Вот, например softwareengineering.stackexchange.com/questions/415908/is-the-database-part-of-the-backend целое обсуждение на тему БД — это бекенд или нет. Однозначного ответа нет, хотя многие склоняются к моему видению.
Кажется раньше это был PHP :)
О, писал на php 6 лет когда-то.
достаточно написать пару for и def, объявить несколько переменных — и вот ты уже профессиональный Python-разработчик уровня middle
Смысл понятен, но вообще-то middle на то и middle что умеет разрабатывать сложные вещи, а сложные вещи на то и сложные, что их нельзя описать просто (можно только сложно или еще сложнее))
Конечно в статье идет манипуляция статистикой. Популярность среди ботаников и студентов еще ни о чем не говорит. У нас аналитики пишут на питоне... Для статистики важно фактически на чем пишут профессиональные разработчики в реальных производственных задачах.
Второе важен момент производительности. Как вертикальный, так и горизонтальный. Вобщем без сравнения бенчмарков, тут говорить не о чем.
Да кстати откройте nuget и посмотрите сколько там пакетов для веб разработки...
Резюмируя можно сказать Вы очень смелые велосипедисты из Райфайзена. Знаете есть еще С++ и ASM очень клевые языки, тоже не проходите мимо.
У нас тоже аналитики пишут и очень любят язык.
> Второе важен момент производительности
Согласен, поэтому я про это и написал. Асинхронный питон вполне быстрый для I/O нагрузки. Я ориентируюсь в оценках на techempower, как самый известный. FastAPI там звезд с неба не хватает, fastify, fasthttp, tokio — обходят, конечно. Но ведет себя достойно. Доверять ли этому бенчмарку или нет — судить не берусь.
> Вы очень смелые велосипедисты из Райфайзена.
Про нас скажу так: у нас очень интересные люди работают и пишут правда качественный код на Python, велосипеды пишем только в крайней необходимости, т.е. редко.
> Знаете есть еще С++ и ASM очень клевые языки, тоже не проходите мимо
Знаем! Ассемблер — хороший язык (или, скорее, семейство языков), но на нём сложновато писать и не очень нужно в большинстве случаев. Но если понадобилась бы супер производительность в каких-то ситуациях, наверное, им бы могли воспользоваться. Правда, о таком я не слышал.
Про С++ тоже много все вспоминают, язык для индустрии известный и важный. Я так понимаю консенсус наших архитекторов и разработчиков, что мы этот язык не очень поддерживаем тут внутри и от него уходим. Но тут я всей полнотой информации не обладаю, может кто-то из коллег придет и расскажет больше, я скорее просто слышал.
Иногда, в некоторых сценариях, на C++ могут писаться Python модули, но мы у себя тоже не практикуем, хотя банк большой, может кто-то и пишет, за всех говорить не возьмусь.
Сдается мне, джентльмены, что в родительском комментарии про C++ и ASM это была ирония.
А если серьезно, то бекэнд бекэнду рознь. Одно дело, если это какая-то типовая финансовая бизнес логика, то тут может быть Python и не самый идеальный выбор. А вот если нужно обрабатывать данные, которые укладываются в численный python с его NumPy + Jax + нейронные сетки, то Python по производительности еще даст фору многим нативным решениям.
А подскажите пожалуйста каким IDE кто пользуется, где был бы нормальный IntelliSense (автодополнение и т.д.)?
GIL всё ещё нас беспокоит. В итоге I/O-bound с небольшим количеством CPU-bound может привести к тому, что некоторые сигналы будут не доставлены.
Какие такие сиглалы, что значит не будут доставлены, тоест ьнапример сообщение от RabbitMQ может не доехать до Питона!? Можно подробнее плз.
Скорее всего автор имел в виду это https://bugs.python.org/issue7946
Вот отличная иллюстрация проблемы https://youtu.be/Obt-vMVdM8s?t=1803
Не уверен что формулировка автора "некоторые сигналы будут не доставлены" верна. IO задачи то будут выполнены, вот только при существовании рядом с ними CPU-bound задач выполнены они будут не так быстро, как могли бы.
Я полагался на вот эту статью 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.
Могу ошибаться и/или неправильно понимать.
Тут скорее питон не пропустит сообщение, а не отправит в RabbitMQ вовремя heartbeat. В результате, RabbitMQ посчитает его мёртвым и перезапустит сообщение.
Поэтому простой синхронный питон без потоков подходит только для таких же простых случаев. Для остальных есть официальный пример: https://github.com/pika/pika/blob/master/examples/basic_consumer_threaded.py
Если бы вы сделали сравнительный анализ языков, было бы полезно.
А что вы пытаетесь доказать в этой статье - не ясно. Что питон хороший? А кто-то сомневается? И не он один хороший. Полно хороших языков, включая упомянутые здесь уже Assembler, c, c++, java, c#.
Но, чтоб нахваливать какие-то фичи, неплохо бы знать как то же решается в других экосистемах.
Если бы вы сделали сравнительный анализ языков, было бы полезно.
Я думаю, у меня знаний не хватит сравнить со многими другими. Не хочется вести как обычно в таких сравнениях случается — поверхностно погружаться в другие языки и так же поверхностно о них судить. Я бы все равно, как разработчик на python, клонил бы в свою сторону, было бы неизбежно. Плюс это бы вызвало негатив у их поклонников и это было бы заслужено.
А что вы пытаетесь доказать в этой статье - не ясно. Что питон хороший? А кто-то сомневается?
Да, хотел сказать, что он хороший, серьезный. Сомневаются, даже тут в комментариях. Очень часто эти вещи, о которых пишу в статье, я слышу. Поэтому и написал статью, наболело.
Полно хороших языков, включая упомянутые здесь уже Assembler, c, c++, java, c#.
Я не хотел «набрасывать» на другие хорошие языки, а хотел рассказать про один, который я хорошо знаю. Поэтому и пишу, что он для конкретно для меня «лучший».
Но, чтоб нахваливать какие-то фичи, неплохо бы знать как то же решается в других экосистемах.
Кое-что про другие экосистемы я знаю, но мне кажется, что не в таком масштабе, чтобы устроить большое сравнение. Идея мне понравилась, спасибо! Я о ней подумаю, может быть правда когда-нибудь найду силы и знания написать такое сравнение.
Самая большая проблема питона в том что люди лезут писать на нем все что не поподя. Абсолютно забивая на огромное разнообразие других языков и решений. Отсюда выливается миллион проблем, начиная от производительности, когда компания вливает миллионы в AWS, чтобы несчастное приложение работало нормально, заканчивая командами программистов которые тратят огромное кол-во человеко-часов чтобы интегрировать какую-то не очень рациональную для питона фичу. Но зато на питоне.
Как фулстек разработчик, я не вижу никакой вау фичи в питоне, написать не большой скриптец, согласен быстро и удобно на питоне. Написать хоть сколько нибудь сложный бакенд? Боже упаси, это настолько неудобно что хочется плакать, особенно когда песня начинается про поддержку кодовой базы. Конечно основной причиной плохого кода всегда являются программисты, а питон всего лишь инструмент, очень добродушный…
Придёт время и Kotlin отожмёт часть ниши у Питона, вопрос только - на сколько большую
Julia https://julialang.org/ вероятно тоже может
Может быть! Давайте будем следить, это точно будет интересно :)
Swift же
А он идёт?
Какой-нибудь JSON-парсер на языке со статической типизацией будет гораздо более многословным и тяжелым в написании, чем на языке с динамической типизацией
Под JSON-parser-ом вы имели виду валидатор? Если да, то не сказал бы. В TypeScript с IO-TS вы можете весьма тривиально типизировать и провалидировать JSON одним и тем же кодом. Выглядит примерно так:
const IO_User = strict({
id: number,
username: string,
birthday: orEmpty(IO_Date)
});
// ...
const user = validate(JSON.parse(json), IO_User);
/* typeof user === {
id: number,
username: string;
birthday: Date | null;
} */Заметьте, одновременно ещё и string в Date сконвертировали. IO-TS умеет и в очень сложные типы, и в алгебру типов.
Или всё же речь шла про настоящий парсер произвольного JSON? Такое точно удобнее писать на статически типизированных языках, т.к. на них удобнее писать сложные конечные автоматы. Не приходится всю картинку держать в голове и отлаживать глупые кейсы, когда сам что-то забыл.
Где-то, где мы в Python отобьемся манипуляциями в рантайме, придется подтаскивать большие объёмы кодогенерации.
Сейчас появились языки, с которыми многие фишки из динамических языков… внезапно можно типизировать и без кодогенерации. Typescript тому пример. Обычно ценой там выступает сложность описания соответствующих типов. Но 95% он покрывает.
На хабре писали:
Instagram написан на Python и Django. Хоть у Python и есть проблемы с CPU-intensive задачами, но зачастую, в веб приложениях, ориентированных на контент, основная нагрузка это - I/O intensive задачи. К тому же, большая часть проблем, решается за счет уровней кеша, CDN и тд.
ЗЫ: основная часть DropBox также на Python, но на 2-й версии. И сам Гвидо долгое время работал на них.
https://habr.com/ru/company/otus/blog/591983/#comment_23779785
То есть у Питона есть своя ниша в вэб приложениях, она обозначена выше, но приложения с разветвленной бизнес логикой - это не к нему.
Вы, наверное, ошиблись комментарием :)
но приложения с разветвленной бизнес логикой - это не к нему
Не так давно половина (если не больше) Cisco на бэкенде была написана на пайтоне с сотнями сервисов на самописных фреймворках с тредингом и мультипроцессингом на десятках продуктов, которые приносили и приносят миллиарды в год.
Так как так то, объясните джуну Java) как можно писать бэк, если нельзя после объекта поставить точку и увидеть всё методы которыми я могу воспользоваться? Или как можно не накосячить не зная какой тип переменной в конкретном участке кода?
Если как писали на Хабре: все решается аннотациями, которые из динамической типизации превращают Пайтон в статическую, то в чем тогда вообще его фишка? В синтаксическом сахаре? Так можно написать библиотеки и юзать их где надо.
Я просто не понимаю как пишут большие проекты на Питоне, почему это выгодно? Потому что всё положительные моменты от Питона действуют только на старте проекта (как я понял)
как можно писать бэк, если нельзя после объекта поставить точку и увидеть всё методы которыми я могу воспользоваться?
Это как нельзя? Наверное только если писать код в блокноте.
Или как можно не накосячить не зная какой тип переменной в конкретном участке кода?
Если у кого-то не хватило ума поставить ретурн-тайп в докстринге метода (до появления аннотаций в 99% случаев никто бы не пропустил без него на код-ревью), тип можно понять или в дебаггере или по названию или как эта переменная используется в других частях кода. Никогда не сталкивался и не слышал о таких проблемах ни на втором, ни на третьем пайтоне.
то в чем тогда вообще его фишка
Как минимум нет сишных скобочек, которые являются визуальным мусором
Уверен дело не только в скобках.
На мой взгляд ретурн-тайп и аннотации выглядят как костыли которые ломают принципы языка.
Мой вопрос был связан с этой статьей, где автор писал про типизацию следующее:
Да, в 3-й версии Питона появились средства явного указания типов, т.е. авторы языка сделали большой шаг в сторону статической типизации, но на текущий момент эти новые фичи слабо поддерживаются как сообществом, так и интерпретатор довольно лоялен к нарушению типизации (по сравнению со строгими языками).
Вторая проблема динамической типизации - это подсказки IDE. Если явно не задан тип объекта, то и отследить его текущий тип очень часто невозможно. Раз тип неизвестен, то и подсказать доступные методы для переменной тоже невозможно. В таком случае, IDE уже не работает как помощник разработчика, а просто служит текстовым редактором.
Далеко не всегда динамическая типизация создает какие-то проблемы. Если программа небольшая и разработчик способен отследить все изменения типов, то работать с динамическими типами гораздо проще, чем явно описывать все классы и типы.
Но, если ваша программа разрастается до больших размеров, то тут уже IDE часто сдается, перестает помогать и уходит много времени на выяснение типов и доступных методов. Также возникают постоянные проблемы с типами, которые никак не отследить и можно выявить только с помощью модульного тестирования. Модульное тестирование - это нужная и полезная вещь, но динамическая типизация предъявляет повышенные требования к нему и требует большего покрытия тестами кода. И чем больше проект, тем будут больше издержки на отладку и поддержку.
Получается это не так?
Ну это всего лишь подсказки по типу , это если и шаг в сторону типизации то очень маленький и незначительный)
В целом это костыль, мое личное убеждение , что должна быть статическая типизация и опционально динамическая,но не наоборот )
Да, в 3-й версии Питона появились средства явного указания типов, т.е. авторы языка сделали большой шаг в сторону статической типизации, но на текущий момент эти новые фичи слабо поддерживаются как сообществом, так и интерпретатор довольно лоялен к нарушению типизации (по сравнению со строгими языками).
Проблема в том, что автор, скорее всего, на другом языке пишет. Он смешал вместе аннотации типов и типизацию. Виртуальной машине безразличны аннотации, они существуют сбоку и до нее не доезжают. Типизация в питоне — динамическая, строгая, утиная. Gradual типизация — подставлена сбоку с помощью аннотаций. Так же сбоку подставили Structural sub-typing (typing.Protocol). И работает это все довольно неплохо уже. Mypy стал сильно лучше и дает делает тайп гарды, сужение типов. В целом, по ощущению, чуть послабее всё это развито сейчас чем в TypeScript (в котором все отлично), может и не пройдет проверку на типобезопасность, но надежность кода сильно повышается. Мы type error не ловим в своем коде никогда, например.
И это не всё. Есть выдающиеся проекты — pydantic и fastapi. Они берут аннотации типов и в рантайме из них делают супер строгую валидацию, сваггер, можно даже «типизированные» настройки потреблять из окружения согласно 12 факторам.
Т.е. мы сейчас из аннотаций извлекаем пользу и на этапе статического анализа и динамически, в рантайме.
Но, если ваша программа разрастается до больших размеров, то тут уже IDE часто сдается, перестает помогать и уходит много времени на выяснение типов и доступных методов
Про это писал в статье. Время микросервисов, можно сейчас не раздувать монолиты. К тому же: коллеги из больших и уважаемых компаний, имеют у себя разработки на питоне исчисляемые сотнями тысяч строк кода на питоне. И полет у них нормальный.
На мой взгляд ретурн-тайп и аннотации выглядят как костыли которые ломают принципы языка.
Часто я слышу это от людей, которые на питоне не пишут и зачастую его не любят.
Я смотрю на эти вещи гибко. Эти «костыли» Гвидо почти 20 лет назад описывал ещё, и тогда никому они костылями не казались. Просто у многих людей сложилось впечатление о языке исходя из The Zen of Python, и судят они язык прям строго по нему. Все просто, для всего один путь, красиво, тут def, тут for, тут мы скриптик написали, а дальше отойдите, дайте дорогу «серьезным людям с серьезными языками» :). А зен размещен на странице с говорящим названием https://www.python.org/doc/humor/. Это всего-лишь шутливый текст, а не свод предписаний.
Язык живет и меняется и это нормально, это здорово, да даже прекрасно.
Gradual типизация — здоровый компромисс между статической типизацией и динамической. Можно быстро, понятно, надежно и не надо выбирать из трёх, можно все три.
Никто не отменял языки со статической типизацией, никто не говорит, что они плохие. Просто питон действительно по совокупности факторов тоже теперь сильный игрок, вот о чём я и говорю, о чём и написал статью.
Нет, иногда действительно показываются методы которые в реальности не существуют у объекта , сам с таким сталкивался при работе с внешней библиотекой )
Ага, особенно прикольно когда стоит Any или подсказки по типу нет из-за старой версии библиотеки ) Непонятно зачем нужны такие костыли, если есть нормальная статическая типизация и опциональная динамическая (в C# она неплохо реализована)
TypeScript мне очень нравится, сам пишу фронтенд на нём, можно сказать, мой второй язык. Считаю связку python + annotations + mypy + typescript — очень рабочей.
Но в его системе типов я пока не очень силен, честно говоря, type challenge пока не шибко хорошо идет.
Про валидацию: у нас все схемы написаны на zod, он мне больше почему-то понравился. Наверное, я его в начале потащил из-за safeParse, я прям очень-очень не люблю try-catch в js, а в ts меня от него совсем плохо.
Зашел прочесть, что такого крутого Райф сделал в бэкенде на Python... и не увидел. Плохо смотрел, ткните пожалуйста? Кликбейтный заголовок, по моему скромному ИМХО, нужно делом подтверждать, рассказывая, что на Python написано в бэке.
При этом язык и правда отличный - кто бы и что не говорил, особенно для всевозможной автоматизации, а также подготовки и анализа данных. Сам осенью чуть-чуть к нему прикоснулся в рамках научной статьи для примитивного анализа данных.
Глобальный же вопрос "Какой язык лучше для <x> ?", имхо, не имеет смысла. Какая разница на чем писать, если задача решена и "бизнес счастлив"? Да хоть на brainfuck.
Также предлагаю не париться на тему о "серьезности/несерьезности" языка в чьих бы то ни было глазах - какое Вам дело до чужого мнения, если вам нравиться Ваш любимый инструмент и Вы умеете с его помощью давать бизнесу ценность, отраженную в вашей зарплате? Немного из другой оперы, но мне нравиться статья английской википедии о полноте по Тьюрингу языков программирования - там даже Minecraft и Excel упомянуты как "непреднамеренно полные по Тьюрингу" :-)
"Какой язык лучше" может и не имеет смысла, если задача уже решена. А если еще нет, то очень даже имеет) Есть какой-то набор объективных метрик, позволяющий сравнивать одно с другим. Например, тот же GIL или динамическая типизация в одном случае норм (и даже плюс!), а в другом не очень норм. Для веба такая типизация ок, потому что можно быстро чинить баги, выкатывать новый код. Для десктопов – сомнительно, накатить новую версию сразу всем клиентам может быть не просто.
Зашел прочесть, что такого крутого Райф сделал в бэкенде на Python... и не увидел. Плохо смотрел, ткните пожалуйста? Кликбейтный заголовок, по моему скромному ИМХО, нужно делом подтверждать, рассказывая, что на Python написано в бэке.
Ну не такой он уж кликбейтный, ведь 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 решениях в банке.
Также предлагаю не париться на тему о "серьезности/несерьезности" языка в чьих бы то ни было глазах - какое Вам дело до чужого мнения, если вам нравиться Ваш любимый инструмент и Вы умеете с его помощью давать бизнесу ценность, отраженную в вашей зарплате?
Спасибо! В целом, понимаю и отчасти принимаю эту философскую позицию и даже считаю её очень умной. Но я решил высказаться, потому что наболело. Плюс, я работаю с сообществом, общаюсь с множеством разных людей, команд, бизнесом и довольно часто в дискуссиях при выборе языка мы чувствуем стигму «не очень серьезного языка». Для меня, словом, это важный вопрос, я не лукавлю. Если бы это касалось меня одного, я бы никогда не решился написать такую статью и высказаться по этой теме, ибо просто бы следовал вашему совету.
Немного из другой оперы, но мне нравиться статья английской википедии о полноте по Тьюрингу языков программирования - там даже Minecraft и Excel упомянуты как "непреднамеренно полные по Тьюрингу" :-)
Занимательнная ссылка, спасибо! :)
Люблю Python)
Когда обсуждают скорость Python, обычно вспоминают про C++, ведь на нем все бенчмарки выглядят в сто раз лучше, чем на Python. Но если мы начнём разбираться в вопросе, то станет ясно, что скорость Python на данном этапе — не такая уж проблема. Конечно, Python действительно медленный в CPU-bound задачах.
Сколько лет существует Python, столько же лет его ругают за производительность. Конечно, есть такие решения, как pypy, numba, но если Python претендует на роль универсального языка, то почему нельзя сделать дефолтный оптимизирующий JIT, как в Java или C#?
Отличная мысль!
По-моему, дело обстояло так. Гвидо долго говорил, что хотите быстрый 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!
Мы очень сдержанно сидим и радуемся этим выдающимся новостям :)
Можно ли в двух словах объяснить, в чём отличие от PyPy (и, если оба будет jit, то зачем их два)?
Мне кажется, что никто не знает пока, т.к. это только декларация о намерениях.
В теории можно полагаться на это: 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 — вопрос, конечно.
Для меня Python хорош тем, что автор языка ОЧЕНЬ сильно заморочился чтобы сделать язык для людей (и не с первого раза получилось и не то что бы "получилось", но всё же). Причём, для настоящих людей, а не вымышленных - ну, знаете, тех, которые в каждую минуту своей жизни знают наизусть и помнят все тонкости C++ и не допускают ошибок в коде и утечек памяти, с удовольствием пишут километры лишних, ненужных слов на Java, помогая транслятору, который сам не догадается, мгновенно парсят глазами и мозгом винегрет из слов со спецсимволами в Rust, радуются что JavaScript сам по себе очень компактен, практически ничего не умеет и всё решается гигабайтами библиотек в npm, так завязанных друг на друга так, что в этом мире зависимостей всегда что-то сломано и т.п.
Язык без лишнего визуального мусора. С кучей возможностей. С терпимыми недостатками. Да, он не идеален. Но когда пытаюсь использовать что-то другое, всё время ловлю себя на мысли "ну как же так можно было упороться и принять такие идиотские решения в дизайне языка, что простую, казалось бы вещь, приходится делать с печалью на лице". При том, что Python - это не моя мама-утка, начинал я вообще с Pascal/Delphi/Basic и лет 6 сидел на PHP.
автор языка ОЧЕНЬ сильно заморочился чтобы сделать язык для людей
И это одновременно благословение и проклятие для пишущих на нём. Python это действительно язык для людей, но проблема в том что выбрав его за эту черту можно однажды обнаружить себя в ситуации когда тебе нужен язык для программистов, а ты выбрал язык для людей.
Он замечателен когда нужно писать небольшие приложения для которых не нужен сложный computing за пределами подключаемых библиотек. Я пару раз оказывался в ситуации когда проект начали писать на питоне и около года хорошо обходились возможностями numpy, а потом появлялась необходимость справляться с в 10-100 раз большей вычислительной нагрузкой. И начинался ад, потому что человеческой многопоточности в языке нет, мультипроцессинг до 3.8 удваивал потребление памяти, и еще много, много неприятных вещей. Код на плюсах который решал задачу в 3-10 раз быстрее и мог сожрать в 2-3 раза больший инпут писался в 2-3 раза быстрее чем его аналог на питоне.
И вся эта боль от того что при старте проекта кто-то смог быстренько набросать mvp на фласке и показать менеджменту.
Python хорош, но далеко не для всего бекенда. И у меня наверное никогда не перестанет гореть от того что именно он захватим ML и DS сферу.
Вот согласен !
В ML и DS прекрасно могли себя чувствовать C# и Java )Но, к сожалению эти языки не так добры к новичкам)
По поводу "ада" - не понял. Даже если надо было переписать все на другом языке, то создание прототипа должно было сократить суммарные издержки. Если такого не происходило, то надо смотреть, почему этап "перевод прототипа в продакшн код" выполнялся неэффективно.
Даже если продакшн код пишется на том же языке, что и прототип, приходится добавлять и менять очень большие части кода. Естественный процесс. Требования к прототипу и к продакшн коду все же сильно отличаются.
Часто прототипы прямиком идут в продакшн. Такое случается в стартапах. Бывает. И тут надо быть готовым к неизбежным проблемам.
Проще говоря, когда на говнокод, написанный на любом другом языке, уже и дышать страшно, не то что менять, поверх Python-говнокода просто набрасывается очередной костыль и всё успешно работает, даже не думая коллапсировать.
Загляните в любой проект, связанный с нейронками — там везде под капотом такая жесть, что волосы встают дыбом на всех частях тела. И, конечно же, никаких тестов, практически никогда ничего похожего на вменяемую документацию, всё собрано из говна и палок, смотанных синей изолентой. Это типичный академический код, и ничего кроме Python такое не вывезет.
Мало того, Python позволяет этот говнокод не только написать и забыть, но ещё и реиспользовать. И просто собрав вот такие поделки со всего Интернета, слепить их вместе, причём очень быстро, и это даже будет работать.
Смотрел ваш доклад на конференции Moscow Python Conf 2021, было очень интересно, здесь тоже ждем от вас побольше интересных статей по python, спасибо
Я думал только 1Сники считают себя неполноценными)))
Это моя рефлексия, не хотел бы создать неверное впечатление о питонистах. Я вижу, что язык в дискуссиях любят приложить, поэтому высказался, это мое видение проблемы. Могу ошибаться.
Большинство из питонистов, насколько мне известно, не испытывают проблем и не чувствуют себя ущемленными. И правильно, язык то замечательный (кто о чём, а я всё о том же) :)
Питон - лучший!
За 20 лет перепробовал все языки, которые только возможно, начиная с Асма и Бейсика, через Си, Паскаль, Пхп, Яву, Яваскрипт и до Раста.
И хочу сказать, что нет ничего более человечного и молниеносного для разработки, чем Питон. Особенно после внедрения typing. Максимальная человекочитаемость и выразительность, нет такого ни у одного другого мэйнстримного языка.
Осталось дать каким-либо образом ему работать в браузере (встроенная ли это будет виртуальная машина или компиляция в wasm), и Питон захватит веб полностью, а недоразумение по имени Яваскрипт отправится туда, откуда приползло :)
ОС и драйвера, конечно, на нём не напишешь, но он и не об этом, это идеальный язык именно для высокого уровня.
Похоже травля достигает предела.
Я вообще дотнетчик и порой тоже шучу о питухоне или пыхе, но это совсем не означает, что эти языки не подходят для интерпрайса.
Мне кажется основная проблема питона в большом количестве школ, которые за три дня из школьника сделают мидл говнокодера. Потом эти говнокодеры накатают тонны так себе кода и питона ждёт наследство от пыхи.
Если есть ребята, которые пишут бэк на жабаскрипте, то питон отличный язык для бэка. Я как-то переписывался бэк... Плакал... Долго плакал. Ребята, если вы отличные спецы в фрон, не ходите в бэк плиз, мы же не ходим к вам в фронт и вы не ходите к нам.
Да травли то особой нет, питон почти все любят. Но имидж не самый лучший сложился. Поэтому я люблю транслировать свою обратную позицию и на этой теме ловить тухлые помидоры.
Отчасти со школами, кажется, так. Но я вот что думаю: неофиты всегда несут проблемы, но это и благо тоже. Да, конечно, на имидже языка сказывается, но зато есть приток новых способных людей, которые рано или поздно создадут что-то стоящее. В конечном счёте, это хорошо, что школ много.
Про специалистов back-front не поддержу, т.к. я за дружбу фронтов и беков, я сам фуллстек, начинал в 2005 году с верстки сайтов, поэтому для меня бек и фронт — не два разных человека, а голоса у меня в голове :)
Имел опыт разработки на python после java .
Для быстрого создания прототипов или небольших приложений хороший инструмент , но динамическая типизация в большинстве случаев это зло. Аргумент «динамическая типизация» позволяет писать меньше кода — правда,но лишь отчасти, разницу в размере кода будет компенсировано большим количеством тестов.
Это единственный (на мой взгляд), но очень серьезный недостаток, который не позволяет python конкурировать с java или C#
P.S
Забавно, я не встречал статей «Java — серьезный язык …» или «C# — серьезный язык …»
Понимаю.
Я как раз в статье пишу про аннотации типов, они снижают накал этой проблемы. Они завозят gradual typing в python, у нас даже алгебраические типы есть. Ну и дженерики всякие, файналы. Type guards, type narrowing появился вот в mypy. Проблема уже решаемая, инфраструктура питона прокачалась. Там не всё ещё идеально (вспоминаю stubs, typeshed, type-*), но очень неплохо сейчас.
Мы покрываем ими весь код и рекомендуем всем людям в community делать так же.
Да, но это лишь «подсказки типов данных», мне бы конечно хотелось бы, чтобы статическая типизация была по умолчанию, а динамическая опциональная (как в C# )
Довольно часто звучит эта самая обесценивающая формулировка — «всего-лишь аннотации».
Но что это значит? Да, у нас нет прям полноценного «вывода типов» (термин, который связан со статической типизацией, насколько я понимаю), но mypy делает очень неплохой статический анализ и типы всё таки анализирует. В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
А ещё исследования статической типизации часто предвзяты и некорректны, когда клонят все в преимущества статической типизации над динамической.
Т.е. получается и нет четких доказательств, что статическая типизация доминирует как и нет доказательств, что аннотации ей чем-то уступают. Так что я бы не стал их обесценивать, т.к. нет доказательств того, что они хоть чем-то плохи.
Мое субъективное мнение такое: Gradual typing — лучшее от обоих миров. Я считаю, что Python и TypeScript пошли по правильному пути, избрав эту концепцию.
Ключевое преимущество языков с динамической типизацией — скорость разработки. Мы просто быстро пишем код, а аннотации стоят рядом и позволяют сделать из этого кода — очень надежный код. Это именно то, что идеально вписывается в agile мир.
Python за аннотации можно было бы накинуть в другом направлении — mypy все ещё не идеальный инструмент.
В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
Уступает, так как даже самые древние библиотеки будут использовать статическую типизацию . Например в Java , возьмите любую библиотеку и вы точно будете знать, что вам возвращается и как с этим объектом работать . Основное преимущество статической типизации это четкий контракт взаимодействия для любой версии языка .
Ключевое преимущество языков с динамической типизацией — скорость разработки.
В целом да, на себе ощутил, что накидать прототип быстрее . Но, если выйти за пределы прототипирования, то скорость разработки (учитывая классные, современные framework-и) будет сравнима (для Java это Spring ). В целом python классный инструмент, у нас он очень активно используется для инфраструктуры, но весь бэк на java был есть и будет)Чему я очень рад)
P.S
Вполне возможно, что я не прав и просто хочу из python сделать java ))
Уступает, так как даже самые древние библиотеки будут использовать статическую типизацию . Например в Java , возьмите любую библиотеку и вы точно будете знать, что вам возвращается и как с этим объектом работать . Основное преимущество статической типизации это четкий контракт взаимодействия для любой версии языка .
Поэтому я и написал — «значительно».
Кроме того, у питона есть ответ на это — .pyi и py.typed, typeshed, теперь types-*
Пока это работает не идеально. В TypeScript тот же types сильно круче, даже у самых мелких пакетов нередко есть *.d.ts.
Вполне возможно, что я не прав и просто хочу из python сделать java ))
Да у языков много общего. Сейчас у питона появился статический анализ, питон компилируется в байт код и исполняется на виртуальной машине...
Пока это работает не идеально.
Ну вот да, с точки зрения бизнеса я бы не выбирал инструмент где такая важная часть как типа данных "значительно уступает"
Даже у вас в банке, как много сервисов написанных не на python ?
В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
Моя цитата была такой, пожалуйста, не вырывайте из неё кусок в свою пользу. Значительно не уступает. Он работает в той степени, что хватает бизнесу. У нас очень мало ошибок в рантайме, а связанных с типам около ноля. И у языков со статической типизацией ошибки в рантайме тоже бывают, есть про это и исследования.
Ну вот да, с точки зрения бизнеса я бы не выбирал инструмент где такая важная часть
Несмотря на некорректную цитату, скажу про это: если бы бизнес выбирал только идеальные инструменты, бизнес бы не выбирал ничего, т.к. таких инструментов нет. Выбор бизнеса не про технологии и не про надежность, а скорее про рынок, популярность и наличие специалистов. И с последним абсолютно у всех сейчас проблемы (большой дефицит всех).
Даже у вас в банке, как много сервисов написанных не на python ?
Я возможно создал неправильное впечатление и прошу за это прощения!
Я не хотел сказать, что у нас ВЕСЬ банк на python пишут, или что он у нас главный язык, возможно я создал несколько неправильный посыл.
Питонистов у нас относительно джавистов, мало, как и в любом банке. Конечно же у нас огромная кодовая база на джаве и никто её никуда не девает и от неё не отказывается. Джава здорова, бодра, весела и много крутых джавистов.
А я развиваю питон сообщество, не так давно, буквально второй год и рассказываю почему питон хорош, в том числе, как альтернативный стек внутри, а теперь и снаружи банка. Питонистов у нас в банке много, но далеко не все из них бекендеры.
Цитата была действительно неверная, прошу прощения !
Надеюсь python будет расти и здравствовать и составлять достойную конкуренцию Java и C# , как не крути единственный путь развития это конкуренция )
Спасибо за статью и за доп.информацию о типизации)
P.S
Возможно Graal VM даст хороший толчок для развития python в корпоративном сегменте )
К этим исследованиям (особенно тому самому про проекты на гитхабе) есть методологические вопросы
Как и ко многим другим, доказывающим преимущество статической типизации https://danluu.com/empirical-pl/. Тут я все таки еще опираюсь и на Uncle Bob и на некоторых других. Конечно, тут можно мне впаять аппеляцию к авторитетам, но т.к. поле информации огромно, а на миллион проектов посмотреть я не могу и не смогу, мало что остаётся. В основном, я тут топлю за python, не против других языков :)
Обратно, есть и такое исследование — там брали проекты на JS, выбирали коммиты, чинящие баги, добавляли аннотации типов в окрестности бажного кода, и смотрели, сколько багов поймается (поймалось 15%).
Надо почитать, тут так то просто выводы сходу не сделаешь. Информация как минимум любопытная, спасибо.
Тогда более-менее равное распределение багов по всем языкам будет как раз ожидаемым
Вероятно, ну у нас тут довольно эмпирическое поле, конечно. Исследований, надежных, исчезающе мало, поэтому я предпочитаю не считать, например, что аннотации — припарка от всего, такого точно нет. Я считаю, что они повышают надежность и даже по исследованию выше — это так и есть. Но и без исследований, чисто эмпирически, и я и многие коллеги находим с ними проблемы и почти никогда я не встречаю в наших проектах type error'ы. На нашем коде — точно нет.
Дядя Боб — это, конечно, специалист, но специалист в ООП и прочих аджайлах, а не в типизации
А кто у нас в принципе признанный всеми авторитет в области типизации? Такой формулировкой можно, по-хорошему, отсеивать вообще любые мнения, включая и собственное.
Ну если говорить об эмпирике и личном опыте — на голом питоне (или жс, или любом другом языке) без типов я писать не могу, моя производительность как функция от объёма уже написанного кода падает экспоненциально и в районе 50-100 строк становится неотличима от нуля.
У нас это не так, у нас все хорошо в районе десятков-сотен тысяч строк. Т.е. тут имеет место проблема личного восприятия языка, а не фундаментальная проблема самого языка.
Например коллеги из Я пишут огромные бекенды в 500+ тысяч строк кода и они у них работают, а сами они довольно продуктивны. К сожалению, не могу рассказать больше, но можете поспрашивать.
куча библиотек была неаннотирована
С этим лучше, но все ещё такое встречается. В целом, это пока не слишком хорошо, но работать с этим можно. Можно и свои стабсы писать для сторонних библиотек при желании максимальной надежности. У нас выходит и без этого.
Ну и я не понял, зачем оно такое надо, если новые проекты можно писать сразу на языках, более дружественных к выразительной типизации и при этом не требующих кучу ритуалов, ассоциирующихся с типизацией у среднего джависта
Вот! Вы, как джавист, не хотите писать на питоне. А питонисты хотят писать на питоне. Аннотации — для питонистов, не для джавистов. И для питонистов они выполняют полностью все возложенные на них ожидания — повышают надежность кода.
Мы относимся с уважением к мнению экспертов в других языках, но для нас польза видна и она есть.
Чтобы ответить себе на вопрос "чем твой любимый язык лучше другого". Ну например, чем питон лучше java?
Надо взять двух мидлов. И дать мидлу java покидать камни в питон. Ну тоесть выслушать а чем же язык плох?
Потом обоим поставить одну и туже задачу. Ну например, сделать миркросервис, который читает/пишет данные в постгрес из 3х справочников. Создать, обновить, удалить, чтобы всё там работало. Завернули чтобы в докер и закинули в кубер. Ограничение 10 под.
Важнон условие, чтобы роуты одинаково работали и назывались.
А потом тестируем нагрузку на сервисы не питоном, а продуктом на джаве jmeter. Ну число одновременных пользователей, время отклика и прочие радости. Прогоните 10 тестов одинаковых
После тестов, вы - как минимум перестанете сравнивать языки и успакоитесь. Кто кидался камнями - перестанет. И наступит мир)
Потому что, окажется что в 4х тестах выиграет питон, в 4х java. А в двух последних упадёт кубер, ибо ингресс контроллер тоже оптимизировать надо. И разница в победе там не в разы, десятки киллограм, а на одну дольку апельсина.
Потом ещё с++ ника надите. С# писта. И всех недовольных кто кидает кирпичи.
Бенчмарки от институов забугорья это конечно прикольно, но реалии таковы, что для выкручивания языка на такие бенчмарки скилов днём с фонарём не сыщешь. И в итоге все на средних скоростях и работают. В коробку вам никто в опен сорс либы не заложил супер производительность. И в язык тоже не прикрутил в коробку. И вообще никому мы там не нужны, чтобы секреты супер быстрого кунфу нам раскрывать.
Все языки так или иначе потом в железо упираются и операционку. И кубер куберу кубернет. У кого на центосе, у кого на убунте.
Ну а на питоне кодить - удовольствие)
Отличная статья, спасибо !
У меня дурацкий вопрос - а питон на питоне написать можно? Просто если нельзя то это не полноценный язык программирования
Если вы про квайны, то можно, есть еще интерпретатор питона на питоне.
есть хвостовая рекурсия на самом python, в качестве декоратора
towardsdatascience.com/python-stack-frames-and-tail-call-optimization-4d0ea55b0542?gi=4755232cd7fa
Не любительница питона, но статью прочитала с удовольствием. Понравилось отсутствие агрессии и поучительных нотаций. Очень удачный позитивный настрой и атмосфера примирения. Все бы так писали. Удачи Вам!
Спасибо, что нашли время написать комментарий! Очень приятно, что вы отметили подачу, я именно такой тон хотел задать статье и стараюсь так подходить ко всей коммуникации. Не всегда получается, но я работаю с этим.
Не сочтите за пафос: я не забываю, что я просто человек со своим скромным опытом, которому в данном случае повезло высказать свое субъективное мнение.
Другим языкам желаю развития и успеха, т.к. на мой взгляд, языковое разнообразие даёт возможность нам всем развиваться.
Python — серьезный язык для разработки backend