Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
Мысль ясна. В 2026 году, если что-то работает слишком медленно, нужно просто добавить еще серверов. Конечный потребитель так или иначе оплатит. А в пределе оплатят банкет вообще все, как в случае с DDR5.
Итак, снова в студии рубрика #MythBusters и её бессменные ведущие... да кому какое дело, кто ведущие, верно? Сегодня снова развенчивают мифы...подтверждая их, прямо и косвенно.
#1 - Медленный. И поэтому вместо освещения реальных усилий по оптимизации байткода, по различным проектам питона мы осветим...внешние библиотеки на С/С++, парой слов упомянув про существование PyPy, закончив копиумом "да не нужна нам эта скорость исполнения ё****ая, у нас же все перекладывает из json в json, у нас клиент же заплатит за всё".
#2 - GIL. У питона есть оффициальная реализация от товарища Ван Россума, которая до сих пор содержит в себе GIL. И только вот-вот начали от него отказываться, в некоторых сценариях, в крайних версиях спеки и интерпретатора. Что это значит? Это значит, что оно с нами ещё лет на 5-7, минимум. Потому, что миграция между версиями той же трёшки - геморрой, но аффтырь об этом решил не говорить, за вспомнив про мультипроцессинг. Который для решения задач, которым показан мультитрединг - тот еще костыль с хорошими накладными расходами на IPC.
#3 - Нет типов. И поэтому аффтар долго и нудно рассказывает про костыли, выросшие вокруг этого "мифа", призванные скомпенсировать этот вопиющий "миф". Типов нет, но если обмазаться костылями, визуальным языковым мусором (требущих линтеров и конвенций вместо такого примитивного и простого сахарного определения int i := 1 ) и pydantic'ами, то они как бы есть, но все равно их нет.
#5 - ООП. Тут вообще оправдания, которые я слышу уже многие годы: "у нас тоже есть ООП! Оно почти такое же, как у взрослых, только луДшеее, я могу залезть и поменять приватные данные без синтаксического сахара доступа! Я весь из себя такой взрослый, что..." + навязывание обязательности линтеров. Приватные данные и методы - приватные для всех, кроме тех, кому не разрешено средствами языка явно, остальное - детская надстройка
Для кого это написано, аффтар?
#5 - я верно вас понял что:
“если нельзя - но через сахар можно = это хороший ООП” (“… я могу залезть и поменять приватные данные без синтаксического сахара доступа! …”)
“если можно - но можно запретить = это плохой ООП” ?
и “… Приватные данные и методы - приватные для всех, кроме тех, кому не разрешено средствами языка явно, остальное - детская надстройка …”, а почему вы не учитываете что такое поведение питона - это его “разрешения языка”?
Миф 1: «Python невыносимо медленный»
Но ведь он действительно жутко медленный, не поспоришь. Остаётся оспаривать "невыносимо", что автор и делает, но коряво. Да, вокруг Python много костылей, но каким боком это есть достоинство? Да, не все задачи требуют полной скорости, но зачем вообще выбирать язык где нужно об этом думать?
радость от того, что узкое место не CPU, проходит как только у каждого сотого пользователя лопается терпение и он уходит
ничто не склеивает С++ лучше, чем С++
и если скорости действительно хочется, то надо помнить
- после ускорения в 3-5 раз вполне может остаться разница в производительности в 10-20 раз
- Numba тяготеет затягивать с поддержкой свежих версий Python и легко может молчаливо дать неверный результат
- кто же поверит, что на Cython получается быстрее, чем на С
Миф 2: «GIL делает многопоточность в Python невозможной»
Читаем "Зачем плодить тяжеловесные потоки операционной системы, когда есть кооперативная многозадачность?" и сразу "Нужно загрузить все ядра? Используйте процессы." Чаво?
Да, GIL уходит в прошлое. А замедление однопотока связанное с его отсутствием тоже уходит в прошлое?
Миф 3: «Отсутствие строгой типизации превращает крупные проекты в ад»
Далее следуют методы обустройства в аду. Ответ на вопрос "Зачем!?" не приводится.
Это часть мифа о типизации, и этот миф - главный, все остальные являются его следствием. Причём в крайних формах - Lua тоже без типизации, но по скорости как минимум вдвое быстрее и реально ускоряется до двойки по сравнению с С через LuaJit. JavaScript тоже без типизации, тоже быстрее в разы, тоже выходит на типизацию через TypeScript... Почему Python?
А потому, что прежде, чем писать тип, нужно знать что это за тип. Если есть наследование - возводите в куб. И если что сделано не так, а при малейшем незнании что-то точно будет не так, то либо рефакторинг путём переписывания с нуля, либо ложимся под лавину технического долга. Поэтому языки без типизации никак и не умрут - люди пока ещё, хотя ИИ должен с этим помочь, продолжают заниматься новыми вещами. Что, по воспоминаниям, подтверждается исторически - как новьё, что HTML генрить, что данные ковырять, что модели гонять - так и Python, а дальше инерция.
А почему именно Python а не JavaScript или Lisp - это отдельный вопрос, и нужно помнить - Python тут не более, чем первый среди равных. Может задач под него, а не под Lisp тот же, больше. Может индустрия считает что Python чтобы въехать в Рай на чужом горбу подходит лучше. Может верят в лёгкий вход. Может ещё чего...
Миф 4: «Python годится только для скриптов, парсеров и Data Science»
И как развенчание предлагаются корпоративные приблуды. Для владельцев крупных компаний, а Хабр кишит ими разумеется, пойдёт. Для стремящихся в корпоративное рабство - пойдёт частично. А можно было понадёргать применений от Kivy до Anvil.works, в процессе не забыв, раз уж так получилось совершенно случайно, что вся графика скриптуется на Python.
Миф 5: «В Python нет нормального ООП (инкапсуляции)»
Это смешной миф за отсутствием определения нормальности. А как его развенчивать никого не обидев оскорблениями - я с хода не догадался.
Анонсы новых статей, полезные материалы, а так же если в процессе у вас возникнут сложности, обсудить их или задать вопрос по этой статье можно в моём Telegram-сообществе. Смело заходите, если что-то пойдет не так, — постараемся разобраться вместе.
При таком уровне изложения, если и зайду (а я не зайду), то разве что за анонсами.
Вот только миф 1 - отнюдь не миф, а реальность, хотя есть задачи, где это не очень важно.
А вот миф 3 - это прям огромная головная боль не только из-за runtime падений где-нибудь в середине pipeline. Это практически блокер для любых нетривиальных рефакторингов.
или задать вопрос по этой статье можно в моём Telegram-сообществе.
Отвечать на вопросы в комментариях на хабре конечно же никто не собирался.
Здравствуйте, у меня много статей и уведомление по новым комментариям не приходит) Поэтому если у вас возникает вопрос лучше написать в тг чтобы мне пришло уведомление и я оперативно вам ответил)
Нет, задам здесь. Хабр это место где обсуждают технические вопросы. Он хорошо индексируется поисковыми машинами и любой желающий может ознакомиться как со статьей, так и с обсуждением в комментариях. В этом заключен основной смысл - обмен опытом между более опытными членами сообщества и новичками. Ваш подход с переходом в телеграм нарушает эту логику. Отсюда у меня вопрос: могли бы вы поучаствовать в обсуждении вопросов по существу вашей статьи в комментариях выше?
Мне django очень понравился делаю xenforo 2.3.10 подобие на нем очень здорово и без всяких вендоров - всё включено в сам python - async, ajax, json, sqlite...
Встроенный администратор интерфейс очень похож на xenforo также используется fastapi
Может в будущем что-то похожее на nextcloud
Узкое место — это не язык, а сеть и база данных (I/O-bound)
И тут Python сильно усложняет жизнь медленностью. Не совсем очевидный тезис, но даже если у вас простой CRUD без математики, алгосов и тд, то идентичный код на питоне может работать в 3-5 раз медленее и жрать в 5-10 раз больше ресурсов, чем гошный/джавовый.
Просто из-за GIL, типизации, интерпретации сложности с паралелизмом и тд. Я ни раз переписывал Python на Go, почти всегда прирост очень большой. (например, тут https://habr.com/ru/companies/whoosh/articles/728926/ под "бенчмарки")
И из-за этого на Python P90 будет 300ms, например, а на Go - 100ms, что в свою очередь для самого бизнеса намного приятнее. Кстати это одна из причин, почему TTM у Go будет пониже, чем у Python - алгос на Go со сложностью O(n) крайне часто будет работать быстрее, чем в Python с O(1), поэтому можно меньше беспокоиться о кешах, редисах, оптимизациях и тд
И еще не очевидный тезис - медленные языки тратят больше ресурсов соседних систем. Идентичный код на Go может нагружать PG условно на 30-50% меньше, чем Python, просто из-за того, что нужно меньше коннектов, долгие транзакцию отрабатывают быстрее, а из-за этого и локи отпускаются быстрее и тд и тп и тд и тп
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Топ-5 мифов о Python, в которые давно пора перестать верить