Здравствуйте, blacktea, Вы писали:

B>Да, все верно, философия fail fast.

Попытка натянуть концепт fail fast на платформу которая не поддерживает супервизоры из коробки обычно заканчивается печально. В общем случае для C++ это полный провал, разве что у тебя не ROS-подобная ОС где супервизор из коробки идет или куча микросервисов под K8s, но это уже спорно, лучше б не падать. По моим ощущениям fail fast за пределами BEAM скорее опасен, нежели полезен.

_>> После нескольких попыток исключение летит выше, и там кто-то или юзеру напишет "проверьте подключение", или там наверху само переключится на резервный url и вызовет ещё раз.
CC>Вот так и получаем софт который просто пишет "ашыпка, нисмагла", а где сломалось и почему — догадайся сам. В лучшем случае — на тебе стек где случилась обосратушка, без состояния.
Ну это уже вопрос рукожопов которые исключения скрывают. Таки чаще всего вылетит не просто исключение, а HttpException, Json.ParseException или BusinessLogicException, со стеком и номером строки. Закрыть это всё под "ашыпка, нисмагла" без возможности узнать детали, это уже признак лёгкой профнепригодности.

Причём в расте абсолютно тоже самое. Коды ошибок придумали чтобы люди всё проверяли, но люди нихрена не хотят проверять. Лепят '?' всюду, чтобы компилятор отвязался. Лишь изредка добавляют какую-то инфу о проблеме. И дай бог чтобы это всё было собрано с каким backtrace, не то и стека не будет. По итогу тоже самое что исключения, только больше ручной работы.

При этом наверняка где-то водятся те кто действительно каждую функцию проверяет, но у таких педантов и исключения будут читабельные, и логи структурные, с отступами.

Здравствуйте, T4r4sB, Вы писали:

TB>Да-да, расскажи, что делаешь ты, когда у тебя есть "движок"-владелец объекта, и тебе нужен временный указатель на объект. Ты делаешь weak_ref? Или выдаёшь сырой указатель?

std::weak_ptr, или же какой-то внешний класс-менеджер, который разруливает вопросы жизни и смерти. Безусловно, можно всё делать в стиле void* и менеджить память на бумажке или в уме, но зачем?

Здравствуйте, CreatorCray, Вы писали:

CC>Паника прекращает исполнение совсем.

Tерминология неоднозначная. Скажем, в Go паники можно перехватить, a в расте поведение настраивается.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, T4r4sB, Вы писали:

TB>>Что лучше — говно, которое кое-как работает, или говно, которое сразу падает?
CC>Конечно же то, что сразу падает.
CC>Тогда быстро выпишут живительных звездюлей, говнодела выкинут на мороз а это говно отправят на переделку.
CC>Иначе же говна будет становиться всё больше.

Перенесём вопрос на уровень выше. Ты пишешь ОСь. Ты пытаешься разобрать случай, когда юзерское говноприложение падает. Будешь ронять систему, или попытаешься закрыть все открытые юзером хендлы и продолжить работу?

Здравствуйте, T4r4sB, Вы писали:

TB>Перенесём вопрос на уровень выше. Ты пишешь ОСь.
Это будет уровень ниже.

TB> Ты пытаешься разобрать случай, когда юзерское говноприложение падает.
TB> Будешь ронять систему, или попытаешься закрыть все открытые юзером хендлы и продолжить работу?

Ты как то странно понимаешь как в принципе работает ОС.
Если приложение "падает" в usermode — происходит банальная терминация процесса, и там уже не суть важно по какой причине оно случилось — все запрошенные им ресурсы будут автоматически освобождены.
Если приложение каким то образом ныряет в кернел и вызывает панику там — схлопнется вообще всё.

Здравствуйте, DarkEld3r, Вы писали:

CC>>Паника прекращает исполнение совсем.
DE>Tерминология неоднозначная. Скажем, в Go паники можно перехватить, a в расте поведение настраивается.

Собственно и в Rust'е паники часто перехватывают. Например это стандартная практика при написание кода под wasm, запускаемого в браузере. Там перехватчик паники должен обеспечить правильное отображение ошибки (например в лог браузера).

Но да, сама по себе идея паники подразумевает прекращение выполнения приложения. Что абсолютно правильно в большинстве случаев критических ошибок.

