Справедливо: для I/O-bound веба скорость языка почти не важна, там правит удобство. Тезис статьи узкий - про compute- и energy-bound задачи ИИ, где оверхед виден. Спасибо, это стоило проговорить явно.
Так это ровно тезис статьи и есть - доминирование Python выросло из среды и привычки (в т.ч. "учат первым"), а не из технического превосходства. Раз причина социальная, а не физическая, то на новых площадках (on-device, edge), где нет инерции экосистемы, выбор снова открыт.
Спасибо, вы сформулировали точнее меня. Именно поэтому "просто напишите умный компилятор" и не работает: раз объекты одного типа не обязаны иметь одинаковый набор атрибутов, а любой из них можно переопределить в рантайме, компилятор обязан оставлять полный динамический поиск. Это потолок семантики, а не лень авторов CPython.
Согласен. После C/C++ Python и JS — это действительно облегчение, и бизнесу важнее всего скорость вывода фичей, а не пара миллисекунд.
Просто в on-device AI эти миллисекунды уже заметно влияют на батарею и стоимость серверов. Поэтому и предлагают Swift - удобство почти как у Python, но без сильного налога на производительность.
Согласен по всем пунктам, кроме "не обойти" - это верно там, где Python держится на инерции экосистемы. А на новых территориях его уже обошли, даже HuggingFace пишет ядро на Rust. Так что да — вниманием стоит не обходить и Swift, и Rust, и Mojo. Победа любого из них лечит главную болезнь: привычку писать всё на двух языках сразу.
Согласен, тормозит бинарник, а не синтаксис. Но язык задаёт компилятору потолок: пока спецификация разрешает в рантайме переопределить любой метод и атрибут, компилятор обязан оставлять динамический диспатч. Поэтому 30 лет и миллиарды в PyPy/Faster CPython дали ~1.4x. А раздел 3 как раз о том, что в ИИ быстрый бинарник и так на C++/CUDA; вопрос лишь, почему исходник над ним обязан быть именно на Python. И ответ не технический, а социальный.
Справедливо: для I/O-bound веба скорость языка почти не важна, там правит удобство. Тезис статьи узкий - про compute- и energy-bound задачи ИИ, где оверхед виден. Спасибо, это стоило проговорить явно.
Так это ровно тезис статьи и есть - доминирование Python выросло из среды и привычки (в т.ч. "учат первым"), а не из технического превосходства. Раз причина социальная, а не физическая, то на новых площадках (on-device, edge), где нет инерции экосистемы, выбор снова открыт.
Спасибо, вы сформулировали точнее меня. Именно поэтому "просто напишите умный компилятор" и не работает: раз объекты одного типа не обязаны иметь одинаковый набор атрибутов, а любой из них можно переопределить в рантайме, компилятор обязан оставлять полный динамический поиск. Это потолок семантики, а не лень авторов CPython.
Нет, уже не Apple-only. На Swift и Swift Embedded можно всё что угодно написать (и пишут)
Согласен. После C/C++ Python и JS — это действительно облегчение, и бизнесу важнее всего скорость вывода фичей, а не пара миллисекунд.
Просто в on-device AI эти миллисекунды уже заметно влияют на батарею и стоимость серверов. Поэтому и предлагают Swift - удобство почти как у Python, но без сильного налога на производительность.
Согласен по всем пунктам, кроме "не обойти" - это верно там, где Python держится на инерции экосистемы. А на новых территориях его уже обошли, даже HuggingFace пишет ядро на Rust. Так что да — вниманием стоит не обходить и Swift, и Rust, и Mojo. Победа любого из них лечит главную болезнь: привычку писать всё на двух языках сразу.
Согласен, тормозит бинарник, а не синтаксис. Но язык задаёт компилятору потолок: пока спецификация разрешает в рантайме переопределить любой метод и атрибут, компилятор обязан оставлять динамический диспатч. Поэтому 30 лет и миллиарды в PyPy/Faster CPython дали ~1.4x. А раздел 3 как раз о том, что в ИИ быстрый бинарник и так на C++/CUDA; вопрос лишь, почему исходник над ним обязан быть именно на Python. И ответ не технический, а социальный.