> А оно является именно "critical" когда с вот лично вас за отказ
> этой штуки могут спросить, с перспективой компенсации ущерба или тем более
> обвинить в причинении вреда здоровью/смерти?Только после того, как клиент согласится провести опломбирование не только изделия, но и управляющего интерфейса машины, во избежание вмешательств с его стороны. Этого уже не первый год от них добится пытаемся. :)
> А так то тесты конечно да, но опять же ресурсов не бесконечно
> и обвешивать все тестами - нафиг надо.
Не понимаю как без модульных, системных, стресс тестов (в том числе климатических и прочее) можно тогда говорить о "Critical" и личной ответственности? Глупо быть обвиненным в кривости изделия, не проверив его в полном объеме.
> Воевать с тулчейном тоже как-то не быстро. И еще лично я не
> доверяю мозилле и их экосистеме. Для меня пакость мне в систему
> пакетынм менеджером - жирный минус, а вовсе и не плюс.
То не тот пакетный менеджер, ничего в систему не ставит, посмотрите как оно сделано. Мы же о cargo говорим?
> А это вообще про какие сценарии? Характер софта, требования к надежности, платформы,
> ... ? А то если это уебня какая-нибудь или корпсофт -
> я в курсе чего там, thank you very much.
Что могу - расскажу. :)
> А если
> это что-то типа микроконтроллеров с требованиями к надежности и жесткому реалтайму,
> это уже интереснее послушать.
Так и есть. Система отслеживает попадание людей в близкое положение к рабочим органам машин или под колеса. При возникновении опасной ситуации выключает механизмы/останавливает машину, если допустимо. Как минимум выдает тревогу оператору машины. Речь о шахтных и карьерных погрузчиках, самосвалах, буровых машинах и т.п.
> Если это честное описание проблем, особенностей и
> грабель вместо слащавого маркетингового булшита, например. Вот маркетинговый булшит я
> могу почитать на сайте любой корпорахи.
Куда же без грабель и особенностей, есть они, но пока ни во что критичное не вляпывались.
Правила разработки в целом те же, что и для safe-critical систем на C, язык просто другой.
Например память только статическая, без аллокаторов, детерминизм всех вычислений, время всех операций считается по worst-case и т.д. и т.п.
Пробегусь по основным замеченным вещам:
1. На удивление не было граблей пока с линковкой с C кодом, просто работает как надо. Все-таки тесно интегрировано с llvm/clang, нечему ломаться.
2. Отладка доставляет некоторый геморой, потому что нормально отладчик работает только в дебаг режиме, без оптимизаций. А в нем все на порядок медленнее, чем в релизе, не попадаем в тайминги реальных операций иногда. Наверное лечится подбором параметров оптимизации llvm, не проверял. Но редко нужен отладчик, 95% багов ловится тестами!
3. После C компиляция медленная конечно, текущий проект в релизе собирается 7 минут, дебаг побыстрее минуты 2. Терпимо, тем более что релиз сам не собираешь, это забота билд-сервера.
4. Поддержка со стороны IDE вменяемая только в IntelliJ/CLion, в остальных есть грабли.