Не пытаться делать из Питона Java вообще совсем.

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

У дискорда https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f?gi=639751e3d789

Я уже тут жаловался как я разбирался как там менеджеры собираются копированием методов

О, точно

Это и правда очень дорого, наверное

Так ли нужна джанга...

да, действительно переход с луиджи на эирфлоу - это большая работа, в основном, потому что лудживские таски сильно завязаны на сущности этого фреймворка. но тем не менее, мы посчитали, что эирфлоу будет лучше по следующим причинам:
1) в эирфлоу есть полноценный web UI, в котором можно много чего посмотреть и сделать например, для перезапуска таски нет нужды идти по ssh на сервер и вспоминать и писать команду в терминале - достаточно зайти в веб UI и очистить статус у нужных тасок/дагов для соответствующих итераций запуска
2) в эирфлоу есть мониторинг почти из коробки - надо лишь доставить рядом statsd и натравить на него airflow
3) одна из базовых сущностей эирфлоу - это оператор (или таска - если мы говорим про время выполнения), и в базовой поставке есть их достаточно много, включая оператор для работы с Amazon S3, MySQL, PostrgeSQL, Docker, и др. https://airflow.apache.org/docs/stable/_api/airflow/operators/index.html. и, хотя лично я использую обычно PythonOperator, можно часто повторяемые задачи выносить в самописные операторы (хотя в таком случае мы возвращаемся обратно к сильной привязке к фреймворку)
4) в эирфлоу, в отличии от луиджи, зависимости тасок в коде читаются очень наглядно и легко:

 extract_from_mysql >> transform_data >> load_to_clickhouse

 extract_from_mysql >> transform_data >> load_to_clickhouse

понятно. спасибо. действительно было бы интересно послушать про него доклад

а что было бы интереснее всего послушать про эирфлоу?

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

Есть )

Это немного другое

Почему? Rust, на беке

Там люди упёрлись в gc. Почти каждый релиз go улучшают gc. Понятно, что переписать на rust интереснее чем просто взять новый релиз :)

Вот интересно насколько теоретически можно улучшить gc, если он единственный способ освободить память в языке? У меня приложение которое занимается обработкой картинок, работает на CPython. Изображения могут быть огромными. Я в нем тщательно слежу, чтобы не было лишних ссылок на объекты во время обработки. Пробовал запустить на pypy, результат был ожидаем: за две минуты стресс-теста приложение выжирало всю доступную память и падало. Существует ли хотя бы теоретическая вероятность запускать такое в средах с gc?

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

Но это вообще ручное управление получается, даже не подсчет ссылок )

А ты видел результаты? Понятно, что мотивация переписать была именно в gc, но там очень здорово всё ускорилось, так что вполне успех

они вроде писали в комментах, что новый релиз go им бы не помог.