В последние пару-тройку лет все больше популярных питонячьих инструментов либо переписываются на Rust, либо просто полностью копируются на нем. И все чаще в сообществе встречаются люди, которые утверждают, что Rust во всем лучше, что там zero-cost абстракции смешаны с «синтаксисом в стиле Python». Если это действительно так, почему мы переходим не на Rust, а на инструменты, написанные на Rust? До Rust мейнстримным «быстрым языком под капотом» для питонистов был C, но там трейд-офф был всем понятен: писать больно и тяжело, зато работает быстро. Пропаганда вокруг Rust иная: она утверждает, что Rust не хуже ни в чем, то есть не может быть ни одной рациональной причины, чтобы писать на Python, а не на Rust.

Лично у меня есть ощущение некоторого неоправданного высокомерия со стороны тех, кто пишет инструменты для питонистов на Rust. Кажется, в комьюнити питонистов они ощущают себя как взрослые среди детсадовцев. Но действительно ли их снобизм оправдан? Всегда ли то, что они делают, оказывается действительно лучше, чем нативные питонячьи инструменты? Далеко нет:

  1. Практически все хайпующие растовые инструменты сегодня — это клоны чего-то оригинального, написанного на питоне. Те же Astral’овские Uv и Ruff, к примеру — полные функциональные копии Pip и Flake8. Эти инструменты не приносят новых идей, они приносят только скорость, что само по себе очень круто, но этого недостаточно для долгосрочного развития экосистемы. Если идеи будут придумывать питонисты, а звездочки и почет за это потом получать те, кто перепишут то же самое на Rust, может ли такая система устойчиво развиваться?

  2. У питонячьих инструментов на Rust есть общая проблема: они часто плохо стыкуются с нативными питонячьими инструментами. Большинство библиотек так или иначе зависят от других библиотек, но если твоя библиотека написана на Rust — ты как бы находишься в зоне отчуждения, где очень многое приходится реализовывать с нуля, а не использовать готовое. В итоге решение распухает от лишнего кода, а его куски не могут с легкостью переиспользоваться другими проектами. В долгосроке это тоже создаст экосистеме проблемы с развитием. Упомянутый выше Ruff изначально позиционировался как замена Flake8, но одной из главных фич последнего является система плагинов. Тысячи разработчиков по всему миру много лет придумывали свои правила линтинга и писали свои плагины, но Ruff до сих пор так и не смог предложить сопоставимой системы: они решили просто переписать все существующие плагины на Rust и засунуть их в свою основную систему.

  3. Одним из самых важных качеств любого инструмента является его чинибельность. Можете ли вы самостоятельно найти и исправить ошибку, когда с ней столкнулись? Так вот, в случае инструментов на Rust это качество явно деградирует. Теперь недостаточно быть просто питонистом, чтобы полноценно отдебажить чужой инструмент, нужно либо совмещать 2 стэка, либо репортить проблему и ждать, что ее решат. Это бьет по фундаментальным основам опенсорса как идеи, и приводит к полной или частичной централизации разработки.

  4. Считается, что Rust всегда быстрее. Но чистый питон не обязан быть медленным! Это зависит от того, насколько нативно ваша концепция ложится в дата-модель питона. У меня на виду, к примеру, библиотека mashumaro, написанная на чистом питоне, которая была значительно быстрее сильно более популярного и с большой помпой переписанного на Rust pydantic’а.

  5. Риски развала разных экосистем суммируются. Рассмотрим ситуацию в пределе и представим, что всю питонячью экосистему таки переписали на Rust. Это бы значило, что теперь экосистема умрет при наступлении любого из событий: смерть PSF и смерть Rust Foundation. Короче, вся экосистема становится более хрупкой и зависимой от неконтролируемых внешних сил.

В общем, минусы мне кажутся довольно серьезными.

Ну и как быть?

Все, что я написал выше, не отменяет простого факта: мы хотим быстрых программ.

Мне нравится мысль о бесплатном ускорении. Ты просто написал свою программу, подождал лет 10, за это время компиляторщики что-то там улучшили и твоя программа стала быстрее на 25 процентов. Круто? Да. Ускорение интерпретатора — наша главная надежда. В 2021 Гвидо запустил проект Faster CPython, который ровно об этом, и, хоть могло показаться, что он слегка пробуксовывает, некоторые результаты все же есть. Кажется, главная проблема здесь — тупо деньги, у питонистов как сообщества недостаточно постоянных разработчиков, которые бы реализовывали идеи по ускорению интерпретатора. В любом случае, итоги их работы подводить пока рано, подобные инфраструктурные проекты требуют десятилетия для заметных изменений.

Но на Гвидо надейся, а сам не плошай.

В ближайшие очень много лет переписывание на другие языки и в частности на Rust — просто неизбежность, если мы хотим реального ускорения. Вопрос не в том, делать ли это, а в том, как делать.

Мне в этом плане кажется крутой идея плагинов для ускорения. Что-то очень похожее много лет случилось с Asyncio и Uvloop. Ты просто устанавливаешь сторонний пакет, меняешь одну строчку кода в своем проекте, и получаешь ускорение в 2-4 раза. Причем таких плагинов может быть несколько и они могут конкурировать между собой. Еще круче, если код моего проекта не нужно менять вообще. Автор библиотеки должен предусмотреть систему плагинов, позволяющую заменять основные компоненты его системы. Это позволяет совместить наличие эталонной питонячьей реализации и быстрой растовской, и когда появляется вторая — первую это никак не аффектит. Это немного усложняет написание кода для разработчика оригинальной системы, нужно лучше проектировать границы и делать ее куски более отчуждаемыми, но эта проблема представляется сильно меньшей, чем огромный ржавый монстр, который придет и сожрет все твои труды.