потребление ресурсов будет значительно отличаться, если речь идет о тысячах задач / тысячах тредов. И не важно, параллельно эти треды будут выполняться (без GIL) или конкурентно (c GIL). Отсутствие GIL - не silver bullet, параллелизм всей сисиемы все равно будет ограничен кол-вом процессорных ядер, а работа тысячи тредов приведет к значительным затратам ресурсов CPU.
важен сам факт что мы можем как-то скинуть задачу с себя и пойти заниматься другими вещами.
согласен с данным тезисом. Однако, если у нас эта самая вычислительная задача не является фоновой, а является полноценной и равнозначной задачей со всеми прочими, разве не будет справедливым говорить об "асинхронном выполнении"?
В прочем, не важно. Это спор за термины, суть которых ясна
синтаксис - дело наживное, вопрос опыта и привычки, а прописать конкретные версии в python’е тоже можно :) Если для вас язык, где дженерики завезли в N-ной версии - это «лучшее» то предлагаю дискуссию закрыть )
Раст то же что Си и С++. Можно многое, надо знать, нужно ебатся, код для не знающего похож на ельфийский - тот же php или js можно научится читать хотя бы примерно за день
для меня код на go похож на эльфийский, а код на расте - вполне читаемый и понимаемый. Так что тут субъективщина чистой воды.
Про "много нужно знать" - при работае с любым ЯП нужно знать, как этот ЯП работает, хотя бы базово.
И, в целом, все что вы написали, ни разу не отменяет моего основного тезиса, сказанного выше. Если язык подразумевает тонны бойлер-плейта по своей сути, то для большего, чем написания небольших приложений он не годится.
строгая типизация при максимально простом языке. Это не только компактные шустрые бинарники, но и читаемость кода пополам с безопасностью
про "читаемость", в python есть type annotations, и кода без оных я не наблюдах в коммерческих проектах последних лет 5 уж точно. Для типобезопасности есть линтеры (с оговорками конечно но все же) которые, как правило, тоже must have
Про проблемы с кроссплатформенностью пайтона - тру стори, только в 99% случаев все запускается на одной платформе
Даже в ноде можно привязаться к конкретным репозиториям и версиям
Что мешает привязаться к конкретным версиям в питоне?
Если очень сильно обобщить, то "конкурентность" - это способность нескольких различных участков кода выполняться независимо друг от друга. Ваше определение "асинхронности" попадает под это понятие, и не понятно, зачем вы их разделяете. Параллелизм - это подвид конкурентности.
P.S. говоря об асинхронности, автор явно имеет в виду конкретно модель асинхронного IO в python, что очевидно
Почему не использовать Go? Чтобы проект с более-менее сложной бизнес-логикой на выходе не был x3 размером по кодовой базе от того, что могло бы быть, используя python :)
Питонистов, привыкших к тому что есть GIL, заставили верить в то, что многопоточный и асинхронный подходы при работе с IO - конкурирующие и взаимоисключающие. Но это справедливо лишь в контексте существования GIL )
Условная M:N модель, где M асинхронных задач (тысячи их) склейлятся на N тредов ОС (ограниченное количество, как правило равное кол-ву ядер CPU) - это нормальная практика во многих ЯП.
А зачем? В питоне уже давно есть stackless корутины, ничего не мешает в будущем использовать их вкупе с многопоточным рантаймом при отсутствии GIL (см. растовый tokio). А грин-треды это в принципе иной подход к реализации многозадачности: pre-emptive вместо cooperative
За последних лет так 5 в разработке на пайтон (в разных компаниях) не видел ни одного проекта без тайп-аннотаций/прикрученных статических тайп-чекеров. Да, это не «статическая типизация», но читаемость кода это значительно повышает
Читаемость пайтон-кода, в среднем, выше в первую очередь из-за тонн синтаксического сахара
Я где-то писал, что раст гарантирует memory safety в понимании термина с Википедии? Не приплетайте свои фантазии)
Ну и, чтобы не быть голословным, предоставьте, пожалуйста, действительно авторитетный источник, где заявляется, что memory leaks относятся к классу ошибок memory safety, а то «много где еще пишут» - такой себе аргумент :)
Скорее, наоборот. Все вокруг орут, что раст «не безопасный» (особенно в комментариях на Хабре под абсолютно любой статей про раст), аргументируя это отсутствием тех гарантий, которых этот язык нигде и никогда не обещал :)
Если вы хотите безопасно обработать возвращенный вам Result / Option, вы можете использовать паттерн-матчинг или специальные методы этих типов. unwrap() - небезопасный способ.
И где вообще (и кем) заявлялось, что раст гарантирует отсутствие thread panics ?
Вам выше написали, как язык это реализует - Rc, Weak и т.д.
потребление ресурсов будет значительно отличаться, если речь идет о тысячах задач / тысячах тредов. И не важно, параллельно эти треды будут выполняться (без GIL) или конкурентно (c GIL). Отсутствие GIL - не silver bullet, параллелизм всей сисиемы все равно будет ограничен кол-вом процессорных ядер, а работа тысячи тредов приведет к значительным затратам ресурсов CPU.
согласен с данным тезисом. Однако, если у нас эта самая вычислительная задача не является фоновой, а является полноценной и равнозначной задачей со всеми прочими, разве не будет справедливым говорить об "асинхронном выполнении"?
В прочем, не важно. Это спор за термины, суть которых ясна
синтаксис - дело наживное, вопрос опыта и привычки, а прописать конкретные версии в python’е тоже можно :) Если для вас язык, где дженерики завезли в N-ной версии - это «лучшее» то предлагаю дискуссию закрыть )
для меня код на go похож на эльфийский, а код на расте - вполне читаемый и понимаемый. Так что тут субъективщина чистой воды.
Про "много нужно знать" - при работае с любым ЯП нужно знать, как этот ЯП работает, хотя бы базово.
И, в целом, все что вы написали, ни разу не отменяет моего основного тезиса, сказанного выше. Если язык подразумевает тонны бойлер-плейта по своей сути, то для большего, чем написания небольших приложений он не годится.
про "читаемость", в python есть type annotations, и кода без оных я не наблюдах в коммерческих проектах последних лет 5 уж точно.
Для типобезопасности есть линтеры (с оговорками конечно но все же) которые, как правило, тоже must have
Про проблемы с кроссплатформенностью пайтона - тру стори, только в 99% случаев все запускается на одной платформе
Что мешает привязаться к конкретным версиям в питоне?
И что, в Go-либах не бывает breaking changes?
Если очень сильно обобщить, то "конкурентность" - это способность нескольких различных участков кода выполняться независимо друг от друга. Ваше определение "асинхронности" попадает под это понятие, и не понятно, зачем вы их разделяете. Параллелизм - это подвид конкурентности.
P.S. говоря об асинхронности, автор явно имеет в виду конкретно модель асинхронного IO в python, что очевидно
Важный параметр - это поддерживаемость кода, верно.
Вопрос: почему я должен охренеть поддерживать приложение на пайтоне, но не охренеть поддерживать аналогичное приложение на go?
Отладка в python просто замечательная
Почему не использовать Go? Чтобы проект с более-менее сложной бизнес-логикой на выходе не был x3 размером по кодовой базе от того, что могло бы быть, используя python :)
Питонистов, привыкших к тому что есть GIL, заставили верить в то, что многопоточный и асинхронный подходы при работе с IO - конкурирующие и взаимоисключающие. Но это справедливо лишь в контексте существования GIL )
Условная M:N модель, где M асинхронных задач (тысячи их) склейлятся на N тредов ОС (ограниченное количество, как правило равное кол-ву ядер CPU) - это нормальная практика во многих ЯП.
А зачем? В питоне уже давно есть stackless корутины, ничего не мешает в будущем использовать их вкупе с многопоточным рантаймом при отсутствии GIL (см. растовый tokio). А грин-треды это в принципе иной подход к реализации многозадачности: pre-emptive вместо cooperative
понятны то, в целом, оба варианта, но вот на тему "Компактности синтаксиса" к джаве есть вопросы конечно :)
P.S. вариант на Котлине лучший
Что с GIL’ом, что без оного, Пайтон, в общем и целом, будет медленнее за счет своей динамической типизации
За последних лет так 5 в разработке на пайтон (в разных компаниях) не видел ни одного проекта без тайп-аннотаций/прикрученных статических тайп-чекеров. Да, это не «статическая типизация», но читаемость кода это значительно повышает
Читаемость пайтон-кода, в среднем, выше в первую очередь из-за тонн синтаксического сахара
Совсем тролли обленились в наши дни :)
Ну тогда разверните мысль, будьте добры)
Я где-то писал, что раст гарантирует memory safety в понимании термина с Википедии? Не приплетайте свои фантазии)
Ну и, чтобы не быть голословным, предоставьте, пожалуйста, действительно авторитетный источник, где заявляется, что memory leaks относятся к классу ошибок memory safety, а то «много где еще пишут» - такой себе аргумент :)
В других ЯП разве нет аналогов го-шных горутин?
Звучит так, будто вы намекаете, что в пасте его нет
Скорее, наоборот. Все вокруг орут, что раст «не безопасный» (особенно в комментариях на Хабре под абсолютно любой статей про раст), аргументируя это отсутствием тех гарантий, которых этот язык нигде и никогда не обещал :)
Если вы хотите безопасно обработать возвращенный вам Result / Option, вы можете использовать паттерн-матчинг или специальные методы этих типов. unwrap() - небезопасный способ.
И где вообще (и кем) заявлялось, что раст гарантирует отсутствие thread panics ?