Перейти на Python после Java, C# и C++ и жить счастливо: большое интервью с разработчиком

Лев Кудряшов

---

Разработчик в «Точке» и бывший мигрант. Стек — Java, Python. Специализация — бэкенд. Есть публикации на «Хабре». Практикует переход сервисов с Java на Kotlin.

Содержание

• Как и зачем программисту переходить на Python
• Как уговорить архитекторов, команду и бизнес включить в стек новую технологию
• Почему низкая скорость Python — не проблема
• Почему корпорации выбирают Java и C#
• Как Python стал популярным
• Как изучать Python и переходить с версии на версию

— Начнём с небольшого разогрева. Как ты пришёл в IT и почему стал писать на Python?

— Я работаю с Python уже пять лет. А до этого пять лет писал на Java. Как я перешёл на Python? Наверное, мне хотелось больше гибкости в проектах и больше «микросервисности».

К моменту, когда я решил плотно заняться Python-разработкой, мне достался на доработку огромный монолит на Java, коробочное решение от вендора, который к тому моменту его уже не поддерживал. Мне надо было написать ряд новых модулей — но некоторые из них сделать было невозможно, потому что требовалась интеграция с другими модулями и программами.

Чтобы дело шло быстрее и чтобы не увеличивать и без того гигантский неповоротливый монолит с кучей legacy, я начал обкладывать его новыми сервисами на Python.

Как и зачем программисту переходить на Python

— Серьёзное решение, если учесть, мягко говоря, скептическое отношение некоторой части программистской тусовки к Python. Кстати, что с ним не так? Откуда столько мемов на тему «петухона», «петушка — золотого гребешка» и прочего?

— Думаю, дело в низком пороге входа — по большому счёту на Python может писать любой школьник, шапочно знакомый со Scratch. Кроме того, многие воспринимают его как псевдоязык из серии «что вижу, то пою» — там ведь действительно что пишешь, то и выводится.

Некоторые разработчики любят разговоры в духе: мы, мол, тру-программисты, постигли статическую типизацию, C-style-код, сидим на шарпах, джаве, РНР, а этот ваш «питон» — ну что это за язык? Ни скобочек, ни точек с запятыми — разве так пишут?

Впрочем, история повторяется — я помню, сколько хейта несколько лет назад вызывал у «истинных джавистов» тот же РНР — все «петушки» тогда доставались именно ему. Сегодня же стало понятно, что дело, скорее всего, было в элементарной зависти: там, где джависты неделями ковырялись с JSP, пэхапешник просто разворачивал полноценный бэкенд и решал проблему за несколько часов. Сейчас в роли объекта насмешек выступает Python — притом что это обычный перспективный язык, который справляется с какими-то задачами лучше, чем другие.

Отдельная песня — претензии по поводу динамической типизации, а также ругань любителей базового программирования в адрес runtime. Ведь Python — интерпретируемый язык, для него нужно устанавливать интерпретатор, который будет работать на кросс-платформе. А интерпретация, в отличие от запуска скомпилированного кода, довольно медленная. И все эти минусы приписываются почему-то самому Python — хотя дело, в общем-то, и не в нём.

Я, будучи джавистом, тоже потешался над Python и совершенно искренне считал, что программировать надо «правильно»: с классами, многоветвистыми фигурными скобочками, в общем — чтобы всё как у людей. Лишь вникнув немного в Python, я понял, что он, оказывается, в большинстве случаев гораздо легче читается: и понять проще, и поддерживать легче.

— В общем, нарушил старую заповедь алкоголиков о том, что в процессе выпивания градус нужно только повышать. И спрыгнул со сложной, элитной, «пацанской» Java на якобы попсовый Python. Не было ли для тебя это неким шагом назад? Не чувствовал себя музыкантом, который после Штрауса и Шнитке начал «давать Киркорова»?

— Я вообще всю карьеру «понижаю градус». До Java я работал с С++, и «плюсовики» тоже, в общем-то, не одобряли моего перехода в другую веру. Потом коллеги-джависты осуждали то, что я ушёл в Python, — некоторые до сих пор не верят, что когда-то я был их тимлидом.

