Объясните про twisted

twisted

не нужно

Не нужно, а что поделать, на нем написан критичный модуль, который без вазелина лучше не трогать

Ну вот и не трогай. А если всё же приспичит трогать, то перепиши на asyncio.

Там коннектор к весьма специфичной железке в виде протокола, его с твистеда переписать надо присесть сильно больше одного раза

дикая попытка под тяжёлыми наркотиками написать джангу на корутинах без aio

Нас спалили, валим отсюда.

В целом - twisted действительно довольно специфичная штука. Возможно просто код той либы которую ты ковыряешь - говно. А может и not enough mana на твоей стороне.

Плюсую этого парня. Twisted это говно мамонта из тех времен, когда async не существовало. Пытаться поддерживать что-то на twisted сейчас это такой же сизифов труд, как и держать в актуальном состоянии проект на python2 в 2021 году.

Чем дольше копаю эту штуку, тем больше кажется что это какая- то дикая попытка под тяжёлыми наркотиками написать джангу на корутинах без aio (которого тогда не было).

Python в асинхрощине - это в целом боль. Язык не проектировался для подобных задач.

Последний эпизод общения с твистедом закончился порванным контекстом, тупящей кафкой и горящим пердаком.

Вот вы едите кактус… Не проще взять Golang, NodeJS или Elixir, если вам нужна асинхронщина?

Я конечно тупой, но как нормально (без стенда) тестить и дебажить эту шарманку до меня так и не дошло, равно как и не дошёл life cycle протокола.

Давайте прежде чем всё это дело разгребать решим, а зачем вам в целом асинхронность в данном сервисе? Вероятно, для ваших задач и Flask будет более чем достаточно.

Это только мои задвиги и я просто не раскурил священный Deferred, или кому-то еще тоже так кажется?

Вы просто пытаетесь использовать инородную сущность для Python и с привычками «синхронного» программиста. Так не работает

просто проходи мимо, он старый, а жизнь одна и тратить её на устаревший подход нет смысла.

В питоне есть куча нового, используй его.

Не проще взять Golang, NodeJS или Elixir, если вам нужна асинхронщина?

Конечно проще, прям так взять один из 50 модулей (ещё и наиболее критичный) и переписать его с нуля на другой язык, который ещё и никто в команде не знает. Звучит как план

Давайте прежде чем всё это дело разгребать решим, а зачем вам в целом асинхронность в данном сервисе

А я и не говорил что она мне нужна. Суть - 5 лет назад кто-то написал модуль на твистеде потому что только под него была реализация протокола к весьма специфичному железу (которую к слову и так пришлось под третий пистон адаптировать ибо EOL). Если б была реализация на фласке - твистеда бы там не было.

Конечно проще, прям так взять один из 50 модулей (ещё и наиболее критичный) и переписать его с нуля на другой язык, который ещё и никто в команде не знает. Звучит как план

Ну так а где эта информация? Вводных жеж нет. Поэтому самое очевидное решение - переписать на том, что подходит под задачу.

А я и не говорил что она мне нужна. Суть - 5 лет назад кто-то написал модуль на твистеде потому что только под него была реализация протокола к весьма специфичному железу (которую к слову и так пришлось под третий пистон адаптировать ибо EOL). Если б была реализация на фласке - твистеда бы там не было.

Тогда могу только посоветовать запастись валерьянкой. Twisted не плохой, но специфичный.

Оно ещё 10 лет назад бессмысленным дерьмом было, к которому не хотелось прикасаться, а сейчас, когда есть asyncio, а это просто эталон ненужности.

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

Вот вы едите кактус… Не проще взять Golang, NodeJS или Elixir, если вам нужна асинхронщина?

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

Да, точно писал.

Если вам попадалось говнище - это вина не Node. На нем давно есть куча хороших, годных фреймворков с приятным api. Ну и в нормальных проектах Node актуальная, а не legacy восьмилетней давности.

