Допустим, пишем эхо-сервер, который должен пережевать 10Gbps пакетами по 64 байта
А здорово вы это придумали, я даже сначала и не понял)
Если же серьёзно, то под каждую задачу есть свой инструмент. Вы привели в пример пограничное значение, которое маловероятно, что будет написано на Python в целом.
При этом базовый echo-server я бы тоже писал на Python. Тут возникает вопрос: "А почему echo-server должен пережевывать 10Gbps?". Если это ошибка в постановке ТЗ - разработчик должен заметить и сказать об этом бизнесу. Если такое придумал сам разработчик - он скорее всего начинающий и не знает, какая реальная будет нагрузка, поэтому закладывается на супер хайлод.
Во всей статье я говорил о реальных примерах и реальном использовании. Поэтому будьте реалистом)
Вы рассуждаете об асинхронности с точки зрения разработчика и технологии. Мой же вывод об асинхонности с точки зрения компании и продукта. Зачастую, владельцу бизнеса не очень важно, асинхронность или многопоточность вы будете использовать. Он будет видеть счёт за вычислительные ресурсы.
А относительно скорости в 80% случаев подходы похожи. Поэтому нет разницы, что использовать. Да и относительно ресурсов, если быть честным, в 80% случаев разницы не будет особой тоже. Типичный паретто)
Справедливости ради, доклад я заканчивал словами о том, что в многопоточную модель потенциально можно было бы привезти green-threads. А точнее, сделать сами потоки "асинхронными внутри". То есть на один поток операционной системы порождалось бы несколько виртуальных потоков. Каждый такой виртуальный поток был бы фактически асинхронной корутиной. Как в Java, Golang и других "честных" языках, где давно уже green-threads или аналоги.
Хотя нечто похожее мы фактически получаем и сейчас, запускаю несколько инстансов асинхронного приложения на UWSGI. У нас фактически есть несколько потоков, каждый из которых внутри поддерживает асинхронность.
Единственный нюанс - эти потоки не видят друг друга и не столь эффективно работают, как в том же Golang
Да, @WLMike прав. Зачастую, когда ты начинаешь свой небольшой проект - проще и быстрее взять язык, для которого много разных библиотек и на котором можно написать "быстро".
Затем ты выходишь на рынок и начинаешь это тестировать. И дальше, если мы говорим о каких-нибудь Pet проектах - проект так и останется маленьким. Или не найдёт свою аудиторию. Так будет в 80% случаев.
А если всё-таки проект вырастет - уже поздновато менять весь стек. Нужно расширять штат. А имеющийся штат только на Python пишет. Да и найти резработчиков - не просто. Поэтому выбирается путь думать об асинхронности и закидывать всё железом)
А если сразу писать всё на C# или чём-то производительном -проект может и не выйти. Или опоздать с моментом выхода. Тот же Golang, на который уходят с Python - сильно многословнее получается.
Могли бы вы пояснить, что хотели этим сказать?
А здорово вы это придумали, я даже сначала и не понял)
Если же серьёзно, то под каждую задачу есть свой инструмент. Вы привели в пример пограничное значение, которое маловероятно, что будет написано на Python в целом.
При этом базовый echo-server я бы тоже писал на Python. Тут возникает вопрос: "А почему echo-server должен пережевывать 10Gbps?". Если это ошибка в постановке ТЗ - разработчик должен заметить и сказать об этом бизнесу. Если такое придумал сам разработчик - он скорее всего начинающий и не знает, какая реальная будет нагрузка, поэтому закладывается на супер хайлод.
Во всей статье я говорил о реальных примерах и реальном использовании. Поэтому будьте реалистом)
Да, всё так. Спасибо за комментарий!
Хотя ветка обсуждения на введение green-threads активно сейчас ведётся, поэтому мб лет через 5 мы можем увидеть что-то такое. Вот ссылка, если интересно:
https://discuss.python.org/t/add-virtual-threads-to-python/91403
Вы рассуждаете об асинхронности с точки зрения разработчика и технологии. Мой же вывод об асинхонности с точки зрения компании и продукта. Зачастую, владельцу бизнеса не очень важно, асинхронность или многопоточность вы будете использовать. Он будет видеть счёт за вычислительные ресурсы.
А относительно скорости в 80% случаев подходы похожи. Поэтому нет разницы, что использовать. Да и относительно ресурсов, если быть честным, в 80% случаев разницы не будет особой тоже. Типичный паретто)
Справедливости ради, доклад я заканчивал словами о том, что в многопоточную модель потенциально можно было бы привезти green-threads. А точнее, сделать сами потоки "асинхронными внутри". То есть на один поток операционной системы порождалось бы несколько виртуальных потоков. Каждый такой виртуальный поток был бы фактически асинхронной корутиной. Как в Java, Golang и других "честных" языках, где давно уже green-threads или аналоги.
Хотя нечто похожее мы фактически получаем и сейчас, запускаю несколько инстансов асинхронного приложения на UWSGI. У нас фактически есть несколько потоков, каждый из которых внутри поддерживает асинхронность.
Единственный нюанс - эти потоки не видят друг друга и не столь эффективно работают, как в том же Golang
Да, @WLMike прав. Зачастую, когда ты начинаешь свой небольшой проект - проще и быстрее взять язык, для которого много разных библиотек и на котором можно написать "быстро".
Затем ты выходишь на рынок и начинаешь это тестировать. И дальше, если мы говорим о каких-нибудь Pet проектах - проект так и останется маленьким. Или не найдёт свою аудиторию. Так будет в 80% случаев.
А если всё-таки проект вырастет - уже поздновато менять весь стек. Нужно расширять штат. А имеющийся штат только на Python пишет. Да и найти резработчиков - не просто. Поэтому выбирается путь думать об асинхронности и закидывать всё железом)
А если сразу писать всё на C# или чём-то производительном -проект может и не выйти. Или опоздать с моментом выхода. Тот же Golang, на который уходят с Python - сильно многословнее получается.
Ответил подробнее ниже