Хотя я считаю, что такая игра на понижение — это как раз нормально. Да, есть более сложные языки программирования и какие-то фундаментальные вещи из Computer Science нужно знать обязательно, иначе переходить обратно с Python на Java будет очень больно: можно не понять, как работает тот же JVM.

Но мир не стоит на месте, и цепляться за свою олдскульность и хардкорность, думаю, всё же излишне. Да, многие хотят как-то поддерживать имидж элитарной профессии, и им не особо радостно наблюдать, как приходит молодая шпана и в одну строчку делает то, что на их языке займёт десять строк плюс подключение либы. Другие просто не хотят обесценивать свой труд и то, что когда-то вложились в язык.

Было и со мной такое, когда я уходил с Java на Python. Мне казалось, что я просто выкидываю серьёзный бэкграунд. А это всегда больно. Ты словно бросаешь всё и уходишь в другое место. Плюс голый Python на рынке труда дешевле голой Java, поэтому вначале я потерял в зарплате процентов тридцать. Но я знал, что и зачем делаю, и не расстраиваюсь, что принял такое решение.

— А как быстро ты эти 30% отыграл, если вообще отыграл?

— За полгода, после первого же перфоманс-ревью. Всё-таки базовые знания, сам бэкграунд в нише бэкенда, который я наработал на Java, отлично ложился на Python. Да, мы сменили стек, с нуля начали ковырять новое, привыкать к интерпретации и динамической типизации — а это в какой-то момент сильно нагружает голову.

Но остаётся тот же SQL, с которым работает каждый бэкендер, сеть работает под управлением Linux, алгоритмы и структуры данных практически те же. Академическая база, логика и множества тоже не сильно изменились за последние пять лет, протоколы взаимодействия между системами остались прежними. А вот мир поменялся, рынок поменялся. И под них стоит подстраиваться, иначе можно оказаться на тонущем корабле.

Когда я писал монолит на Java, то понял, что сильно проиграю, если продолжу в том же духе и не попробую что-нибудь маленькое разворачивать вокруг него на Python. Переломный момент настал в 2015 году, когда все уже начинали потихоньку переходить на микросервисы. Я был первым в своей компании, кто пытался это всё внедрить. Оппозиционером, можно сказать, — и архитекторы за это меня даже недолюбливали :)

Как уговорить архитекторов, команду и бизнес включить в стек новую технологию

— Их можно понять: работаешь себе тихо, спокойно — и тут приходит кто-то и говорит: а давайте всё поменяем! Насколько вообще всё это сложно пробивать? Как уговоривать стейкхолдеров, общаться с командой, чтобы тебя не отправили в игнор и не пытались выгнать?

— С айтишниками обычно договориться тяжелее, чем с бизнесом. Если подойти к архитектору компании, которая работает только на Java, и предложить попробовать сделать что-то на Python — скорее всего, вам выкатят огромную телегу аргументов, почему так делать не надо.

Архитектор старый, ему 40+, он не хочет шевелиться, а если вспомнить, что было пять-шесть лет назад, — это ещё и технически под запретом было. «Ты будешь платить новому штату? — возразит он. — Где я возьму тебе сотрудников на новый язык?» Это веский аргумент: когда нет людей, которые понимают Python и способны подхватить дело, если тебя, грубо говоря, завтра собьёт автобус, — всё и в самом деле выглядит рискованно.

Тем более что всё это ещё и в будущем необходимо поддерживать. И так будет практически по каждому пункту: споры с технарями — это всегда большие, тяжёлые и долгие холивары. Зато они очень хорошо помогают самому разобраться, действительно ли нужно проекту то, что ты предлагаешь.

Бизнес, как правило, гораздо лучше открыт новому. Говоришь ему: «На Java это будет неделю разрабатываться, а на Python я сделаю за два дня». И он начинает потихонечку взвешивать: «А давай пилот запустим». Начинает что-то предлагать. Если, конечно, это адекватный бизнес, который не просто пытается нагрузить тебя, а по-настоящему ждёт результата.

Люди из бизнеса очень хорошо понимают, когда показываешь им плюсы, объясняешь, как будет дешевле и быстрее. Тем более что порог входа действительно низкий и питонистов на рынке много: можно быстро взять любого и переобучить уже в команде.

