Удручающе

На Golang надо было переходить, если не поздно.
В Go это элементарно, и параллельно на ядрах.

async/wait захвативший большинство языков выглядит антипаттерном по сравнению с Go. Python удобен в одном потоке, лучше оставить для Python координацию, бизнес-логику, cache, набор начальных данных из DB. Всё остальное на Go.

async/wait захвативший большинство языков выглядит антипаттерном по сравнению с Go. 

В питоне норм, чуть привыкнуть к context manager и exit stack и сойдёт. Проблема что переписать вообще все на aio тупо нереально

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

Так думают те кто не видел свет.
Python прекрасен в своей компетенции, никуда не уйдёт потому все продвинутые 3D моделеры будут на нём автоматизировать работу, он встроен в весь софт, коммерческий и свободный.
В machine learning почти незаменим.
Python идеальная замена Bash, хорошо работает со строками, с логикой принятия решений, которая может меняться.

Но то как в Go описывается всё это «сделать всё параллельно и синхронизированно», несравнимо просто. Со скоростью максимально приближённой к C.

Python идеальная замена Bash, хорошо работает со строками

есть такое, действительно

Всё остальное на Go.

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

Со скоростью максимально приближённой к C.

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

Ясен фиг зажал. Задачу с собственного собеса в сеть слить. Ещё можно прямо в жобс запостить рядом с вакансией

Golang может это делать параллельно, прозрачно относительно кол-ва ядер. Было 8 ядер, поставишь 16 - автоматически все будут задействованы если будет достаточная нагрузка.

Но главная мысль в том что выражение задач типа:
«сделать всё параллельно и синхронизированно, что перед чем, что от чего зависит»
легче чем в любом другом языке, и такая ситуация среди языков уже не изменится. Речь не только о скорости близкой к C.

Я просто посмотрел ещё раз на asyncio в Python, это тяжело воспринимать психологически, при том что Python нравится.

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

Так было наверное в 2009-2015.
Golang до 2020 самый быстроразвивающийся язык именно в аспекте реализации, не синтаксиса.
Для web вся стандартная библиотека заменяющая большинство фреймворков в других языках. Но библиотеки есть для GUI, GPU.
Быстрая компиляция в один «exe» очень привлекательно. Нет зависимостей кроме базовых платформенных. То есть Linux значит просто Linux в целом, не важно какие там libc.
Стандартная кросс-компиляция. Значит что если нет зависимостей от сторонних C библиотек, то на Windows легко скомпилировать исполняемый файл для Linux.

Скорость компиляции и переносимость от Pascal. Так компиляция не огромных проектов выглядит как запуск скрипта на Python:
go run main.go
команда скомпилирует изменённые модули и запустит программу. И тому подобное.

Для web вся стандартная библиотека заменяющая большинство фреймворков в других языках

Свежо питание да серится с трудом. В том же пистоне прям в asyncio сервер можно поднять, но чёт фласк и джанга как жили так и живут

Плюс глядя на жуткий text/template сомнения прям через край

Про области применения питона аргуметация из разряда «почему bash хороший язык». Ну да, питон с нами надолго. Радоваться этому я бы не стал.

В том же пистоне прям в asyncio сервер можно поднять, но чёт фласк и джанга как жили так и живут

Традиция в Python делать свои dev серверы. Но их не всегда используют даже во время разработки.
Живы также и Wordpress, и Joomla.

Плюс глядя на жуткий text/template сомнения прям через край

Если нужен синтакс Django https://github.com/flosch/pongo2
Или аналог hadlebars.js 3 https://github.com/aymerick/raymond

В Go модули устанавливается прямо из публичных репозиториев стандартными инструментами. Pip или Poetry не нужно.
Можно их завендорить в папку vendor, но это обычно не нужно.

URL matcher с стандартной либе Go изначально был для микросервисов, если нужна замена тех что в Django то их тоже несколько основных.

Ну да, питон с нами надолго. Радоваться этому я бы не стал.

Это язык управления, и на самом деле он только набирает обороты, не в web.
Все моделеры и другие специальности в 3D уже используют Python для автоматизации, плагины для софта в их индустрии.
Нельзя создать всеобъемлющий набор инструментов для моделинга, иногда моделер знает уже конкретную методику в конкретной области и думает давай я сделаю для этого Python скрипт(встроенный в софт для плагинов с API). И это надолго, что бы там программисты других областей ни говорили. Легендарный Blender от Ton Roosendaal из Нидерландов. Весь коммерческий 3D софт вроде бы весь с Python для автоматизации.

В machine learning есть понятие dataset, входные данные по которым и будет проходить обучение. Они могут быть в разных форматах, или нужна подготовка, парсинг, для этого Python всегда под рукой, удобен не только благодаря уже существующим библиотекам. Обработка мединских изображений, сопоставление.
Поэтому в мире продолжают всё больше преподавать Python для применения в профессиях, хобби, для непрофессиональных программистов.

