За последних лет так 5 в разработке на пайтон (в разных компаниях) не видел ни одного проекта без тайп-аннотаций/прикрученных статических тайп-чекеров. Да, это не «статическая типизация», но читаемость кода это значительно повышает
Читаемость пайтон-кода, в среднем, выше в первую очередь из-за тонн синтаксического сахара
Я где-то писал, что раст гарантирует memory safety в понимании термина с Википедии? Не приплетайте свои фантазии)
Ну и, чтобы не быть голословным, предоставьте, пожалуйста, действительно авторитетный источник, где заявляется, что memory leaks относятся к классу ошибок memory safety, а то «много где еще пишут» - такой себе аргумент :)
Скорее, наоборот. Все вокруг орут, что раст «не безопасный» (особенно в комментариях на Хабре под абсолютно любой статей про раст), аргументируя это отсутствием тех гарантий, которых этот язык нигде и никогда не обещал :)
Если вы хотите безопасно обработать возвращенный вам Result / Option, вы можете использовать паттерн-матчинг или специальные методы этих типов. unwrap() - небезопасный способ.
И где вообще (и кем) заявлялось, что раст гарантирует отсутствие thread panics ?
Напомню вам ваш комментарий на который я ответил: «раст делает больно программисту, и ничего за это не дает». Какие конкретно гарантии раст дает, а какие нет - вы можете почитать в официальной документации, в раст-буке, номиконе и т.д., а не спорить об определениях с Википедии
Раз уж вы ссылаетесь на Википедию, то там написано следующее: «Безопасность доступа к памяти — концепция в разработке программного обеспечения, целью которой является избежание программных ошибок, которые ведут к уязвимостям, связанным с доступом к оперативной памяти компьютера, таким как переполнения буфера и висячие указатели»
Где, простите, вы вычитали, что безопасность доступа к памяти - это отсутствие утечек?
Запомните уже наконец: memory safety - это не про гарантии отсутствия «утечек», это про гарантии отсутствия UB при некорректной работе с той самой памятью, которое легко допустимо в С/C++, например. И (safe) rust дает эти самые гарантии.
я спорил не с вашим возражением в целом, а конкретно с вашим выражением про "запуск задач" и пытался донести, что "запустить задачу" явно + при этом не блокируясь в некоторых случаях попросту нельзя
А если в целом, то будет ваш код работать реально асинхронно (a.k.a. конкурентно) или же это будет последовательный код с async/await - зависит от того, как вы его напишите
P.S. если по-честному, то данная статья вообще не стоит обсуждения ))
Скорее, это вы прицепились к моей формулировке "питонячего потока" ) Надеюсь, я выше в комментариях смог донести что именно имелось в виду.
Касательно CPU-bound задач - к сожалению, не для всего есть готовые либы, использующие "обходные пути" (отпускание GIL и т.д.). А писать свои реализации на языках без GIL / реализации, использующие Python C API - то еще удовольствие
где я говорил что "код с использованием asyncio последовательный"? Я говорил про то, что код с использованием asyncio может работать синхронно, если он написан без знаний/понимания нюансов того, как работает ивент-луп. И шансы стать на эти "грабли" крайне велики, особенно для тех разработчиков, кто не сильно посвящен в детали. Причина же данной проблемы лежит в плоскости того, как именно реализован ивент-луп. Да и, в целом, асинхронная модель в пайтоне оставляет желать лучшего.
Еще раз: любой поток созданный в пайтон-коде будет использовать GIL. Любой поток, созданный библиотекой на С/C++/Rust, НЕ будет использовать GIL. Это попросту разные уровни абстракции. Что конкретно вам тут не понятно? Также выше я подробно расписал, почему логическое разделение на "потоки языка X" и "потоки языка Y" вполне уместны и валидны в контексте пайтона. Подчеркиваю - ЛОГИЧЕСКОЕ, а не ФИЗИЧЕСКОЕ.
Разберитесь в вопросе для начала, чтобы понимать то, о чем вам пишут. А то уже сотый коммент просто выдаете общеизвестные истины, параллельно повторяя как мантру "нет никаких других потоков, есть только потоки ОС")
Но наличие кооперативности не делает конкуретный код внезапно последовательным или синхронным.
чтобы код был конкурентным (т.е. выполнялся конкуретно), он должен быть написан со знанием нюансов работы ивент-лупа. Наличие async/await в коде не делает его конкуретным априори, и у питонячего ивент-лупа есть конкретные ограничения. Об этом и речь.
К чему вы тут виды многозадачности привели - вообще не понятно. Некоторые языки (например, Rust) релизуют асинк-модель (например, tokio runtime) с использованием тредов, но при этом многозадачность там - кооперативная.
оттуда же, откуда они берутся в любой библиотеке написанной на C и использующей многопоточность.
Внезапно, если в потоке порожденным питоном отпустить GIL (а это делается в куче случаев, начиная с банального hashlib), то гил отпустится и можно занять несколько ядер
спасибо за очередную порцию общеизвестных вещей) Интересно, вы сами себя пытаетесь удивить своими же познаниями?)
Вы можете написать свою собственную числодробилку на С/С++/Rust и юзать в ее реализации N потоков, а потом заиспользовать это в пайтоне. Все будет работать параллельно, потому что потоки уровня низлежащего языка не блокируются GIL (потому что они тупо не знают вообще что такое GIL).
Повторюсь: интерпретатор пайтона (CPython) использует свою абстракцию над потоками ОС (в комменте выше я писал какую - PyThreadState). Благодаря этому реализуется синхронизация потоков через GIL. «Физически» же выполнение пайтон байт-кода происходит в ОС потоке (иного я нигде и не утверждал). Так что «питонячий поток» - это ОС поток + PyThreadState, который использует интерпретатор. Потоки же, порождаемые С-шными либами - это тоже OC потоки, но они могут выполняться реально параллельно (на разных ядрах CPU), т.к. они вообще ничего не знают про GIL. Исходя из вышесказанного, вполне валидно логически разделять потоки на "питонячие" и (например) "с-шные", несмотря на то, что под капотом и там, и там - ОС потоки
P.S. Советую почитать очень занимательную статью за авторством Виктора Скворцова про GIL (она на английском)
понятны то, в целом, оба варианта, но вот на тему "Компактности синтаксиса" к джаве есть вопросы конечно :)
P.S. вариант на Котлине лучший
Что с GIL’ом, что без оного, Пайтон, в общем и целом, будет медленнее за счет своей динамической типизации
За последних лет так 5 в разработке на пайтон (в разных компаниях) не видел ни одного проекта без тайп-аннотаций/прикрученных статических тайп-чекеров. Да, это не «статическая типизация», но читаемость кода это значительно повышает
Читаемость пайтон-кода, в среднем, выше в первую очередь из-за тонн синтаксического сахара
Совсем тролли обленились в наши дни :)
Ну тогда разверните мысль, будьте добры)
Я где-то писал, что раст гарантирует memory safety в понимании термина с Википедии? Не приплетайте свои фантазии)
Ну и, чтобы не быть голословным, предоставьте, пожалуйста, действительно авторитетный источник, где заявляется, что memory leaks относятся к классу ошибок memory safety, а то «много где еще пишут» - такой себе аргумент :)
В других ЯП разве нет аналогов го-шных горутин?
Звучит так, будто вы намекаете, что в пасте его нет
Скорее, наоборот. Все вокруг орут, что раст «не безопасный» (особенно в комментариях на Хабре под абсолютно любой статей про раст), аргументируя это отсутствием тех гарантий, которых этот язык нигде и никогда не обещал :)
Если вы хотите безопасно обработать возвращенный вам Result / Option, вы можете использовать паттерн-матчинг или специальные методы этих типов. unwrap() - небезопасный способ.
И где вообще (и кем) заявлялось, что раст гарантирует отсутствие thread panics ?
Напомню вам ваш комментарий на который я ответил: «раст делает больно программисту, и ничего за это не дает». Какие конкретно гарантии раст дает, а какие нет - вы можете почитать в официальной документации, в раст-буке, номиконе и т.д., а не спорить об определениях с Википедии
Раз уж вы ссылаетесь на Википедию, то там написано следующее: «Безопасность доступа к памяти — концепция в разработке программного обеспечения, целью которой является избежание программных ошибок, которые ведут к уязвимостям, связанным с доступом к оперативной памяти компьютера, таким как переполнения буфера и висячие указатели»
Где, простите, вы вычитали, что безопасность доступа к памяти - это отсутствие утечек?
Говорить про «утечки и краши» языка, и привести как аргумент ссылку на форум, где обсуждается «unwrap() hurts readability» …
Запомните уже наконец: memory safety - это не про гарантии отсутствия «утечек», это про гарантии отсутствия UB при некорректной работе с той самой памятью, которое легко допустимо в С/C++, например. И (safe) rust дает эти самые гарантии.
я спорил не с вашим возражением в целом, а конкретно с вашим выражением про "запуск задач" и пытался донести, что "запустить задачу" явно + при этом не блокируясь в некоторых случаях попросту нельзя
А если в целом, то будет ваш код работать реально асинхронно (a.k.a. конкурентно) или же это будет последовательный код с async/await - зависит от того, как вы его напишите
P.S. если по-честному, то данная статья вообще не стоит обсуждения ))
Скорее, это вы прицепились к моей формулировке "питонячего потока" ) Надеюсь, я выше в комментариях смог донести что именно имелось в виду.
Касательно CPU-bound задач - к сожалению, не для всего есть готовые либы, использующие "обходные пути" (отпускание GIL и т.д.). А писать свои реализации на языках без GIL / реализации, использующие Python C API - то еще удовольствие
где я говорил что "код с использованием asyncio последовательный"? Я говорил про то, что код с использованием asyncio может работать синхронно, если он написан без знаний/понимания нюансов того, как работает ивент-луп. И шансы стать на эти "грабли" крайне велики, особенно для тех разработчиков, кто не сильно посвящен в детали. Причина же данной проблемы лежит в плоскости того, как именно реализован ивент-луп. Да и, в целом, асинхронная модель в пайтоне оставляет желать лучшего.
Еще раз: любой поток созданный в пайтон-коде будет использовать GIL. Любой поток, созданный библиотекой на С/C++/Rust, НЕ будет использовать GIL. Это попросту разные уровни абстракции. Что конкретно вам тут не понятно?
Также выше я подробно расписал, почему логическое разделение на "потоки языка X" и "потоки языка Y" вполне уместны и валидны в контексте пайтона. Подчеркиваю - ЛОГИЧЕСКОЕ, а не ФИЗИЧЕСКОЕ.
Разберитесь в вопросе для начала, чтобы понимать то, о чем вам пишут. А то уже сотый коммент просто выдаете общеизвестные истины, параллельно повторяя как мантру "нет никаких других потоков, есть только потоки ОС")
чтобы код был конкурентным (т.е. выполнялся конкуретно), он должен быть написан со знанием нюансов работы ивент-лупа. Наличие async/await в коде не делает его конкуретным априори, и у питонячего ивент-лупа есть конкретные ограничения. Об этом и речь.
К чему вы тут виды многозадачности привели - вообще не понятно. Некоторые языки (например, Rust) релизуют асинк-модель (например, tokio runtime) с использованием тредов, но при этом многозадачность там - кооперативная.
оттуда же, откуда они берутся в любой библиотеке написанной на C и использующей многопоточность.
спасибо за очередную порцию общеизвестных вещей) Интересно, вы сами себя пытаетесь удивить своими же познаниями?)
Вы можете написать свою собственную числодробилку на С/С++/Rust и юзать в ее реализации N потоков, а потом заиспользовать это в пайтоне. Все будет работать параллельно, потому что потоки уровня низлежащего языка не блокируются GIL (потому что они тупо не знают вообще что такое GIL).
Повторюсь: интерпретатор пайтона (CPython) использует свою абстракцию над потоками ОС (в комменте выше я писал какую - PyThreadState). Благодаря этому реализуется синхронизация потоков через GIL. «Физически» же выполнение пайтон байт-кода происходит в ОС потоке (иного я нигде и не утверждал). Так что «питонячий поток» - это ОС поток + PyThreadState, который использует интерпретатор. Потоки же, порождаемые С-шными либами - это тоже OC потоки, но они могут выполняться реально параллельно (на разных ядрах CPU), т.к. они вообще ничего не знают про GIL. Исходя из вышесказанного, вполне валидно логически разделять потоки на "питонячие" и (например) "с-шные", несмотря на то, что под капотом и там, и там - ОС потоки
P.S. Советую почитать очень занимательную статью за авторством Виктора Скворцова про GIL (она на английском)