Скажем, я просто запустил тестовый микросервис, показал, как он работает, как быстро для него выполняются задачи и тому подобное. И все вопросы отпали. Я вообще не люблю долго рассказывать: гораздо проще выкатить код, который сделает что-то сам и скажет сам за себя. Это самый действенный способ.

Почему низкая скорость — не проблема Python

— Ты говорил, что Python называют непроизводительным и медленным, но в целом это не проблема. Что ты имел в виду?

— Раньше и Java клеймили за то, что JVM медленнее, чем шарпы, по CPU-bound и прочим показателям. Сейчас эстафета перешла к Python. Но проблема-то не в этом, а в том, что CPU-bound-задачи — это, условно говоря, подсчёт попугаев.

В каких-то сложных задачах, расчётах, которые конкретно нагружают CPU, Python действительно медленный. Но если подумать: а сколько таких задач решает реальный бизнес? Практически ни одной — если, конечно, это не поисковик или ещё какая-то сложная система, где Python вряд ли будет полезен.

В остальных же сферах мы уже давно ушли на SaaS-микросервисы и тому подобные архитектуры. Я знаю компании, в которых уже по 200–300 микросервисов. И это российские компании. Я боюсь представить, что происходит где-нибудь в Netflix.

А на чём в основном держатся все такие экосистемы? На взаимодействии подсистем: input-output, задержка протокола, очень быстрое формирование каких-то простых данных и их отправка, поддержка идемпотентности, транзакционности и так далее.

И это всё нужно для того, чтобы поддерживать graceful degradation, то есть «изящную деградацию». Это означает, что мы разносим задачи на разные сервисы либо заставляем эти сервисы взаимодействовать асинхронно. Допустим, вы совершили оплату в какой-то системе, она не смогла провести транзакцию, а сервис уведомлений упал. И получается, что сервис оплаты прямо сейчас не может достучаться до сервиса уведомлений и вызвать триггер для отправки вам уведомления. Поэтому задача на уведомление клиента даётся асинхронно: когда сервис уведомлений починят, он просто разгребёт все накопившиеся в Kafka таски и выполнит их.

То же самое с тулингом. Python вообще-то немолодой язык, просто ругать его стали относительно недавно. А так ему уже 30 лет, он даже старше меня. И за это время комьюнити постоянно росло, обрастало тулингами. А чем больше инструментария, тем быстрее шлёпаются круды и тем меньше времени требуется на обучение разработчиков. А разработчики сегодня дорогие.

Сильные разработчики порождают слабые времена, а слабые времена порождают сильных разработчиков. Всё циклично. И я думаю, что сейчас такой переломный момент, когда все снова смотрят на какую-то статическую типизацию и говорят о проблемах, свойственных Python.

Python медленно работает в CPU-bound-задачах? Да, наверное. Но его спасает интерпретация. То есть мне не надо компилить и билдить приложение заново. Я могу его просто поправить на коленке и перезапустить. Перезапуск сервера на Python, каким бы тяжёлым он ни был, происходит за секунды. И это очень помогает в сборке приложений. Если мы живём в микросервисах, исповедуем twelve-factor-apps, мы сильно выигрываем во всём.

Есть, конечно, мем, где разработчик делает ошибку, которая заставляет каждого пользователя ждать на одну секунду больше. А потом эта лишняя секунда умножается на количество пользователей — и получаются астрономические человеко-часы, которые мы «потеряли». Но это некорректный анализ, потому что есть NPS, есть другие факторы для клиентов.

Мы не валимся по ошибке. И если нас забрутфорсят, у нас есть тот же graceful degradation, про который я уже говорил. А для тех моментов, когда действительно нужно «посчитать попугаев», — например, для каких-то тяжёлых сетевых вещей, — нам на помощь придут вещи из параллельного программирования: мы просто добавим ещё один интерпретатор, который выглядит как отдельный процесс в Linux, — и он возьмёт работу на себя.

То есть мы можем гибко параллелиться. И здесь гвоздём программы у Python, начиная с версии 3.5, становится асинхронное программирование. С его помощью в комьюнити происходит очень большое движение: начали писать просто неимоверные какие-то фреймворки, работать с сетью… Так что какой смысл упираться в язык, который будет «считать попугаев» на одну миллисекунду быстрее?