Здравствуйте, kaa.python, Вы писали:

KP>Не знаю починили ли в Rust главную проблему — непредсказуемые паники
В Rust нет непредсказуемых паник.

KP>но на данный момент для серьезных задач (авиация, автомобилестроение, космос) он банально не подходит.
Подходит.

KP>Хотя я 100% уверен что с ним было бы спокойнее писать компоненты где требуются гарантии уровня DAL-B/A или ASIL-D.
https://ferrous-systems.com/ferrocene/

KP>Там даже можно было бы пойти на ублажение компилятора ради увеличившийся безопасности решения. Но, увы и ах, его даже Глав Пингвин забанил, ожидать что Blackberry пропустит в QNX вообще не реально
Линус Торвальдс поддерживает Rust в ядре. Сейчас люди его туда адаптируют — https://lkml.org/lkml/2021/12/6/461

Здравствуйте, CreatorCray, Вы писали:
ть работу?

CC>Ты как то странно понимаешь как в принципе работает ОС.
CC>Если приложение "падает" в usermode — происходит банальная терминация процесса, и там уже не суть важно по какой причине оно случилось — все запрошенные им ресурсы будут автоматически освобождены.
CC>Если приложение каким то образом ныряет в кернел и вызывает панику там — схлопнется вообще всё.

А теперь представь, что есть приложение с главным циклом, надёжность которого надо обеспечить любой ценой, и есть модуль, пишущийся джуном. И желательно чтоб после ошибок джуна приложение как-то работало, разумеется, выдав сообщение, что "плагин джуна сдох по такому-то адресу, продолжаю работу"

Здравствуйте, T4r4sB, Вы писали:

TB>А теперь представь, что есть приложение с главным циклом, надёжность которого надо обеспечить любой ценой, и есть модуль, пишущийся джуном. И желательно чтоб после ошибок джуна приложение как-то работало, разумеется, выдав сообщение, что "плагин джуна сдох по такому-то адресу, продолжаю работу"
Разделить приложение по разныим процессам как в Chrome, Firefox и пр., вынести плагин джуна в отдельный процесс.

Здравствуйте, T4r4sB, Вы писали:

TB>А теперь представь, что есть приложение с главным циклом, надёжность которого надо обеспечить любой ценой, и есть модуль, пишущийся джуном.

Вот такую комбинацию ну никак не представляю.
В таком раскладе ошибка в ДНК тех, кто пускает джунов в критическую систему

TB> И желательно чтоб после ошибок джуна приложение как-то работало, разумеется, выдав сообщение, что "плагин джуна сдох по такому-то адресу, продолжаю работу"
Только выносить в отдельный, изолированный процесс с жёсткими квотами на ресурсы. А ещё лучше — на отдельный хост.

Здравствуйте, Cyberax, Вы писали:

KP>>Хотя я 100% уверен что с ним было бы спокойнее писать компоненты где требуются гарантии уровня DAL-B/A или ASIL-D.
C>https://ferrous-systems.com/ferrocene/

Спасибо что подтвердил моё утверждение о том, что Rust не подходит для систем где требуются высоки гарантии надежности

Берем первую страницу:

Ferrocene aims to qualify the Rust compiler at ISO 26262/ASIL-B readiness and general availability by the end of 2022

1. Ferrocene пока что не смогли сертифицировать компилятор и надеются суметь к концу 2022. На данный момент Rust не подходит для критических систем, только QM уровень (но тут может быть вообще что угодно включая какой-нибуть Python).
2. Ferrocene пытается сертифицировать Rust для систем с уровнем ASIL-B, а не ASIL-D о которых я говорю выше. Код на C++ для ASIL-B вообще мало чем отличается от обычного кода (кода уровня QM) и насколько я помню, там никто не ограничивает исключения.

Почему важно ASIL-D, а не ASIL-B. Системы с требованиями к надежности принято декомпозировать по уровням что бы упростить разработку и удешевить систему. Основная цель — сделать как можно больше компонент уровня QM с минимумом компонент уровня ASIL-Ы. Вводить компоненты уровня ASIL-B особо не целесообразно, т.к. это крайне редкие пограничные случаи и делать что-то типа QM -> ASIL-B -> ASIL-D с точки зрения архитектуры выйдет дороже чем QM -> ASIL-D. А вот то что Rust не возможно в текущем виде сертифицировать для ASIL-D (т.е. реально критичных компонент) я утверждал в посте выше и приведенная тобой линка это никак не опровергает.

