#16 Асинхронный Python / Python FastAPI / Python uv / Юрий Селиванов
Расскажи, каким образом ты пришел к тому, что стал ко-разработчиком Python?
Да, на самом деле, интересный вопрос.
Меня с Питоном познакомил мой ко-фаундер, с которым мы сейчас тоже компанию строим.
Мы с ним начали строить нашу первую компанию в 2008 году.
И тогда он обратил внимание на Питон, сказал, типа, вот мы сейчас будем строить новую
компанию.
Тут такой интересный язык разработки, давай на него будем смотреть.
Я прочитал книжку по нему за несколько дней, более-менее просто осознал, что это сейчас не
можно делать, и мы начали, собственно, шипить наше первое приложение на джанге.
И сразу поняли, что нам она не сильно заходит по многим параметрам, то есть нам казалось,
что можно делать гораздо лучше.
Ну и мы, естественно, стали пытаться делать лучше, стали делать свой фрейм-ворк.
И тут как бы сразу...
С первого дня, первой минуты я начал писать прям такой серьезный же битон, то есть с
метапрограммированием.
В общем, использовать все, что в языке есть абсолютно для того, чтобы сделать свой
фреймверк.
И в определенный момент у нас там был свой датаслой, собственно, библиотека, которой мы
общались в базе данных.
И в определенный момент мы заметили, ошибки, когда ты проверяешь есть у объекта атрибут
или нет, ошибки при этом все просто исчезают.
А вот так получалось, что нас динамическое программирование, нас там очень много всякого
кода вызывалось, мы не могли ошибку найти несколько часов.
Я подумал, ну это совершенно жить не дело.
Как так?
Мы просто сейчас выбросили там 4 часа дебага, вместо того, чтобы просто пойти посмотреть
на exception на экране и исправить ее.
Я пошел и написал...
Ну, не могу сказать, что злое, но сообщение.
Недружелюбное.
На мейлинг-лист Питона, как же так?
Что происходит вообще?
Надо это срочно исправить.
Написал патч, там буквально патч на одной или две строки СИ был.
Вот, и тут внезапно Гидо Ван Росом, создатель языка Питона, приходит туда, вот, Белл Третт
и говорит, да, что-то на самом деле, много раз уже эта тема поднималась, каждый раз мы
говорим нет, но вот, время пришло.
дело исправить.
вот, собственно, это был мой первый, самый первый такой вот первый мой момент в жизни,
когда я вот что-то в большой Open Source проект добавил своего.
Вот.
И потом, поскольку я уже испытал, что это такое, я стал обращать внимание на вещи, которые
мне не нравятся или на вещи, которые недоработаны.
Мне кажется, что я исправил пару-тройку мелких вещей.
Вот.
И потом был момент, опять-таки, благодаря работе над фрамиорком, мне нужно было
работать над API, который может понять информацию о функции в ее аргументах, дефолтных
значениях для этих аргументов, в общем всю информацию.
И я нашел на Python...
Я нашел все API, которые были в Python на тот момент, не нравились, но я нашел Python
Enhancement Proposal, так называют PEP в простонародии.
Я нашел PEP, который предлагал гораздо более продвинутый API.
и я попытался воспользоваться, но я понял, что он не работает, и я его переделал.
Ну и казалось бы, на этом все может закончиться, в определенный момент, тоже на
mailing-листе питона, где происходит все самое интересное всегда, кто-то спросил, а
давайте мы этот пап, собственно, либо закроем, либо доведем его до ума.
Кто готов взяться за это?
Ну, я читал этот тред, как раз написал, ну, я попытался его сделать, он не совсем
работает, но я понял, как сделать так, чтобы он работал.
Я начал этим заниматься, потратил это, наверное, где-то месяц, довел его до ума, писал,
собственно, Пеп, защитил его в дискуссии.
И там был такой довольно большой патч, мне кажется, 1200 строк, довольно такой сложный, и
его смёрзли, и казалось бы, всё.
Я немного расстроился, потому что я подумал, ну после этого вот ими аккорд-девелоперы
должны сделать по-любому, и чё-то никому это в голову мысль не пришла.
И ну я подумал, ну окей, ладно, может быть, может быть, когда-нибудь потом.
И где-то через год я пришел, как раз запускал новую версию Python и обратил внимание, что
вот API, который я добавил уже был немножечко протух, некоторые вещи мне надо было
поправить, я их поправил, один из core-developers эти патчи заметил и сказал, давай
короче, я тебе core-developer сделаю, мы должны были тебе это сразу вообще предложить.
И тут, конечно, энтузиазм снова появился, и мне сделали core-developer, и все было
замечательно.
И уже через год я приехал на специальный ивент, который называется Python Language Summit.
Туда приезжают, как правило, все core-девелоперы.
Ну, или все те, кто могут приехать.
Это единственное событие в году, когда все core-девелоперы, гарантированно, могут друг
друга увидеть и поговорить о чем-то.
Я приехал туда, я познакомился с огромным количеством людей, понял вообще, как работает
процесс изнутри, ну и потом меня уже втянуло конкретно.
И поскольку я уже узнал людей, я уже понимал, как работает проект, для меня заталкивать в
питон какие-то очень большие и сложные вещи стало гораздо легче.
То есть просто так добавить там какой-то огромный API или поменять синтакс из питона очень
тяжело.
Но когда ты знаешь людей и когда ты понимаешь, когда все работает изнутри, ты это можешь
делать.
тебя появляется такая superpower.
Вот она меня появилась в этот момент.
И с тех пор, как бы это было, мне кажется, 2014 год или 2013, я этим делом и занимаюсь.
Слушай, у на самом деле по пути появилась целая кучка вопросов, которые я тебе хочу
задать.
Смотри, первый, наверное, вопрос.
Ты так легко к этому пришел, что типа, ну вот я на фреймворке пишу, а тут раз и я, значит,
делаю патч, котором нехилое такое метапрограммирование туда затаскиваю.
Это же просто так не бывает.
есть далеко не каждый человек может это сделать.
Какой у тебя бэграунд был?
То есть как так получилось, что ты так легко туда вошел?
Ну...
Совсем ранний бэкграунд я закончил Баммонку как раз по теме, собственно, программирования.
Потом я приехал в Канаду, и моя первая работа, в принципе, последняя, после этого я уже
занимался своим делами.
Первая и последняя работа моя была в небольшой компании, которая делала программное
испечение для, грубо говоря, автоматизации продажи в сети Home Depot, и потом они,
по-моему,
продукт женерализировали и стали продавать его в Walmart, не знаю, что сейчас с этой
компанией же происходит, но они это дело писали на языке PHP, я этот язык знал и первая
работа в Канаде была моя именно такая, есть попалась такая работа, я на нее пошел и когда
я туда пришел, я понял, как бы уровень софта изнутри, немного
Так себе, его можно значительно улучшить, можно дженерализировать, можно тут еще очень
много всего построить.
Потихоньку я начал этим заниматься, и потом туда пришел мой кофаундер, будущий, с которым
я там и познакомился.
И мы с ним вдвоем эту систему разы, так три переписали.
И под конец то, к чему мы пришли, PHP напоминало уже очень очень очень отдаленно.
То есть вся бизнес-логика этого приложения описывалась в XML-файлах.
Почему XML?
Ну, потому что это был 2006 год, это был мейнстрим.
Вообще, нормально, но будет немножко странно смотреть.
Но у нас тогда, по сути, что мы сделали?
Мы сделали декларативное изокрограммирование свое собственное.
Он был в XML, но с помощью него мы могли описать полностью всю логику системы, и потом из
нее собиралось собственное приложение.
То есть мы...
по сути, генерировали код бизнес-приложения из декларации бизнес-логики, описанной в XML
файлах.
Довольно продвинутые подходы, делали мы это просто потому, что нам нравится, нас перло.
Но потом, когда у компании появились амбиции продавать это в Walmart и так далее, внезапно
выяснилось, что вот лёгким движением руки, поменяв 5 XML файлов, мы можем приложение
переформатировать на другую бизнес-логику.
И тут, конечно, от этого немножечко офигели, включая нас самих на самом деле, очень
сильно.
И на фоне этой эйфории, как круто мы сделали такой вот фреймберг, в котором можно
нетривиально без услуги очень сложного приложения.
В 15 уровнях только разного менеджмента были с разными уровнями доступа и так далее.
На фоне этой эйфории как раз мы с моим кафаундером и начали делать уже свой бизнес.
Мы попробовали джанго после этого, осознали, что джанго не тянет по сравнению с тем, что
мы на PHP сделали.
Это просто вообще как бы не там, а не туда.
Иначе писать свой фреймберг.
Ну и поскольку, по сути, предыдущая наша система, было такое метапрограммирование на
стероидах, для меня уже в мозгу были определенные circuits, которые были готовы к этому
метапрограммированию и просто брать из языка, активно лепить что-то другое, на что он не
способен.
Мы уже этому научились, нам это начало нравиться, и естественно, порыв был делать именно
это.
Ну вот мы и начали.
Хочется пошутить на эту тему, чем более ты остановился в тот момент, когда ты говоришь, мы
запустили бизнес и нам джанка не подошла, и мы начали что-то делать, что чем более
успешным ты остановился и проникал в сторону кор разработки, тем скорее всего хуже шла у
тебя бизнесовая штука, потому что, как правило, если ты делаешь свой бизнес, ты как раз
все дальше и дальше от разработки, Тебя все-таки тогда увлекло в development совсем.
Это очень интересный вопрос на самом деле.
меня про него есть несколько вещей, которые можно сказать.
Во-первых, MicroFounder, который тоже в принципе законтривил несколько вещей в Python, но
просто на порядок меньше, я.
Собственно, почему на порядок меньше?
Потому что он в это время толкал бизнес.
Пока у меня там были периоды, когда два месяца я мог, например, просветить Python в
определенные года.
В 2015-2016 для меня было нормально.
Три месяца в год потратили full-time на Python.
Но тут нужно понимать, что я обязан своей карьере очень многому этому.
То есть свой текущий бизнес, который я строю, на который привлек инвестиции, я смог эти
инвестиции привлечь, потому что у меня был профайл определенный в Open Source мире.
Меня знают люди, у меня есть уже track record со сложными вещами, которые я смог сделать.
И далеко не факт, что у меня бы получилось сделать...
начать делать то, что я делаю сейчас, если бы вот эта вот интересная дорога в сторону не
была, в сторону питона.
Это да, понятно, но при этом, я так понимаю, что тот бизнес, который вы пытались тогда
мутить, все-таки закончился.
Он закончился, да, но на пике его, например, нам пришел Pinterest и попросил помочь нам
оптимизировать их бэкэнд.
К нам пришел Microsoft и попросил нас написать...
Ну, по сути, мы сделали первую версию.
все среды для запуска питонного функции в Azure Cloud.
есть первые несколько сотен коммитов, написанных мной.
То есть в определенный момент, имя в Open Source поднимается до определенных величин, ты
начинаешь от этого получать очень очень много...
такой какой-то возвратки.
Но...
На тот момент, когда я этим всем занимался, я этого всего не знал.
есть мне просто сильно-сильно чесалось и хотелось сделать лучше.
И я в основном мотивирован был этим и только этим.
И на тот момент я, конечно, немножко переживал.
Как же так и так много времени тратим на Open Source?
Может быть, мне нужно больше заниматься время своим делами.
Но вот получилось как получилось, в итоге все получилось замечательно.
Я, кстати, подтвержу тут.
всегда как бы знаешь вот сколько я учу программистов работаю с ними то есть мы очень
толкаем людей к open-source приучаем постоянно делаем участвуем единственное в основном
прикладные какие-то вещи да но например у меня есть тоже такой маленький полуреквесты в
рельсу и было забавно что когда я это сделал это давно тоже было очень не кисло после
этого поперли сообщения в линк и везде типа из серии о выгодит контрибьютор давайте с вами
поболтаем
Это конечно очень мощно работает даже на гораздо более скромных объемах.
Это я специально говорю для аудитории, потому что сейчас многие посмотрят, скажут, о, до
такого уровня нам...
Не, ребят, бы ко-разработчикам не обязательно становиться, чтобы иметь бенефиты.
Нам с тобой нужно об этом поговорить на самом деле сейчас или как-нибудь потом, зависит от
тебя, но каждый раз, когда я приезжаю на кубик-инференцию, каждый раз встать в Россию,
когда я был в 2017 году на PyCon Russia.
Я активно всех агитирую начать Contribute, потому что для того, чтобы Contribute, тебе не
нужно иметь какие-то сверхмозги, более того, я не думаю, что они есть у меня.
Contribution может быть абсолютно разным.
Некоторые люди Contribute улучшают документации, некоторые добавляют тесты, некоторые еще
что-то.
Для всех найдется место, и не обязательно это делать в Python.
Но в целом я хочу сказать, что это, наверное, один из самых важных опытов в жизни
программиста.
Теперь, с высоты своих лет, могу сказать, один из самых важных опытов в жизни
программиста.
Это активно поконтребить в какой-то большой Open Source проект.
очень-очень важно.
Кстати, да, у меня есть гордость небольшая.
Один из наших студентов стал контрибьютором React.
Знаешь, что я хотел сказать?
Одна из интересных каких вещей...
Сейчас подожди, у из головы мысль вылетела по поводу Open Source и Contribute.
Ладно, я понял, что я потерял мысль.
Хорошо, поехали дальше.
Смотри, у нас на самом деле есть несколько моментов, да.
Мы с тобой обязательно частично еще к этому вопросу вернемся.
Но одна из главных тем, которые я предлагаю сейчас постепенно переходить, это, собственно,
вообще питон в целом как язык, да.
То есть скорее поговорить про него, про его изменения, будущее.
А, вспомнил, про что хотел сказать.
Короче, когда ты рассказывал, что ты Contribute-ил?
Ты это рассказал, знаешь, образом, что вот...
Я правильно говорю, Гвида его зовут, да?
Да.
А то я боюсь каждый раз.
Припуть я редко просто его имя.
Гвида...
Гвида Ван Рос.
Да.
Пришел Гвида, вы там поговорили, принял, тра-та-та.
У меня просто был недавно подкаст о PHP, да.
Парень, приходил, он тоже контрибьютор PHP, чуть более скромный, но все же контрибьютор.
И он как раз рассказывал про процесс, то, что PHP, очень в этом плане остался там, позади.
То есть там, где у них сейчас...
все это происходит, как отстроен процесс, и так далее.
И нам реально пришлось посвятить довольно большое количество времени именно самому
процессу.
То есть, чтобы просто прорваться туда и что-то сделать даже микроскопическое, это просто
какой-то ад.
И они сейчас пытаются это переделать, но это и до сих пор идет со скрипом, потому что там,
например, в команде много взрослых дядей, которые, ну, сам понимаешь, привыкли к
классическим подходам и организациям всего процесса.
Но судя по тому, что ты говоришь, как будто бы Python Community, видимо, очень быстро
рвануло вперед.
и процесс в целом как будто бы достаточно мягкий ну просто ты вообще не сказал ни слова
про то что ну надо было долго гадать кроме того что тебе надо было защищаться да то есть
как будто бы не так сложно как могло бы быть ну это на самом деле очень сложный вопрос я к
сожалению не знаю как работает у PHP я знаю что часть своих вещей они скопировали у Python
например процесс с PEP'ами у PHP это называется RFC я могу ошибаться
Конечно.
Но мне кажется, что они начали этим активно заниматься в определенное время, и именно вот
почему это Питон повлиял на них.
Как работает там что-то другое, я толком не знаю.
Я знаю, что в PHP есть большие организации типа Facebook, например, которые активно...
Плюс есть организация...
Ну, я уже не помню, как называется.
Которая, собственно, Zend, по-моему, да?
Которая продвигала Питон довольно много.
Потом Facebook начал активно.
тянуть на себя одеяло.
Поэтому там может быть какая-то динамика не такая, в Питоне.
В Питоне конкретно больших организаций за Питоном до сих пор нет.
Это полностью сообщество волонтеров.
И самый главный волонтер довольно долгое время был Гвидо.
И он, собственно, модерировал все как бы комьюнити кордевелоперов Питона.
И его личный взгляд на вещи всегда был такой, что чем больше людей придет, тем лучше.
И, соответственно, планка стать Coord developer, она на самом деле не какая-то
сверхвысокая.
Вас никто не будет спрашивать ваше образование профильное оно или не профильное.
Вас никто не будет просить, чтобы вас был идеальный английский язык, разговорный или любой
другой.
Все, что на самом деле было нужно и до сих пор на самом деле так, это просто желание
улучшать вещи и консистентно...
по крайней мере, поначалу, консистентно, собственно, контребитить, то есть фиксить,
исправлять проблемы, писать код или документацию или еще что-то.
Когда маленькая хотя бы группа людей начинает замечать тебя, замечают очень быстро, может
быть, после 20-ти, наверное, коммитов или что-нибудь в этом роде, они сами придут и,
скорее всего, скажут,
может быть ты хочешь больше этим заниматься, быть тебе надо как-то помочь, может быть тебе
нужно расширить твой круг интересов, что ты еще хочешь сделать и так далее.
То есть в целом Питон построен вот так.
И сейчас, мне кажется, даже чуть проще стало разобраться, как все это работает, чем когда
я присоединился к Питону.
Потому что после того, как я присоединился, через пару лет, например, сделали, собственно,
книгу Cordover Handbook или что-то в этом роде.
где рассказывают, как там стать, что это вообще такое и так далее.
Когда я всем этим начинал заниматься, я вообще не понимал, как это все работает.
Но что мне помогло, это просто посидеть на mailing-листе некоторое время и просто
посмотреть, о чем они говорят, как они говорят и так далее.
Ты просто смотришь, читаешь, учишься и потихоньку начинаешь чувствовать вообще какой вайп
этого как-нибудь, что там вообще происходит.
Мне вот это тогда помогло, я просто понял, что...
Но опять-таки у меня никогда не было цели стать именно кордовым опером.
есть у меня все время мое желание им быть материализовалось после того, я им стал.
Или после того, как я сделал там очень большое какое-то contribution, огромное.
Когда я уже взял там 2000 строк патч, сделал, написал пеп, ответил на 200 имейлов на
mailing-листе, защищая, объясняя, почему вот это API такое, не другое.
То есть я уже очень много своего времени, колоссально количество времени инвестировал.
Ну пару месяцев работы full-time просто по сути.
На тот момент уже да, я уже как бы окей, наверное, хочу быть кордевелопером, почему они
меня не делают, меня был вопрос.
Я же вроде много всего сделал.
Но изначально я шел не за этим, изначально я просто реально хотел улучшить вещи.
И мне кажется, что если ты с таким настроем придешь в любой другой проект, будь то питон
или реакт, или даже PHP, то это всего лишь вопрос времени.
когда тебя этим человеком сделают, тебе дадут чуть больше привилегий, когда с тобой
познакомятся все остальные, те, кто, ну, ключевые люди в этом проекте и так далее.
То есть тут все упирается исключительно в желание и в консистентное просто вот вовлечение
себя в то, что тебе интересно.
И это очень хорошая мысль.
А давай перечисли, то есть с тех пор прошло довольно много времени, да, ты до сих пор
являешься core-девелопером, я так понимаю, чуть меньше участвуешь, но участвуешь.
Перечисли, пожалуйста, вот вещи, с которыми знакомы обычные питанисты, которые ты сделал в
Python, не просто как бы списком.
Вот большой мой первый с вами пепп это был signature API, он в модуле Inspect находится,
то есть если вы пользуетесь signature API, его сделал я.
Я добавил в Python Async Await, я так практически...
переписал, наверное, AsyncIO.
То есть там очень много было изменений, которые пришли от меня.
Очень много новых API, которые я добавил в него.
Я добавил асинхронные генераторы в Python, я добавил асинхронные Comprehension в Python.
Я добавил модуль ContextBars.
Это штука, которая позволяет делать такой локальный контекст, похожий на локальный
контекст в тредах.
RedLocal переменные.
но эта штука заточена на AsyncAwait.
В принципе, я сделал дизайн для нового синтаксиза питона exception groups.
Это когда ты можешь accept звездочко вписать тоже для синхронного кода.
Ну, мне кажется, были еще какие-то вещи разные.
В определенный момент, например, у стал интересен перформанс Питона очень сильно.
Могу ли я его улучшить?
И я сделал пару оптимизаций, которые в итоге в Питоне работали несколько лет.
Сейчас они уже более грамотно сделаны.
Одна из оптимизаций, например, была в том, что когда программа на Питоне работает, каждая
переменная в нем, она на самом деле
она на самом деле интерпетатором ищется в локальном дикшнере, это тот, который,
собственно, тело твоей функции, например, все локальные перемены лежат в определенном
объекте дикшнере.
Глобальные перемены тоже лежат в глобальном дикшнере, и перемены твоего модуля, в котором
ты работаешь, все это на самом деле дикшнериз.
И есть определенные правила, по которым интерпетатор видит ими переменной.
и пробегает по ним и ищет их.
И я сделал оптимизацию такую, которой он не искал больше.
То есть он запоминал просто место в памяти, где значение этой переменной находится.
И полностью весь этот оверхед практически убирался.
Вот, я, например, сделал это изменение, и похожие изменения я сделал для attribute lookup.
То есть когда у тебя ты пишешь в питоне self.a, например,
обратиться к property.a.
Я сделал похожую оптимизацию, которая на уровне объекта запоминала, а где, собственно, a
будет.
И в следующий раз, ты спрашиваешь, а тебе же надо бегать по дикшн-рис и искать его там.
Ей это, по-моему, дало процентов 10, наверное, ускорение питона в сумме, этих изменения.
Но зашипились они не за один раз, они как бы сначала в одной версии было одно, потом в
другой версии добавили другое и так далее.
Но в принципе, вот как бы...
идею, наверное, оптимизации чего-то на уровне как бы виртуальной машины питона, наверное,
я начал.
По крайней мере, я сделал первые патчи, которые туда приземлились, которые делали именно
вот эти принципы, эти оптимизации.
Теперь я перфомансом занимаюсь, там гораздо более сложный проект теперь вокруг всего этого
образован.
Вот, ну вот тоже, например, один из моментов, что я делал в питоне.
Плюс как бы в первые, наверное,
Вот до того, я с NKU начал заниматься серьезно, я обратил внимание, что нужна помощь с
документом, который называется What's New.
Каждый раз, когда Python выпускается, у него есть большой документ What's New.
И сейчас Cordova Loper очень организованно, на самом деле, добавляют туда сами информацию,
каждый раз, когда они добавляют новые фичи.
Но раньше этого не было.
И в определенный момент я увидел, что некому этим заниматься, я просто взял и,
собственно...
перелопатил все комиты за два года и составил документ вот с Нью сам то есть расписал что
в питоне нового что в питоне появилось привлекли этого кстати вот бизнес партнера Элвиса и
вот вместе мы вот это сделали и потом нас попросили люди делать это еще пару раз и мы
делали еще раз и тоже за это пополнили свои хранилища кармы довольно неплохо сейчас
наверное чат gpt все призывают для того чтобы проблему решать или еще нет пока
Ну, я думаю, что от GPT помог бы сильно.
Но опять-таки через коммиты пришлось бы смотреть, скорее всего, самому.
Слушай, ну вот прикольно.
На самом деле это, конечно, сумасшедший объем того, что ты рассказываешь и фичи, да, и как
это повлияло на остальных, там, те же самые сингабейты.
Кстати, правильно я понимаю, что из C-sharp вы это адаптировали?
Ну, и да, и нет.
То есть, да, C-sharp, безусловно, меня был...
на уме, когда я думал про Sync Await, но я добавил пару вещей, которых не было нигде.
есть одна из них, это...
Python есть так называемая штука, штука называется Context Manager.
Это with блок.
Ты можешь написать, например, with transaction.
И дальше все, что внутри этого блока будет работать.
И если, например, произойдет ошибка, то транзакция в базе данных откатится сама собой.
Это вот позволяет делать протокол Context Manager.
И я сделал асинхронный вариант context-manager, то есть в питоне можно писать async with.
И насколько я знаю до сих пор этого нигде нет, может быть уже появилось, но в 2015 году не
было никакого языка программирования, где такая тема была бы.
Я добавил асинхронный тератор протокол, то есть можно писать async for, то есть не просто
for loop, а асинхронный for loop.
И идея была в том, моя основная мотивация была в том, чтобы можно было, например, сделать
датабейс курсор, который открыт.
в базу данных, и, соответственно, если он стянул там 200 строк, то он будет через них
быстро проэтерируется.
Когда в следующий раз ему нужно будет еще 200 стянуть в буфер, он сделает ассимпромный
запрос.
И, соответственно, Async4, новый протокол, позволял это делать.
То принципе, как бы я так добавил в него немного своего, вкусовщины, то есть...
Это была, наверное, первая...
первый момент, когда я так серьезно думал, какой Syntaxys лучше.
То есть AsyncAwait сам по себе понятия, но вот, например, AsyncWidth и AsyncFor, там есть
уже небольшое определенное пространство, потому как ты можешь конкретно задизайнить
протокол вокруг этого всего, как ты можешь задизайнить, собственно, сам Syntaxys, как он
будет работать.
И это было очень-очень приятно и интересно этим заняться.
Это, знаешь, особенно, учитывая, не могу не сказать про эту штуку, у Питона, наверное,
синтаксисом вообще отдельная попоболь из-за перехода со второго на третий, да, такое, я
уверен, отношение к этому чуть более серьезное, чем может быть в других языках, потому что
это до сих пор и кает, наверное, Грида.
Там вообще все интересно, получилось на самом деле, то есть да, на тот момент как бы всех
была паника в Питоне, что как бы Питон 2.7 все еще доминировал очень серьезно, и Питон 3.
все воспринимали как что-то, у чего не хватает мотивации, грубо говоря, на миграцию.
И в принципе, считаю, что у Питона было две фичи, которые сильно помогли с переходом на
версию 3.
И это не мое мнение, это мнение в том числе, например, того же самого Гвида.
Первая фича — это была синько вейт.
Потому что в тот момент...
Я прям помню, как это произошло.
Я предложил эту фичу на Пайконе, там было очень много людей из Инстаграма и Фейсбука,
программистов.
И когда они услышали, что мы хотим добавить AsyncAwait, у них загорелись глаза, они
сказали, как только это будет, мы будем все переписывать на Python 3, потому что вот у нас
есть AsyncAwait в нашем PHP диалекте Hack.
У нас весь Facebook написан на этом, и если будет в Python 3 AsyncAwait, то все, просто
вот завтра начинаем мигрировать.
И тогда стало понятно, что, короче, тут за этой идеей что-то интересное стоит.
Это мотиватор.
Второе большое изменение были fstrings в Python.
Казалось бы, но...
для огромного количества людей это был гигантский мотиватор собственно мигрировать на
Python 3 но вот Python 3.5 это был релиз, которым появился AsyncAwait и мне кажется, что
это был какой-то такой большой свежий воздух, грубо говоря, в Python, потому что это
большое интересное добавилось и люди резко стали им интересоваться а по поводу того, как
это все произошло, это все произошло довольно интересно, это все произошло за...
подошел Гвидо с этой идеей за два месяца до фичер-фриза Питона 3.5.
Вот, эта идея была идеей.
То есть просто мне пришла в голову, а может быть мы сделаем Async-Await в Питоне.
Я ему это рассказал, и он сказал, давай.
И я помню тогда, в принципе, чуть ли не как сейчас, что, собственно, этот Language Summit,
где этот разговор состоялся, он был в Монреале, в Канаде.
И я сел на поезд.
и поехал в Торонто.
И на этом поезде я как бы открыл лэптоп и стал, собственно, хачить SYNCOVATE в
интерпретатор.
За 4 часа, мне кажется, всё, чего я добился, это я вспомнил более-менее сисного, потому
что на тот момент я довольно долго на него не писал, я вообще более-менее осознал, где в
проекте что за что отвечает, а потом меня какой-то включился гиперфокус, и я два дня не
спал, я просто взял и за два дня сделал полностью рабочий прототип этого всего.
в принципе, я SYNC-Await работал вместе с Async-With и с Async-For.
Первый прототип я сделал реально за 48 часов не спя.
Отправил это Гвида, Гвида это неделю игнорировал, что навело меня на мысль, что может быть
поспать все-таки стоило.
Но потом еще где-то в две недели мы сражались, и в основном основная была, основной
комментарий у многих core-developers был, что вообще происходит, вы что делаете, вы
добавляете там...
Куча нового синтаксиса, новых протоколов, это гигантский Пепп, самом деле, который меняет
язык очень сильно.
И вы его пытаетесь засунуть реально за последние вот, чуть ли не две недели уже осталось
до фичер-фриза полного в языке.
Но Гвидо, вот он прям ему сильно понравилась эта идея, и он меня через весь процесс
провел.
Мне кажется, что меня где-то 500 имейлов было отвечено, то есть я ответил на 500 имейлов,
когда вот вот вся тема была.
То есть это была прям, ну, такая мощная работа.
Ну вы прям пошли этот в обход так сказать процессов, я так понимаю.
Это очень сложно себе представить, что где-то ты мог бы так вот настолько сильно пойти
поперек всех.
Ну реально новый синтакс, если изменения там что-то на двоих порешали, все остальные в
шоке, наверное сидят с квадратными глазами типа, ребят, что происходит?
Это работает хорошо, я собственно создатель языка программирования сильно этого сам
захотел.
Это работает только в этом случае, Ну да.
кстати.
Это невозможно было бы представить себе.
там корпоративном языке типа Java.
Они бы это делали несколько лет скорее всего.
Кстати, вот такое просто последнее сравнение.
Мне почему-то я не знаком ни с Gvid, ни с Linux, но вот стороны Gvid для Python то же
самое, что Linux для Linux.
Как будто бы похоже.
Может быть есть, наверняка есть очень много параллелей.
У них очень разная personality, то есть Gvid это очень открытый и на самом деле...
не сказать ничего лишнего.
Ну, в общем, да, это очень открытый человек, который старательно следит за тем, как он
общается, и очень старается сделать так, всем в Cordover community было более-менее, грубо
говоря, хорошо и комфортно.
То есть иногда он этим не справляется, иногда справляется лучше, чем нужно, но в целом его
фокус заключается в том, что он делает язык для людей,
И он очень сильно хочет сделать так, чтобы комьюнити было человечным.
У Линуса я не уверен, что мотивация человечности где-то присутствует особая.
У меня, безусловно...
Истории много.
Да, у меня нему глубочайшее абсолютное уважение.
То есть это такое божество, грубо говоря, для меня в компьютерсайенс.
Но я не думаю, что с Линусом Торвальдсом очень комфортно работать.
По крайней мере, первые несколько лет пока ты с ним...
если что, ты ним пересекаешься.
С глида, наверное, наоборот.
есть не могу сказать, что он прям совсем ко всем открыт, но если он видит, что у тебя есть
прям драйв, улучшить питон, и если ты более-менее понимаешь, что ты делаешь, то он будет
тебе всячески помогать и содействовать.
Окей.
Я хочу плавно перейти к теме, знаешь, именно питона для прикладных разработчиков, потому
что мы сейчас тобой говорили очень много про твою вот эту историю.
наверное я начну с самого высокого уровня вопроса, а дальше мы уже там будем смотреть,
нырять и так далее.
Что вообще грубо говоря происходит?
То есть вот когда мы там например обсуждали ноду, то есть меня вот было по ноде, по PHP
там, ну знаешь PHP например там на spud, типа будущие изменения, тратата, например там по
ноде, там есть тоже определенная история, что GS на на back-end, ну не набирает той
популярности, которую хотел, а вот с Python, когда я задаю этот вопрос,
такое ощущение как будто бы Python на подъеме находится у него причем как будто несколько
таких было пиков и вот сейчас он снова находится на таком и него вообще все хорошо и никто
не парится или я не прав?
это сложный вопрос я не могу сказать что я мировой эксперт в traction языков но пару
мыслей я скажу во-первых да есть ощущение что Python на подъеме не везде
То есть, например, мне кажется, что веб-девеломент конкретно проседает, потому что
появился TypeScript, потому что появился React, потому что появился Next.js и еще куча
разных интересных фреймворков, и стало комфортно писать небольшие веб-приложения на
JavaScript.
И часть, ну, 100%, часть пользователей это отъела у Python.
Django, конечно, комьюнити в первую очередь.
Ну, я думаю, Django и, может быть, каких-то других комьюнити, которые начинали
образовываться.
Это с одной стороны.
С другой стороны, например, есть фронтверк Fast API для Python, вокруг которого абсолютно
какое-то несоразмерное бурление сейчас происходит.
есть он очень очень активно, он везде.
И, например, здесь силиконовое долине, огромное количество стартапов строятся на Fast API.
То есть, безусловно, какой-то отток в node community произошел.
Но сказать, что произошел он полностью есть, наверное, нельзя.
Что по-настоящему для Python работает?
Data science и machine learning.
Так уж и получилось, что огромное количество машин-лерни-библиотек и
дейт-эссеннез-библиотек на Python доступны или их делают доступными как можно скорее.
И поскольку это язык гораздо проще, чем C++, то большое количество людей хотят
пользоваться для написания рагов, программирования всяких пайплайнов для LLM и всего
остального.
ну и в том числе классического data science.
Не будем зацикливаться исключительно о ламах.
Правило, ну не правило, а закономерно заключается в том, что на самом деле мир активно
цифровизируется, и мы на самом деле все еще в начале этого процесса.
Может быть, многим кажется, что это не так, многие думают, что есть айфоны, апсторы,
фейсбуки, инстаграмы и тиктоки, но на самом деле мир очень очень слабо цифровизирован до
сих пор.
огромные Fortune 500 компании и так далее до сих пор только в начале этого пути, на самом
деле.
У многих очень очень отставшая инфраструктура внутри.
И на самом деле количество кодов в мире, которые надо выкинуть и переписать, оно просто
зашкаливает все, что можно зашкалить.
Поэтому я бы не сильно волновался за то, что программисты скоро станут не нужны из-за чата
GPT или еще что-то в этом роде.
На самом деле работы хватит и на чат GPT, и на обычных программистов, потому что огромное
количество станут переделать.
И так же получается, что когда ты софт переделываешь, в наше время стало понятно, что ты
не можешь бизнесом руководить, и ты не можешь бизнес строить, если тебя нет очень четкого
понимания обо всех данных внутри твоего бизнеса.
И если ты хочешь эти данные обрабатывать, то...
скорее всего, то, чего ты дотянешься первым, будет Python.
И так и получается, что Python на самом деле это тот язык, на котором можно делать не
только данные, обрабатывая, так на, не знаю, на языке AR, например, на котором можно и
website запилить, и много чего другого построить.
И вот я думаю, это основной драйвер сейчас роста Питона.
Это то, что всем, абсолютно всем нужно работать с данными, абсолютно всем нужно строить
pipeline для анализа данных и так далее.
Плюс сейчас LLM на подъеме, AI на подъеме тоже Python для этого замечательно подходит с
учетом всех библиотек, которые он поддерживает.
И мне кажется, что то, что Drive сейчас рост Питона безумно сильно и в том числе не
позволяет вот именно Web Development части Питона просто написать приложение и умереть,
потому что многим людям это по-прежнему нужно, поэтому нет такого, что можно сказать,
например, что вот Node.js победил и теперь все Web Publications будут писать на Node.js.
Ну, в самом деле не так.
потому что если тебя огромное количество приложений уже написано на Python или что-нибудь
в этом роде, ты скорее всего с ним останешься и будешь только Frontend JavaScript писать.
Надеюсь, мою мысль можно было отследить, но в целом ответ на твой вопрос, да, Python на
подъеме, кажется, и мне кажется, что он будет на подъеме еще очень очень долго, потому что
самое главное сейчас, наверное, стезя Python'а, это дата-анализ, machine learning и так
далее, она будет просто экспоненциально расти.
есть при этом интересная вещь.
я могу узнать с какой стороны на это посмотреть и сказать.
То когда мы говорим про эти направления, мы же во многом говорим не совсем про
программистов.
То есть там Python как бы это все хорошо.
О, кстати, знаешь, чего я сейчас заметил?
Ты же говоришь Python.
И это так забавно, потому что огромное количество людей, то есть представляешь, то есть ты
там core-разработчик, да, настолько близок, и ты не паришься, говоришь, Python.
А куча людей включают этот GrammaNation режим, что надо правильно говорить только Python и
так далее, при этом они, естественно, в него не контрибьютили.
Это так, просто ремарка.
Да, тут надо еще понять, что, как бы, на самом деле, больш...
Ну, как бы, моя речь в разговоре именно рабочим, она исключительно на английском языке.
И там, естественно, Python из Python.
Вот.
Но в русском языке это все как бы сфонировалось чуть ли не со студенчества.
То есть, как на первом курсе университета я узнал про язык Python, так оно меня
заимпринтилось в мозг.
так оно теперь там и живет.
И язык не поворачивается мне сказать Python по-русски.
Более того, как бы, а как же все смешные шутки, да, которые можно делать с питоном, это
гораздо веселее и приятнее.
Ну, и надо понимать, что питон – это питон на английском.
Так что да.
Мы когда учим питону, у нас есть несколько аспектов, касаемых каждого языка, и питон
немножко отличается.
Вот, например, когда ты учишь PHP,
На самом деле гораздо проще, потому что ты понимаешь, это скорее всего веб-разработка, и
когда человек смотрит на вакансии, он видит 1000 PHP вакансий.
Он подойдет под все эти вакансии почти наверняка.
Понимаешь, С Python или Python.
Блин, меня реально переучили на Python, ну ладно, как поучить.
Может, перелихо хочешь.
Да-да-да.
Ну просто я, знаешь, я был сначала Я точно не грамотен.
Да, я такой Python, Python, Python, Python, а потом меня задрали все, я такой, ладно, буду
Python говорить.
Так вот...
С ним другая ситуация.
И я всегда про это рассказываю, когда меня спрашивают.
Я говорю, ребят, с ним есть очень сложная штука, что когда вы смотрите на популярность,
во-первых, сразу, наверное, процентов 25 надо отрезать.
Это типа институты.
Ну типа как-то так получилось, что Питон захватил весь мир в этой штуке.
Это, кстати, вот иногда там говорят, это объективно.
Я не очень согласен, что это объективно.
Любой другой язык мог бы быть на его месте.
Более того, и был.
Это вопрос разных случайных факторов и так далее.
Питону повезло, и он там, и это круто для него очень.
Но это очень сильно помогает.
У есть теория, почему на самом деле.
Да?
Ну-ка давай скажи, а потом я продолжу вот про эту штуку.
Мне кажется, что ну по моему личному опыту, он может не совпадать с другим опытом других
людей, но мне кажется, что начинать например программирование с Си, ну ничего в этом
совершенно плохого нет, но есть огромное количество вещей, которые
которые знать не обязательно с первого дня.
То есть memory management, как работать с указателями, что это вообще произойдёт, очень
такой низкоуровневый язык программирования.
И с другой стороны, есть, например, более высокоровневые языки, там C++, и там
достаточно...
Ну, там просто...
не знаю, это по-русски сказать...
просто кошмар, на самом деле.
Сколько всего там есть и насколько оно всё...
перекособоченные местами.
Соответственно, Python на самом деле позволяет людям ощутить вообще кайф от
программирования, потому что тебе не надо думать об указателях, о памяти.
Ты больше понимаешь, как вообще работает программирование.
На мой взгляд, чуть ли такой самый идеальный текст-интерфейс, когда ты можешь в машине
объяснить, что нужно делать, что нужно читать.
Может быть, медленный по сравнению с C.
Но он позволяет тебе почувствовать вообще, это такое.
Начать пользоваться функциями, может быть, какими-то потихоньку объектами, посчитать один
плюс один и сделать это очень быстро и просто.
В Python есть REPL, то есть ты можешь запустить Python и прям вот вбить какой-то
expression туда и поэкспериментировать с ним.
Вот, не надо компилировать, просто берешь, запускаешь программу, она работает.
То есть в целом вот именно...
как язык для первого ознакомления с программированием, кажется, идеальным.
Потом, когда ты уже осознал, что такое программирование, безусловно, нужно знать C, на мой
взгляд, просто хотя бы курсорно, хотя бы чуть-чуть, понимать, как работает все изнутри.
Но как первый язык для первого знакомства с программированием, кажется, Питон
замечательный язык.
Он, в отличие, например, тоже JavaScript, ты не можешь, например, Питоне добавить один к
строке.
То есть у Питона очень правильная таблица операторов и так далее.
есть него правильный баланс, мой взгляд, вещей, которые можно делать и которые нельзя
делать.
Хотя ничего против JavaScript как первого языка я бы тоже не имел.
Мне просто кажется, выскоуровневые языки для этого подходят меньше, чем выскоуровневые
языки.
Это правда.
Я скорее сравниваю с динамикой разной, плюс, например...
есть же еще Леспы, еще Ирланд, есть еще куча всяких языков, которые очень раскоурдические.
экологические в этом их проблемы, да-да-да.
В институтах проблем совсем особо нет, вопрос в скажем, я за то, чтобы они тоже
присутствовали в любом случае, независимо от того, что там Python или нет.
все-таки тут не могу не сказать следующего, несмотря на то, что вот если прям совсем
объективно Python действительно у него сильная типизация, это лучше, чем в JavaScript, в
остальном они, кстати, очень равна...
Ну очень похожий, плюс эта часть частично линтерами фиксится или даже целиком сейчас, да,
то есть поэтому можно не париться.
Но у меня скорее всё-таки знаешь какой поинт, так же как и Linux победил FreeBSD не потому
что он был круче, да, то есть всё-таки вот на таких масштабах такие вещи работают
исключительно потому что где-то пошёл пиар.
Это не обязательно, потому что вы это сделали конкретно там с гвидо, возможно в каком-то
универе был какой-то маньяк или понимаешь там, как это часто бывает типа...
какой-нибудь еврокомиссии, там мой друган программист сказал питон самый классный язык и
мы соответственно его внесли в списки там ну понимаешь да я просто в системе образования
поскольку меня есть свой собственный колледж я не понимаю как такие вещи делаются там
никакой объективщины не существует то есть это не работает по принципу о смотрите питон
объективного список знаешь лучше всех вот неважно какой ты стране находишься вот а так ну
да в любом случае он победил как бы что имеем то имеем а вот дальше я хотел сказать что
Когда мы говорим про большинство вещей, которые ты сказал, которые толкают Python, это в
первую очередь не программисты, и Python там, конечно, хорошо, но типа там гораздо больше
других знаний, которых должно быть.
И получается, что, опять же, если мы про вакансии говорим и вообще про язык, то получается
довольно интересно.
Человек такой учится, ну такой, я думаю, буду программировать на Python, Остальные вещи он
как-то там себе так фантазирует, как прикладнуха.
Это просто, опять же, то, что я учу программирование, я это постоянно наблюдаю.
Человек учится, учится, учится, потом идет, смотрит вакансии или пытается понять, и вдруг
он для себя сознает, у тебя, например, пять тысяч вакансий, из них мы там и начинаем
отрезать, у тебя, во-первых, админских вакансий сколько?
Ну, наверное, процентов 20, наверное, будет.
Потом у тебя там дата-аналитика половину сразу срезали, частично там вот машинное обучение
тра-та-та, и, собственно, само программирование прям вот, прям питон, как язык, это, как
правило, все-таки веб или, ну, не обязательно веб, но близко к этому часто вся эта
история, очень маленький процент.
Вот ты так отбиваешь или нет?
И сложность именно в том, что как бы учить Python просто чтобы типа я вот вами
программировать сложнее гораздо, многие другие языки, потому что вот Go скорее ты уйдешь
учить и ты будешь программировать на Go как бы ну что там все сервисы херачат, Там на PHP
понятно веб, на JSE тоже более-менее понятно, хотя там разнообразие есть.
А вот Python капец слишком разный.
Вот очень много совершенно параллельных миров.
Ну вот у меня такое впечатление про Python.
Университетская среда, аналитическая среда.
Не знаю, может быть.
Может быть, это действительно так.
Я, честно скажу, на эту тему никогда не думал.
Не задумывался.
Сейчас вот я не задумываюсь и думаю, что как минимум есть два пути параллельных.
Это Data Science и веб-приложение на Python.
Они не пересекаются вообще.
Там есть свое ответление в них тоже.
То есть, например, веб-приложение, это может быть Django, который вполне себе до сих пор
используется.
Или, например, какой-нибудь там Fast API современный, который выглядит очень-очень и очень
по-другому.
И с другой стороны, я думаю о том, что люди, которые идут в Data Science, это не простые
программисты.
То есть у них конкретное, скорее всего, образование математическое или физическое, они
идут делать очень конкретную работу, тоже...
Программирование там больше используется как инструмент для анализа данных, не более того.
То есть от них никто не ожидает какой-то...
совершенно красивый поддерживаемый код.
От них решают, от них ожидает больше.
Реши проблему как можно быстрее.
Покажи нам анализ этих данных.
Поэтому, честно говоря, я не знаю.
Может быть, прав.
Может быть, не до конца.
Но так чисто абстрактно учить питон, я тоже не знаю как.
Наверное, нужно учить все-таки конкретно.
Надо научить, нужно поставить тебе какую-то цель.
То есть, если, например, твоя цель это...
какой-то машин-лернинг-модель запинать или еще что-то в этом роде на TensorFlow, ты
пойдешь одной дорогой к Python, и, скорее всего, у тебя будет абсолютно параллельно на
язык Python.
Тебя будет волновать...
Да, Гораздо другие книжки.
Да, тебя будет неслительно волновать, вообще, как данные обрабатываются, тебя будет больше
волновать на фреймворкс, с которым ты работаешь, и библиотеки, чем язык, который тонким
слоем размазан между ними.
С другой стороны, если ты, например, пойдешь учиться веб-приложение писать на Fast API,
тебя будет совершенно другая траектория разработки, которая тебя может вывести в
совершенно разные места.
Ты можешь остаться до конца веб-разработчиком или, например, тебя может дернуть, ты
начнешь какой-нибудь суперсложный бэкэнд писать на Python и свои собственные фрейм ворки
разрабатывать для того, чтобы это получилось.
Поэтому, поэтому да.
Как, кстати, пример бэкэнда, знаю, интересно, что ты про это думаешь.
Один из таких известных питаниячих проектов, где ребята, ух, заморочились, это Wargaming
был.
Помнишь, когда они стреляли и они рассказывали, я не знаю, просто я знаком был с ребятами,
мы на конфах встречались, они рассказывали очень интересные вещи.
Знаешь, какого плана, например.
Они же игрушку писали.
Кстати, ассинковоидов тогда не было.
У них что там, Select был, наверное, да, что-нибудь в таком духе.
Короче, смысл в том, что...
они отключали «Горбаш коллектор» и что-то там еще делали, какое-то сумасшедшее.
То есть на тот момент Питон вообще был неспособен делать то, что им надо, и они там его
как-то выкручивали.
Вот мне казалось, они 100 % должны были с Core-девелперами это все прорабатывать.
Но возможно.
Это было даже раньше или ты не...
Я не знаю про них ничего конкретного, но есть одна из...
Мне кажется, имя этой игры знает, слышал каждый.
Игра называется Eve Online.
эпический космический симулятор мало кто знает, но написано весь на питоне вот и там
применяется fork питона, называется stackless python который по сути что он делает есть
фреймвер для питона, называется g event он сейчас уже наверное умер полностью или в
процессе туда в ту сторону вот
Да, это был фреймёрк основной для такого асинхронного программирования до AsyncAwait и до
AsyncAware.
И вполне возможно, вполне возможно, спекулирую сейчас, но эти ребята использовали просто
же самый статус Python и сделали, может быть, похожую архитектуру, которая была в EVE
Online.
Потому что EVE Online, несколько миллионов игроков и сейчас, я думаю, есть каждый день, и
них как-то так получилось, что нет проблем с келлидпитоном.
Очень часто люди говорят, что Python не скелется больше трех пользователей одновременно,
но на самом деле это не так.
Ой, все эти разговоры, смешно даже.
Я просто никогда на них внимания не обращаю по поводу скелется-не скелется.
Кстати, а вот знаешь, что интересно, вот AsyncAway там есть.
Я бы хотел немножко сравнить его с JSON.
В каком смысле?
даже не беря в расчет, что ассинковейты там немножко по-разному работают, да, а может быть
сильно по-разному, тут я не готов, наверное, глубоко откопать, но что я могу точно
сказать, есть интересная штука, в этом смысле получается они все-таки довольно сильные
конкуренты сейчас, да, то есть в принципе и то то можно выбрать, чтобы решать эти задачи.
И мне всегда значило было интересно, у меня есть опыт вот именно такого, еще до
ассинковейтов на Ruby, и там всегда была проблема у тебя, что
Если тебя сам язык по себе синхронный, а в нем вот типа есть синхронная часть, и
соответственно тебе event loop надо отдельно запускать, да, у тебя есть во-первых много
версий библиотек, такие и сякие, а вторых ты в любой момент можешь тупануть и вызвать
что-нибудь синхронного, сломав к чертям все.
И JS как бы тебя от этого в общем-то защищает, то есть ты по дефолту, то есть ты на нем
пишешь, понимаешь, да, вот мне интересно, это действительно так или не так на практике,
насколько это проблема, если это так?
Это сто процентов так.
Джова Скрипт, поскольку у него заход через браузеры был и так далее, он всегда был
ивентно-ориентированным языком, и Async Await в Джова Скрипте работает очень по-другому, в
отличие от Питонова.
Они очень похожи внешне, но именно внутреннее различие довольно серьезное.
Да, в Джова Скрипте всегда есть ивент Loop.
Ты можешь о нем не знать или не догадываться, что он есть, но он там есть.
у него действительно нет.
У тебя есть наобразие по всем библиотекам, Да, и большая часть.
Все просто один, экосистема одинаковая.
Ну, там и да, и нет, есть свои всякие разные интересные вещи, библиотека может, например,
тот же самый Node.js API, есть функции для работы с файловой системой синхронной и
асинхронной, и никто не мешает кому-то взять, например, синхронную вызвать, потом она
всегда работает нормально, а внезапно вдруг не заработала нормально, и весь твой сервер
встал.
из-за этого.
есть такие моменты бывают, но уже скриптей гораздо меньше.
В Python это сложнее.
И это до сих пор боль.
Больно, Да, это больно, потому что по-хорошему хотелось бы, например, асинхронное файло
API сделать в Python, чтобы AsyncAvoid работал на них, потому что нужен, потому что нельзя
предполагать, что ты просто будешь файло и он откроется.
А ее до сих пор в Python асинхронное?
То есть нет асинхронного?
Конкретно файловое.
сеть естественно вся синхронная, но файловая, файл сохранить.
идее тебе нужно аккуратненько это класть в threadpool.
И для этого есть API, чтобы положить это в threadpool.
Но тебе нужно об этом думать.
есть если, например, Тебе нужна калификация определенная, чтобы знать, Ну, тебе нужно
понимать, да, как это работает.
Диск, на самом деле, как правило, не блокируется.
У нас SSD сейчас и все остальное есть, все уже замечательно.
Ну вот если, например, кто-то там, не знаю, там, лог директорию через наторка TouchStorage
сделал, а он на самом деле уже там latency может быть совершенно как бы...
ну конская и там например синхронная синхронная файловая операция использовать уже нельзя
то есть ты должен понимать что операция на файловой системе иногда могут заблокироваться и
заблокироваться надолго и питон тебе никак в этом не поможет абсолютно и здесь нужно
просто знать поэтому вот эти грабли в использовании питона их по-прежнему надо убирать они
там есть и с ними надо что-то делать плюс в javascript гораздо меньше расслоения
называемая, я не знаю, это называется по-русски, можно перевести дословно разноцветные
функции.
То есть, когда у тебя есть функция асинхронная, и когда у тебя есть синхронная.
То есть, у есть функция с кивордом Async перед ней, в которую можно Obey написать, а есть
функции, которые этого нет.
В GeoScript'е, мне кажется, эта проблема гораздо меньше.
потому что в JavaScript в принципе гораздо меньше операций, которые блокируются.
есть Node.js, большинство API, как бы, работают с внутренним event loop.
Проблемы разноцветных функций, кажется, в JavaScript гораздо меньше, потому что в
JavaScript есть этот event loop, потому что очень многие API в языке, в принципе, они
задизайнены уже как AsyncAwait.
До AsyncAwait в JavaScript были callbacks, потом появились promises, потом это все
завернулось очень аккуратно в AsyncAwait.
Но так или иначе, дорога стартовала.
от Event Loop.
А в Python большинство вещей, которые есть, они объективно.
Они все-таки написаны под синхронное IO.
И, соответственно, есть вот эта проблема.
есть, как бы, вот я хочу приложение свое переписать на SinkAway по тем или иным причинам.
Или, например, я начал писать свое приложение на SinkAway и хочу использовать эту
библиотеку.
И тут возникают вопросы, собственно.
А насколько код тот совместим с SinkAway?
совместимы или нет.
можешь начать оказаться в ситуации, когда начинаешь конвертировать свой код на Sync Await,
и оно работает как вирус, то есть ты начинаешь больше больше функций конвертировать в Sync
Await, начинаешь их овейтить и так далее.
Мне кажется, что питония это чуть более ярко выраженная проблема.
Со временем эта проблема уменьшается и она будет уменьшаться.
Как если ты знаешь, что это библиотека совместима со Sync Await, будешь ее использовать.
Ну и потом на самом деле, можем об этом тоже поговорить отдельно, tooling.
развивается тоже для Python и довольно скоро появятся разные интересные вещи, которые
позволят эти проблемы отлавливать.
мне что автоматически, например, говорить о том, что был вызван синхронное там, где не
надо?
Ну, например, мониторить, что твоя программа делает.
Рекомендация.
Через механизмы похожи на стрейс, например, когда ты можешь понять, в этом месте программа
не должна была делать blocking call.
или в этом месте, например, ты делал тяжелый какой-то compute и это заблокировал event
loop и ты в это время не процессил сетевые запросы.
Слушай, но глобально все равно получается проблема...
правильно я понимаю, что она глобально не решаемая все равно, то есть у тебя все равно
будут либо заточены на синхронность и асинхронность или...
Или всё же ты можешь делать всё либо синхронно, а потом синхронно использовать.
Просто я тут не до конца я питом, настолько знаю, чтобы ответить на Да, глобально эту
проблему решить очень тяжело, но мне кажется, что эту проблему решает это то, что все
прыгнули на AsyncAwait, радостно.
я...
Типа синхронность, в конце концов, уйдёт в будущем?
Она даже не то чтобы уйдёт, она просто не будет никем использовать.
Она всегда там уже останется, по понятным причинам.
Но mainstream становится AsyncAwait.
И это абсолютно прекрасно.
И здесь мы можем сейчас резко свернуть.
тропинка очень глубокого моего философского рассуждения на тему AsyncAwait.
Потому что это очень больная тема в комьюнити.
Я вот все порываю блокпостно.
Эту тему написать и объяснить, самом деле, почему за AsyncAwait-ом будущее есть.
Вне зависимости от ограничений питона или еще чего-либо.
Но это как бы отдельная дискуссия.
Ну, я просто как Джейсер со стажем тоже могу сказать, что я вот прошел этот путь от
калбеков к AsyncAwait-ам.
И знаешь, что меня поразило?
То есть как только они начали появляться, я не знаю, вообще это Nodo умудрилось сделать,
это сообщество, и фаундейшн, который это всё делает, с такой скоростью всё это было
пройдено, что у меня до сих пор, не понимаю, по-моему, никто так быстро этого не делал.
То есть тебя появились какие-то промежуточные фреймворки, потом они резко упали, потом
резко появились осинки, и вдруг у тебя, ну, видимо, это связано как раз с тем, что у тебя
рантайм.
Такое, соответственно, гораздо проще всё это было сделать.
Ну и плюс настолько сильно больно было от калбеков, да?
что это быстро перешло.
Это последнее.
Это просто колбеки.
Я сам написал мне в жизни, наверное, столько же в «Оскриптазском капитоне», если не
больше.
Я очень хорошо знаю этот язык.
И колбеки были настолько безумно болезненные, что я думаю, когда-нибудь просто прыгнул на
«Синкавейтер» первой Потому что, как генераторы появились, все резко на них рванули и
очень быстро проскочили, слава богу.
И что могу сказать, вот, наверное, частично подтолкну тебя вот к этому, по поводу этой
статьи.
Действительно, когда ты уже вот всё перешло, тебя все либо и так далее, ты такой
понимаешь, а смысла писать не на осинках нет, у тебя синхрон, если ты будешь писать
синхронно или пытаться писать, тебя код проще-то не станет уже всё, он дошёл до точки,
когда вот, ну типа всё понятно, всё просто.
Я даже, более того, скажу, как человек, который вот им научит программирование, я заметил
такую штуку, что если людям давать сразу осинковый и не, то есть у нас, знаешь, в обучении
прямо из-за этого целый прям был такой переход.
Если ты не даёшь промезы до асинковейтов, люди даже не осознают, что они пишут на
синхронный код.
И это, честно говоря, негативно влияет очень сильно потом на понимание того, что они
делают.
Поэтому мы прям принудительно проходим промезы прям ручные до того, как даём асинковейт.
Потому что иначе они почти прям в голове...
Совершенно другие модели складываются, не те, которые на самом деле надо понимать.
Вполне, вполне возможно.
Я людей никогда особо не учил программировать, поэтому я не знаю.
Может быть, действительно так.
Ну, слишком высоковыска уровень, а концепция.
Но основная фишка Async-Await – это то, что она делает сетевой код видимым.
И это гигантское огромное преимущество.
Поэтому, в принципе, как только это кликает у людей, что, окей, если я вижу Async-Await,
значит, здесь где-то зарыт network-код, который куда-то делает какой-то запрос по сети.
Как правило, это кликает у людей, они начинают врубаться вообще, что происходит.
И, как правило, рано или поздно они начинают… как это сказать, ну…
благодарными что есть такой синтезис есть потому что он позволяет им вообще осознать как
программа работает на которую они смотрят где где что вот это такая вот супер супер пауэр
ассинковые то ну кстати интересно вот например каким таймер ассинхронный да то есть типа
аля slip можно в ноде так реализовать в поедине что же так можно сделать конечно конечно
да
Не каждый ассинк сетевой, но на самом деле фишка в том, что почти каждый.
То есть так или иначе как бы все крутится вокруг интернета в наше время.
Безусловно.
Я не знаю, ясеньковый использую для того, чтобы, например, написать питоновый скрипт,
который пять процессов разным запускает.
Просто потому что с ассинковой там есть очень конкретные примитивы, которыми очень легко
пользоваться.
Можно подождать на всех пяти, и как только первый из них обвалится, напечатать сообщение,
например.
Как писать такой код без ассинковой, я просто не знаю.
потому что тяжело, объективно тяжело, нет ремитивов для того, чтобы эти вещи делать
элегантно.
мне кажется, простенько Awade становится мейнстримом.
Это правда, но я не могу не сказать следующую вещь, что у меня есть определенный опыт
разработки прям продакшн-приложений Neuralunga или Xiri, и, его модель мне безумно
нравится, и она, честно говоря,
интереснее в определенных моментах и если бы типа он гораздо более массовый язык наверное
часть вещей я бы вызывал использовал чаще например особенно если какой-то у тебя стоит в
полпроцессе в бэйке которым надо обмениваться это на самом деле очень классно нас просто
игрушка так на нем реализована и ты понимаешь насколько это просто легко об этом думать и
в таких терминах вообще рассуждать то есть здесь я вообще не спою я на 100 % убежден что
как бы
вообще, как бы, Erlang slash elixir путь, это, наверное, чуть ли не самый правильный путь,
но так получилось, что с этого пути надо начать, чтобы там оказаться.
Ты не можешь взять и переписать питон фундаментально, чтобы он стал elixir'ом, это
невозможно.
AsyncAwait — это способ решать проблему, когда проблема уже...
Другая проблема уже решена.
Ну, я скорее-то просто добавил, Сразу бы правильно сделал.
Я просто скорее добавил, что существует модель, которая очень крутая, очень понятная,
очень классная.
Но это, к вопросу о том, что, понимаешь, мы когда говорили, что становится популярным.
Ну, вообще-то, Ирланд со своей моделью, сам язык, такой деревянненький, но если бы он был
нормально прокачан, то, конечно, вот эта модель, блин, она могла бы очень круто зайти.
Ну, вот так звезды сложились, что не зашло.
А зашло за кого?
Ну, не было элексира.
То есть если бы Erlang начался с Алексира, то это был бы синтакс, который понятен обычным
смертным, а не только пи-жди в математике и в компьютерсайнец, то все было бы по-другому.
Хочу тебе в этом плане, знаешь, пожаловаться как...
Я думаю, что по этому сообществу это как раз понимает очень хорошо, лучше, чем многие
другие.
Вот как раз вот про эту часть мы постоянно когда разговим про языки, я все время говорю,
что tooling самое главное.
Типа, если вы не начали свой язык с пакетного менеджера разрабатывать, он как бы никому не
нужен.
И я вот как бы первый раз на Erlang я начал писать, например, 2014 году.
Ну и какое-то время там вот писал.
И могу сказать, что я, блин, до последних лет, вот когда создатель, да, умер еще вот, ну
вот он еще живой был, они все равно все такие, нам хватит make-файлов.
Там вот этот трибар, который, да, типа пакетный, мы же никто его там не хотели как-то там
не дорабатывали.
Так вы думаете, да, господи, ребята, ну какие make-файлы, ну проснитесь.
Я просто не могу нормально...
лог файлов нет, ничего нет.
Кстати, и в этом отношении...
Пайтон, честно говоря, тоже немножко напрягает, потому что вот этот вот его путь как бы к
нормальному тулингу именно в этом отношении, он, честно говоря, какой-то очень тернистый.
То есть вроде бы сейчас, давай так, я тебя спрошу, вы определились уже наконец-то или нет?
Или до сих пор как бы прыганье?
Ну, определились мы на самом деле очень давно.
Путь ужасно тернистый, здесь я не спорю.
И опять-таки все знают об этом, что это проблема.
Я думаю, что в определенный момент Python был одним из лучших, несмотря на то, что если ты
посмотришь на него сейчас, то это конечно...
ну не сейчас, а...
Таймлайн тоже очень переместный на самом деле.
Конкретно сейчас, например, вот сейчас появился UV.
Это новая туза для Python, с которой ты ставишь пэкеджи.
Она работает очень быстро, она написана вся на Rust.
Она имплементирует самые последние...
проползалы по тому как с пэкнжингом надо работать она имплементирует те проползалы которые
даже нативные питоновые тулзы еще не сделали они их уже сделали а погоди это отдельная
тулза это не ядра?
тулза она называется UV она плавно захватывает питоновый мир и сто процентов она его
захватит уже уже ни у кого нет сомнений никаких по этому поводу мне за вас как-то
переписывать а?
я говорю у меня есть курс по настройке огружения Python
Это один из самых проблемных курсов, и ты не поверишь, меня на следующей неделе созвон,
потому как его апдейтить.
И как раз мы будем говорить так.
Апдейтить и сразу же… Можете сразу же на UV апдейтить.
Называется UV.
Компания, которая его делает, называется Astral SH.
знаю фаундера этой компании, хорошо, Чарли, он начал с того, что он сделал линтер для
питона, RAF.
Он очень известный.
огромное количество людей им сейчас пользуется.
Он по сути имплементировал Flake8, но Flake8 написан на Python, а RAF написан на Rusty.
RAF, соответственно, работает, наверное, в тысячу раз быстрее.
Что для линтера важно.
После того, как RAF стал популярным, он поднял деньги и строит компанию сейчас вокруг
туллинга для...
Туллинга?
Серьезно?
Вау!
Да.
Как конкретно они из этого построят бизнес?
Это отдельный вопрос.
Оставим это Charlie на домашнюю работу, но...
RAV классный, и UV тоже хороший.
UV полностью замещается будет PIP, это питоновый пэкч-менеджер.
И помимо всего прочего, по-моему, он еще сильно очень упрощает работу с виртуальными
инвараментами, так называемыми, в питоне, которые в принципе концепт сложный для понимания
людьми.
По крайней мере, моем, ну, по моему опыту.
Там это все упрощается, стримлайнится, и все становится прям совсем просто и красиво.
Как вы думаете?
Да, казалось, что Poetry захватит мир, но нет.
Poetry был шанс на самом деле, но с UV помогла в том числе и скорость тоже.
То есть, когда у тебя PIP ставит пэкаджи минуту, а UV делает это за три секунды, разница
настолько сильно взрывает мозг людям, что они просто идут и используют UV.
И потом они уже начинают обнаруживать, что помимо скорости там есть еще и улучшение во
всех остальных областях.
Ну, это работает, когда есть очень сфокусированная и мотивированная небольшая группа
людей, которые просто в состоянии взять и решить проблемы правильно.
И вот она наконец-то в Питоне появилась.
Раньше ее не было, потому что пэкэджинг в Питоне очень сложная тема.
На самом деле можно понимать, что даже такая вещь, UV, это маленькая-маленькая вишенка на
огромном гигантском айсберге просто.
Потому что пэкэджинг в Питоне очень сложный из-за нативных пэкэджей, огромного количества
фортрана в мире и чего-то...
только не заадаптированно под питоновый код.
Есть огромное количество всяких осложнений с внутренними депенденциями на нативный код, в
том числе и то же.
Если пакет один зависит на пакет с нативным кодом с одной версией, а другой пакет зависит
на пакет с нативным кодом другой версией, что там происходит, как это все резолвуется.
Все это сложные довольно процессы и сложная экосистема, и в ней все запутано и сложно.
И каждый раз, кто-то что-то пытается в менять, сразу же выливается просто какой-то
мегаватный поток ненависти на этого человека, потому что что-нибудь у кого-нибудь
обязательно сломается.
Сломает.
Знаешь, это так забавно.
Да.
Что я имею в виду в разработке языков программирования, тема пакетных менеджеров, это,
наверное, одна из самых просто сложных, запутанных и вообще важных для людей, потому что
это тот интерфейс, с которым ты взаимодействуешь каждый день.
И, конечно, если там что-то пошло не так...
съедят просто целиком.
Ну, тут нужно понимать, что тема языков программирования с пакетными менеджерами просто
меркнет по сравнению с гораздо большей темой.
Это, собственно, билд-система которых в мире появляется каждый день, скорее всего, одна
новая, и все они сломаны, абсолютно все, без единого исключения.
В больших организациях, как правило, несколько, ну, отдельная команда людей, которая
занимается...
Единственное, чем это, вот, поддержка билд-системы.
Все, что касается packaging и компиляции и собирания софта, к сожалению, судя по всему это
NPI проблема, она просто не решается.
Не решается, да.
что я как раз с ребятами из мира, мировой, блин, раз у меня со всеми названия проблема.
Короче, мы тоже на подкасте встречались и обсуждали то, что у них там сколько-то миллионов
строк кода на TypeScript, много миллионов строк кода.
И там целая команда только этим занимается, чтобы оптимизировать этот весь туллинг.
Ну там вообще свои специфические проблемы, которые тоже очень интересные.
И есть вот прям название, я не помню как они называются, Frontops что ли, вот сейчас такие
команды, которые этим занимаются.
Это, конечно, безумие, Да, подоученного, с ним очень интересно.
Знаешь, меня, вот что пугает, ты говоришь, еще раз, как она UV называется, да?
UV.
Просто UV у меня ассоциация только с ультрафиолетом.
Я не знаю, почему они это назвали, они искали какое-то короткое имя, мне кажется.
Так вот, смотри, просто пакетный менеджер — это одна из вещей, которую тоже я очень
плотно, так сказать, как...
прикладник на разных языках проходил.
один, помнишь, да, из примеров, это бандлер в Ruby был очень классный пример, который
потом разошелся, с которым многие взяли потом, да, я даже не знаю, что ярны всякие там,
кокопоц, ну, геты, там, это все было с бандлеров взято.
Я просто как рубист, мне это близко, я знаю, что ребята сделали очень крутую штуку.
И вот там просто такая была история, помнишь, когда в ноде же тоже проходили этот путь,
там логфайлов не было, значит, бандлер в ярн превратили.
а потом у тебя еще один, еще один, еще один, они вдруг себе бум-бум-бум начали умирать.
И мы как бы ринулись тоже, перешли, и я теперь, знаешь, я очень боюсь всех вот этих новых
штук, потому что думаю, так, два года не стоится, посмотрим, что сделает команда
разработки.
И вот, например, в случае ноды, это всегда очень смешно было, может быть, ты знаешь, они,
с одной стороны, такие товарищи, которые не очень спешили всегда, но с другой стороны, я
имею в с точки зрения инфраструктуры вот этой вот, да, но с другой стороны, если хоть
кто-то рядом появлялся, кто делал что-то интересное...
они, бам, через месяц релиз, в который они это внедрили.
И ты в какой-то момент понимаешь, что с этими ребятами надо просто сидеть на попе ровно,
они всё равно в npm это втащат.
А вот в Python не так, то есть ты говоришь, ювьи, окей, предположим, мы это сделаем, ну
скажем, будем вот его рекламировать и будем ему учить.
Не будет ли такого, что через год вы скажете, мы там PIP обновили и всё, теперь типа
возвращаемся?
Какой у вас план?
теоретически может быть, но нужно понимать опять-таки, что PIP обновляют волонтеры, а с
другой стороны, сидят venture backed компании, которая прямо долбит этот UV сейчас и денег
у них.
Это пока нее деньги есть.
На несколько лет вперед.
Но он полностью open source из других новостей, так что если они реально эту проблему
решат и проблема будет полностью решена и все будут, вот UV станет просто стандартом, он
не пропадет, даже если компания затронется, можно не перезвать за это.
Слушай, а тебе не кажется все-таки перебором, вот я тоже смотрю на эту тенденцию, да, у
тебя очень многие tooling, а...
особенно вот в ноде видно, да, он ногой на расте начинает писаться.
Гораст, гораст, гораст.
Мне почему-то кажется, что раст перебор.
Ну чисто такой...
Ну...
Ну...
В плане языка или в плане решения этой проблемы?
Скажем так, рас скорее будет быстрее, го.
В теории.
Я не пишу на этих языках, но, наверное, теории рас быстрее, го.
Но просто сложность рас-то по сравнению с го и там количество разработчиков и так далее,
типа, не слишком ли рискованно и кардинально, что можно было бы на го, и тогда у вас было
бы в тысячу раз больше разработчиков?
Или я неправильно себе вижу картину?
Мы тут рискуем наступить сейчас в такую огромную пропасть, что к куку людей отпишутся
твоего подкаста и от меня, и не знаю.
А мне просто интересно, я потому что, я не знаю, я смотрю на это, меня такие мысли
возникают, что это все-таки игрушки как будто бы немножко.
Не знаю, мне кажется, что программисты, которые в состоянии написать Package Manager, они
ценят в языке не то, для чего Go был, не те приоритеты, которые задизайнили Go.
которые лежат в основе Go.
В основе Go лежит легко читаемый, быстро пишущийся код.
Очень быстро компилируемый, с минимальными осложнениями, чем любую.
Просто сделать язык, котором огромная компания Google может очень-очень-очень быстро очень
много кода писать.
Который может понять любой человек, который даже эта языка не знает.
Когда я первый раз на Go смотрел Review QueryQuest, я Go знал...
Я тутуриал прошел, Сейчас.
Я знал год-час, и я уже мог ревьюить полреквесты на ГО.
Может быть, не идеально, но я, по крайней мере, мог понять, что здесь более-менее
происходит.
Здесь вот ошибка.
Здесь вот логическая ошибка.
Здесь вот неправильно таймап прохендлил.
Уже было понятно.
С растом совершенно другая ситуация.
Это гораздо более сложный язык.
Сравнение с растом это скорее...
Я не знаю, если ГО, это там какой-то, не знаю...
Можно как-то...
— Ну машина и самолёт, давай так вот.
— Можно питон притянуть как-то ГОИ, сказать, что они примерно где-то в одной плоскости
где-то существуют.
То плоскость расы — это C++.
То есть это как бы...
это совершенно другой уровень вообще языка.
И люди, которые выбирают рас для написания компиляторов, для написания двинтеров, им очень
важна корректность, очень важна корректная обработка ошибок.
Быстрая и простая.
Им нужно, чтобы ты скомпилировал свой компилятор на расе, и ты был в принципе более-менее
уверен, что...
по крайней мере в нем нет каких-то совершенно глупых ошибок.
Потому что, ну, раз просто как язык просто форсят, писать более корректный код.
И страдать немножко, наверное.
Ну, безусловно, но это цена.
На все есть своя цена.
Цена корректного кода — это страдание.
С другой стороны, таких вещей, линтеры...
Например, линтер конкретно.
Линтер, я могу себе представить, что...
линтер, например, можно было бы распаралелить.
Возможно, RAV как раз распаралеливается.
Вполне возможно, что там алтетреддет модель, и там часть файлов линтиц параллелена с
другой части.
Но если в линтер немножко посмотреть глубже, и то, что они сейчас, собственно, делают, они
хотят добавить вот type checking.
Type checking — это очень интересная тема.
Вот представь, что у тебя есть 10 миллионов строк кода на Python, и тебе нужно про-type
check-ить его.
Что это означает?
Это означает, что тебе нужно...
построить по сути проанализировать все типы данных которые все типы функций которые у тебя
в том приложении есть это означает что скорее всего ты не хочешь делать это
последовательно ты хочешь это распараллельно для этого тебе нужен параллельный стороч
какой-то где эти все типы будут накапливаться информация программе тебе нужно параллельно
эти все файлы читать потенциально не знаю там ну там 100 редов например сделать для чтения
на мощном cpu вот то есть внезапно тебя появляется конкарнси внезапно у тебя появляются
локи и так далее
На Rust с этим нет никаких проблем.
Раст...
Ну, они...
Проблемы с Malta Traded программирования всегда есть, это, в принципе, сложная тема.
Но Rust как язык и его туллинг и компилятор позволяют тебе огромное количество проблем
отловить в самом-самом зародуше.
Вот.
И на Rust, ну, здесь, может быть, мое мнение, многие с ним не согласятся, но, на мой
взгляд, сложные Malta Traded программы на Rust писать гораздо проще, сложные синхронные
программы на Go, где просто там 100 разных каналов используются и нужно их все
синхронизировать.
Поэтому, на мой взгляд, для написания каких-то сложных компонентов и как не парадоксально,
линтер может стать сложным компонентом, мне кажется, что раз подходит, что-то чуть лучше.
И тут вопрос уже не в производительности, по скорости, тут вопрос в том, что просто будет
она вообще летать или нет, будет работать или нет.
Ребят, кто нас слушает, не могу не отметить, что сейчас, возможно, подорвались пердаки.
Поэтому обязательно в комментариях.
Я там чувствовал уже.
Я тоже уже оповел от экрана.
Ребят, обязательно напишите в комментариях, что вы поэтому думаете, все что вы думаете о
нас, о Го, о Расте и так далее, потому что это на самом деле интересный батл.
Я стою со стороны и смотрю просто на это А я тоже со стороны стою.
Я просто случайно прошел.
Мы просто случайно сказали и Даже не мое мнение я просто прочитал вчера.
Ну да.
Кстати, интересно, вот, опять же, ребята, когда про TypeScript говорили, на чем они там
пишут?
Просто то, что ты рассказываешь, ну, я так пару копеек тоже вставлю, как будто я умный.
Начальная индексация, наверное, да, но потом так редко файлы меняются, что, по большому
счету, там, как бы, если все нормально покэшировать, то как будто бы, этот...
Инкрементально-то уже не принципиально, да, но это такое дилетанское мнение, как будто бы
там уже большой разницы такой не будет.
Вот, ну может быть, конечно, все совсем не так.
Опять же, объясните нам, если вы этом хорошо разбираетесь.
Хорошо, слушай, я знаешь, про что хотел спросить?
Что вернуться к Python, и классная тема, ты ее затронул, но мы про нее больше не говорили.
Интересная тема — это облака.
И вот этот вот serverless, который попер, да, и, собственно, твое участие в том, что
Python туда завел в ажуру, да, это интересно, и расскажи, что ты об этом думаешь, какая
тенденция.
Я просто классический чувак в кубернате.
мы серверов не используем, нас там как бы что запустили, то запустили.
А вот интересна вот эта тенденция, потому что я просто в двух словах скажу, вот мы когда
общались опять же по ноде, обсуждали там это, для меня стало удивлением, потому что я про
это не знал, что оказывается, нода при всех своих там плюсах, там оптимизации,
ба-ба-ба-ба-ба, она все-таки рассчитана на длительную на длительную жизнь запускаемого
скрипта, соответственно получается, что там интересно.
там очень много всякого инцелизации происходит, у тебя там, короче, коллектор и так далее,
и типа в serverless все это не нужно, и оказывается, что появилась куча других
имплементаций, которые как раз для длительного запуска не работают, но зато в serverless
просто идеальные, они там все просто порезаны, все максимально быстро, g-то никакого нет,
ни хрена нет, все короче классно.
Вот расскажи про Python, насколько он захватывает и насколько сам Python там подходит или
там какие-то альтернативные имплементации.
Ты все правильно сказал, мне практически добавить нечего.
есть да, это проблема startup time и Node.js и Python.
Эти проблемы надо решать.
Есть разные способы решения, есть проблемы абсолютно.
Но в целом, какой-то такой глубокий take на serverless это то, что это прикольно для
начала, когда ты делаешь маленькое приложение и тебе нужно, чтобы оно работало как можно
быстрее.
Но когда это приложение развивается, серьезным, мне кажется, serverless подходит уже все
меньше и меньше и меньше для этого.
Большие компании этим, как правило, не пользуются, того, что я понимаю, потому что
непредсказуемый прайсинг абсолютно.
И потому что, в принципе, тенденция у них так или иначе к какому-то монолиту рано или
поздно проскальзивает.
Потому что, по сути, если ты пользуешься таким классическим serverless, тебя вот маленькая
функция здесь, маленькая функция там.
все это аккуратненько собирается и само собой работает, тебя получается такой вот прямо
практически микросервис манифестирует себя в этих функциях.
И с ними очень тяжело, когда количество кода становится большим.
И не размера даже мира, или не размера Pinterest или Facebook, а даже в среднем уже
приложений, когда у тебя эти функции появляются 100 штук, ну, люди уже...
Уже повесишься, да.
И на этом сервис уже быстро очень заканчивается.
Поэтому это очень важный entry point для того, чтобы люди могли очень быстро писать,
например, на на викинде просто приложение или может быть приложение в принципе не должно
быть большим.
Многие приложения написаны, маленькие, они выполняют свою задачу и не всему обязательно
эксподенциально расти.
Вот, но как правило, если что-то вот таки эксподенциально растет, то серверлос там
заканчивается очень рано.
Из моего опыта, по крайней мере.
Да, я тоже видел, как много люди страдают и прям впираются, начинаются проблемы и уже не
так легко переехать.
И вообще они с самого начала говорят, блин, на самом деле это была скорее ошибка.
Но знаешь, тут интересный момент.
Это все равно работает на неокрепшие мозги, людей это манит, они туда идут.
И тут скорее, наверное, так интересно, это, PR как бы важный эффект.
То есть, типа, там надо хорошо запускаться и там надо поддерживать, знаешь, типа, ощущение
у всех, что мы вообще Python классно там работаем, просто хотя бы чтобы у людей было
ощущение, что он и там.
потому что иначе типа проигранная сцена.
Да, конечно, питон добавлять нужно, и я тут немного помогаю, наверное, компании Versel
этим заниматься тоже, с питоном.
То есть, в принципе, всем...
Всем нужен Python.
Но всё равно там Python обычный, да?
Или номер два, вот whatever.
есть всем он нужен.
С Python, конкретно с serverless всё чуть-чуть сложнее.
есть JavaScript есть довольно много компаний, тот же Versel и Netlify, которые более-менее
Versel, для которого serverless более-менее работает.
И работает неплохо.
И у AWS есть решение тоже своё, и у Microsoft.
С Python, с Python serverless он вроде как бы есть, но там огромное количество есть
ограничений с ним.
с пэккаджингом, например, и так далее.
есть если функция очень легкая и ничего только не импортировать, работает.
То есть, если тебе нампай надо импортировать, и сайкид, и пайторч, все внезапно
превращается в совершенно другую историю.
Поэтому мне кажется, что в принципе в мире питона serverless он как бы так, потихоньку
вроде и есть, вроде как бы его нет.
Скажешь, что это мейнстрим, мне кажется, что нет.
Будет ли он мейнстримом?
Я думаю, что да.
потому что, как я сказал, всех самое-самое сложное в любом проекте — это его начать.
И если начать serverless проще, то значит надо делать serverless.
Все компании, которые строят клауды, они все на самом деле как деревья наркотиков.
Им очень важно, чтобы ты первую дозу попробовал, чтобы ты запустил первую свою функцию,
запустил первый свой frontend, задеплоил.
зашел на сайт, он работает, тебя сразу включается как бы feedback loop и ты пошел за
второй дозой.
Вот, если ты Cloud компания, для того чтобы начать ей пользоваться, тебе нужно
разобраться, что такое backend, такое frontend, как написать там правильно приложение, как
его задеплоить, внезапно получается, что ты можешь в другую компанию пойти задеплоить, а
зачем тебе это нужно.
Поэтому мне кажется, что Serverless просто позволяет тебе очень сильно сократить этот
feedback loop от идеи...
до задиплоенного рабочего приложения.
И поэтому он будет развиваться дальше.
Но, всё-таки runtime это альтернативная есть?
Для Python нет.
Python очень много раз...
Сложно, ...виртуальных машин и runtime, там PyPy, самый известный из них.
Но в основном так получается, что все сидят на одном и том же Cpython, вот, и живут с ним.
И, по сути, стратегии две.
Либо ты...
Делаешь какие-то очень интересные прыжки вокруг packaging и импортов и всего остального,
чтобы тебя приложение быстро загружалось.
Относительно быстро загружалось.
Либо, что мы для Microsoft сделали, когда я это делал, это то, что есть просто процесс
питона, который крутится все время и запускает функции внутри себя.
То есть он никогда не останавливается.
Он все время работает.
Приходит запрос, он вызывает эту функцию.
То есть у тебя там есть...
нормальный контекст, изоляция, а-ля Java, когда ты можешь так сделать?
Да, да, да.
есть, там зависит от того...
Опять-таки, был прототип, который мы им сделали, мы как бы его запустили в Production, и
потом мы уже, собственно, переехали сюда и начали строить свою компанию.
Мы прекратили строительство того продукта.
Microsoft сам его сейчас разрабатывает, и я уверен, что он уже очень сильно поменялся,
скорее всего.
Вот.
Но изначально тогда была идея в том, что если тебя есть большой...
Большое приложение, которое используется в серверах, то запускаешь просто постоянно
процесс.
Потому что вероятность того, что тебе гораздо выгоднее, этот процесс крутился все время и
отвечал на эпизодические функции, чем стартовать его каждый раз заново, это просто
выгоднее.
Поэтому то, что мы сделали, это такой вот процесс, который просто крутился непрерывно и
запускал функции с твоего проекта, где тебе изоляция уже не так сильно нужна.
То есть там...
секьюрити консервов никаких нет, потому что каждый такой процесс работает на конкретный на
конкретного клаут клиента, конкретные виртуальные машины.
Хотел просто как пример сказать.
позволило просто убить в ноль практически.
Ну да, да, Но если ты не начнешь сталкиваться с проблемами, когда они пошарят стейд
где-нибудь, кто-нибудь какую-нибудь дичь сделает, ну не знаю сколько реально.
Для этого там тайпинг, гайдлайны, документация и так далее.
Да, просто надо может выстрелить.
будет весело разбираться, что за фигня.
Кстати, знаешь, я вообще-то подумал из того, что мы используем такого Serverless, не
используем, но знаешь, мы активно используем.
То современный мир же, больше такой про интеграцию, у тебя сервисов полно, ты все это
соединяешь.
вот сервисы а-ля Zapier, то есть вот у нас N8MN стоит, возможно ты в курсе про такие вещи,
когда у тебя, ну, тебе нужно любую опишку с любой соединить, Вот у нас там много кастомных
пайплайнов, которых есть интеграции готовые, которые готовы откуда-то взять, куда-то
отправить.
А иногда приходится самим писать.
Они, конечно, мы на ноде все пишем.
Ну, в смысле на джейсе.
Там, я, кстати, не знаю, что там запускается.
Но я такое понимаю, что здесь, конечно, Python мы даже не рассматриваем.
Хотя я видел, что внедряется.
как-то это совершенно бессмысленно.
Вот у меня, кстати, два еще, я понял по пути два вопроса.
Вот поскольку мы говорили в принципе про сервелы, значит, я сейчас что понял.
Когда люди говорят про...
Любители же сейчас все сервисы, микросервисы.
Хотя, кстати, уже пошел откат.
Уже начинают писать статьи на тему того, что почему микросервисы...
но все же, по крайней мере, когда речь идет про микросервисы, я сейчас понял, что про
Python, Python и микросервис никогда рядом не стоят, Ну, крайне редко, это, только у тех,
кто и так на Python пишет, а в целом...
этого я не знаю, я бы здесь не говорил.
Понятно, что никаких ограничений нет, да, все прекрасно, но вот как будто бы он как-то
мимо прошел.
Так уж получилось, чтобы у меня было привилегие посмотреть на несколько очень больших
компаний изнутри, питоновых.
Там лифт, фейсбук и так далее.
Пинтеры тот же.
И я много всего там интересного видел, в том числе и огромное количество микросервисов на
питоне.
В таких компаниях.
Я, сожалению, не знаю, грубо говоря, что происходит на глобальной сцене микросервисов.
Я в принципе небольшая фанат этого паттерна, может быть, поэтому мой мозг и дистанцирует
меня от этого.
От знания этого.
понял.
Слушай, еще одну штуку, которую не могу не спросить, она просто рядышком со всем, что мы
обсуждали, это все-таки вот эта тенденция запуска кода в браузере, когда у тебя ты пишешь
на...
Нет, я понял, надо еще про типа потом спросить.
Короче, тенденция запуска кода в браузере, да, сейчас же вот эта вся есть история, когда
ты транслируешь это все...
в браузер, там запускаешь, и видно, что по чуть-чуть, по чуть-чуть.
Мне, кстати, это очень важно, потому что у нас тренажеры, нас так далее, но там мы на бэк
ходим, все такое.
Но меня были попытки найти имплементации, и какие-то вещи я находил.
Сейчас у нас есть WASM, сейчас есть всякие штуки, которые что-то позволяют.
Вот ты вообще в курсе про эту тему?
Есть какое-то такое движение в эту сторону?
Или это просто энтузиасты что-то там пилят сбоку?
Ну, нужно смотреть на компании, которые как бы...
настоящему сакссу, одна из компаний Figma, которая наверняка многие пользуются для,
собственно, Figma для рисования.
Ты хочешь сказать, они на питоне пишут?
Нет, они на питоне.
В смысле, раз.
Они там основной движок на Вазме, вот, крутятся.
То есть я к тому говорю, что, на мой взгляд, да, если ты хочешь делать приложение, которое
работает на каком-то другом уровне от того, что все остальное, скорее всего, ты будешь
пользоваться такими продвинутыми вещами, как Вазм.
и частично где-то как бы продавливать границу возможного.
Питон конкретно с вазмом, он возможен, он вроде как работает, я видел всякие демо, но там
просто объем данных, которые тебе надо скачать, прежде чем он загрузится, большой,
мегабайт 5, по-моему, лежит в этом роде.
Понятно дело, пока это звучит как немного-много, но может быть там через...
через 10 лет, там уже будет 6G или что-нибудь в этом роде, 5 Мб в секунду будет везде
скорость скачивания данных, и всем будет абсолютно это параллельно.
Поэтому прямо сейчас мне кажется, что большой размер данных, который надо скачать, чтобы
что-то заработало, это пока препятствие большое.
И поэтому многие люди даже серьезно это не смотрят.
А какой смысл на это смотреть, если у тебя, многих людей там на телефоне это будет
грузиться два дня?
Но учитывая, что опять-таки все развивается по экспоненте и скорость связи тоже, то вполне
возможно, что через 10 лет мы будем смотреть на это совершенно по-другому.
Сам потому что классная штука, мы даже в своей компании используем для каких-то вещей.
Я почему спросил тоже, у это еще такой, знаешь, старый опыт там, из 10-го года, когда на
ГВТ у нас был редактор, ну, такой простенький, но редактор в браузере, и на тот момент,
как бы, всех технологий, позволяющих это сделать, только ГВТ, по сути, соответственно, у
тебя Java, ну, правда там Java транслировалась в JavaScript, и все это добро работало, и,
понятно дело, что, вот в какой-то момент, я помню, CodeLineActive, там еще что-то, там
было много этих разговоров, что вот-вот-вот-вот-вот сейчас мы сделаем, то есть, у меня
было ощущение, и я вот...
давно его не проверял, что типа многие экосистемы, языки стремились как бы сделать типа ну
сейчас фронт же надо, можно и важно и возможно как бы очень важной часть экосистемы это
как раз трансляция туда куда-то в браузер чтобы там можно писать на своем языке но
транслироваться туда вместо gs пока непонятно как бы будет ли развиваться активно это
направление и станет ли оно мейнстримом каким-то или gs вот просто в typescript
превратится и все и на это все закончится
Я думаю, развиваться.
Ну, не знаю, маленький пример из того, что мы делаем в нашем продукте.
У нас есть UI, и этом UI крутится в браузере.
И в UI нам нужно наш язык запросов парсить, чтобы подсвечивать его, ошибки в нем искать и
так далее.
Парсер написан на Rust, поэтому просто крутится в браузере.
все.
Весь UI написан на JavaScript, но конкретно вот функция, которая парсит язык, она написана
на Rust, и она замечательно крутится в браузере.
Поэтому мне кажется, многие вещи...
Ну, же самый ВАЗМ, например, уже 100 % становится мейнстримом, он там останется.
Конкретно компиляция других медленных языков, как питон, например, лишь бы на джевоскрипте
не писать.
Ну, это вопрос, что с этим будет дальше.
Джевоскрипт, в принципе, далеко не такой уж и плохой.
Нет, он сильно изменился.
скрипс, это замечательная вещь абсолютно, на мой взгляд.
да, да.
Слушай, вот прям, видишь, как у нас вытекает одно из другого, мы прям классно пришли
сейчас с тобой к типизации, потому что я за этим не очень слежу, но я знаю, что питон тоже
ровется туда и вроде как уже даже дорвался.
Скажи что-нибудь пару слов по этому поводу.
Питон реально очень-очень сложный.
Язык со сложным прошлым, наверное.
Я не знаю, как это даже сказать.
С травмой дирской?
Да, какие-то у него травмы, это и травма, и благословление одновременно.
То есть язык, который полностью движется некоммерческими организациями.
Сейчас они спонсируют его, то есть есть там, по-моему, три или четыре программиста,
которые full-time работают над Python.
Их там спонсирует Meta, Bloomberg, Microsoft.
и Google, по-моему.
Всего лишь четыре программиста в мире, которым платят прям полноценно, в полное рабочее
время, без каких-то заданий, просто чтобы они развивали Python.
То есть это безумно мало, на самом деле.
И с typing ситуация похожая.
Потому что typing начался, когда GWID работал в друбоксе и смотрел на то, что они никак не
могут сконвертировать код бейс свой из Python 2 на Python 3.
И Гвидо всегда думал про таппинг, у него всегда была идея, что какой-то таппинг в Питоне
нужен, опциональный и статический.
Но мотивации, видимо, не хватало этим заняться.
Вот там оно появилось, потому что огромное...
огромное количество кода, десятки миллионов строк, там безумно абсолютно.
Что не скажешь со стороны, казалось бы, дробокс и 100 миллионов строк кода, где, где,
где...
Как так?
Ну, так получается.
То есть не 10, 100 миллионов в Ну, там это помимо питона есть и другие языки, на которых
учатся.
Там абсолютно сумасшедшие, необъятные просторы.
Я не помню точно 100 или нет, но там вот этот порядок.
То есть там больше, 10 точно.
И смысл в том, что это безумное количество кода.
И когда у тебя есть такое количество кода, часть и миллионы строкод на питоне, то tapping
необходим.
Он это осознал там, в он до этого осознал это в Google.
Но в Piton уже прям реально в друбоксе мотивация была, потому что нужно было миграцию
сочетать срочно.
И тогда он этим занялся, и тогда друбокс проспонсировал создание, ну не создание, а
развитие проекта, который назывался MyPy.
Нанял создателя MyPy, его зовут Yukka, замечательный человек.
И...
Фин, да, судя по всему?
Он фин, да.
Yukka Lehtosala.
И еще несколько людей и Гвида.
И вот у них была группа, которая занималась исключительно тайпингом.
в то же время параллельно...
Подобная вещь происходила в гугле, начала происходить и в фейсбуке.
И как-то они так объединили более-менее свои силы и как минимум договорились на собственно
синтоксической составляющей.
И вообще как-то тайповая система будет работать приблизительно.
но tooling, именно tools, над этим будут работать, которые будут парсить твой код и
смотреть на типы, они создались параллельно.
Facebook это был спин-офф их tooling для хака, он назывался Pyre, по-моему, для Python, и
у Facebook еще был очень важный момент, потому что они хотели делать, так называемый,
taint analysis, они хотели проверять
что сенситив данной не гуляет по коду просто так.
То есть они смотрели, окей, если это сенситив...
— На уровне стемтипов?
— Да.
Если это пароль, то он не может случайно оказаться вот в тимплейте, например.
— Блин, ну это кажется как будто в линтер надо они в это пихать.
— Ну это как раз нужно в компилятор встраивать, потому что компилятор знает, может
проследить весь путь данных.
Но да.
Это такой интересный момент, я очень удивился, когда я про это узнал.
У Google был свой какой-то тейпчекер, а вот Guido со своей командой делали MyPy в
друбоксе.
Потом друбокс, таки, мигрировал на Python 3, насколько я понимаю.
Он же сейчас там не работает, и знаю я об этом уже тоже мало.
Но они, таки, по большей части мигрировали, боль основная прошла, и с тех пор MyPy как-то
немножко деприоритизировался.
И немножко — это очень слабое слово здесь.
По сути, им на него уже пофиг.
Вот.
И тут произошел опять какой-то питоновый сплит экосистемы.
есть появился Pyrite.
Это тул, который встроен в VSCode.
Его сделал Microsoft.
Он абсолютно параллельно имплементирует Typechecker.
Есть MyPy.
Компания, которая стоит за UV, сейчас пишет свой Typechecker на Rust для питона, который
будет быстрым и всеобъемлющим.
Вот.
И есть еще гугловая тулза.
И, по-моему, даже Pyrite до сих пор можно в Facebook'овый скачать и им пользоваться.
В итоге ничего не развивается сейчас.
Python и Python вытайпывается Слушай, я хотел, знаешь, уточнить для того, чтобы меня в
голове картинка правильная.
Опять же, просто Python давно не смотрел, уже так плотно.
Скажи, сами типы там описывают, это часть синтаксиса, это же не какие-то dog-блоки там?
Да, это часть синтаксиса.
В Python есть так называемая аннотация параметров, в которой Гвиды когда-то, в принципе,
добавил язык, но он добавил их интересно.
То есть он сказал, что...
вы можете ими пользоваться для чего хотите но в принципе я их добавляю чтобы когда-то в
питоне появился таппинг и в принципе как бы никто ими толком и не пользовался были
какие-то фреймерки которые что-то пытались использовать их для каких-то небольших вещей
некоторые даже довольно интересные вещи делали но в конечном итоге появилось время желания
угвида и он таки сделал таппинг и поэтому эти аннотации параметров которые в питоне много
лет были ими просто никто не пользовался
они обрели, собственно, значение какое-то и стало, грубо говоря, мейнстримом написать
функцию, которая приведет параметр a, 2.int.
Все стало понятно, что тип параметра a, int, И так вот...
И в PYTHONES пришел.
Да, PYTHONES есть GENERIC, в PYTHONES есть GENERIC, в PYTHONES более-менее все неплохо,
вот.
Но проблема в том, что этого, на мой личный взгляд, этого не хватает.
И меня мой личный взгляд, он очень сильно переплетен, собственно, моей основной
деятельностью, моим продуктом, который я строю.
На мой взгляд, Python нужно сильно близко подвинуться к TypeScript по возможностям
TypeSystem.
Что конкретно есть TypeScript, чего нет в Python, я не знаю, как сказать, по-русски,
программируемые типы.
Это когда ты можешь сказать, что вот этот тип берет другой тип и, например, меняет у него
там int на float.
все инты поменять на флоту.
Например, такую вещь на TypeScript здесь делать абсолютно тривиально, а на Python
невозможно.
Вот нужно, чтобы на Python это появилась возможность сделать, потому что тогда можно будет
на Python делать очень крутые всякие библиотеки, которых будет очень крутой статик typing.
Но пока этого на Python нет, и кто это будет делать тоже непонятно, потому что нет
какой-то движущей силы за typing.
Поэтому он в Python оказался на уровне, где он уже достаточен для очень многих вещей.
но все еще не такой крутой, как в TypeScript, чтобы делать какие-то вещи, ...стоит уже
начинать делать потихоньку.
Знаешь, это интересная штука, что какие бы ни были разные разработчики, которыми я тоже
общаюсь, разные языки, разные подходы, но TypeScript все-таки, конечно, впечатляет всех.
есть его уровень системы типов, конечно, она просто...
Все писаются кипятком от нее.
И это действительно приятно, когда...
когда у тебя там выводится все просто строчки там SQL, у тебя типизируется, тебя IE18,
короче любая фигня, которую ты делаешь.
Анафюрин комплит у них, то есть там в принципе можно писать Vite на системе типа в
TypeScript, конечно будет работать очень долго, но теоретически можно.
да, у меня был прикол, мы вот когда разговаривали тоже тогда с ребятами по поводу
TypeScript, то что у них там много миллионов, блин, Анина, у нас проект намного меньше.
в тысячу раз меньше, но они на те же самые грабли наступали и мы тоже.
Например, i18n типизирует все строчки, это очень круто, у тебя все прямо из ямол файла или
джальсончику подтягивается и само работает, только проблема в том, что тебя просто
намертво все виснет и не работает.
И там есть сложная система типов, она тоже имеет свои проблемы.
Тайвс Крит просто жизнь заставила этим всем заняться.
Так уж получилось, что...
у TypeScript была просто вилка.
Либо он умрет, либо не умрет.
Вот чтобы ему не умереть, нужно было сделать так, чтобы любые JavaScript-пакеты, будь то
jQuery, котором мало кто пользуется, но кто-то пользуется, или какой-нибудь, не знаю, там
эзотерический пакет для рисования, там какой-нибудь там canvas, все они могли затайпиться.
И учитывая все паттерны, которые в JavaScript появились за годы без нормальной типовой
системы,
получилось, что вот нужно вот вот космический корабль построить из телевизорного
обскрепления.
Это круто.
реально круто.
Кстати, я хотел знать, что пока ты разговаривал, не могу не отметить ироничность ситуации,
что человек, так сказать, был одной из причин появления Питона-3, не совместил с
Питоном-2, пострадал от этого в первую очередь сам в привопытке перевести проект со
второго на третий Питон.
Это довольно забавно.
Гвидо как бы он...
Аминь это один из самых умных людей, с которым я общался.
То есть думать, что он был наивен или еще что-то не стоит.
Но он действительно немножко недооценил, наверное, ту колоссальную боль, которую у людей
будет с перевода одного на другое.
Основная, конечно, боль была — это байты и строки в питоне.
Это страшно месиво — в питоне два.
Консенсус, тем не менее.
Консенсус.
Всех CordyVale оперов абсолютно.
И всех более-менее продвинутых пользователей Python, кого я знаю.
Заключается в том, что да, это был безумно болезненный experience.
Теоретически, может быть, можно было бы что-то сделать, чтобы он прошел лучше.
Но фундаментально, слава богу, что мы это сделали.
Вот и все.
Ну, да, после, если дошло, Абсолютно ни у кого нет никаких мыслей про то, что мы не должны
были этого делать.
Абсолютно на сто процентов.
полный саппорт, что это надо было делать, мы выправили язык, наконец-то можно вообще
понять, что в нем строка, а что в нем не строка.
И это было важно для меня.
Если одна группа лиц, это предприниматели, которые потеряли на этом много миллионов
долларов, то, конечно, они, может быть, по-другому чуть-чуть смотрят.
Тут нужно смотреть на это по-другому.
Тут нужно смотреть на это по-другому.
вот таких предпринимателей абсолютно не жалко.
По одной простой причине.
Потому что эти предприниматели, в принципе, очень многие появились благодаря Python.
То есть не секрет, что Instagram начался полностью с Python, что фаундеры Instagram
более-менее понимали Django на очень примитивном уровне.
Dropbox – та же самая фишка.
Django.
Pinterest.
Django.
Многие из этих продуктов не появились бы без Python, вполне возможно.
Если бы язык программирования C++, далеко не факт, что вот конкретно те, кто стали в
предпринимателями успешными, стали бы именно они ими.
Фиг его знает, как история бы положилась.
Поэтому тут нужно на самом деле смотреть.
Python — это язык, который очень многим позволил очень-очень быстро построить очень крутые
вещи.
И если уж так получилось, что языку нужен был очень серьезный сеанс у хиропрактора, ну,
может быть, всем нужно немножечко потерпеть и дать ему зажить.
И не переживать.
Сломали.
Сломали.
Слушай, да-да-да, мне кажется, мы очень круто прошлись по всему питону.
И ты уже несколько раз упоминал по поводу своего проекта.
Мне хочется об этом поговорить, потому что у тебя...
Ты уже упоминал, что тебя 20 человек работает, своей компании, ты уже, в общем-то,
достаточно давно занимаешься своим собственным бизнесом.
Расскажи чуть подробнее про эту историю.
Да, ну я быстро расскажу, собственно, предысторию.
Предысторию то, что в 2008 году я и мой кофландр Элвис, который, кстати, говорит по-русски
совершенно свободно, несмотря на имя Элвис, мы сделали компанию в 2008 году в Торонто,
которая делала Software Development, то есть мы другим компаниям помогали строить софт.
Как-то так получилось, что мы начали помогать сначала маленьким компаниям, а потом
закончили General Electric, Cisco, Microsoft, Pinterest и многими другими.
Набили руку на Software Development, получили опыт в Open Source и потом начали делать
свою компанию, потому что мы устали делать такой консалтинг-бизнес.
Это тяжелая работа.
И когда мы начинали свою компанию, мы подумали, что мы умеем делать очень хорошо.
Мы умеем очень хорошо программировать и мы знаем...
Мы знаем, где в мире программирования много боли.
И самое большое количество боли с нашей точки зрения в базах данных.
И основная проблема с базами данных заключается в том, что релиционные базы данных,
которые в принципе доминируют мир баз данных, они были разработаны в 70-х и с тех пор
особо ничего в них фундаментально нового не произошло с точки зрения конкретной
организации данных или языка запросов.
То есть SQL безусловно развивается, но фундаментально чем он был, тем он остался.
И таблицы с джоинами как были, так ими и остались.
Есть очень большая дырка между базами данных и языками программирования.
Программированные языки очень быстро развиваются, у есть очень много интересных вещей.
Там, не знаю, трейды, множественное наследование, перегрузка операторов.
классные разные языки программирования, оптимизирование на то или на другое.
А база данных — это такая вот штуковина, которая застряла полностью в 70-х.
Вот она там и живет.
И в связи с этим есть огромное количество проблем.
Во-первых, программисты не думают таблицами.
Мы думаем, нас, по сути, в голове граф данных, с которым мы сейчас работаем.
Программистам тяжело учить SQL, потому что SQL, несмотря на то, что декларативный,
синтаксис у него абсолютно забудробительный.
Но и самое что интересное — он и вербозный.
Но самое что интересное, опять-таки SQL это язык, который работает на таблицах, с
таблицами.
есть даже если ты используешь там какой-нибудь ORM, библиотеку, которая тебе позволяет
думать о своих данных, как будто бы они там, не знаю, питоновые классы или джубоскриптовые
классы или еще что-то, от SQL ты далеко не уйдешь никак.
Вот.
И есть определенные ORM, которые могут дать тебе чуть-чуть более там высокоуровневый API
для работы с базовыми данными.
Не знаю, там user.
Find by ID, например, или что-нибудь в этом роде.
Но как-то так получается, что когда ты меня пользуешь, ты пользуешься, не знаю, 3 %
способностями своей базы данных.
Если ты хочешь по-настоящему достать 100 % из базы данных, тебе надо использовать SQL, а
пользоваться им очень тяжело.
И мы подумали, что так не должно быть.
Это неправильно.
То есть это не то чтобы какой-то закон вселенной, что базы данных должны так сильно
отставать от языков программирования, от мейнстрима, не годит закон вселенных, что это
должно быть...
настолько больно с базами данных работать?
Что если мы попытаемся сдвинуть это все дело и сделать базу данных, которой будет работать
гораздо проще?
Что если мы можем поднять уровень абстракции значительно, улучшить модель данных, улучшить
типизацию и дать людям язык запросов, в котором есть много вея от современных языков
программирования?
что если мы сделаем так, этот язык запросов работал не на плоских данных, а на объектных
данных, на графе.
И так родилась идея HDB.
В 2019 году мы подняли первый раунд финансирования, переехали оба из Канады в
Сан-Франциско, и вот с тех пор мы ее собственно и строим.
Первая версия HDB была зарелизена в 2022 году.
И скоро будет версия 6.
Зарелизина.
И очень много интересных всяких разных вещей с ней произойдет.
Но в целом, грубо говоря, такой elevator pitch за GDB это то, что ее занимает поставить
время, наверное, не знаю, 5 секунд.
Поэтому, в отличие от пасгрейса, который можно поставить гораздо сложнее, ты можешь
ставить много параллельно разных версий, если тебе это интересно.
Есть поддержка бренчей, есть крутой cloud, есть крутой UI.
Мы переделали полностью NetR protocol по сгрессовой, таким образом, чтобы он был более
оптимальным, чтобы количество запросов туда-обратно практически никогда не превышало один
на любой запрос, связи с чем повысился перформанс.
Мы очень много лет потратили на язык запросов, который мы назвали EdgeQual, у которого у
нас цель, чтобы со временем он перегнал EdgeQual по возможностям, и где-то он перегоняет
его сейчас, где-то пока не догоняет, надо еще доработать.
Но с HQL абсолютно тривиально делать иерархические запросы на обновление данных, на
добавление данных, удаление данных и на запросы.
И в в одном квейре можно совершенно спокойно делать огромное количество разных вещей.
Вставлять данные, обновлять данные, удалять данные, доставать их из разных типов и так
далее.
За этим проектом стоит довольно сильная математическая база.
То мы самого начала понимали, что мы не можем...
Мы не можем сделать, грубо говоря, новую базу данных без какой-то правильной
математической основы.
Поэтому у нас, в принципе, по-русски, наверное, научная работа, по-английски это paper,
который мы сейчас пытаемся запаблишить на разных интересных конференциях этому
посвященному, где за нашей моделью данных и за языком запросов стоит самая настоящая
математическая модель, где мы показываем, как конкретно мы...
строим сверху длиционные модели, как конкретно мы её продвигаем вперёд.
То когда мы говорим, что мы знаем, что наш язык запросов быстрее, когда мы знаем, что он
более эффективный, когда мы знаем, что он поддерживает определённые вещи, например, как
Compose Ability, мы можем это подтвердить математически, греческими разными интересными
буквами.
И да, этом основная цель.
Основная цель — это дать людям современную базу данных, с которой они могут делать гораздо
больше, потому что они комфортны с языком запросов, которая устойчивая, которая быстрая и
так далее.
Мы строим ее на позгрессе, что вызвало довольно много дискуссий — база данных мы или не
база данных, и на это мой честный совершенно ответ мне честно пофиг, вы главное
пользуйтесь.
Почему мы строим это на Пасгрессе?
Потому что Пасгресса считает, наверное, одна из самых продвинутых баз данных в мире и
самых мощных.
И это имеет смысл это делать.
Потому что мы как компания не можем одновременно и движок базы данных построить, и язык
запросов, и модель данных, и весь тулинг вокруг этого всего и Cloud.
Надо где-то провести черту.
Вот пока что мы строим на Пасгрессе, и скорее всего, мы на нем и останемся.
Вот.
Но тем не менее, HDB — это база данных, которую ты ставишь.
Она сама менеджит внутри себя Пасгресс полностью.
Это такой двигатель.
под капотом ты не знаешь, он там, но если хочешь знать, знай.
Она полностью его менеджит.
Это ваша сборка пасгресса будет запускаться или это стандартный?
Мы поддерживаем ванильную тоже.
Долгое время у нас был нестандартный пасгресс, потому что нас заняло некоторое время
пофиксить определенные баги в пасгрессе, которые только мы нашли.
Так уж получается, что мы пасгресс реально на 120 процентов юзаем.
Все, что можно из Postgresа вытянуть, мы вытягиваем, чтобы наш High-Level модель нашу
запинать сверху.
Мы нашли несколько edge-кейсов и несколько лет нас заняло пофиксить это все в Postgres.
Теперь мы работаем на ванильном Postgres абсолютно.
Если ты пользуешься нашим Cloud, то опять-таки Postgres тебя знать не обязательно.
Но если ты хочешь пользоваться Open Source HDB, весь Open Source, и задеплоить его сам
куда-нибудь, то ты можешь его задеплоить сверху Google Postgres или AWS Aurora или еще
чего-нибудь.
Но почему мы это всё делаем?
Мы это делаем для того, чтобы люди могли очень быстро писать приложения свои на HDB.
И HDB начался как бы с идеи, давай мы дадим тебе крутой язык запросов, который любой может
выучить за 5 минут.
Похож с виду на GraphQL и SQL.
И модель данных, которой есть множественное наследование, абстрактные типы и так далее, то
есть она метчится с растом или с TypeScript на раз-два-три.
Очень мощная модель данных.
Сначала мы тебе дадим это, но со временем это все разрослось.
Теперь у HDB есть built-in модуль аутентификации, то есть вам не нужен Clorac, например,
если вам нужно делать логин пароли или IOU.
База данных сама это может за вас сделать, и даже UI вам сделает автоматически.
Недавно мы добавили поддержку AI и конкретно embedding, то есть ты просто говоришь, что
вот вот этом типе данных я хочу для него embedding создать.
Ты конфигурируешь какой конкретно, конфигурируешь, например, OpenAI или Anthropic.
И HDB сама будет полностью генерирует имбеддинг, и даже RUG endpoint даст тебе.
Добавился в это UI.
И, наверное, одна из самых мощных вещей — это Access Control, который у нас есть.
Потому наш Access Control полностью программируется, можешь объявлять так называемую
глобальную перемену у себя в схеме, давать им строгие типы, использовать их в триггерах, в
Access Policies, Policies на типах и так далее.
И база данных позволяет тебе часть своей бизнес-логики совершенно спокойно как бы...
декларативно объяснить на уровне базы данных, потом она инфорсится везде, полностью
автоматически.
И в SQL, и в HQL query, которые приходят, и во всем остальном.
И сам, я говорил, мне кажется, минут 10, но мне кажется, я рассказал, наверное, только топ
10 процентов того, что HDB на самом деле делает.
То есть это абсолютно гигантский получился проект, который довольно быстро сейчас
развивается, и в принципе, я считаю, что...
Мы, наверное, единственная попытка, серьезная, по-настоящему посмотреть на релационные
базы данных не просто с угла, а давайте мы все переделаем и будем делать скимулы, как
MongoDB, А с позиции того, что...
можем ли мы...
Вот как релационная база данных выглядела, если бы ее делали сейчас, а не в 1970 году?
Слушай, знаешь, у меня такой вопрос.
Я вот пока открыл сайт...
Кстати, ты говоришь edgeDB, меня почему-то слышится HDB сначала, я думаю, что за HDB?
Вот, да, HDB.
Я как раз недавно писал бэк для нода используя drizzle, потому что я как раз выбирал,
типа, какую сейчас взять, знаешь, современную ремку, которая нормальная, и слава богу.
Кстати, по-моему, украинцы ребята делают, я им даже что-то issues какие-то писал.
Вот, и drizzle мне очень понравился по сравнению со всем, что было до этого, потому что я
задолбался в ноде с этими ремами, проблема большая.
и даже призма там это не очень у них там есть свои проблемы но короче я посмотрел и там
действительно вот у тебя пример значит это конечно продажный пример вы выбрали очень
сложный кейс но типа когда у тебя ты смотришь над RISO вот я сейчас смотрю я вижу какого
размера там запрос и сложности что такое просто написать как бы без пол литра невозможно и
вашу штуку да у меня возникает вопрос а нельзя ли было просто этот язык как бы
имплементить на уровне
библиотеку языках и все можно быстро да я отвечу на этот вопрос с огромным удовольствием
но можно я сначала посмотрю на запрос прям на главный окей окей да да да вот прямо на
главный прямо на него сейчас смотрю я хочу конкретно аргументировать слово продажный я
понимаю в каком контесте ты сказал что мы хотели показать свой ну вы сложно скинуть да да
да да да но на самом деле вы давай мы этот запрос сейчас прочитаем это займет 10 секунд
все что в этом запросе происходит
Мы достаем из базы данных тип Movie, потому что это база данных типо MDB.
База данных хранит фильмы и актеров, которые в этом фильме играют, и ревью на эти фильмы.
Все, что этот запрос делает, он достает Movie по конкретному ID, достает для него title и
имена всех актеров, которые там были.
И считает рейтинг, средний рейтинг этого фильма по обзорам.
Я не могу сказать, что это сложный запрос.
Сама постановка вопроса здесь, она на самом деле интересна, потому что многие программисты
посмотрят на это и скажут, о, это сложный запрос.
Но на самом деле, с точки зрения даже того же самого сиквел, этот запрос абсолютно
тривиальный.
Если слушатели наши видели когда-нибудь серьезные запросы на сиквел, там не знаю
какой-нибудь там...
сложный отчет в какой-нибудь Fortune 500 компании или еще что-нибудь.
Там может быть 200 строк на SQL совершенно спокойно.
Это сложный запрос.
То, что мы делаем здесь, это тривиальный вопрос на самом деле.
Проблема в том, что за счет SQL, за счет ORM, за счет неэффективного вот этого вот моста
между миром приложений и баз данных, нам, программистам, включая меня, такие запросы
кажутся сложными.
Но на самом деле они абсолютно тривиальными.
является.
И в этом как раз и заключается наш драйв, почему мы этот продукт строим.
Потому что мы не хотим, программисты думали, что эти запросы сложны, эти запросы
элементарны.
Этот запрос должен занять у себя пять секунд, написать и зашипить в продакшн.
А вместо этого подобные запросы занимают 30 строк на дризл.
И самое что страшное, дризл сделает это не за один запрос, он сделает их за два запроса
или за три.
Prisma тратит пять сиквел запросов на вот этот вот квери.
Пять.
То есть, у тебя latency между твоей базой данных и бэкэндом там 5 мс, вот ты уже 25 мс
просто выбросил, потому что это просто вот ORM, это просто такс, налог ОРМа.
Поэтому, да, то есть я к тому говорю, что мы очень много времени потратили на это, сделать
это таким образом, это было не...
чтобы нам не нужно было, грубо говоря, лезть в карман за какими-то сложными запросами,
чтобы показать достоинство.
Мой фундаментальный вот такой вот...
момент заключается в том, что я искренне верю, что в HDB любой запрос, абсолютно любой, с
потолка будет в два-три раза короче, чем соответствующий сиквел, его будет гораздо проще
прочитать, он будет работать быстрее.
Но, опять-таки, ты задал вопрос про Drizzle, и почему HDB это HDB сама по себе?
Потому что мы решаем очень много разных проблем, на самом деле, и мы самое главное, хотим
эту проблему решить не только для джокскрипта.
или не только для питона.
Мы хотим эту проблему решить для всех.
То есть вот конкретно сейчас просто с точки зрения вот ресурсов.
Мы не можем как компания себе позволить просто взять и написать базу данных полностью на
расти.
Хотя, честно скажу, очень сильно бы хотелось просто с нуля взять и написать галактическую
классную розовую базу данных образцово-показательную с нуля.
Это было бы круто.
Вот.
Но это невозможно.
Потому что в пасгре заложили там, не знаю.
20 лет своей жизни очень много талантливых инженеров.
такие вещи быстро не пишутся.
Как RoachDB была подобной попыткой, и в принципе до сих пор они еще, я думаю, по
стабильности, по сгреться не догнали.
То есть писать свой engine, database, это капитальный инвесмент на потенциально много
десятков миллионов долларов или сотен.
Поэтому мы сделали Hang.
Мы как бы строим что-то, что выглядит как база данных.
потому что у нее свой собственный сетевой протокол, свои утилиты для установки, свой язык
запросов, свой язык моделинга схемы, своя схема, своя модель данных, то есть оно wax like
a duck, то есть оно со всех сторон выглядит как database server.
Но есть implementation detail, то что Engine за этим всем пока позгрес.
Что произойдет дальше, я не знаю, может быть мы форкнем позгрес и просто заембедим его, мы
сейчас переписываем на Rust полностью движок свой.
Вполне возможно, мы будем просто гонять по сгресу внутри.
А вполне возможно, мы когда-нибудь станем очень успешными, разрастемся и по сгресу нам
будет больше не нужен.
Но опять-таки наша амбиция здесь не сделать очередную библиотеку, наша амбиция сделать
самую следующую базу данных, которая будет просто гораздо более высокоуровнен, гораздо
более мощная, чем то, что есть сейчас.
Ну вот пока что, пока что движемся в этом направлении.
Юр, большое спасибо, что пришел.
Мне было безумно интересно про Python узнать из первых рук и я надеюсь, нашим слушателям и
смотрятелям, кто будет смотреть на YouTube, это тоже интересно.
Ребят, ставьте свои лайки, подписывайтесь.
Я думаю, что это не последний раз.
И, как видите, у Python Bright Future, так что все будет хорошо и...
Будем надеяться.
Значит, используйте его во все поля, пишите свои комментарии, будет интересно, что вы
думаете о том, что мы обсудили.
Спасибо, Юр.
Еще раз, пока.