Почему корпорации выбирают Java и C#

— Если Python такой классный — почему тогда «глупые» корпорации сидят на Scala, на Java, на тех же шарпах? Почему шарпистов и джавистов на рынке до сих пор больше?

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

Да и сейчас лобби Microsoft никто не отменял: не секрет, что в каждой лаборатории Института кибернетики до сих пор стоят компьютеры, полностью нафаршированные майкрософтовским ПО. Хотя, конечно, и в те времена находились панки вроде меня, которые даже на «винде» использовали Java и прекрасно себя чувствовали.

Тем не менее программисты-олдскульщики ещё не вымерли, и они продолжат писать на том, на чём умеют. Кроме того, до сих пор остались задачи, которые лучше всего решать на шарпе. Например, у компании партнёрка с Microsoft, и крутится она только на Windows-серверах. Понятно, что нанимать такая компания будет строго шарпистов и никого больше. Но думаю, таких кейсов уже мало.

В общем, бэкграунд у серьёзных языков программирования до сих пор довольно толстый: это в основном большие, тяжёлые монолиты, где микросервисностью пока и не пахнет. Хотя сейчас всё отчётливее тенденция распиливать даже их, так что я бы не сказал, что шарписты с джавистами преобладают на рынке.

Например, весь «Циан» уже на Python — я видел их конференцию. Точно так же какие-то бэкенд-решения на Python пишут «Яндекс», «Сбер», «Тинькофф», Mail.ru, не говоря уже о моей «Точке».

У Python давно уже своя ниша. Python — это не про тяжёлый бэкенд, который будет собирать кучу бизнес-логики и потребует для работы четыре огроменных сервера. Наоборот — это нечто небольшое, лёгкое, гибкое, коммерциализированное. При этом диапазон применения очень широк: сегодня Python есть и в дата-инжиниринге, даже GUI-приложения на нём пишут. Хотя это, конечно, игрушки.

Основные же сферы применения Python в веб-разработке — это нетяжёлый бэкенд, e-commerce, всякие интернет-магазины на джангах, CMS и так далее. И существует очень много готовых решений. Например, просто подключаешь фреймворк — и получаешь CRM под ключ. Здорово? Здорово.

Точно так же есть куча скриптов для DevOps-специалистов или сисадминов. И с их помощью легко решать кучу задач. Потому что, если писать это на Bash, код получится очень длинным, да и поддерживать его потом будет сложно.

Наконец, есть даже дата-аналитика с мапом и редьюсом. Она, конечно, пока медленная, но она уже есть. Скажем, тот же Jupyter-ноутбук создавался как раз для исследователей и НИИ — как удобный интерфейс, в котором можно быстро проводить какие-то микрорасчёты, писать маленькие сниппеты. Ты просто пишешь код — и он работает.

Впрочем, голый Python практически нигде не используется: везде есть база знаний, best practice, свой тулинг. А вот обслуживающие сервисы часто пишут на Python. Они выполняют свою маленькую задачу, свою лямбда-функцию, как любят говорить функциональщики, и это хорошо ложится на продакшен.

Как Python стал популярным

— При этом Python чуть ли не старше Java, насколько я помню. Но Java давным-давно закрепилась на бэке, в энтерпрайзе, а Python жил себе и довольно долгое время никто его особо не замечал. А потом вдруг будто что-то перемкнуло в последние лет 10 — и Python из гадкого утёнка вдруг превратился в прекрасного лебедя. Хотя там, конечно, во многом заслуга C и Java, потому что не столько Python взлетел, сколько они в рейтингах упали. Почему так произошло?

— Мне кажется, это эволюция. То есть в 1990-х годах пересесть с Pascal на какую-нибудь Java было легко: синтаксис был другой, а принципы программирования — те же. Python же, как и РНР, был интерпретируемым языком. Но PHP по определённым причинам стал популярен чуть раньше, потому что сразу решал очень много задач из коробки для веба, а Python оставался в основном скриптовым языком на уровне Perl. На нём не было ни тулинга, ни зрелого инструментария, да философия была несколько другая.

