До const-generics сделать что-то отдаленно похожее на eigen в расте было нельзя совсем. Сейчас const-generic тоже могут мало, для поднятия на уровень типов приходится городить такие приколы
Да, const-generics пока все не очень. Надеюсь допилят.
Там сложение создаёт новую матрицу, а для всех симд операций отдельно захардкодены явные методы (если вообще захардкодены).
В eigen автоматически выбирается вариант симд, а в nalgebra нужно явно передать с использованием внешних ящиков. Не могу сказать что способ eigen всегда лучше (хотя он всегда проще), зависит от алгоритма. В некоторых случаях нужно подбирать размер симд операции (например AVX 4,8 или 16 слов) чтобы добиться максимальной производительности. https://www.rustsim.org/blog/2020/03/23/simd-aosoa-in-nalgebra/
Про новую матрицу не понял, поясните.
В nalgebra даже transpose() копирует матрицу, а transpose().transpose() делает две копии. В то время как в нормальном фреймворке эти операции не делают ничего вообще.
Ну это проблема в библиотеке, хз почему не реализовали.
В любом случае, nalgebra это был просто пример того, что библиотеки обычно не переписывают с С и С++ на Rust, а создают новые.
Как раз то что ансейф есть в 1/5 крейтов это ок. Я вам это и сказал в первом сообщении. А все остальные цитаты и выводы из поста что вы привели, - это уже потенциально реклама.
Значит я вас неправильно понял. Думал вы в негативном смысле написали.
то же самое может внезапно оказаться для оставшихся 80%
Но в те времена стандартная библиотека была гораздо хуже, и некоторые сейчас очевидные вещи нельзя было сделать без unsafe. По-этому распределение может быть в пользу пакетов с unsafe, но конечно надо проверять.
Скажите это растоманам которые бегают по гитхабу и создают ишью вида "consider rewriting in rust". Недавно один уникум даже в Qt багтрекере такое создал. Но наверное на созданиях тикетов деятельность по переписыванию на раст обычно и заканчивается =)
Я на Rust пишу с 2018 примерно, но по гитхабу так не бегаю) И я ни разу не видел чтобы переписали какой-то проект целиком на Rust (не исключаю что такое существует). Но видел много новых библиотек, аналогичных по функционалу уже существующим на С и С++, но с другим API. Например eigen в С++ и nalgebra в Rust. Хотя казалось бы математика везде одинакова.
Напомню ветка началась с обсуждения зависимостей. Вы жаловаолись что зависимости на си или си++ это плохо, они могут быть не протестированы санитайзерами, не следовать современным практикам и т п... А теперь оказывается "это обертки над С, но никто не жалуется" :-D
Я сейчас отлистал вверх и не нашел начало ветки от Arenos, похоже он удалил сообщение (пора уже делать скриншоты..). Но он заявлял что санитайзеры и современные практики для него лучше подходят, а компилятор Rust слишком сильно ограничивает. На это я ему и ответил, что
могут быть не протестированы санитайзерами, не следовать современным практикам и т п..
Так что я от своих слов не отказываюсь, а вы их вырвали из контекста. Я считаю что больше гарантий от компилятора это лучше. Но Haskel пока не освоил.
Даже плохой unsafe блок либо повалит программу в ошибку, либо испортит какое то значение локально, не приводя к общему UB программы.
Вот в этом не соглашусь. UB в unsafe блоке может испортить любую часть программы за пределами unsafe, даже очень далеко стоящую, и на первый взгляд не связанную с unsafe блоком. В этом плане UB в Rust ничем не отличается от UB в C и C++. Их абсолютно нельзя допускать.
Другой вопрос, что сам список UB намного, просто в десятки раз меньше чем в С++. Ну и п.1 и п.3 сильно помогают.
Так замеры делало rust foundation. Всё что написано в этой статье нельзя считать объективной информацией. Понятно что задача раст евангилистов убедить нас в том что это нестрашно, рассказать что это виновата ОС и кто угодно кроме них. А чтобы оценить сколько реально ансейф процентов в итоговом продукте, надо сравнивать сколько функционала за теми С/С++ обертками. При том как то умнее чем просто по количеству строк, потому что раст очень вербозный.
Они просто подсчитали крейты, в которых есть хотя бы 1 строчка unsafe. Это вполне объективная информация для данной простой модели подсчета.
Of those 127,000 crates, 24,362 make use of the unsafe keyword, which is 19.11% of all crates. And 34.35% make a direct function call into another crate that uses the unsafe keyword. [6] Nearly 20% of all crates have at least one instance of the unsafe keyword, a non-trivial number.
Другую статистику никто не посчитал. Но не потому что это заговор каких-то там евангелистов, а потому что это сложнее, и надо договориться по методике которая всех устроит.
Но если подсчитать, то может внезапно выясниться, что среди тех 19.11% крейтов многие написаны во времена выхода Rust 1.0 и не поддерживаются (аналогичные проблемы есть и в других пакетных менеджерах, например npm).
Кроме того надо еще исключить пакеты с 10 строчками кода, выложенные ну просто потому что хотелось попробовать выложить (опять те же претензии к npm).
Вобщем все сложно, но ведь это вы сослались на эту статистику, и постом ниже уже считаете её необъективной xD.
Понятно что задача раст евангилистов убедить нас в том что это нестрашно, рассказать что это виновата ОС и кто угодно кроме них.
Не возможно и не нужно переписывать все библиотеки мира на Rust. Нужно соблюдать разумный баланс.
То же относится к любым языкам, которые используют библиотеки других языков. На Python вообще половина PyPi это обертки над С, но никто не жалуется. При этом код по сути unsafe, но ключевого слова такого нет, и за счет этого выглядит приятнее)
Так что вы предлагаете то? Или приведите пример другого языка, где FFI вделан лучше и безопасней.
Утверждал что не используют для верифиакции библиотек. То что модель мири как-то покрутили в коке на предмет совместимости с какой-то моделью оптимизаций - не знал.
Most of these Unsafe Rust uses are calls into existing third-party non-Rust language code or libraries, such as C or C++.
Так что все зависит от ваших зависимостей. Если добавлять библиотеки-обертки из C, C++ и других языков, то там конечно будет unsafe. Ну и конечно API ОС:
In fact, the crate with the most uses of the unsafe keyword is the Windows crate [7], which allows Rust developers to call into various Windows APIs.
Впрочем то же самое будет в любом языке, использующем код другого языка, только не будет помечено unsafe (хотя в C-Sharp есть свой unsafe). Но соотношение 20/80% намекает, что для часто используемых областей написаны библиотеки на чистом Rust без единой строчки unsafe.
Так а сколько кода реально верифицировано? Думаю мало.
Я к тому и веду, что вы тоже были не правы, что coq совсем не используется. А сейчас выяснилось, что вы читали первоисточник, и все-же категорично утверждали обратное.
Вот тут вы рассказли про верефикацию стд библиотеки и привели ссылку на мири. Мири не делает формальную верификацию стд библиотеки потому что мири это санитайзер. Вы ошиблись. Я указал вам на эту ошибку.
Согласен, тут я ошибся.
Где я это утверждал? Что значит совсем? Вообще в мире?
Вы утверждали, что coq никто не пользуется в Rust. Не передергивайте, вот ваша цитата:
coq уже больше похоже на правду, но реально им никто не пользуется
Далее:
Фраза "формально проверили правила borrow checker" сама по себе не имеет смысла. Что именно проверили? Что правила не противоречивы между собой? Выражайтесь в следущий раз яснее. Возможно для этого полезно ознакомится с темой более глубоко прежде чем делать громкие заявления.
Предлагаю вам ознакомиться с первоисточником:
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 give formal proofs (mechanized in Coq) showing that this rules out enough programs to enable optimizations that reorder memory accesses around unknown code and function calls, based solely on intraprocedural reasoning. 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
Не бывает безопасного/надёжного на 99% кода, код либо надежный и безопасный, либо нет, так же как вы либо живы либо мертвы, но не живы на 90% :) Поэтому unsafe блоки в коде делают его весь ненадёжным и проще уж тогда на C++ писать :)
А как тогда работают другие языки? Ведь все они под капотом вызывают API ОС и код зависимостей на C, что по определению не безопасно. Вот только в Java, Go или C-Sharp что-то не слышно про ошибки с памятью и UB.
Так что таким подходом вы отрицаете саму идею безопасного API и разделения ответственности между авторами библиотек.
Есть большая разница: утечка из-за ошибки в коде (в unsafe) и сознательно вызванная утечка через Box::leak. Почитайте документацию:
This function is mainly useful for data that lives for the remainder of the program’s life.
Box::leak не приведет к use after free, double free и т.д. Потому что гарантии borrow checker никуда не деваются, и после выхода этой ссылки из области видимости вы уже не сможете к ней обратиться.
То, что трейт есть только в nightly builds, не говорит о том, что информация, о которой я пишу, недостоверна.
Это внутренняя реализация компилятора. Сегодня он есть в nightly, а прямо завтра может не быть. И такое реально много раз происходило с типами, которые есть только nightly, потому-что это эксперименты.
Кроме того вы не понимаете, что такое nightly компилятор. В нем нормальный рабочий код может не скомпилироваться, а может сгенерить неправильный ассемблер. А завтра сгенерит правильный. А при полной перекомпиляции снова неправильный. Скажите, вы в продакшен на с++ тоже генерите код альфа-версией gcc?
"Давай, до свидания" (с)
Переход на личности первым сделали вы, но токсичный почему-то я. Просто прекрасно!
Нет, пример был про Miri, в нем формально проверили правила borrow checker, заодно проверив и компилятор в части borrow checker. Вы же утверждали, что coq не используется совсем.
Кроме того проверять нужно только крейты, который активно используют unsafe, но при этом нет unsafe во внешнем API. В моей предметной области (микроконтроллеры) таких ровно 2: embassy-sync и heapless.
по факту для отлова уб используются утилиты заимствованные из С++
Нет, это вы сели в лужу, т.к. по факту везде используется miri, не имеющий отношения к С++. Но если очень хочется, то можно использовать valgrind и т.д.
coq уже больше похоже на правду, но реально им никто не пользуется
Я отвечал на это, и привел пример что используется.
1) Тем что стандартная библиотека Rust почти на 100% формально верифицирована именно чтобы устранить баги с unsafe. https://github.com/rust-lang/miri-test-libstd 2) Тем что в Rust принято формально верифицировать библиотеки, работающие с unsafe. Для этого есть соответствующие инструменты (https://github.com/rust-lang/miri/, https://github.com/formal-land/coq-of-rust и т.д.), и ими реально пользуются. 3) Наконец есть valgrind, адрессанитайзеры и прочие инструменты, которые работают как с С++, так и с Rust. Статические анализаторы тоже есть, хотя не совсем понятно зачем они нужны после всего вышеперечисленного.
Любопытно. Но если вы сами прорубите окно в реальный мир, то окажется что ваши зависимости не следуют вашим style гайдам. Более того, они и тулингом могут быть не покрыты, и тестами. А вот компилятор может обнаружить ошибку сразу, без доп инструментов, и его невозможно не запустить.
Кстати, тулинг ловит не все ошибки, об этом чуть выше писали. А С++ ругают за тысячи UB, из которых многие можно было бы сделать хотя бы unspecified behavior или platform-dependent.
Это эксперимент из nightly компилятора, и не известно когда будет к стабильном, и будет ли вообще. Ближайшая аналогия - proposal из С++, который специальным ключем поддерживается в gcc.
И тут внезапно натыкаемся на код, где функция, внутри которой дёргается ? возвращает Option.
Для Option синтаксический сахар раскроется по-другому. Это проблема?
Оу! Кажется, я понял, что имел ввиду один из комментаторов в недавнем посте, про токсичность растеров.
То что вы написали никогда не было в стабильном компиляторе. Что я написал про оператор ? - действует как минимум 9 лет с выходя Rust 1.0. Кроме того это самая базовая часть языка, без которой не получится написать буквально ни одной строки кода. Но вы почему-то считаете себя достаточно опытным чтобы писать недостоверную информацию про Rust.
Написать свой Result с блекджеком и дамами с низкой социальной ответственностью, в котором enum будет не с вариантами Ok и Err, например.
Ну ок. Но практическое применение этого какое? Всё-таки очень мало какие языки позволяют добавлять кастомные операторы, или изменять уже существующие.
В той статье автор не понятно на что плачет. Всегда можно написать static mut переменную, и везде к ней обращаться через unsafe. Также можно всю обработку ошибок игнорировать, вызывая unwrap, для прототипа сойдет. Всё обвешать слабыми ссылками и т.д. Но он хочет писать на Rust как на Python, о чем ему в комментариях и написали.
Остальные его претензии относятся к геймдев библиотекам. Ну так они видимо сырые, и когда-нибудь доведут до ума. Те же проблемы будут у любого языка, который только пришел в геймдев.
А в С++ есть исключения, и магические операторы try/catch, ваша мысль понятна.
Но базовые знания по Rust у вас отсутствуют. Никакого трейта Try не существует! Оператор ? это синтаксический сахар для обработки ошибок с типом Result. Строка let res = func()?; разворачивается компилятором в let res = match func() {
Ok(res) => res,
Err(err) => return err.into(),
};
То же самое вы можете написать без оператора ?. Хотя обычно никто не против синтаксического сахара в любом языке.
Но я так и не понял, зачем вам может понадобиться свой аналог оператора ?.
Вот это уже предметное обсуждение.
Да, const-generics пока все не очень. Надеюсь допилят.
В eigen автоматически выбирается вариант симд, а в nalgebra нужно явно передать с использованием внешних ящиков. Не могу сказать что способ eigen всегда лучше (хотя он всегда проще), зависит от алгоритма. В некоторых случаях нужно подбирать размер симд операции (например AVX 4,8 или 16 слов) чтобы добиться максимальной производительности.
https://www.rustsim.org/blog/2020/03/23/simd-aosoa-in-nalgebra/
Про новую матрицу не понял, поясните.
Ну это проблема в библиотеке, хз почему не реализовали.
В любом случае, nalgebra это был просто пример того, что библиотеки обычно не переписывают с С и С++ на Rust, а создают новые.
Значит я вас неправильно понял. Думал вы в негативном смысле написали.
Но в те времена стандартная библиотека была гораздо хуже, и некоторые сейчас очевидные вещи нельзя было сделать без unsafe. По-этому распределение может быть в пользу пакетов с unsafe, но конечно надо проверять.
Я на Rust пишу с 2018 примерно, но по гитхабу так не бегаю) И я ни разу не видел чтобы переписали какой-то проект целиком на Rust (не исключаю что такое существует).
Но видел много новых библиотек, аналогичных по функционалу уже существующим на С и С++, но с другим API. Например eigen в С++ и nalgebra в Rust. Хотя казалось бы математика везде одинакова.
Я сейчас отлистал вверх и не нашел начало ветки от Arenos, похоже он удалил сообщение (пора уже делать скриншоты..).
Но он заявлял что санитайзеры и современные практики для него лучше подходят, а компилятор Rust слишком сильно ограничивает. На это я ему и ответил, что
Так что я от своих слов не отказываюсь, а вы их вырвали из контекста.
Я считаю что больше гарантий от компилятора это лучше. Но Haskel пока не освоил.
Вот в этом не соглашусь. UB в unsafe блоке может испортить любую часть программы за пределами unsafe, даже очень далеко стоящую, и на первый взгляд не связанную с unsafe блоком. В этом плане UB в Rust ничем не отличается от UB в C и C++. Их абсолютно нельзя допускать.
Другой вопрос, что сам список UB намного, просто в десятки раз меньше чем в С++. Ну и п.1 и п.3 сильно помогают.
Они просто подсчитали крейты, в которых есть хотя бы 1 строчка unsafe. Это вполне объективная информация для данной простой модели подсчета.
Другую статистику никто не посчитал. Но не потому что это заговор каких-то там евангелистов, а потому что это сложнее, и надо договориться по методике которая всех устроит.
Но если подсчитать, то может внезапно выясниться, что среди тех 19.11% крейтов многие написаны во времена выхода Rust 1.0 и не поддерживаются (аналогичные проблемы есть и в других пакетных менеджерах, например npm).
Кроме того надо еще исключить пакеты с 10 строчками кода, выложенные ну просто потому что хотелось попробовать выложить (опять те же претензии к npm).
Вобщем все сложно, но ведь это вы сослались на эту статистику, и постом ниже уже считаете её необъективной xD.
Не возможно и не нужно переписывать все библиотеки мира на Rust. Нужно соблюдать разумный баланс.
То же относится к любым языкам, которые используют библиотеки других языков.
На Python вообще половина PyPi это обертки над С, но никто не жалуется. При этом код по сути unsafe, но ключевого слова такого нет, и за счет этого выглядит приятнее)
Так что вы предлагаете то? Или приведите пример другого языка, где FFI вделан лучше и безопасней.
Ок, принято.
Ага, и там же написано:
Так что все зависит от ваших зависимостей. Если добавлять библиотеки-обертки из C, C++ и других языков, то там конечно будет unsafe. Ну и конечно API ОС:
Впрочем то же самое будет в любом языке, использующем код другого языка, только не будет помечено unsafe (хотя в C-Sharp есть свой unsafe).
Но соотношение 20/80% намекает, что для часто используемых областей написаны библиотеки на чистом Rust без единой строчки unsafe.
Я к тому и веду, что вы тоже были не правы, что coq совсем не используется. А сейчас выяснилось, что вы читали первоисточник, и все-же категорично утверждали обратное.
Статистику в студию!
Согласен, тут я ошибся.
Вы утверждали, что coq никто не пользуется в Rust. Не передергивайте, вот ваша цитата:
Далее:
Предлагаю вам ознакомиться с первоисточником:
https://plv.mpi-sws.org/rustbelt/stacked-borrows/paper.pdf
А как тогда работают другие языки? Ведь все они под капотом вызывают API ОС и код зависимостей на C, что по определению не безопасно. Вот только в Java, Go или C-Sharp что-то не слышно про ошибки с памятью и UB.
Так что таким подходом вы отрицаете саму идею безопасного API и разделения ответственности между авторами библиотек.
Есть большая разница: утечка из-за ошибки в коде (в unsafe) и сознательно вызванная утечка через Box::leak. Почитайте документацию:
Box::leak не приведет к use after free, double free и т.д. Потому что гарантии borrow checker никуда не деваются, и после выхода этой ссылки из области видимости вы уже не сможете к ней обратиться.
Похоже вы из моего комментария прочитали только слово unsafe.
Формально верифицированный алгоритм будет на 100% надежен, и абсолютно без разницы сколько там unsafe, на С++ написан или на Rust.
Гм, всё-таки я первый начал. Был не прав, извиняюсь.
Кстати, а в чем магичность трейта Add?
В языке есть реально 2 магических трейта, но это самый обычный.
Это внутренняя реализация компилятора. Сегодня он есть в nightly, а прямо завтра может не быть. И такое реально много раз происходило с типами, которые есть только nightly, потому-что это эксперименты.
Кроме того вы не понимаете, что такое nightly компилятор. В нем нормальный рабочий код может не скомпилироваться, а может сгенерить неправильный ассемблер. А завтра сгенерит правильный. А при полной перекомпиляции снова неправильный.
Скажите, вы в продакшен на с++ тоже генерите код альфа-версией gcc?
Переход на личности первым сделали вы, но токсичный почему-то я. Просто прекрасно!
Нет, пример был про Miri, в нем формально проверили правила borrow checker, заодно проверив и компилятор в части borrow checker. Вы же утверждали, что coq не используется совсем.
Кроме того проверять нужно только крейты, который активно используют unsafe, но при этом нет unsafe во внешнем API. В моей предметной области (микроконтроллеры) таких ровно 2: embassy-sync и heapless.
Нет, это вы сели в лужу, т.к. по факту везде используется miri, не имеющий отношения к С++. Но если очень хочется, то можно использовать valgrind и т.д.
Я отвечал на это, и привел пример что используется.
Ок, по п.1 мне нужно было скинуть ссылку из п.2. И тем не менее:
libcore https://github.com/formal-land/coq-of-rust/tree/main/CoqOfRust/core
liballoc https://github.com/formal-land/coq-of-rust/tree/main/CoqOfRust/alloc
см. п1
Каким образом Miri заимствован из C++? Кстати модель ссылок StackedBorrows в нем формально верифицирована. И некоторые другие его части тоже.
1) Тем что стандартная библиотека Rust почти на 100% формально верифицирована именно чтобы устранить баги с unsafe.
https://github.com/rust-lang/miri-test-libstd
2) Тем что в Rust принято формально верифицировать библиотеки, работающие с unsafe. Для этого есть соответствующие инструменты (https://github.com/rust-lang/miri/, https://github.com/formal-land/coq-of-rust и т.д.), и ими реально пользуются.
3) Наконец есть valgrind, адрессанитайзеры и прочие инструменты, которые работают как с С++, так и с Rust.
Статические анализаторы тоже есть, хотя не совсем понятно зачем они нужны после всего вышеперечисленного.
Любопытно. Но если вы сами прорубите окно в реальный мир, то окажется что ваши зависимости не следуют вашим style гайдам. Более того, они и тулингом могут быть не покрыты, и тестами.
А вот компилятор может обнаружить ошибку сразу, без доп инструментов, и его невозможно не запустить.
Кстати, тулинг ловит не все ошибки, об этом чуть выше писали.
А С++ ругают за тысячи UB, из которых многие можно было бы сделать хотя бы unspecified behavior или platform-dependent.
Это эксперимент из nightly компилятора, и не известно когда будет к стабильном, и будет ли вообще. Ближайшая аналогия - proposal из С++, который специальным ключем поддерживается в gcc.
Для Option синтаксический сахар раскроется по-другому. Это проблема?
То что вы написали никогда не было в стабильном компиляторе. Что я написал про оператор ? - действует как минимум 9 лет с выходя Rust 1.0. Кроме того это самая базовая часть языка, без которой не получится написать буквально ни одной строки кода.
Но вы почему-то считаете себя достаточно опытным чтобы писать недостоверную информацию про Rust.
Ну ок. Но практическое применение этого какое? Всё-таки очень мало какие языки позволяют добавлять кастомные операторы, или изменять уже существующие.
В той статье автор не понятно на что плачет. Всегда можно написать static mut переменную, и везде к ней обращаться через unsafe. Также можно всю обработку ошибок игнорировать, вызывая unwrap, для прототипа сойдет. Всё обвешать слабыми ссылками и т.д. Но он хочет писать на Rust как на Python, о чем ему в комментариях и написали.
Остальные его претензии относятся к геймдев библиотекам. Ну так они видимо сырые, и когда-нибудь доведут до ума. Те же проблемы будут у любого языка, который только пришел в геймдев.
А в С++ есть исключения, и магические операторы try/catch, ваша мысль понятна.
Но базовые знания по Rust у вас отсутствуют. Никакого трейта Try не существует!
Оператор ? это синтаксический сахар для обработки ошибок с типом Result.
Строка
let res = func()?;разворачивается компилятором вlet res = match func() {Ok(res) => res,Err(err) => return err.into(),};То же самое вы можете написать без оператора ?. Хотя обычно никто не против синтаксического сахара в любом языке.
Но я так и не понял, зачем вам может понадобиться свой аналог оператора ?.