Но вот async/wait, это не только в Python неудача, везде, в C#, Javascript, и так далее. Сама модель программирования неудобная в лучшем случае, с непреодолимыми ограничениями. Появляется два типа функций, async и обычные, в Go этих неудобств нет.
Обычно ссылаются на культовую статью:
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Поэтому в мире продолжают всё больше преподавать Python для применения в профессиях, хобби, для непрофессиональных программистов.

Это всё прекрасно (нет). Я с этими очевидными вещами и не спорю.

Вот только когда очередной непрофессиональный скрипт вырастает до библиотеки на 50k строк, вот тут-то все грабли и вылазят.

Это в принципе ко всем утиным языкам относится. Но в питоне адок особого местного колорита.

Но вот async/wait, это не только в Python неудача, везде, в C#, Javascript, и так далее. Сама модель программирования неудобная в лучшем случае, с непреодолимыми ограничениями.

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

Что сподвигло это делать в Python… хз…

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Кстати, спасибо. Не мог найти.

Кстати, cast byko3y

Вот только когда очередной непрофессиональный скрипт вырастает до библиотеки на 50k строк, вот тут-то все грабли и вылазят.

Для автоматизации работы это не имеет никакого значения. Для программистов эту проблему решили в Pascal, где везде типы и программирование в сравнении с Lisp описывали как «строительство пирамиды» и что это может сделать один человек, создаёшь типы, используешь их, и наращиваешь «пирамиду».

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

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

Поэтому Guido van Rossum сейчас работая в Microsoft и занимается дальнейшим развитием выразительности и читаемости Python. Pattern matching в синтаксис добавляют.

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

а с таким подходом вам не питонист нужен

где записаться в джуны переростки, но я не настоящий сварщик да (:

Я б такую чушь на собесе и не стал спрашивать, надо здорово упороться чтоб в iadd запихать io (хотя некоторые ODM так делают). Это ответ на гордое «используй атомик» жопича.

Хотя кстати дежурно спросить зачем эти смешные методы с двумя underscore спереди-сзади таки можно, часть народу этого тоже не знает, особенно кто из ML приходит

популярный сейчас DEVOPS

Слово девопс в трех разных конторах может обозначать три разных вещи

Кстати, cast @byko3y

А что я? Я уже отметился в треде. Он правильно пишет — этот кактус давно и надолго, потому-то я и выбрал писать под него софт. Не «на нем», конечно же, потому что писать на «этом» работающий софт невозможно, а «под него» — то есть мое понимание асинхронности-многозадачности, каким оно должно быть, и это уже наполовину свой собственный язык. Например, в питоне вообще нет конструкций плана «отреагировать на изменение переменной», поскольку веками было принято писать в синхронной форме функции обратного вызова или даже прямые вызовы чужих функций при изменении общей переменной. Даже с приходом async/await не удалось ввести адекватной конструкции, и в итоге wait_for тупо в цикле опрашивает переменную:

async def wait_for(self, predicate):
    """Wait until a predicate becomes true.

    The predicate should be a callable which result will be
    interpreted as a boolean value.  The final predicate value is
    the return value.
    """
    result = predicate()
    while not result:
        await self.wait()
        result = predicate()
    return result

Вы уже придумали. как при этом параллельно ждать ввода-вывода из сокета?

отреагировать на изменение переменной

Вот как раз лок и condition. Делаешь property set, в нем notify

Вот как раз лок и condition. Делаешь property set, в нем notify

А теперь у тебя Condition-ов сотня, и какой-то из них неправильно работает. Задача — найти какой не работает.

А теперь у тебя Condition-ов сотня, и какой-то из них неправильно работает

Если у тебя сотня таких конструкций, возможно с твоим кодом что-то не так

А теперь у тебя Condition-ов сотня, и какой-то из них неправильно работает

Если у тебя сотня таких конструкций, возможно с твоим кодом что-то не так

Каждый Future внутри использует Condition, например.

Ну у тебя их натурально сотня внутри одного вызова единовременно? Два-три-пять понятно, но сотня - ты загнул

Ты про магию в питоне? Кстати, я знаю что магические методы предопределены, а вот есть ли смысл/возможность делать свои магические методы?

В плане свои? Переопределять? Или совсем свои?

Ну у тебя их натурально сотня внутри одного вызова единовременно? Два-три-пять понятно, но сотня - ты загнул

Какого еще «вызова»? Функции, что ли? Если твой «вызов» запускает какой-то массовый ввод-вывод, вроде управления распределенной обработкой — тогда сотня покажется тебе умеренным количеством. Я понимаю, что отлаживать это нереально, и потому такую функциональность обычно реализуют на каком-нибудь серваке очереди сообщений — я указываю на то, почему все-таки эти фичи не делаются полностью на питоне «ведь питон — такой удобный инструмент».