Почему произошёл резкий скачок популярности при переходе с Python 2.7 на Python 3? Потому что в языке произошла настоящая революция, чего не может позволить себе Java. У Java обратная совместимость — что-то вроде культа, и язык тащит за собой наследие прошлого.

У Python же был путь и ниша скриптового языка, а потом что-то поменялось. Причём что-то поменялось, как мне кажется, в голове у Гвидо. Он решил пересмотреть всю концепцию языка и резко перескочить сразу на третий Python, закинуть туда всё то, чего в прошлом хотело сообщество, и выкинуть всё лишнее, избавиться от рудиментов.

И это обновление помогло: народ созрел для того, чтобы относиться к интерпретации нормально. К тому моменту уже и JS очень хорошо зарекомендовал себя на рынке. JS качал, и PHP качал, поэтому интерпретация уже не была таким страшным словом, а Python спокойно набирал обороты, обрастал тулингом, мясом, фреймворками, и его развитие резко ускорилось.

Я думаю, что это был чуть ли не единственный момент, когда такой резкий сброс повлиял на эволюцию технологии. Хотя в своё время то же самое сделали и шарпы: они очень резко перешли на .NET Core и тоже от этого только выиграли.

Сейчас шарписты набирают обороты на том же самом: они не пытаются тянуть за собой наследие прошлого, исправлять свои прежние косяки с помощью обратной совместимости, чтобы не потерять, как Java, свои знаменитые «три миллиарда устройств».

Они просто поняли, что сейчас мир живёт по-другому. Дропнули — и поехали. Для рынка это возможность. Потому что не всем надо быть прошаренными и рыться в кишках технологий. Некоторым достаточно уровня middle, где они могут просто быстро сделать себе сервис. Бизнес таких любит. Бизнес таким платит. И ждёт таких. Потому что это быстро, это не приводит к большим ошибкам. Там, где джавист уровня senior будет ковырять систему в течение недели, придёт питонист уровня middle и скажет: «Ха, я подключил Django, завернул всё это в Docker — и теперь у вас есть готовый сервис. Пишите бизнес-логику». И эта бизнес-логика будет писаться очень быстро.

— У Python есть разные реализации: классический CPython, JVМный Jython, есть MicroPython, реализация для встраиваемых устройств и микроконтроллеров. Для чего вообще нужны эти неклассические реализации и насколько они популярны?

— Jython в продакшене я не видел ни разу. И питонисты, даже те, кто пришёл из Java, обычно его чураются. Я понимаю, почему так происходит. Всё-таки мы говорим про язык.

Единственное, что пробовал я сам, — JIT-компиляция. Она неплохо ускоряет выполнение кода. Мы, в принципе, просто поменяли интерпретатор. Есть вещи, где в Python просто встраивают куски «сишного» кода, — это тот самый DSL. Я знаю точно, что половина библиотек в Python, которые требуют высокой производительности, написаны на C; большая часть из них даже требует установки GCC на компьютер.

Если нет необходимости что-то быстренько собрать, JIT-компилировать и так далее, проще пользоваться простым интерпретатором. Конечно, использовать какие-то альтернативные виды сборок с академической точки зрения по-своему прикольно: поиграться, посоздавать монстра…

Но это не бизнес-история: это усложняет проекты, затрудняет наём разработчиков, то есть сводит на нет два главных преимущества, из-за которых выстрелил Python. Это не наш путь — наоборот, нужно двигаться в сторону упрощения, увеличения коннекта айтишников с людьми не из нашей сферы, в сторону больших возможностей и большего количества продуктов.

Это абсолютно рыночная история, и очень показательная. Недавно наши технари сказали мне, что я уже мыслю больше как менеджер, чем как разработчик, который «за трушечку». И они правы: как технарь я понимаю: мне необходимо за минимальное количество действий сделать как можно больше импактов.

Поэтому мой ленивый мозг программиста склоняется к Python. Я хочу написать две строчки, я не хочу сидеть и ковыряться. У меня и так дома стоит Arch Linux, зачем мне ещё заморочки? И это такая философия.

Кстати, о философии — философия у Python тоже классная, The Zen of Python. Просто прочитав её и вникнув, уже невозможно кодить абсолютное дерьмо. Это будет как минимум тяжело: если ты прямо сильно накосячил, то у тебя либо память потечёт, либо просто ничего не взлетит, в runtime упадет. Настолько бинарно всё. Даже заранее компилировать не надо.