Аналогично могу сказать, про Python проекты, большую часть что видел. Но там были команды профнепригодные. Не понимаю любовь большинства программистов оправдывать свои кривые руки косяками технологии (((.

Поэтому, по Node, или ваша любовь выбирать такие проекты, или везение на них. Говнокод есть на любом языке, это проблема не инструментов а людей.

Ты писал о том, что каким-то образом асинхронщина на ноде лучше асинхронщины на питоне. Я отвечаю, что это два сорта говна, никакое из них не лучше другого. Так что я по прежнему возмущен предложением перейти на ноду, при том, что у него проект на питоне.

Ты писал о том, что каким-то образом асинхронщина на ноде лучше асинхронщины на питоне.

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

Я отвечаю, что это два сорта говна, никакое из них не лучше другого.

Окей, а какой подход к асинхронщине лучше? Как без системы сообщений и колбеков реализовать поведение? Общий подход будет на всём, в целом, плюс\минус одинаковый. Просто есть разной степени готовности батарейки и элементы синтаксиса для этого.

Так что я по прежнему возмущен предложением перейти на ноду, при том, что у него проект на питоне.

Почему? Потому, что это Node, а не Aio для Python? Или не go-рутины? Варианта два - есть кактус или перейти на более готовый инструмент. Скажем перенос кодовой базы на Aiohttp даст такое же переписывание части кода с Twisted. Т.к. не было вводной «надо сохранить проект на Python» было предложено решение - взять подходящий для задачи инструмент.

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

У меня есть проблемы с поиском асинхронных либ для JS. Потому что встроенная асинхронщина в JS появилась примерно одновременно с аналогичной в питоне, а кучу безальтернативного наследия так никто и не переписал на новые механизмы. Причем, в JS асинхронщина — это всё тот же сахар поверх синхронного языка.

Окей, а какой подход к асинхронщине лучше? Как без системы сообщений и колбеков реализовать поведение?

У Erlang, например, замечательная асинхронщина.

Просто есть разной степени готовности батарейки и элементы синтаксиса для этого

Сама по себе асинхронность ничего из себя не представляет — вся разница как раз и заключается в батарейках и инструментах описания решения задачи. Тоесть, асинхронность — это подход, метод, а конкретный ЯП и библиотека — это реализация асинхронного подхода.

Потому, что это Node, а не Aio для Python? Или не go-рутины? Варианта два - есть кактус или перейти на более готовый инструмент

Ну с Go я так-то даже соглашусь, к нему у меня претензий нет. И с Elixir, как производным Erlang, я соглашусь. Меня возмутило наличие в этом списке ноды, которую я считаю самым бессмысленным и беспощадным решением для сервера.

Потому что встроенная асинхронщина в JS появилась примерно одновременно с аналогичной в питоне

Вообще-то намного раньше. Правда ад из коллбэков это не отменяет

Ну и в нормальных проектах Node актуальная, а не legacy восьмилетней давности

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

У меня есть проблемы с поиском асинхронных либ для JS.

Как вы это сделали? За более чем 5 лет разработке на NodeJS не встречал такой проблемы. Скорее была проблема найти синхронную.

Потому что встроенная асинхронщина в JS появилась примерно одновременно с аналогичной в питоне,

Вы серьезно? ИМХО вы ничего не знаете ни про JS, ни про Python. Первый оооочень давно в себе имел систему событий/колбеков без блокировки VM, которые собственно и реализовывали асинхронщину.

а кучу безальтернативного наследия так никто и не переписал на новые механизмы.

Внезапно, большая часть современных либ идут на нативных Promise, что уже позволяет использовать их и async/await. Любые callback based либы можно «превратить» в Promise через promisify. Надо только доку почитать было.

Причем, в JS асинхронщина — это всё тот же сахар поверх синхронного языка.

JS умеет асинхронно выполнять код вызываемой функции/метода. И асинхронность в нём - не сахар, а вполне себе часть event loop виртуальной машины (мы сейчас не про полифилы ведь). Из тезиса могу сделать вывод, что вы не понимаете как работает NodeJS.

У Erlang, например, замечательная асинхронщина.

Так скажите, чем она лучше? Да и не спрашивал я где лучше, а просил описать рпимер лучшего подхода, чем события + колбеки.

Сама по себе асинхронность ничего из себя не представляет — вся разница как раз и заключается в батарейках и инструментах описания решения задачи.

Собственно я это и сказал, да. И сказал, что на Python инструментов для этого меньше.

Тоесть, асинхронность — это подход, метод, а конкретный ЯП и библиотека — это реализация асинхронного подхода.

И? В Python подход является инородным исходя из банально dao python, которую вкорячили, т.к. проще сделать это, чем оптимизировать достаточно медленный язык. В JS изначально приходилось делать инструменты для работы с асинхронщиной, т.к. в браузерах была событийная модель для вызова исполнения JS кода. Корнями асинхронщина JS уходит туда.

Ну с Go я так-то даже соглашусь, к нему у меня претензий нет.

Даже не удивлён. И всё равно, что Go сливает по производительности NodeJS в реальных приложениях для web’a (и плевать, что не для этого язык делался). Он модный зато. И нравится. А JS - фу, а не язык.

И с Elixir, как производным Erlang, я соглашусь.

Думаю, при оспаривании - вы бы ещё более глупо выглядели.

Меня возмутило наличие в этом списке ноды, которую я считаю самым бессмысленным и беспощадным решением для сервера.

Ваше мнение очень важно для сообщества. Я думаю вы - эксперт гораздо больший, чем специалисты IBM, которые почему-то втащили (вот идиоты!) в свой стек JS, а не Go или Elixir.

Если не стебать, то детский подход - считаю/не считаю. Есть задачи и инструменты. Работа программиста решать задачи эффективно. Если для решения берётся менее эффективный инструмент потому, что «не нравится», то что… такой программист.

Я плохо относился сам к NodeJS пока не начал решать задачи, в которых он на самом деле лучший.

З.Ы.: прекрасный «слух» про Golang. Его начали делать в «корпорации зла», т.к. у них была куча Python разработчиков, которым не давались высоконагруженные сервисы, а в асинхронщину на каком-нибудь более сложном языке они не могла. Поэтому Пайку заказали язык с нулевым порогом входа, чтобы под высокую нагрузку могли даже питонисты)

Хорошо пошутил.

Более 10 «тырпрайз» проектов, которые работают далеко не для отдачи фронта. На самом деле, может мне просто везло. Но даже по всем оферам - использования express уже моветон, а callback hell есть, но не так как когда-то. Вариант - продукты в разных сферах с вами, где древняя NodeJS норма.

В крупных проектах зачастую можно куски перла, пыха и даже кобола увидеть.

Не, ну NodeJS видел на относительно свежих проектах. Так да, не спорю. До сих пор помню как нашёл в PHP приложении куски на С++ и QBasic..

Переписывать бэк под каждый новый фреймворк это смузихлебство для локалхоста

Ну, если брали изначально фреймворк (да даже express), то не сложно его выправить до современного состояния. Рефактор в рамках полудня/дня. Но тут будет сильно зависеть от версии Node.

Потому что встроенная асинхронщина в JS появилась примерно одновременно с аналогичной в питоне

Вообще-то намного раньше. Правда ад из коллбэков это не отменяет

Ты о каком «намного раньше» ведешь речь? Twisted в питоне в 2002 родился так-то, только говном от этого быть не перестал. Ключевое свойство ЯП — это сочетаемость конструкций. Машина Тьюринга, в частности — это вариант универсального комбинатора. И JS в частности страдает от плохой сочетаемости асинхронных функций с синхронными, которая проистекает из однопоточно-гуевых истоков JS. У питона истоки другие, но результат примерно тот же.

Как вы это сделали? За более чем 5 лет разработке на NodeJS не встречал такой проблемы. Скорее была проблема найти синхронную

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

Вы серьезно? ИМХО вы ничего не знаете ни про JS, ни про Python. Первый оооочень давно в себе имел систему событий/колбеков без блокировки VM, которые собственно и реализовывали асинхронщину

Представь себе, питон очень давно имел систему потоков и отпускания GIL, которые решали абсолютно ту же задачу. Но ты, почему-то, не знаешь об этом, а берешь судить меня.

Любые callback based либы можно «превратить» в Promise через promisify

Ты будешь мне это за спасибо делать? Я почему-то не вижу наплыва добровольцев. Естественно, я имею в виду не hello world либы, а что-то более серьезное, что не костылится за пять минут.

JS умеет асинхронно выполнять код вызываемой функции/метода. И асинхронность в нём - не сахар, а вполне себе часть event loop виртуальной машины (мы сейчас не про полифилы ведь). Из тезиса могу сделать вывод, что вы не понимаете как работает NodeJS

Асинхронность в Go — не сахар, потому что отдельная нить выполнения может выполняться, ветвиться, и сливаться обратно агностично по отношению к остальной системе и какому бы то ни было главному циклу (которого обычно у сервисов на Go просто нет). Async/await в JS — это сахар над генераторами, а генераторы (которые в питоне были всегда, а в JS появились недавно) — это костыль (но не сахар) над синхронным кодом для превращения его в как бы асинхронный. То есть, синхронное выполнение по очереди дергает то один генератор, то другой, иммитируя параллельное выполнение. Естественно, такая организация нагибает раком кодера, заставляя его руками пробрасывать генераторы через все вызовы — потому это именно костыль, а не полноценная асинхронщина.

Так скажите, чем она лучше? Да и не спрашивал я где лучше, а просил описать рпимер лучшего подхода, чем события + колбеки

Агенты и каналы. Соответственно Erlang и Go. Чем лучше агенты? Тем, что абстрагируют целую кучу низкоуровневого геморроя и позволяют решать задачу, а не решать проблему формы решения.

Сама по себе асинхронность ничего из себя не представляет — вся разница как раз и заключается в батарейках и инструментах описания решения задачи.

Собственно я это и сказал, да. И сказал, что на Python инструментов для этого меньше.

Нет, ты сказал другое:

Общий подход будет на всём, в целом, плюс\минус одинаковый

Подходы для организации зеленых потоков есть совершенно разные, и конкретно JS с питоном являются двумя очень похожими реализациями одного из вариантов организации асинхронности.

В JS изначально приходилось делать инструменты для работы с асинхронщиной, т.к. в браузерах была событийная модель для вызова исполнения JS кода

Фронт на JS вполне может работать в основном синхронно, поскольку в браузере, как правило, нет никакой интенсивной обработки. Асинхронщина в node.js была безальтернативным решением, потому что иначе не получалось сделать хоть какую-то приемлимую производительность обработки запросов при ограниченных ресурсах сервера. Причем, та же проблема была и у питона. И ее нет у целой кучи языков — на одних JVM с CLR десятки языков уже написаны, и там нет никаких проблем с тем, чтобы просто сделать пул потоков и обрабатывать запросы в них, безо всяких асинхронных костылей. Но в питоне и ноде нет возможности выполнять сразу несколько потоков. По крайней мере не было.

И всё равно, что Go сливает по производительности NodeJS в реальных приложениях для web’a (и плевать, что не для этого язык делался). Он модный зато. И нравится. А JS - фу, а не язык

Я хз, что там у тебя за более реальные приложения для web'a, но бенчи нереальных приложений показывают, что нода тягаться с Go не может:

https://www.techempower.com/benchmarks/

К слову, показательно, что таки JustJS с Go вполне тягается — как раз потому, что является реализацией либы JS с нуля, на голых системных вызовах.

Я думаю вы - эксперт гораздо больший, чем специалисты IBM, которые почему-то втащили (вот идиоты!) в свой стек JS, а не Go или Elixir

Цель IBM — помочь себе (заработать денег), а не заказчику. Если заказчики платят деньги за ноду, то IBM будет продавать ноду.

прекрасный «слух» про Golang. Его начали делать в «корпорации зла», т.к. у них была куча Python разработчиков, которым не давались высоконагруженные сервисы, а в асинхронщину на каком-нибудь более сложном языке они не могла. Поэтому Пайку заказали язык с нулевым порогом входа, чтобы под высокую нагрузку могли даже питонисты

Go — это «правильная» Java. Только и всего. Он весьма далек от питона: в нем нет GIL, он статически компилируется, он не построен на динамических типах, и тем более не на ассоциативных массивах. В каком-то смысле, благодаря AOT-компиляции он даже ближе к C/C++/Rust, чем к питону. В отлчиие от Java, которая так и не смогла в адекватную AOT-компиляцию, а потому упала куда-то рядом с нодой, но дальше от питона.

Более 10 «тырпрайз» проектов, которые работают далеко не для отдачи фронта. На самом деле, может мне просто везло

На самом деле ты участвовал в проектах, которые живут два-три года. Повезло или нет — сам решай.

Но даже по всем оферам - использования express уже моветон

Express у нас когда вышел? 2010. То есть, если работа по экспресу, то проекту где-то 5-10 лет. Если же экспрес не нужен — это проект менее пяти лет. Я думаю, что не нужно пояснять, что никто не будет переписывать 500 тысяч строк на новые фичи ноды, и тем более на новый фреймвор, просто потому что такая теперь мода.

Ну, если брали изначально фреймворк (да даже express), то не сложно его выправить до современного состояния

Ага, ангулар на реакт например

До сих пор помню как нашёл в PHP приложении куски на С++ и QBasic..

Это кстати бывает необходимо. У нас есть сишка в пистоне, вернее cython и ctypes. Мало, но где надо прям быстро - есть

Представь себе, питон очень давно имел систему потоков и отпускания GIL, которые решали абсолютно ту же задачу.

Ну это примерно как тормоза из машины вытащить, что-то сложнее хелловорлда свалится в 99.9% случаев

Go — это «правильная» Java

Котлин - правильная жаба. Го - кресты для младшей школы

Вот после таких высказываний:

Представь себе, питон очень давно имел систему потоков и отпускания GIL, которые решали абсолютно ту же задачу. Но ты, почему-то, не знаешь об этом, а берешь судить меня.

далее

Async/await в JS — это сахар над генераторами

и

но бенчи нереальных приложений показывают, что нода тягаться с Go не может (в контексте JustJS)

и далее

Go — это «правильная» Java. Только и всего.

Показывает уровень компетенции, которые исключает возможность осознавать аргументацию собеседника. Поэтому, добра, удачи, прекрасной жизни в вашем уютном мирке.

На самом деле ты участвовал в проектах, которые живут два-три года. Повезло или нет — сам решай.

Я уже понял ваш уровень знаний. Вы круче инженеров IBM, ещё можете судить по проектам не зная их. Просто диву даюсь, вам место в палате мер и весов.

Ага, ангулар на реакт например

Не самый лучший выбор React, ой не самый… Лучше уже пусть живёт на ангуляре.

Это кстати бывает необходимо. У нас есть сишка в пистоне, вернее cython и ctypes. Мало, но где надо прям быстро - есть

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

Ну это примерно как тормоза из машины вытащить, что-то сложнее хелловорлда свалится в 99.9% случаев

Да не, вы что. Ведь так постоянно делают, всё хорошо и стабильно. И скорость - аж волосы сдувает).

Котлин - правильная жаба. Го - кресты для младшей школы

Да не ломайте вы человеку мир. Для него параллелизм и асинхронщина одно и то же, а компилируемые языки допустимо сравнивать с VM.

Ну это примерно как тормоза из машины вытащить, что-то сложнее хелловорлда свалится в 99.9% случаев

Что значит «свалится»? Сегфолт вряд ли будет. Если ты про то, что кто-то решит обращаться к разделяемым объектам самого питона из потоков, и какой-то поток неожиданно увидит не то значение, которое ожидал — ну что ж, нельзя запретить стрелять в ногу. Причем, та же проблема никуда не девается в асинхронном питоне, просто становится менее острой, но по прежнему за время await переменные могут поменяться и программа отработает неправильно.

Котлин - правильная жаба. Го - кресты для младшей школы

Отличные кресты без шаблонов, перегрузки функций и операторов, наследования. Еще и с GC. Что там вообще от крестов? Так-то некоторые доходят до «питон — это почти тот же самый Си».

Я же берусь утверждать, что JVM содержит в себе фундаментальную проблему, которая не дает возможности эффективной AOT-компиляции.

Объясните про twisted

Это не для веба, и тем более не для веб макак.