Я хоть и не автор статьи но у меня тоже есть что сказать по этому поводу…
>> Миф №1. Арифметика в Rust ничуть не безопасней C++
> То есть вы считаете нормой, что перемножив 46341 в Rust в релизе вы получите -2147479015 а не аналог исключения. Это ничуть не безопаснее.
Rust отключает некоторые проверки в release-е, но в debug-е он вызывает завершение программы через вызов макроса panic! при этом он говорит где была задетектирована ошибка, со строкой в файле и даже backtrace-ом
В release-е компилятор конечно же некоторые проверки убирает, но паника все равно остается для того кода на производительность которого это не сильно влияет или это не преведет к SIGSEGV (Segmentation Fault)
>> Миф №2. Плюсы Rust только в анализе времени жизни объектов.
>> Это заявление ложно, так как безопасное подмножество Rust защищает от ошибок, связанных с многопоточностью
> В Rust без вских unsafe можно получить deadlock doc.rust-lang.org/std/sync/struct.Mutex.html
> Основная причина — невозможность выразить необходимое в системе типов Rust. Поэтому да — только lifetime (что включает в себя немного гонок, и выстрелов по памяти)
Deadlock является проблемой программиста, так как компилятор не может проверить семантику программы, но все что компилятор может проверить статическими методами он делает
>> Миф №4. Rust медленнее C++.
>> Складывается впечатление, что весь этот анализ ассемблерного выхлопа был нужен лишь для того, чтобы сказать, что больше асма → медленнее язык.
>> Миф №5. C → С++ — noop, C → Rust — PAIN!!!
> Да, штатный пакетный менеджер помогает замять множество проблем. Первоначальная проблема от этого остаётся.
Единственное что для C/C++ int, long long нужно использовать типы из ffi
>> Миф №6. unsafe отключает все проверки Rust.
> Забавно, что в другом разделе документации имеется неполный список UB doc.rust-lang.org/reference/behavior-considered-undefined.html, который практически полностью совпадает с C++ списком. Обратите внимание на термин «unsound», подразумевающий что код после unsafe может взорваться в любом месте. Так что да, unsafe все проверки убивает.
Проверки не убираются…
В статье описано что разрешено делать в unsafe секции
>> Миф №7. Rust не поможет с сишными библиотеками.
> Только вот мало какая С библиотека нынче поставляется с LTO. Так что накладные расходы пока есть. Ну и про unsafe см выше, вы не можете использовать C без unsafe.
Интересно как?
>> Миф №8. Безопасность Rust не доказана.
> В выступлении эта часть была про Хаскель :) Но процитируйте пожалуйста полностью эту часть выступления, вы парировали только треть (да и то не до конца честно, см UB в Mutex).
Да она не доказана, но это все равно лучше чем дает С++ :)
Это был лишь пример использования, чтобы показать что в случаях где нет необходимости контролировать время жизни объекта вручную, можно обойтись малой производительностью, но больше сконцентрироваться на логике
Я не могу понять почему такая острая критика, за мелкие неточные выссказывания в статье?
Как по этим фразам можно считать разбирается человек или нет?
Фразы которые вы привели лишь о случаях в которых можно было бы использовать данный тип объекта
Я прекрасно разбираюсь shared_ptr/weak_ptr, cс чего вы взяли что я не разбираюсь?
Ничего ужасного, это один из вариантов как можно писать код и не заморачиваться со структурой программы, естественно этот вариант не подходит для высокопроизводительных программ, но если производительность не интересует, а интересует быстро реализовать задачу то вполне подходит и такой pointer )
Да, я видел его выступления на тему статического анализа утечек памяти в C++
Безумно интересно, но мне кажется одно другому не мешает…
У нас в C++ будет:
1) Raw Pointers — наивысшая производительность, но возможна утечка памяти при неаккуратном обращении
2) Smart Pointer — совсем малость хуже производительность, лучше с управлением памятью, но опять же при неаккуратном обращении возможны утечки памяти… Чтобы их исключить необходимо хорошо организовывать свои структуры данных и flow программы
3) Garbage Collector Pointer — наихудшая производительность из всех возможных, но гарантированное разрушение объектов во вполне определенных местах в программе. Не нужно разбираться со структурой программы добавляй и он просто работает
4) Static Analyze Memory Leaks — никаких накладных расходов, но не все случаи охватываются
И пусть люди выбирают в зависимости от задачи что им больше подходит
Вполне детерминироваными, так как если заранее просчитать все связи можно сказать когда объекты удалятся
Для обычного Garbage Collector-а время его запуска непредсказуемо и время выполнения непредсказуемы
Ну declare_reachable и undeclare_reachable не трекают связи между объектами, я же их трекаю через специальные методы connectToRoot и disconnectFromRoot, которые я налижу на генератор и добавлю к библиотеке, пока что их необходимо прописывать руками (
Единственное что позволили бы мне эти методы сделать reachable unreachable sematic более явной
Из граничных условий я виже пока, что не отработает в lambda-выражениях при сохранении lambda-функций в std::function так как надо получить достук к установки рута для std::function и контекстно захваченых объектов
>> Выглядит как панацея и серебряная пуля вместе взятые.
Нет, это не панацея, есть свои недостатки производительности
>> Я правильно понимаю, что вы при каждой потере ссылки проходите до рута чтобы понять, не была ли она последней?
Не совсем, я бегу не всегда от рута, а от места где поменялась ссылка, так я прохожусь по части графа, а не по всему графу от рута… Добавлю в статью картинку попозже…
Да это медленно, но в отличии от обычного Garbage Collector-а этот pointer детерминистически pointer ведет себя детерминированно
Замеров по памяти и скорости работы и памяти еще не делал, намереваюсь сделать…
Я хоть и не автор статьи но у меня тоже есть что сказать по этому поводу…
>> Миф №1. Арифметика в Rust ничуть не безопасней C++
> То есть вы считаете нормой, что перемножив 46341 в Rust в релизе вы получите -2147479015 а не аналог исключения. Это ничуть не безопаснее.
Rust отключает некоторые проверки в release-е, но в debug-е он вызывает завершение программы через вызов макроса panic! при этом он говорит где была задетектирована ошибка, со строкой в файле и даже backtrace-ом
В release-е компилятор конечно же некоторые проверки убирает, но паника все равно остается для того кода на производительность которого это не сильно влияет или это не преведет к SIGSEGV (Segmentation Fault)
>> Миф №2. Плюсы Rust только в анализе времени жизни объектов.
>> Это заявление ложно, так как безопасное подмножество Rust защищает от ошибок, связанных с многопоточностью
> В Rust без вских unsafe можно получить deadlock doc.rust-lang.org/std/sync/struct.Mutex.html
> Основная причина — невозможность выразить необходимое в системе типов Rust. Поэтому да — только lifetime (что включает в себя немного гонок, и выстрелов по памяти)
Deadlock является проблемой программиста, так как компилятор не может проверить семантику программы, но все что компилятор может проверить статическими методами он делает
>> Миф №4. Rust медленнее C++.
>> Складывается впечатление, что весь этот анализ ассемблерного выхлопа был нужен лишь для того, чтобы сказать, что больше асма → медленнее язык.
>> Миф №5. C → С++ — noop, C → Rust — PAIN!!!
> Да, штатный пакетный менеджер помогает замять множество проблем. Первоначальная проблема от этого остаётся.
По моему все работает также само как и в C++… Также есть ключевое слово extern… ?!
doc.rust-lang.org/std/keyword.extern.html
doc.rust-lang.org/nomicon/ffi.html
Единственное что для C/C++ int, long long нужно использовать типы из ffi
>> Миф №6. unsafe отключает все проверки Rust.
> Забавно, что в другом разделе документации имеется неполный список UB doc.rust-lang.org/reference/behavior-considered-undefined.html, который практически полностью совпадает с C++ списком. Обратите внимание на термин «unsound», подразумевающий что код после unsafe может взорваться в любом месте. Так что да, unsafe все проверки убивает.
Проверки не убираются…
В статье описано что разрешено делать в unsafe секции
>> Миф №7. Rust не поможет с сишными библиотеками.
> Только вот мало какая С библиотека нынче поставляется с LTO. Так что накладные расходы пока есть. Ну и про unsafe см выше, вы не можете использовать C без unsafe.
Интересно как?
>> Миф №8. Безопасность Rust не доказана.
> В выступлении эта часть была про Хаскель :) Но процитируйте пожалуйста полностью эту часть выступления, вы парировали только треть (да и то не до конца честно, см UB в Mutex).
Да она не доказана, но это все равно лучше чем дает С++ :)
Как по этим фразам можно считать разбирается человек или нет?
Фразы которые вы привели лишь о случаях в которых можно было бы использовать данный тип объекта
Ничего ужасного, это один из вариантов как можно писать код и не заморачиваться со структурой программы, естественно этот вариант не подходит для высокопроизводительных программ, но если производительность не интересует, а интересует быстро реализовать задачу то вполне подходит и такой pointer )
Безумно интересно, но мне кажется одно другому не мешает…
У нас в C++ будет:
1) Raw Pointers — наивысшая производительность, но возможна утечка памяти при неаккуратном обращении
2) Smart Pointer — совсем малость хуже производительность, лучше с управлением памятью, но опять же при неаккуратном обращении возможны утечки памяти… Чтобы их исключить необходимо хорошо организовывать свои структуры данных и flow программы
3) Garbage Collector Pointer — наихудшая производительность из всех возможных, но гарантированное разрушение объектов во вполне определенных местах в программе. Не нужно разбираться со структурой программы добавляй и он просто работает
4) Static Analyze Memory Leaks — никаких накладных расходов, но не все случаи охватываются
И пусть люди выбирают в зависимости от задачи что им больше подходит
Для обычного Garbage Collector-а время его запуска непредсказуемо и время выполнения непредсказуемы
Единственное что позволили бы мне эти методы сделать reachable unreachable sematic более явной
Из граничных условий я виже пока, что не отработает в lambda-выражениях при сохранении lambda-функций в std::function так как надо получить достук к установки рута для std::function и контекстно захваченых объектов
Нет, это не панацея, есть свои недостатки производительности
>> Я правильно понимаю, что вы при каждой потере ссылки проходите до рута чтобы понять, не была ли она последней?
Не совсем, я бегу не всегда от рута, а от места где поменялась ссылка, так я прохожусь по части графа, а не по всему графу от рута… Добавлю в статью картинку попозже…
Да это медленно, но в отличии от обычного Garbage Collector-а этот pointer детерминистически pointer ведет себя детерминированно
Замеров по памяти и скорости работы и памяти еще не делал, намереваюсь сделать…