— Ты упоминал, что уровень абстракции растёт при переходе от С++ к Java, от Java к Python. Как будто бы среднестатистическому программисту уже всё меньше требуется понимать низкоуровневые концепции. Мог бы ты примерно охарактеризовать, что для каждой из этих технологий тебе казалось самым важным качеством разработчика или тем, на чём сфокусирован разработчик? На что приходилось обращать особенное внимание? И отличается ли этот фокус на Python от того, что было на Java, от того, что было на «плюсах»?

— На шарпах и в Java я больше задумывался над архитектурой и паттернами при написании кода. Я начинал с дизайна, а потом доводил этот дизайн до рабочего состояния. Всё на классах: как правильно наследовать, сделать нужную абстракцию, какой-то определённый интерфейс.

Всё это мешало и раздувало код до большого количества файлов. Не было каких-то best practice. Всегда были нетривиальные задачи: вот здесь мы поставим фасад, а вот здесь из этого фасада нам надо перекинуть какой-нибудь синглтон, чтобы сконнектиться с БД. И на самом деле хорошо, если разработчик об этом задумывается хотя бы немного.

Но в экосистеме Python всё проще: я могу написать пару функций прямо в runtime — то есть в Python Shell — и потом их рефакторить как захочу. Там ты можешь писать код, наживую подключать модули из проекта и в режиме реального времени вызывать разные фрагменты кода и функции приложения, не перезапуская его каждый раз. То есть сразу выдавать рабочий код с нужными мне алгоритмами.

Мне не надо писать классмейт — можно просто написать код, грубо говоря, одной строчкой, и не обвязывать это всё в инфраструктуру языка. По этому пути, кстати, пошёл Kotlin, где ты просто объявляешь функцию и запускаешь. И я думаю, что он этой штукой и побеждает. JS тоже движется в этом направлении.

Что ещё бросалось в глаза, когда я разрабатывал на Java? На Java очень плохо с совместимостью — именно когда ты тащишь какие-то определённые библиотеки, которые созданы не для твоей версии языка. Бывает, у тебя слишком устарела Java и тебе очень тяжело переходить на новую версию. Всегда что-нибудь вылезет в зависимостях.

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

В Java очень сложно, когда приходится компилировать большое приложение. Я запускал компиляцию и в лучших традициях всех мемов о программистах уходил гулять. Потом приходил и забывал, что я поправил. А ещё бывало, что на этапе компиляции ты пропустил какую-то ошибку в runtime — и компилируешь всё по новой.

Так что те, кто пытается мне объяснить, что минус Python в runtime, неправы. Потому что runtime есть везде. Runtime-error — это распространённая практика и в шарпах, и в Java.

Да, в Python я могу проверить кусок кода и убедиться, что он вроде как рабочий, но допустить где-то в середине ошибку, которую не отловит линтер. И это очень классная мотивация для того, чтобы писать тесты и проверять выполняемость кода, следить за тем, как значения переходят от одной функции к другой. Дебажить на Java гораздо тяжелее, чем дебажить на Python. Так, в Python я просто ставлю в середине кода ПГБ-пойнтер (точку останова) в терминале, запускаю код и прямо в том же терминале в runtime могу разбираться, как работает код, дополнять его.

Наверное, это всё-таки рабочая схема. Потому что я часто бываю невнимателен, когда пишу код. Я не люблю долго писать и думать над кодом, обдумывать архитектуру. В Python она модульная. Она такая, какой ты хочешь её видеть. А ещё ты можешь писать в разных парадигмах. То есть на функциональщине, процедурном или просто на ООП — сидеть, обдумывать всё это и строить какие угодно абстракции.

И тут не считается моветоном, если у тебя в одном модуле лежит класс, а в другом — просто куча функций. Это не вызывает баттхёрта внутри самого Python-комьюнити. Это нормальная история.

Как изучать Python и переходить с версии на версию

— А вот кое-что всегда казалось мне тайной. Смотри, язык постоянно обновляется — и как часто, с помощью каких ресурсов программисты поддерживают актуальность своих знаний?

