In this work, we propose Stacked Borrows, an operational semantics for memory accesses in Rust. Stacked Borrows defines an aliasing discipline and declares programs violating it to have undefined behavior, meaning the compiler does not have to consider such programs when performing optimizations.
А под ней:
We also implemented this operational model in an interpreter for Rust and ran large parts of the Rust standard library test suite in the interpreter to validate that the model permits enough real-world unsafe Rust code.
А в самой статье описана реализация интерпретатора Miri, который проверяет код std на соответствие модели Stacked Borrows:
We implemented Stacked Borrows in Miri to be able to test existing bodies of unsafe Rust code and make sure the model we propose is not completely in contradiction with how real Rust code gets written. Moreover, this also served to test a large body of safe code (including code that relies on non-lexical lifetimes), empirically verifying that Stacked Borrows is indeed a dynamic version of the borrow checker and accepts strictly more code than its static counterpart.
Так что либо вы сами издеваетесь, либо мы по разному понимаем термин Aliasing Model.
Конечно. Например я обратил внимание, что вы даже не перешли по ссылке оппонента. В ней 11-я статья от 2020 года описывает то, что вам нужно. А вы привели две статьи 2018 года, конечно в них всё было в зачаточном состоянии.
Это не правда. Вот этот комментарий, и особенно комментарии по всей ветке ниже показывают, что ваша претензия к реализации связного списка не справедливы. На Rust можно написать связный список без unsafe, но нельзя написать оптимальную реализацию в стиле С.
А вот в этом комментарии и нижележащей ветке вам привели ссылки на доказательства корректности модели памяти Rust. Но не доказательства корректности её реализации в компиляторе.
Так и не лезут: компилятор допилили под требования Торвальдса, API выделения памяти допилили (чтобы возвращать OutOfMemory через Result, а также отделили библиотеку alloc от std). Вообще кучу всего в std доделали, и это будет полезно не только в Linux.
Сейчас Торвальдс требует опцию rustfmt, чтобы он не менял агрессивно форматирование блоков use. Звучит вполне логично, и это тоже сделают.
А Rust в ядре Linux есть и будет. И это мнение Торвальдса как раз основано на том, что его требования к языку и экосистеме учитывают и удовлетворяют тем или иным способом.
Работа с регистрами по определению unsafe, но в С и С++ нет такого ключевого слова, так что по кол-ву unsafe сравнивать некорректно.
Но поверх unsafe можно построить safe API, и этим повсеместно пользуются. Приведу простой пример:
Если взять стандартную библиотеку любого языка, то там 90% кода будет unsafe из-за системных вызовов, передачи указателей в ядро ОС, арифметики указателей ради быстродействия и т.д. Стандартной библиотекой пользуется любой программист на этом языке.
По моему опыту, скорость компиляции (инкрементальной) примерно одинаковая с С++. В работе с матрицами точно быстрее, где-то медленнее. В целом меня устраивает. В последней статье правильно указали про lto, в текущем проекте (верхний крейт 40kloc) инкрементальная компиляция 4-5 секунд, но если выключить lto то 1-1.5 секунды.
Не инкрементальную делаю наверное раз в пол года, когда обновляю компилятор, так что вообще не важно. И в последней статье как-раз про то, как её ускорить на билд сервере.
В BetterC, например. Это базовое требование для поддержки baremetal. Так что во всех ЯП с таким специалитетом.
Ну в С и С++ с этим как-то грустно, BetterC пока не пробовал.
Часть про Rust устарела процентов на 90. Вероятно и про остальные языки тоже. Например в конце вот этого очень длинного комментария описано реальное распространение Rust.
поменяли логику контроллера ссылок NLL (я умудрился в учебнике наступить на пример, как в статье) сломав 220 сторонних библиотек, которые как зависимости утащили за собой еще 2000.
Это неправда. Вы можете запустить те самые примеры из учебника даже на последнем компиляторе с edition="2015", и они будут работать. И библиотеки с edition="2015" можно вызывать из кода с edition="2024", будет (почти всегда) компилироваться и работать.
Нарушения обратной конечно совместимости были, но их очень мало, а не так как вы пытаетесь представить.
Например, недавно была новость про переписывание tmux на rust с 67к си кода на 87к строк unsafe rust кода, что определённо менее надёжно, чем tmux на си, который уже обкатан.
В той новости сам автор прямо пишет, что это альфа версия и хобби-проект:
Автор решения советует не использовать эту наработку в том случае, если кто-то не готов мириться с частыми сбоями.
Давайте все-таки сравнивать сравнимое. Подождем рабочий вариант, если он будет конечно.
Я и искал try_compile. А сейчас вы скинули совсем другие макросы. И вы в скриншоте вырезали строку "Please do not use this.", что как-бы намекает..
Есть куча документации прямо говорящей, что процедурные макросы компилируются в отдельные библиотеки, запускаются в отдельных процессах, в коде компилятора сами разбирайтесь зачем им сервера и клиенты макросов
Видимо вы не различаете декларативные и процедурные макросы. Последние по определению работают в отдельном процессе. Но вы писали про try_compile, который декларативный.
📦 postcompile: A macro for compiling Rust code at runtime. Useful for snapshot testing.
Вообще первый раз вижу, чтобы макрос делал fork, и нельзя ли было без него обойтись. В остальных 99% макросов никаких форков нет, и все в одном процессе.
А вы заявляете как будто любой макрос в Rust запускает что-то в отдельных процессах, что очевидная ложь. Вобщем продолжайте набрасывать дальше..
Аргументация в самой статье, о чем я и написал. Но в комментариях до моего первого поста суть статьи почти не обсуждали.
Менять же можно разными способами: добавляя новые ключи компиляции, внести в один из профилей безопасности и т.д. А старый функционал постепенно объявлять deprecated.
А теперь посмотрите, на мой первый пост. Минусующие (и вы тоже) даже не поняли, что я знаю как работает std::move по стандарту, и критикую именно стандарт. А заминусовали за то, что я как-бы не знаю стандарт.
Вместо того, чтобы паясничать, могли бы просто признать что были не правы про пропаганду. А вы не правы, как ни считай: ни по кол-ву крейтов, ни по кол-ву строк кода.
Ваше образование почему-то не позволило вам прочитать внимательно текст по вашей же ссылке:
Например, чтобы узнать методом Монте-Карло, какое в среднем будет расстояние между двумя случайными точками в круге, нужно взять координаты большого числа случайных пар точек в границах заданной окружности, для каждой пары вычислить расстояние, а потом для них посчитать среднее арифметическое.
4 штуки никак нельзя назвать большим числом. А вот 127,000 шт по моей ссылке уже большое число.
Кроме того, если в 4 крейтах будет 1/100000000000000000000000 строчек unsafe, по вашей статистике будет 100% случаев unsafe.
Встает вопрос, какие ещё допущения вам позволяет ваше математическое образование =)
P.S.
Вообще метод описан, если Вам мала выборка из 4х, берите большую. Будет выше точность.
С увеличением размера выборки до бесконечности (до фактического кол-ва крейтов) метод Монте-Карло превращается.. превращается в полноценную статистику, которую я уже приводил.
Интересно вы по выборке из 4 приложений отменили общую статистику по всем крейтам (127,000 шт). Большая разница (25% vs 81%) должна была вам тонко намекнуть, что 4 шт для статистики ничтожны.
Вот статистика по строчкам кода из 4 приложений еще куда ни шло, т.к. обеспечена статистически значимым числом: суммарно 109000 строк кода.
Итого 0,04% обоснованного (или 0,05% всего) unsafe кода - это я и называю "в прикладном коде unsafe практически не встречается". Делайте выводы математически правильно!
1) parity-db 20/24600 = 0.081% Внутри вызовы mmap и libс. Обоснованно. Еще 3 transmute, на первый взгляд можно и без них. 2) tabiew 11/7252 = 0,15% Всё в тестах, и абсолютно не нужно. Можно использовать static_cell или атомарные переменные. 3) xi-editor 30/29356 = 0.11% sse, avx, libc - какие-то оптимизации. Еще 2 не нужных str::from_utf8_unchecked.
4) poem 0/47700 = 0% Если выкинуть ненужные (на мой взгляд) unsafe, выйдет (17+28)/(24600+7252+29356+47700) = 0.04% В 2 из 4 проектах можно обойтись без unsafe точно.
P.S. mmap очевидно нужен, c libc, sse и avx я не разбирался, тут уже нужно много времени потратить.
Прямо над вашей цитатой написано следующее:
А под ней:
А в самой статье описана реализация интерпретатора Miri, который проверяет код std на соответствие модели Stacked Borrows:
Так что либо вы сами издеваетесь, либо мы по разному понимаем термин Aliasing Model.
P.S. Чисто ради интереса, минусы тоже вы лепите?
И вы еще раз подтвердили, что не переходите по ссылкам. Еще раз дублирую:
Конечно. Например я обратил внимание, что вы даже не перешли по ссылке оппонента. В ней 11-я статья от 2020 года описывает то, что вам нужно. А вы привели две статьи 2018 года, конечно в них всё было в зачаточном состоянии.
Это не правда. Вот этот комментарий, и особенно комментарии по всей ветке ниже показывают, что ваша претензия к реализации связного списка не справедливы. На Rust можно написать связный список без unsafe, но нельзя написать оптимальную реализацию в стиле С.
А вот в этом комментарии и нижележащей ветке вам привели ссылки на доказательства корректности модели памяти Rust. Но не доказательства корректности её реализации в компиляторе.
Да, конечно я имел ввиду библиотеку core, а не std.
Так и не лезут: компилятор допилили под требования Торвальдса, API выделения памяти допилили (чтобы возвращать OutOfMemory через Result, а также отделили библиотеку alloc от std). Вообще кучу всего в std доделали, и это будет полезно не только в Linux.
Сейчас Торвальдс требует опцию rustfmt, чтобы он не менял агрессивно форматирование блоков use. Звучит вполне логично, и это тоже сделают.
А Rust в ядре Linux есть и будет. И это мнение Торвальдса как раз основано на том, что его требования к языку и экосистеме учитывают и удовлетворяют тем или иным способом.
Работа с регистрами по определению unsafe, но в С и С++ нет такого ключевого слова, так что по кол-ву unsafe сравнивать некорректно.
Но поверх unsafe можно построить safe API, и этим повсеместно пользуются. Приведу простой пример:
Если взять стандартную библиотеку любого языка, то там 90% кода будет unsafe из-за системных вызовов, передачи указателей в ядро ОС, арифметики указателей ради быстродействия и т.д. Стандартной библиотекой пользуется любой программист на этом языке.
По моему опыту, скорость компиляции (инкрементальной) примерно одинаковая с С++. В работе с матрицами точно быстрее, где-то медленнее. В целом меня устраивает.
В последней статье правильно указали про lto, в текущем проекте (верхний крейт 40kloc) инкрементальная компиляция 4-5 секунд, но если выключить lto то 1-1.5 секунды.
Не инкрементальную делаю наверное раз в пол года, когда обновляю компилятор, так что вообще не важно. И в последней статье как-раз про то, как её ускорить на билд сервере.
Ну в С и С++ с этим как-то грустно, BetterC пока не пробовал.
Согласен.
Просто я не вижу смысл обсуждать альфа-версии софта (давно известного), портированные с других языков.
Часть про Rust устарела процентов на 90. Вероятно и про остальные языки тоже.
Например в конце вот этого очень длинного комментария описано реальное распространение Rust.
Это неправда. Вы можете запустить те самые примеры из учебника даже на последнем компиляторе с edition="2015", и они будут работать. И библиотеки с edition="2015" можно вызывать из кода с edition="2024", будет (почти всегда) компилироваться и работать.
Нарушения обратной конечно совместимости были, но их очень мало, а не так как вы пытаетесь представить.
Перенесли большие куски кода из std в core и alloc. Скажите, в каком языке вы сможете пользоваться большей частью std без рантайма и даже без кучи?
В той новости сам автор прямо пишет, что это альфа версия и хобби-проект:
Давайте все-таки сравнивать сравнимое. Подождем рабочий вариант, если он будет конечно.
Вы написали
Я и искал try_compile. А сейчас вы скинули совсем другие макросы. И вы в скриншоте вырезали строку "Please do not use this.", что как-бы намекает..
Видимо вы не различаете декларативные и процедурные макросы. Последние по определению работают в отдельном процессе. Но вы писали про try_compile, который декларативный.
Этот макрос часть проекта https://github.com/scufflecloud/scuffle, нужен им для тестирования:
Вообще первый раз вижу, чтобы макрос делал fork, и нельзя ли было без него обойтись. В остальных 99% макросов никаких форков нет, и все в одном процессе.
А вы заявляете как будто любой макрос в Rust запускает что-то в отдельных процессах, что очевидная ложь. Вобщем продолжайте набрасывать дальше..
Аргументация в самой статье, о чем я и написал. Но в комментариях до моего первого поста суть статьи почти не обсуждали.
Менять же можно разными способами: добавляя новые ключи компиляции, внести в один из профилей безопасности и т.д. А старый функционал постепенно объявлять deprecated.
А теперь посмотрите, на мой первый пост. Минусующие (и вы тоже) даже не поняли, что я знаю как работает std::move по стандарту, и критикую именно стандарт. А заминусовали за то, что я как-бы не знаю стандарт.
Вместо того, чтобы паясничать, могли бы просто признать что были не правы про пропаганду. А вы не правы, как ни считай: ни по кол-ву крейтов, ни по кол-ву строк кода.
Итак?
Ваше образование почему-то не позволило вам прочитать внимательно текст по вашей же ссылке:
4 штуки никак нельзя назвать большим числом. А вот 127,000 шт по моей ссылке уже большое число.
Кроме того, если в 4 крейтах будет 1/100000000000000000000000 строчек unsafe, по вашей статистике будет 100% случаев unsafe.
Встает вопрос, какие ещё допущения вам позволяет ваше математическое образование =)
P.S.
С увеличением размера выборки до бесконечности (до фактического кол-ва крейтов) метод Монте-Карло превращается.. превращается в полноценную статистику, которую я уже приводил.
Интересно вы по выборке из 4 приложений отменили общую статистику по всем крейтам (127,000 шт). Большая разница (25% vs 81%) должна была вам тонко намекнуть, что 4 шт для статистики ничтожны.
Вот статистика по строчкам кода из 4 приложений еще куда ни шло, т.к. обеспечена статистически значимым числом: суммарно 109000 строк кода.
Итого 0,04% обоснованного (или 0,05% всего) unsafe кода - это я и называю "в прикладном коде unsafe практически не встречается". Делайте выводы математически правильно!
Господа минусующие, не могли бы вы аргументировать свою позицию?
Куда же вы пропали? Прошло уже 3 дня, на хабре вы бываете регулярно..
Я все еще жду от вас аргументации про пропаганду. Свой тезис я доказал общей статистикой, и вашим способом, по вашим же ссылкам.
Надеюсь на аргументированный ответ (но надежды уже тают..)
1) parity-db 20/24600 = 0.081%
Внутри вызовы mmap и libс. Обоснованно.
Еще 3 transmute, на первый взгляд можно и без них.
2) tabiew 11/7252 = 0,15%
Всё в тестах, и абсолютно не нужно. Можно использовать static_cell или атомарные переменные.
3) xi-editor 30/29356 = 0.11%
sse, avx, libc - какие-то оптимизации.
Еще 2 не нужных str::from_utf8_unchecked.
4) poem 0/47700 = 0%
Если выкинуть ненужные (на мой взгляд) unsafe, выйдет (17+28)/(24600+7252+29356+47700) = 0.04%
В 2 из 4 проектах можно обойтись без unsafe точно.
P.S. mmap очевидно нужен, c libc, sse и avx я не разбирался, тут уже нужно много времени потратить.