Да проблема транзакционности. Миша выше уже описал, это фиксится transactional outbox'ом в некоторых случаях (мы это применяем иногда), просто в гайд все не внесёшь, не было желания его раздувать
Что такое «определенно пользоваться надо им очень аккуратно»? Можно чуть подробнее? Потому что это отдаёт оккультным посылом. Мы много лет им пользуемся и это довольно простая и дубовая штука. Ты её описываешь пока скорее как нечто тайно-опасное, что мне кажется преувеличением.
«преподносится он как готовое решение» — это готовое решение, которому много лет. К тому же в статье специально много примечаний вроде «В нашей концепции» или «Сразу хотим предупредить! Несмотря на то, что эти рекомендации применяются в наших командах и кажутся нам довольно полезными, они вовсе не являются единственно верными». Т.е. если есть, на мой взгляд, очень сильно преувеличенные опасения на тему pydantic-settings (стабильного проекта), то можно просто им не пользоваться. Наш опыт многих энтерпрайзных сервисов и многих лет в продакшене показывает, что проблем с этой штукой просто нет и достаточно даже странно слышать такие опасения на тему этого маленького и довольно незначительного и безобидного проекта.
Я не могу сказать, что я согласен с такими строгими рестрикциями. Ещё раз сошлюсь на наш опыт, у нас сотни переменных (на один сервис, а всего их многие тысячи, мы храним их в волте и закидываем через конфигмепы и секреты) и десятки (скорее уже сотни сервисов) и тысячи инстансов, которые нас окружают везде, которые спокойно работают на подходе, изложенном в статье. Т.е. на мой вкус это это просто избыточные рестрикции, которые никак не обоснованы.
Раскрой, пожалуйста, откуда растут твои опасения и как часто это «стреляет» в продакшене? Потому что на нашем скейле мы такого и не встречаем.
При загрузке энва явно передавать путь.
Путь к чему? Это переменные окружения. В нашей трактовке. Со всем уважением, у нас это работает.
Не использовать вложенные сеттинги для тех источников, которые нативно это не умеют.
Мы не предлагали. В статье нет такого
Проектировать формат и структуру конфигурации, а не полагаться на библиотеку
Абстрактный посыл, на мой взгляд. Что значит «проектировать» в данном контексте?
Под каждый источник данных иметь свой класс PydanticSettings со своей настройкой алиасов и т.п. Это позволит нормально переключакться между ними.
Да, Миша глаголет базу. Когда в своё время я растаскивал такую штуку по сервисам, я её растащил вообще везде, даже на фронтенд затащил. Все в курсе, что есть такой объект settings, в котором лежат настройки. Просто, понятно и за годы использования я не встречал его критики (ну кроме этой статьи) %)
Там есть опция case_sensitive для таких случаев, это вроде бы закрывает вопрос.
Но если быть откровенным, мы за 5 лет работы с таким подходом (ну ладно, года за 4, потому что до этого мы таскали/писали вот такие пакеты — https://github.com/xfenix/envcast) ни разу на таком не подрывались, чтобы кто-то заводил переменные с одинаковыми именами в разном регистре. При том, что у нас на приложение может быть легко около двух сотен переменных, например.
Странно, я не могу понять почему «слишком сомнительно».
Ты же знаешь преимущества пакета — это опции настройки, енв файлы, case_sensitive, env_prefix. Ну то есть в чём претензия, раскрой, пожалуйста. Что мы используем для парсинга енвов предназначенный для этого пакет? Может лучше написать Самуелю, что тебе не нравится его пакет?
Для нашего кейса это и справедливо и осмысленно. Мы используем время от времени .env файлы (у Миши может и нет, но в других командах бывает), используем и префиксы так же. Плюс мы иногда делаем иерархические настройки, которые можно удобно настраивать. Зачем ради этого писать лишний код я не понимаю, кроме того экономия на размере пакета (а он небольшой) нам действительно не актуальна, у нас и так довольно жирные образы.
А сомнительно почему? pydantic_settings не даёт плюсов почему?
У нас этот «паттерн» работает хорошо. Ты всегда знаешь, что в project_name лежит settings.py из которого ты достаешь глобальный объект с настройками, которые могут потребляться из любого окружения. Чем это хорошо:
Если вы используете язык, который может выдавать бинарные файлы, задача по установке всех зависимостей с правильными версиями является одноразовой: это происходит во время сборки. Это не происходит каждый раз при запуске программы. Более того: этот процесс можно автоматизировать, чтобы результат можно было распространять.
Нет, это не так. Ты код обновляешь от раза к разу, и точно так же собираешь его. «В питоне» есть прекрасная альтернатива процессу компиляции — докер! И ровно все тоже самое получается, только артефакты чуть жирнее получаются, зато уже везде под это готовые системы доставки и оркестрации есть. Т.е. вполне есть себе сборка. А до этого люди и rpm не стеснялись делать.
Каждый раз, когда вы запускаете программу на Python, все зависимости должны присутствовать
Как и в любой другой программе. Например, so/dll библиотеки тоже должны быть часто.
Если один из них внезапно пропал, был обновлен или требуемая версия Python недоступна, ваша программа скорее всего не запустится
Так любой софт работает.
Каждое обновление в цепочке зависимостей любых из используемых нами инструментов, сопряжено со значительными рисками сломать нашу среду сборки
У новых версий появляются несовместимости. Опять же, не питон это придумал, в любом другом языке у тебя есть зависимости от внешних библиотек, которые тоже имеют свойство меняться и ломаться время от времени.
Многие встроенные зависимости неприемлемо хрупкие
Увы, но это спекуляция пока не приведены примеры (многие примеры).
Хотите решать проблемы, возникшие из-за выбора Python?
Если я не хочу, то тогда мне придется решать проблемы, возникшие из-за выбора %LanguageName%.
Если вы используете Python сегодня, я думаю, что вы просто обязаны попробовать сделать несколько небольших проектов на языках, более подходящих для создания простых инструментов, которые работают независимо от того, как настроена ваша система
Пользовался и языки норм. Но когда тебе спустя пару лет надо вернуться к своему проекту на Go, ты внезапно обнаруживаешь, что все зависимости сломались и дико поменялись. У меня от момента первого написания до возврата к таким проектам в язык успели втащить систему модулей, например. Пойду ли я писать о том, что Go не надо использовать? Конечно нет! Потому что все абсолютно нормально.
В крайнем случае, даже Java представляет лучшую альтернативу, поскольку у вас есть возможность создавать файлы «jar», содержащие все зависимости. Не модный, но объективно куда менее хрупкий вариант.
И всё ещё обращу внимание на docker.
Я говорю это, потому что потратил слишком много недель на то, чтобы заставить плохо продуманные инструменты работать, я не увидел значительных улучшений за последние годы
Надо обсуждать конкретные примеры. Пока это звучит как «у меня что-то сломалось, не используйте python».
Разве что, чисто для протокола, я не джавист, и джаву тоже не люблю :]
Простите, приписал лишнего! К джаве, кстати, я спокойно отношусь. Мне кажется, как и у любого языка, у неё есть недостатки и есть свои позитивные стороны и, соответственно, чему поучиться.
Спасибо, что нашли время написать комментарий! Очень приятно, что вы отметили подачу, я именно такой тон хотел задать статье и стараюсь так подходить ко всей коммуникации. Не всегда получается, но я работаю с этим.
Не сочтите за пафос: я не забываю, что я просто человек со своим скромным опытом, которому в данном случае повезло высказать свое субъективное мнение.
Другим языкам желаю развития и успеха, т.к. на мой взгляд, языковое разнообразие даёт возможность нам всем развиваться.
Дядя Боб — это, конечно, специалист, но специалист в ООП и прочих аджайлах, а не в типизации
А кто у нас в принципе признанный всеми авторитет в области типизации? Такой формулировкой можно, по-хорошему, отсеивать вообще любые мнения, включая и собственное.
Ну если говорить об эмпирике и личном опыте — на голом питоне (или жс, или любом другом языке) без типов я писать не могу, моя производительность как функция от объёма уже написанного кода падает экспоненциально и в районе 50-100 строк становится неотличима от нуля.
У нас это не так, у нас все хорошо в районе десятков-сотен тысяч строк. Т.е. тут имеет место проблема личного восприятия языка, а не фундаментальная проблема самого языка.
Например коллеги из Я пишут огромные бекенды в 500+ тысяч строк кода и они у них работают, а сами они довольно продуктивны. К сожалению, не могу рассказать больше, но можете поспрашивать.
куча библиотек была неаннотирована
С этим лучше, но все ещё такое встречается. В целом, это пока не слишком хорошо, но работать с этим можно. Можно и свои стабсы писать для сторонних библиотек при желании максимальной надежности. У нас выходит и без этого.
Ну и я не понял, зачем оно такое надо, если новые проекты можно писать сразу на языках, более дружественных к выразительной типизации и при этом не требующих кучу ритуалов, ассоциирующихся с типизацией у среднего джависта
Вот! Вы, как джавист, не хотите писать на питоне. А питонисты хотят писать на питоне. Аннотации — для питонистов, не для джавистов. И для питонистов они выполняют полностью все возложенные на них ожидания — повышают надежность кода.
Мы относимся с уважением к мнению экспертов в других языках, но для нас польза видна и она есть.
К этим исследованиям (особенно тому самому про проекты на гитхабе) есть методологические вопросы
Как и ко многим другим, доказывающим преимущество статической типизации https://danluu.com/empirical-pl/. Тут я все таки еще опираюсь и на Uncle Bob и на некоторых других. Конечно, тут можно мне впаять аппеляцию к авторитетам, но т.к. поле информации огромно, а на миллион проектов посмотреть я не могу и не смогу, мало что остаётся. В основном, я тут топлю за python, не против других языков :)
Обратно, есть и такое исследование — там брали проекты на JS, выбирали коммиты, чинящие баги, добавляли аннотации типов в окрестности бажного кода, и смотрели, сколько багов поймается (поймалось 15%).
Надо почитать, тут так то просто выводы сходу не сделаешь. Информация как минимум любопытная, спасибо.
Тогда более-менее равное распределение багов по всем языкам будет как раз ожидаемым
Вероятно, ну у нас тут довольно эмпирическое поле, конечно. Исследований, надежных, исчезающе мало, поэтому я предпочитаю не считать, например, что аннотации — припарка от всего, такого точно нет. Я считаю, что они повышают надежность и даже по исследованию выше — это так и есть. Но и без исследований, чисто эмпирически, и я и многие коллеги находим с ними проблемы и почти никогда я не встречаю в наших проектах type error'ы. На нашем коде — точно нет.
о что он под капотом использует (почти всегда) базы данных, не делает что же базы данных backend-ом?!
А почему нет? БД — часть бекенда. Если ты пишешь свою БД — написанный тобой бекенд.
А если я числодробилку в WebWorker-е подключу в браузерной вкладке будет ли это frontend-ом?
Так это фронтенд. Можно сказать, что бекенд фронтенда, если так удобнее. Но код будет крутится на клиенте и формально попадать под определение фронтенд. Даже написан он будет на JS. И заниматься им будут фронтендеры.
Едва ли. Просто косвенное задействование сопутствующих технологий.
Вот тут речь о терминологии. Обычно она размытая, но БД расположена на беке, а вебворкер на фронте.
Про бекенд — у нас бекенд на питоне, делает ML предикшены. Чат-бот. Вот он бек, он слушает рэббит, там весь код нами написан. Я считаю его бекендом и это нормально. При том что на клиентов смотрит сервис перед ним. Все эти термины — про разделение проблем. Ну то есть можно назвать это «глубоким бекендом», можно как угодно, но факт в том, что это крутится в наших контейнерах, пишется нами и деплоится тоже нами. Более того, я общаюсь с нашими датасайентистами и мы пишем общие продукты. Для нас проблемы даже общие зачастую.
Если бы мы называли только front-faced сервисы бекендом, то в этом мире не существовало такого явления как tracing, например!
В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
Моя цитата была такой, пожалуйста, не вырывайте из неё кусок в свою пользу. Значительно не уступает. Он работает в той степени, что хватает бизнесу. У нас очень мало ошибок в рантайме, а связанных с типам около ноля. И у языков со статической типизацией ошибки в рантайме тоже бывают, есть про это и исследования.
Ну вот да, с точки зрения бизнеса я бы не выбирал инструмент где такая важная часть
Несмотря на некорректную цитату, скажу про это: если бы бизнес выбирал только идеальные инструменты, бизнес бы не выбирал ничего, т.к. таких инструментов нет. Выбор бизнеса не про технологии и не про надежность, а скорее про рынок, популярность и наличие специалистов. И с последним абсолютно у всех сейчас проблемы (большой дефицит всех).
Даже у вас в банке, как много сервисов написанных не на python ?
Я возможно создал неправильное впечатление и прошу за это прощения!
Я не хотел сказать, что у нас ВЕСЬ банк на python пишут, или что он у нас главный язык, возможно я создал несколько неправильный посыл.
Питонистов у нас относительно джавистов, мало, как и в любом банке. Конечно же у нас огромная кодовая база на джаве и никто её никуда не девает и от неё не отказывается. Джава здорова, бодра, весела и много крутых джавистов.
А я развиваю питон сообщество, не так давно, буквально второй год и рассказываю почему питон хорош, в том числе, как альтернативный стек внутри, а теперь и снаружи банка. Питонистов у нас в банке много, но далеко не все из них бекендеры.
Да, в 3-й версии Питона появились средства явного указания типов, т.е. авторы языка сделали большой шаг в сторону статической типизации, но на текущий момент эти новые фичи слабо поддерживаются как сообществом, так и интерпретатор довольно лоялен к нарушению типизации (по сравнению со строгими языками).
Проблема в том, что автор, скорее всего, на другом языке пишет. Он смешал вместе аннотации типов и типизацию. Виртуальной машине безразличны аннотации, они существуют сбоку и до нее не доезжают. Типизация в питоне — динамическая, строгая, утиная. Gradual типизация — подставлена сбоку с помощью аннотаций. Так же сбоку подставили Structural sub-typing (typing.Protocol). И работает это все довольно неплохо уже. Mypy стал сильно лучше и дает делает тайп гарды, сужение типов. В целом, по ощущению, чуть послабее всё это развито сейчас чем в TypeScript (в котором все отлично), может и не пройдет проверку на типобезопасность, но надежность кода сильно повышается. Мы type error не ловим в своем коде никогда, например.
И это не всё. Есть выдающиеся проекты — pydantic и fastapi. Они берут аннотации типов и в рантайме из них делают супер строгую валидацию, сваггер, можно даже «типизированные» настройки потреблять из окружения согласно 12 факторам.
Т.е. мы сейчас из аннотаций извлекаем пользу и на этапе статического анализа и динамически, в рантайме.
Но, если ваша программа разрастается до больших размеров, то тут уже IDE часто сдается, перестает помогать и уходит много времени на выяснение типов и доступных методов
Про это писал в статье. Время микросервисов, можно сейчас не раздувать монолиты. К тому же: коллеги из больших и уважаемых компаний, имеют у себя разработки на питоне исчисляемые сотнями тысяч строк кода на питоне. И полет у них нормальный.
На мой взгляд ретурн-тайп и аннотации выглядят как костыли которые ломают принципы языка.
Часто я слышу это от людей, которые на питоне не пишут и зачастую его не любят.
Я смотрю на эти вещи гибко. Эти «костыли» Гвидо почти 20 лет назад описывал ещё, и тогда никому они костылями не казались. Просто у многих людей сложилось впечатление о языке исходя из The Zen of Python, и судят они язык прям строго по нему. Все просто, для всего один путь, красиво, тут def, тут for, тут мы скриптик написали, а дальше отойдите, дайте дорогу «серьезным людям с серьезными языками» :). А зен размещен на странице с говорящим названием https://www.python.org/doc/humor/. Это всего-лишь шутливый текст, а не свод предписаний.
Язык живет и меняется и это нормально, это здорово, да даже прекрасно.
Gradual типизация — здоровый компромисс между статической типизацией и динамической. Можно быстро, понятно, надежно и не надо выбирать из трёх, можно все три.
Никто не отменял языки со статической типизацией, никто не говорит, что они плохие. Просто питон действительно по совокупности факторов тоже теперь сильный игрок, вот о чём я и говорю, о чём и написал статью.
Уступает, так как даже самые древние библиотеки будут использовать статическую типизацию . Например в Java , возьмите любую библиотеку и вы точно будете знать, что вам возвращается и как с этим объектом работать . Основное преимущество статической типизации это четкий контракт взаимодействия для любой версии языка .
Поэтому я и написал — «значительно».
Кроме того, у питона есть ответ на это — .pyi и py.typed, typeshed, теперь types-*
Пока это работает не идеально. В TypeScript тот же types сильно круче, даже у самых мелких пакетов нередко есть *.d.ts.
Вполне возможно, что я не прав и просто хочу из python сделать java ))
Да у языков много общего. Сейчас у питона появился статический анализ, питон компилируется в байт код и исполняется на виртуальной машине...
Да проблема транзакционности. Миша выше уже описал, это фиксится transactional outbox'ом в некоторых случаях (мы это применяем иногда), просто в гайд все не внесёшь, не было желания его раздувать
Что такое «определенно пользоваться надо им очень аккуратно»? Можно чуть подробнее? Потому что это отдаёт оккультным посылом. Мы много лет им пользуемся и это довольно простая и дубовая штука. Ты её описываешь пока скорее как нечто тайно-опасное, что мне кажется преувеличением.
«преподносится он как готовое решение» — это готовое решение, которому много лет. К тому же в статье специально много примечаний вроде «В нашей концепции» или «Сразу хотим предупредить! Несмотря на то, что эти рекомендации применяются в наших командах и кажутся нам довольно полезными, они вовсе не являются единственно верными». Т.е. если есть, на мой взгляд, очень сильно преувеличенные опасения на тему pydantic-settings (стабильного проекта), то можно просто им не пользоваться. Наш опыт многих энтерпрайзных сервисов и многих лет в продакшене показывает, что проблем с этой штукой просто нет и достаточно даже странно слышать такие опасения на тему этого маленького и довольно незначительного и безобидного проекта.
Я не могу сказать, что я согласен с такими строгими рестрикциями. Ещё раз сошлюсь на наш опыт, у нас сотни переменных (на один сервис, а всего их многие тысячи, мы храним их в волте и закидываем через конфигмепы и секреты) и десятки (скорее уже сотни сервисов) и тысячи инстансов, которые нас окружают везде, которые спокойно работают на подходе, изложенном в статье. Т.е. на мой вкус это это просто избыточные рестрикции, которые никак не обоснованы.
Раскрой, пожалуйста, откуда растут твои опасения и как часто это «стреляет» в продакшене? Потому что на нашем скейле мы такого и не встречаем.
Путь к чему? Это переменные окружения. В нашей трактовке. Со всем уважением, у нас это работает.
Мы не предлагали. В статье нет такого
Абстрактный посыл, на мой взгляд. Что значит «проектировать» в данном контексте?
Что такое источник? О каких алиасах речь идет?
Да, Миша глаголет базу. Когда в своё время я растаскивал такую штуку по сервисам, я её растащил вообще везде, даже на фронтенд затащил. Все в курсе, что есть такой объект settings, в котором лежат настройки. Просто, понятно и за годы использования я не встречал его критики (ну кроме этой статьи) %)
Там есть опция case_sensitive для таких случаев, это вроде бы закрывает вопрос.
Но если быть откровенным, мы за 5 лет работы с таким подходом (ну ладно, года за 4, потому что до этого мы таскали/писали вот такие пакеты — https://github.com/xfenix/envcast) ни разу на таком не подрывались, чтобы кто-то заводил переменные с одинаковыми именами в разном регистре. При том, что у нас на приложение может быть легко около двух сотен переменных, например.
Странно, я не могу понять почему «слишком сомнительно».
Ты же знаешь преимущества пакета — это опции настройки, енв файлы, case_sensitive, env_prefix. Ну то есть в чём претензия, раскрой, пожалуйста. Что мы используем для парсинга енвов предназначенный для этого пакет? Может лучше написать Самуелю, что тебе не нравится его пакет?
Для нашего кейса это и справедливо и осмысленно. Мы используем время от времени .env файлы (у Миши может и нет, но в других командах бывает), используем и префиксы так же. Плюс мы иногда делаем иерархические настройки, которые можно удобно настраивать. Зачем ради этого писать лишний код я не понимаю, кроме того экономия на размере пакета (а он небольшой) нам действительно не актуальна, у нас и так довольно жирные образы.
А сомнительно почему? pydantic_settings не даёт плюсов почему?
У нас этот «паттерн» работает хорошо. Ты всегда знаешь, что в project_name лежит settings.py из которого ты достаешь глобальный объект с настройками, которые могут потребляться из любого окружения. Чем это хорошо:
— унифицировано
— наглядно
— просто
Наш кейс — разработка приложений.
В бонус ты можешь сделать вот такой автоматически обновляемый каталог env переменных (если вдруг хочешь в маркдауне): https://github.com/xfenix/spellcheck-microservice/tree/main?tab=readme-ov-file#config-options
https://github.com/xfenix/spellcheck-microservice/blob/main/.github/workflows/pipeline.yml#L97
Нет, это не так. Ты код обновляешь от раза к разу, и точно так же собираешь его.
«В питоне» есть прекрасная альтернатива процессу компиляции — докер! И ровно все тоже самое получается, только артефакты чуть жирнее получаются, зато уже везде под это готовые системы доставки и оркестрации есть. Т.е. вполне есть себе сборка. А до этого люди и rpm не стеснялись делать.
Как и в любой другой программе. Например, so/dll библиотеки тоже должны быть часто.
Так любой софт работает.
У новых версий появляются несовместимости. Опять же, не питон это придумал, в любом другом языке у тебя есть зависимости от внешних библиотек, которые тоже имеют свойство меняться и ломаться время от времени.
Увы, но это спекуляция пока не приведены примеры (многие примеры).
Если я не хочу, то тогда мне придется решать проблемы, возникшие из-за выбора %LanguageName%.
Пользовался и языки норм. Но когда тебе спустя пару лет надо вернуться к своему проекту на Go, ты внезапно обнаруживаешь, что все зависимости сломались и дико поменялись. У меня от момента первого написания до возврата к таким проектам в язык успели втащить систему модулей, например. Пойду ли я писать о том, что Go не надо использовать? Конечно нет! Потому что все абсолютно нормально.
И всё ещё обращу внимание на docker.
Надо обсуждать конкретные примеры. Пока это звучит как «у меня что-то сломалось, не используйте python».
Отличная статья, у которой незаслуженно мало просмотров! Спасибо за ваш труд!
Простите, приписал лишнего! К джаве, кстати, я спокойно отношусь. Мне кажется, как и у любого языка, у неё есть недостатки и есть свои позитивные стороны и, соответственно, чему поучиться.
Спасибо за ваши комментарии! :)
Спасибо, что нашли время написать комментарий! Очень приятно, что вы отметили подачу, я именно такой тон хотел задать статье и стараюсь так подходить ко всей коммуникации. Не всегда получается, но я работаю с этим.
Не сочтите за пафос: я не забываю, что я просто человек со своим скромным опытом, которому в данном случае повезло высказать свое субъективное мнение.
Другим языкам желаю развития и успеха, т.к. на мой взгляд, языковое разнообразие даёт возможность нам всем развиваться.
Если вы про квайны, то можно, есть еще интерпретатор питона на питоне.
А кто у нас в принципе признанный всеми авторитет в области типизации? Такой формулировкой можно, по-хорошему, отсеивать вообще любые мнения, включая и собственное.
У нас это не так, у нас все хорошо в районе десятков-сотен тысяч строк. Т.е. тут имеет место проблема личного восприятия языка, а не фундаментальная проблема самого языка.
Например коллеги из Я пишут огромные бекенды в 500+ тысяч строк кода и они у них работают, а сами они довольно продуктивны. К сожалению, не могу рассказать больше, но можете поспрашивать.
С этим лучше, но все ещё такое встречается. В целом, это пока не слишком хорошо, но работать с этим можно. Можно и свои стабсы писать для сторонних библиотек при желании максимальной надежности. У нас выходит и без этого.
Вот! Вы, как джавист, не хотите писать на питоне. А питонисты хотят писать на питоне. Аннотации — для питонистов, не для джавистов. И для питонистов они выполняют полностью все возложенные на них ожидания — повышают надежность кода.
Мы относимся с уважением к мнению экспертов в других языках, но для нас польза видна и она есть.
Согласен. Спасибо!
Graal VM — интереснейший проект!
Как и ко многим другим, доказывающим преимущество статической типизации https://danluu.com/empirical-pl/. Тут я все таки еще опираюсь и на Uncle Bob и на некоторых других. Конечно, тут можно мне впаять аппеляцию к авторитетам, но т.к. поле информации огромно, а на миллион проектов посмотреть я не могу и не смогу, мало что остаётся. В основном, я тут топлю за python, не против других языков :)
Надо почитать, тут так то просто выводы сходу не сделаешь. Информация как минимум любопытная, спасибо.
Вероятно, ну у нас тут довольно эмпирическое поле, конечно. Исследований, надежных, исчезающе мало, поэтому я предпочитаю не считать, например, что аннотации — припарка от всего, такого точно нет. Я считаю, что они повышают надежность и даже по исследованию выше — это так и есть. Но и без исследований, чисто эмпирически, и я и многие коллеги находим с ними проблемы и почти никогда я не встречаю в наших проектах type error'ы. На нашем коде — точно нет.
А почему нет? БД — часть бекенда. Если ты пишешь свою БД — написанный тобой бекенд.
Так это фронтенд. Можно сказать, что бекенд фронтенда, если так удобнее. Но код будет крутится на клиенте и формально попадать под определение фронтенд. Даже написан он будет на JS. И заниматься им будут фронтендеры.
Вот тут речь о терминологии. Обычно она размытая, но БД расположена на беке, а вебворкер на фронте.
Про бекенд — у нас бекенд на питоне, делает ML предикшены. Чат-бот. Вот он бек, он слушает рэббит, там весь код нами написан. Я считаю его бекендом и это нормально. При том что на клиентов смотрит сервис перед ним. Все эти термины — про разделение проблем. Ну то есть можно назвать это «глубоким бекендом», можно как угодно, но факт в том, что это крутится в наших контейнерах, пишется нами и деплоится тоже нами. Более того, я общаюсь с нашими датасайентистами и мы пишем общие продукты. Для нас проблемы даже общие зачастую.
Если бы мы называли только front-faced сервисы бекендом, то в этом мире не существовало такого явления как tracing, например!
Более того, термины всё таки неточно определены, они про разделение концептов. Вот, например softwareengineering.stackexchange.com/questions/415908/is-the-database-part-of-the-backend целое обсуждение на тему БД — это бекенд или нет. Однозначного ответа нет, хотя многие склоняются к моему видению.
О, писал на php 6 лет когда-то.
Моя цитата была такой, пожалуйста, не вырывайте из неё кусок в свою пользу. Значительно не уступает. Он работает в той степени, что хватает бизнесу. У нас очень мало ошибок в рантайме, а связанных с типам около ноля. И у языков со статической типизацией ошибки в рантайме тоже бывают, есть про это и исследования.
Несмотря на некорректную цитату, скажу про это: если бы бизнес выбирал только идеальные инструменты, бизнес бы не выбирал ничего, т.к. таких инструментов нет. Выбор бизнеса не про технологии и не про надежность, а скорее про рынок, популярность и наличие специалистов. И с последним абсолютно у всех сейчас проблемы (большой дефицит всех).
Я возможно создал неправильное впечатление и прошу за это прощения!
Я не хотел сказать, что у нас ВЕСЬ банк на python пишут, или что он у нас главный язык, возможно я создал несколько неправильный посыл.
Питонистов у нас относительно джавистов, мало, как и в любом банке. Конечно же у нас огромная кодовая база на джаве и никто её никуда не девает и от неё не отказывается. Джава здорова, бодра, весела и много крутых джавистов.
А я развиваю питон сообщество, не так давно, буквально второй год и рассказываю почему питон хорош, в том числе, как альтернативный стек внутри, а теперь и снаружи банка. Питонистов у нас в банке много, но далеко не все из них бекендеры.
Проблема в том, что автор, скорее всего, на другом языке пишет. Он смешал вместе аннотации типов и типизацию. Виртуальной машине безразличны аннотации, они существуют сбоку и до нее не доезжают. Типизация в питоне — динамическая, строгая, утиная. Gradual типизация — подставлена сбоку с помощью аннотаций. Так же сбоку подставили Structural sub-typing (typing.Protocol). И работает это все довольно неплохо уже. Mypy стал сильно лучше и дает делает тайп гарды, сужение типов. В целом, по ощущению, чуть послабее всё это развито сейчас чем в TypeScript (в котором все отлично), может и не пройдет проверку на типобезопасность, но надежность кода сильно повышается. Мы type error не ловим в своем коде никогда, например.
И это не всё. Есть выдающиеся проекты — pydantic и fastapi. Они берут аннотации типов и в рантайме из них делают супер строгую валидацию, сваггер, можно даже «типизированные» настройки потреблять из окружения согласно 12 факторам.
Т.е. мы сейчас из аннотаций извлекаем пользу и на этапе статического анализа и динамически, в рантайме.
Про это писал в статье. Время микросервисов, можно сейчас не раздувать монолиты. К тому же: коллеги из больших и уважаемых компаний, имеют у себя разработки на питоне исчисляемые сотнями тысяч строк кода на питоне. И полет у них нормальный.
Часто я слышу это от людей, которые на питоне не пишут и зачастую его не любят.
Я смотрю на эти вещи гибко. Эти «костыли» Гвидо почти 20 лет назад описывал ещё, и тогда никому они костылями не казались. Просто у многих людей сложилось впечатление о языке исходя из The Zen of Python, и судят они язык прям строго по нему. Все просто, для всего один путь, красиво, тут def, тут for, тут мы скриптик написали, а дальше отойдите, дайте дорогу «серьезным людям с серьезными языками» :). А зен размещен на странице с говорящим названием https://www.python.org/doc/humor/. Это всего-лишь шутливый текст, а не свод предписаний.
Язык живет и меняется и это нормально, это здорово, да даже прекрасно.
Gradual типизация — здоровый компромисс между статической типизацией и динамической. Можно быстро, понятно, надежно и не надо выбирать из трёх, можно все три.
Никто не отменял языки со статической типизацией, никто не говорит, что они плохие. Просто питон действительно по совокупности факторов тоже теперь сильный игрок, вот о чём я и говорю, о чём и написал статью.
Поэтому я и написал — «значительно».
Кроме того, у питона есть ответ на это — .pyi и py.typed, typeshed, теперь types-*
Пока это работает не идеально. В TypeScript тот же types сильно круче, даже у самых мелких пакетов нередко есть *.d.ts.
Да у языков много общего. Сейчас у питона появился статический анализ, питон компилируется в байт код и исполняется на виртуальной машине...