Речь идет о дедлоках в одном приложении, в многопотоке, не в IPC.
Высокоуровневый язык и может предоставлять гарантии отсутствия блокировок, если вместо низкоуровневых блокировок он предоставляет механизм CSP с неблокируемой или буферизованной связью. И такие языки есть.
Тестовый набор JDK содержит десятки тысяч тестов, в общей сложности более двух миллионов строк кода. Это относительная гарантия того, что unsafe Java runtime не будит ломать safe Java код.
Если я подлючу случаный крейт с unsafe-фрагментом кода, где гарантия, что он был написан столь же ответственно, и что его ежедневные фиксы не сломают мое приложение?
Ни один язык программирования не защитит от бесконечной вставки чего-либо в массив, от чего будет «утечка памяти» или от явного указания программистом «упади здесь».
Переполнение стека и накопление аллокаций в теоретически достижимых точках иерархии объектов - это частные следствия проблемы останова (halting problem). Они не имеют решения, поэтому все системы, гарантирующие отсутствие утечек памяти (и вообще любых ресурсов) явно или неявно исключают из рассмотрения эти недоказуемые "утечки".
Проблема Раста (среди прочих) в том, что он совершенно никак не болется с утечками памяти, в то время как его промоутеры или не акцентируют внимание публики на том что "Раст течет" либо вовсе раздают гарантии что Раст "prevents most leaks", ведь если прямо цитировать РастБук (memory leaks are memory safe), то народ начинает задаваться вопросом, а так ли велика выгода за те ограничения, которые вводятся Растом?
видимо, надо отдельно оговорить, что в Safe Rust, что покрывает бо́льшую часть кода, который пишут)
Исследования (например, RustBelt) показывают что ~30–50% крейтов используют unsafe хотя бы один раз. Более 90% кода Rust косвенно зависят от библиотек, которые используют unsafe, поэтому зависимость от них транзитивно вносит unsafe. Safe Rust существует только в академических примерах.
Этот проект использует опасные техники, приводящие в крэшам, такие как unwrap и unsafe код.
Его трекер содержит десятки багов с крэшами.
Его пустой пример hello world занимает 126.4M RAM
99% этого проекта написано не на Расте, а на внутреннем DSL, который вводится макросом live_design!. Этот отдельный язык дополнительно затрудняет написание, отладку, сопровождение этого проекта и всех проектов, которые его используют, поднимают порог входа в и без того непростой Раст. Сам факт наличия DSL для UI говорит не в пользу выразительности Раста.
Внутри Makerpad для хранения графа сцены используется полностью самописная библиотека умных указателей (WidgetRef), которая никак не связана с Растом. Этому может быть только два правдоподобных объяснения:
система управления памятью Раста не пригодна для безопасной и эффективной работы с древовидным DOM-ом
или она столь сложна, что проще написать свою собственную.
Надеюсь на взаимность, хотелось бы увидеть пример (в виде комментария или статьи), как Раст помогает проектировать структуры данных любой предметной области, свободные от утечек, крашей и data races.
Почему все статьи нахваливающие Раст статьи никогда не приводят реальных примеров, реальных задач с реальными структурами данных, где Раст показывает свои сильные стороны.
Покажите как в Расте делается иерархия вложенных виджетов, которые шарят общие стили и связываются ссылками между собой и с моделью/контроллером. Как декларации времени жизни предотвращает утечки памяти. Как borrow checker обеспечивает безопасность памяти.
Если GUI-виджеты не ваша тема, покажите эти замечательные механизмы на примере бизнес-объектов, офисных документов, медиа-данных или игровых движков.
Насколько я увидел из примеров и новостей, Раст не просто "делает программистам больно", он ничего за это не дает - Раст-программы так же текут и падают на сложных задачах.
Это не сборщик, но он встраивается в CMake и работает на любой платформе. При старте CMake-сборки он автоматом выкачивает все зависимости в исходниках, патчит их под целевую платформу, собирает в debug/release, удобно раскладываает все по файловой системе и пишет в лог, какие target_link_libraries добавить, чтобы беспроблемно начать использовать - хоть Skia на Raspbian, хоть Curl под виндами. Без него подключение больших кросс-платформенных зависимостей превращается в квест на несколько недель с ним - одна строка в json.
Очки работают на любом компьютере с USB type-c video out. Для windows, андроид и макос существует nebula - программа создающая виртуальные рабочие столы. Без этой программы очки всё равно работают, показывая один монитор жёстко закреплённый прямо перед глазами. Это очень удобно для игр, например на steam deck-e. Но чтобы кодить лучше использовать небулу. Если видеокарта не тянет, или нет USB type-c, можно купить брелок x-real beam - который создаёт виртуальный монитор закреплённый в пространстве. Как небула, только аппаратно и беспроводно. К биму также можно подключаться HDMI-USB type-c проводом. Это решает вообще все проблемы совместимостью.
Кодить, отлаживаться, читать документацию - ок. Разрешения маловато поэтому за столом все еще удобнее пользоваться большими мониторами, но у экрана лаптопа очки выигрывают во всех портативных сценариях. Пробовал использовать метаквест-3. У него разрешение получше и углы обзора побольше, но лицо от долгого ношения... не то чтобы потеет, но как-то не комфортно. Да и в транспорте его неудобно использовать.
Я купил за $200 ar-очки Xreal Air, и воткнул их в usb-c своего лаптопа. Теперь у меня есть три больших приватных монитора висящих в воздухе передо мной, и я могу их использовать в офисе, дома на диване, на улице, в самолёте и автомобиле, когда не за рулём (отвлекает). Подумываю о том чтобы открутить ставшую ненужной крышку-дисплей, чтобы сделать лаптоп моноблочным "компьютером в клавиатуре".
Речь идет о дедлоках в одном приложении, в многопотоке, не в IPC.
Высокоуровневый язык и может предоставлять гарантии отсутствия блокировок, если вместо низкоуровневых блокировок он предоставляет механизм CSP с неблокируемой или буферизованной связью. И такие языки есть.
Существуют языки, защищающие от дедлоков. И да, никто не дает обычным приложениям прав на удаление таблиц в базах данных.
Тестовый набор JDK содержит десятки тысяч тестов, в общей сложности более двух миллионов строк кода. Это относительная гарантия того, что unsafe Java runtime не будит ломать safe Java код.
Если я подлючу случаный крейт с unsafe-фрагментом кода, где гарантия, что он был написан столь же ответственно, и что его ежедневные фиксы не сломают мое приложение?
Переполнение стека и накопление аллокаций в теоретически достижимых точках иерархии объектов - это частные следствия проблемы останова (halting problem). Они не имеют решения, поэтому все системы, гарантирующие отсутствие утечек памяти (и вообще любых ресурсов) явно или неявно исключают из рассмотрения эти недоказуемые "утечки".
Проблема Раста (среди прочих) в том, что он совершенно никак не болется с утечками памяти, в то время как его промоутеры или не акцентируют внимание публики на том что "Раст течет" либо вовсе раздают гарантии что Раст "prevents most leaks", ведь если прямо цитировать РастБук (memory leaks are memory safe), то народ начинает задаваться вопросом, а так ли велика выгода за те ограничения, которые вводятся Растом?
Как в такой схеме предотвращаются дедлоки?
Исследования (например, RustBelt) показывают что ~30–50% крейтов используют unsafe хотя бы один раз. Более 90% кода Rust косвенно зависят от библиотек, которые используют unsafe, поэтому зависимость от них транзитивно вносит unsafe. Safe Rust существует только в академических примерах.
Спасибо за ссылку на Makerpad
Этот проект использует опасные техники, приводящие в крэшам, такие как unwrap и unsafe код.
Его трекер содержит десятки багов с крэшами.
Его пустой пример hello world занимает 126.4M RAM
99% этого проекта написано не на Расте, а на внутреннем DSL, который вводится макросом live_design!. Этот отдельный язык дополнительно затрудняет написание, отладку, сопровождение этого проекта и всех проектов, которые его используют, поднимают порог входа в и без того непростой Раст. Сам факт наличия DSL для UI говорит не в пользу выразительности Раста.
Внутри Makerpad для хранения графа сцены используется полностью самописная библиотека умных указателей (WidgetRef), которая никак не связана с Растом. Этому может быть только два правдоподобных объяснения:
система управления памятью Раста не пригодна для безопасной и эффективной работы с древовидным DOM-ом
или она столь сложна, что проще написать свою собственную.
Пожалуйста:
https://youtu.be/PG0wRb7eYms
https://www.reddit.com/r/rust/comments/13400bu/my_rust_program_well_game_is_leaking_memory_4mbs/
https://internals.rust-lang.org/t/the-problem-s-with-unwrap/22046
https://thenewstack.io/unsafe-rust-in-the-wild
Надеюсь на взаимность, хотелось бы увидеть пример (в виде комментария или статьи), как Раст помогает проектировать структуры данных любой предметной области, свободные от утечек, крашей и data races.
Почему все статьи нахваливающие Раст статьи никогда не приводят реальных примеров, реальных задач с реальными структурами данных, где Раст показывает свои сильные стороны.
Покажите как в Расте делается иерархия вложенных виджетов, которые шарят общие стили и связываются ссылками между собой и с моделью/контроллером. Как декларации времени жизни предотвращает утечки памяти. Как borrow checker обеспечивает безопасность памяти.
Если GUI-виджеты не ваша тема, покажите эти замечательные механизмы на примере бизнес-объектов, офисных документов, медиа-данных или игровых движков.
Насколько я увидел из примеров и новостей, Раст не просто "делает программистам больно", он ничего за это не дает - Раст-программы так же текут и падают на сложных задачах.
Открыл google docs, фичи не нашел: Insert > Building Blocks > Нет никакого "Code blocks". То есть не просто форматирования, но блоков кода вообще.
VSCode и GitHub тоже стороной обходить?
vcpkg не просто free, это open source под MIT
Это не сборщик, но он встраивается в CMake и работает на любой платформе. При старте CMake-сборки он автоматом выкачивает все зависимости в исходниках, патчит их под целевую платформу, собирает в debug/release, удобно раскладываает все по файловой системе и пишет в лог, какие
target_link_librariesдобавить, чтобы беспроблемно начать использовать - хоть Skia на Raspbian, хоть Curl под виндами. Без него подключение больших кросс-платформенных зависимостей превращается в квест на несколько недель с ним - одна строка в json.Про vcpkg будет?
Прочитав эту статью я перестал понимать теорию категорий, спасибо.
Очки работают на любом компьютере с USB type-c video out. Для windows, андроид и макос существует nebula - программа создающая виртуальные рабочие столы. Без этой программы очки всё равно работают, показывая один монитор жёстко закреплённый прямо перед глазами. Это очень удобно для игр, например на steam deck-e. Но чтобы кодить лучше использовать небулу. Если видеокарта не тянет, или нет USB type-c, можно купить брелок x-real beam - который создаёт виртуальный монитор закреплённый в пространстве. Как небула, только аппаратно и беспроводно. К биму также можно подключаться HDMI-USB type-c проводом. Это решает вообще все проблемы совместимостью.
Кодить, отлаживаться, читать документацию - ок. Разрешения маловато поэтому за столом все еще удобнее пользоваться большими мониторами, но у экрана лаптопа очки выигрывают во всех портативных сценариях. Пробовал использовать метаквест-3. У него разрешение получше и углы обзора побольше, но лицо от долгого ношения... не то чтобы потеет, но как-то не комфортно. Да и в транспорте его неудобно использовать.
Я купил за $200 ar-очки Xreal Air, и воткнул их в usb-c своего лаптопа. Теперь у меня есть три больших приватных монитора висящих в воздухе передо мной, и я могу их использовать в офисе, дома на диване, на улице, в самолёте и автомобиле, когда не за рулём (отвлекает). Подумываю о том чтобы открутить ставшую ненужной крышку-дисплей, чтобы сделать лаптоп моноблочным "компьютером в клавиатуре".
То есть изобрели имена файлов, только не уникальные и без возможности их задавать вручную.
VR/AR очки = сколько угодно огромных экранов. Даже в самолёте и автомобиле.