Здравствуйте, kaa.python, Вы писали:

C>>https://ferrous-systems.com/ferrocene/
KP>Спасибо что подтвердил моё утверждение о том, что Rust не подходит для систем где требуются высоки гарантии надежности
KP>Берем первую страницу:
KP>

Ferrocene aims to qualify the Rust compiler at ISO 26262/ASIL-B readiness and general availability by the end of 2022

Ключевое слово — qualify. Т.е. они занимаются сертификацией.

Кстати и с С просто так взять любой попавшийся GCC и использовать в ASIL-B не получится.

KP>1. Ferrocene пока что не смогли сертифицировать компилятор и надеются суметь к концу 2022. На данный момент Rust не подходит для критических систем, только QM уровень (но тут может быть вообще что угодно включая какой-нибуть Python).
Подходит.

KP>Почему важно ASIL-D, а не ASIL-B.
ASIL-D никому нафиг не нужен. На нём пишут код для всяких контроллеров сигнала поворота, причём с таким качеством, что оно там пишется через "как".

Весь более-менее интересный современный код (self-driving и прочее) вообще не использует ASIL.

Здравствуйте, Cyberax, Вы писали:

C>ASIL-D никому нафиг не нужен. На нём пишут код для всяких контроллеров сигнала поворота, причём с таким качеством, что оно там пишется через "как".
C>Весь более-менее интересный современный код (self-driving и прочее) вообще не использует ASIL.

Твой уровень знаний в безопасности AV поражает своей глубиной

Здравствуйте, Cyberax, Вы писали:

C>Весь более-менее интересный современный код (self-driving и прочее) вообще не использует ASIL.
А, ну понятно теперь почему иногда теслы убивают своих водителей

Здравствуйте, CreatorCray, Вы писали:

C>>Весь более-менее интересный современный код (self-driving и прочее) вообще не использует ASIL.
CC>А, ну понятно теперь почему иногда теслы убивают своих водителей

Похоже что так. В конце цепочки принятия критических решений, подтверждение выбранной тректории, подтверждение отсутствия препятствия, экстренное торможение и т.д. как раз код ASIL-D работающий на железе ASIL-D. Доверять машине в которой это не так идея так себе. Но да, не интересно, не современно, ага

vaa,

vaa>да, возможно вы правы.
vaa>но я лишь хотел сказать, что и на ди и на обероне(причем реалтайм) ОС пишутся не смотря на наличие GC.
vaa>но при этом все же они намного проще синтаксически и семантически. т.е. если нужно выжать максимум из железа по-моему проще на сях это сделать.
vaa>раст я так понимаю привлекает молодежь падкая на рекламу. если же инженер уже знает си, то ему проще написать на нем. чем учить новый сложный яп.

У вас несколько иллюзорные представления. На Rust работает масса опытных специалистов. Вы разберитесь, за термином Rust не только реклама и новые буквы в синтаксисе, а очень хорошие и проверенные на практике идеи написания безопасного кода. Ни в C, ни в C++ не смогут никогда решить свои внутренние проблемы по причине обратной совместимости, а новые стандарты не только не решают, а больше ухудшают состояние экосистемы.

https://t.me/rust_beginners_ru/58928

Artem Korneev,

AK>Всё это выливается в боль и страдания, но код получается значительно безопаснее аналогичного на Си. Вот отсюда и весь хайп, а вовсе не из рекламы.

AK>На мой взгляд, Rust это как раз то, в какую сторону должны двигаться современные системные компилируемые языки. Синтаксис его мне, правда, не очень нравится. Но пока что есть, то есть.

Да и боль со страданиями сильно преувеличены, по крайней мере для обычного кода. Вот с асинками часто весьма неочевидные сообщения об ошибках, но тут помогает навык создания MRE и ошибки улучшаются от релиза к релизу.
В целом, как человеку, работающему на Rust мне довольно комфортно, а вот каждое заныривание в C++ действительно приносит боль и страдания, уж извините.