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

KP>Ну вот как сертифиуируете по какому-то серьёзному процессу, так и расскажешь про паники в критичном коде.

Обязательно расскажу

PS: кстати, мы с тобой в одной области вроде даже работаем (то есть, я работал), SDC

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

B>PS: кстати, мы с тобой в одной области вроде даже работаем (то есть, я работал), SDC

Я, честно говоря, не знаю что такое SDC
У меня как бы autonomious vehicle, но к самому autonomious не имею, у меня это своего рода фронтэнд и бэкенд на колесах

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

KP>Я, честно говоря, не знаю что такое SDC
KP>У меня как бы autonomious vehicle, но к самому autonomious не имею, у меня это своего рода фронтэнд и бэкенд на колесах

SDC — Self Driving Cars.

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

KP>Я люблю исключения и считаю их лучшим способом информировать об ошибках нежели коды возврата.
Обработка их уж очень геморная. Весь код оказывается густо засран try/catch

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

B> работал над критическим кодом на C++
B> отказались от исключений
B> ввели вместо них Паники

Это как?
Исключение можно поймать и обработать.
Паника прекращает исполнение совсем.

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

TB>в С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер".

Недаром у C++ два плюса в названии. Видимо, мы с Вами пишем на разных — кто-то на левом, а кто-то на правом.

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

CC>Это как?
CC>Исключение можно поймать и обработать.
CC>Паника прекращает исполнение совсем.

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

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


MD>Недаром у C++ два плюса в названии. Видимо, мы с Вами пишем на разных — кто-то на левом, а кто-то на правом.

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

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

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

KP>>Я люблю исключения и считаю их лучшим способом информировать об ошибках нежели коды возврата.
CC>Обработка их уж очень геморная. Весь код оказывается густо засран try/catch

Насколько я понял из разговора с их сторонниками — надо не засирать код try/catch, а поставить один try/catch вокруг функции, написанной джуном, чтоб она не повалила остальное.

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

B>Да, все верно, философия fail fast.
Тогда у тебя должна быть куча процессов, что добавляет накладные runtime расходы по их взаимодействию

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

TB>Насколько я понял из разговора с их сторонниками — надо не засирать код try/catch, а поставить один try/catch вокруг функции, написанной джуном, чтоб она не повалила остальное.
А остальные функции никогда не ошибаются никогда что ли?

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

CC>А остальные функции никогда не ошибаются никогда что ли?

Можно в главном цикле поставить один большой трай. Типа главный цикл можно отладить нормально 1 раз.

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

TB>Можно в главном цикле поставить один большой трай. Типа главный цикл можно отладить нормально 1 раз.
Это не программа а кусок говна получается.
Можно тогда уже просто тупо падать по ошибке

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

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

TB>>Можно в главном цикле поставить один большой трай. Типа главный цикл можно отладить нормально 1 раз.
CC>Это не программа а кусок говна получается.
CC>Можно тогда уже просто тупо падать по ошибке

Что лучше — говно, которое кое-как работает, или говно, которое сразу падает?

KP>>Я люблю исключения и считаю их лучшим способом информировать об ошибках нежели коды возврата.
CC>Обработка их уж очень геморная. Весь код оказывается густо засран try/catch
Ну это же фигня. Try/Catch нужно ставить только там где ты можешь разумно исправить ситуацию. Например ты отправляешь запрос в сеть и ожидаешь что в ответ прилетит тонна упакованного Json — нет никакого смысла оборачивать в try/catch каждое чтение из сокета, парсинг токенов, и т.п. Оборачиваешь в один try/catch всё скопом — и запрос, и распаковку, и парсинг. Если что-то сломалось — верхнему уровню пофиг на нюансы — исключение в лог, операцию повторить. После нескольких попыток исключение летит выше, и там кто-то или юзеру напишет "проверьте подключение", или там наверху само переключится на резервный url и вызовет ещё раз.
Двумя try/catch вполне вменяемое поведение с минимумом лишней работы. С кодами ошибок — хочешь или нет, а проверять будешь в каждой грёбанной строке. В случае rust хоть '!' но воткнуть придётся. В случае go...

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

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

Ну они не то чтоб прям "непредсказуемые".
Есть всякое такое — атрибут [nopanic] проверит в компайл-тайме возможность получить panic в интересующем куске кода.
Я пока в продакшне этот атрибут не пробовал, но скоро буду попробовать.

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

KP> его даже Глав Пингвин забанил

Разве? Я не очень-то слежу за темой, но вроде ж недавно были прямо противоположные новости, что, мол, Rust в ядре Linux будет.
Причём, толкает всё это Google, так что перспективы у этой инициативы, на мой взгляд, хорошие.

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

vaa>если же инженер уже знает си, то ему проще написать на нем. чем учить новый сложный яп.

Конечно же проще. Rust это ж вообще не про простоту. Rust это как помесь Си и С++, к которой прилагается специально-обученный человек компилятор, который больно бьёт вас по голове каждый раз, когда вы пытаетесь написать небезопасную конструкцию.
Всё это выливается в боль и страдания, но код получается значительно безопаснее аналогичного на Си. Вот отсюда и весь хайп, а вовсе не из рекламы.

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

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

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

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

_>Try/Catch нужно ставить только там где ты можешь разумно исправить ситуацию. Например ты отправляешь запрос в сеть и ожидаешь что в ответ прилетит тонна упакованного Json — нет никакого смысла оборачивать в try/catch каждое чтение из сокета, парсинг токенов, и т.п. Оборачиваешь в один try/catch всё скопом — и запрос, и распаковку, и парсинг. Если что-то сломалось — верхнему уровню пофиг на нюансы — исключение в лог, операцию повторить.
Сильно зависит что ты пишешь. У меня например достаточно кода в котором результат операции "не success" это одно из допустимых состояний. Так что с try/catch код превращается в плохочитаемую кашу очень быстро. Так что в таком раскладе if выходит куда предпочтительнее а исключения остаются для гм, исключительных случаев типа "глубоко в недрах Мории случилась уж совсем полная жопа и надо всё бросать и свистать всех наверх".

_> После нескольких попыток исключение летит выше, и там кто-то или юзеру напишет "проверьте подключение", или там наверху само переключится на резервный url и вызовет ещё раз.
Вот так и получаем софт который просто пишет "ашыпка, нисмагла", а где сломалось и почему — догадайся сам. В лучшем случае — на тебе стек где случилась обосратушка, без состояния.

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

KP>>Я люблю исключения и считаю их лучшим способом информировать об ошибках нежели коды возврата.
CC>Обработка их уж очень геморная. Весь код оказывается густо засран try/catch

try/catch всегда можно поставить поменьше, только в местах где можно обработать ошибки разом и повторить действие/отказаться в зависимости от обстоятельств. С кодами ошибок же всё засирается на порядок быстрее, тот же код на Go — это сплошные сопли из if/else для обработки кодов возврата. Да, оно проще читается и создает меньше возможностей для ошибок т.к. ты всегда знаешь где и что было обработано, но вот "засрано" — это точно не про исключения