— У Python восхитительная документация. Она объясняет всё. Я и сам Python изучил по официальной документации самого Python, не читал никаких книг, не проходил курсов, мне не нужен был YouTube, мне не нужно было ничего. Я просто открыл официальную документацию Python — и сразу понял, как с ним работать.

Она очень friendly и легко читается. В ней куча примеров, как что-либо использовать. Она просто отвечает на все вопросы, которые есть у разработчика.

Например, у Java очень много legacy и таких моментов, когда надо просто зарываться в исходники языка. И если ты не закопаешься в них, ты не поймёшь, как это работает. Другого выхода просто нет. Я и сам тратил на это неимоверное количество времени.

А в Python очень классная документация — она сразу показывает, что нового, что обновилось. С обновлением с минорной на минорную версию у разработчиков тоже нет проблем. Хотя могут возникать проблемы с зависимостями: например, в версии 3.7 появились дата-классы, которых нет в 3.6. Но по большому счёту, если проект не использует каких-то других библиотек, мы спокойно можем переехать с Python 3.6 на 3.10 хоть сейчас и код править не придётся.

Как-то я общался с джавистом. Он мне говорит: «Ну что, будешь обновлять Python сейчас?» Я говорю: «Да-да-да». Я меняю одну строчку в Docker-файле с «Python 3.6» на «Python 3.8». И просто нажимаю деплой. И оно деплоится. И работает уже на сервере.

И он спрашивает: «Чё?! В смысле?! А все где мытарства?! Где всё это?!» Я говорю: «А мытарства будут потом, когда я уже буду какие-то тулы обновлять». Хотя и с обновлением тулов проблем очень мало — разве что если ты переводишь какой-то массивный фреймворк с одного мажорного релиза на другой. Но это фреймворк, это не язык.

При этом, конечно, с Python 2.7 на Python 3.0 переезжать очень сложно, потому что это вообще разные языки с разной философией и разным инструментарием. Поэтому как-то странно сетовать: «Вот, вы с мажорки не переключаетесь никак, а вот мы на Java так умеем». Я говорю: «Так Python 2.7 и Python 3.0 — это вообще разные языки, и попробуйте со мной поспорить». Просто разные от и до, вплоть до интерпретаторов под капотом.

— Не было ли это как раз тем фактором, который отпугивает энтерпрайз? Например, крупные компании смотрят и говорят: «Ну, вот. А потом будет с 3 на 4 какой-то резкий перескок — и что мы будем делать?» У Java обратная совместимость на обратной совместимости сидит и обратной совместимостью погоняет. А здесь сообщество решит и скажет: «Всё, третий Python морально устарел, перескакиваем на мажорную версию». Да так, что там будет практически другой язык.

— В мире Java, если тебе надо обновить Spring, ты не сможешь его обновить из-за версии своей Java, потому что тебе надо обновить сначала Java, а уже потом Spring, — и вот тут у энтерпрайза начнутся такие же проблемы, как и с возможным в будущем появлением условного четвёртого Python, который будет коренным образом отличаться от третьей версии. Мне так это видится.

И ещё я не знаю точно, что планирует комьюнити и создатели Python по поводу четвёртой версии. Может, её и совсем не будет никогда. Может, будет просто ребрендинг — и четвёртой версией станет минорная версия. Я думаю, что с переходом на четвёртый Python все уже будут готовы переехать. Да и с 2.7 на 3 на самом деле не так тяжело мигрировать. Есть очень много гайдов, большое комьюнити. Есть те, кому не лень поддерживать Jython. Есть те, кому не лень поддерживать скрипты, которые помогают автоматически переносить проекты с версии 2.7 на тройку. Я один раз попробовал такие — было прикольно.

— Наверняка у Python и для этого есть своя библиотека, да ещё и не одна :)

— Кстати, внутри комьюнити, сколько бы библиотек не было, всё равно есть адекватное правило: «Не тащи библиотеку ради выполнения маленькой функции». То есть нет такой истерии, как у JS-разработчиков: подключать библиотеку просто на всё. У нас на review обязательно спросят: «Зачем ты тянешь новую зависимость?» — «У нас так это принято». — «Но зачем, если можно написать одну строчку?» И начинают работать по принципу бритвы Оккама. И мне нравится такая философия.