За последние десять лет появилось не столь много новых языков программирования. Один из самых обсуждаемых — Rust. Исследования сообществ языков программирования показали, что растовцы самые счастливые, что мы тут тоже обсудим. Это язык без cборки мусора, с zero-runtime, типобезопасный и с мощными средствами абстракции. На нём даже написали операционную систему! Так в чём подвох? Почему весь мир не перешёл на Rust, несмотря на призывы его фанатов? Почему даже Go — язык с GC — часто опережает Rust по скорости? Далее я приведу свои наблюдения по этой теме.
...
Этот язык пропитан ложью: он пытается быть низкоуровневым, несмотря на невероятно высокоуровневую природу; пока он претендует, что не включает в себя сборщики мусора, его сообщество активно их использует; он забывает о последовательных программах в погоне за параллельными, и в итоге весь код становится писать сложней; он заявляет о том, что даcт прекрасные макросы, а на деле подсовывает лишь неудобное подобие, при этом существенно замедляющее время компиляции всех программ. Это язык-монстр, но ещё страшней его сообщество.
...
Несмотря ни на что, на Rust можно писать хорошо работающие программы. Но делать это будет крайне неприятно, а сами программы будут очень мало кому понятны, да их ещё и будет критиковать токсичное сообщество. Каким-то чудом в сообществе Rust умудряются выжить единицы адекватных программистов, и мне больно видеть, как их разъедает ржавчина. Не давайте себе и своему железу заржаветь!
Подводя итоги: не зря Mozilla сократила команду, работавшую над Rust.
Здравствуйте, Michael7, Вы писали:
M>Обсудим статью? http://rustmustdie.com/
M>(мопед не мой, если что)
статью писал буквально(!) студент. имеет смысл послушать людей использующих язык в коммерческих проектах, плюсы, минусы.
что там по скорости (как performance так и development time) в сравнении с теми же плюсами, действительно ли багов меньше при разработке, что с поддержкой IDE, легко ли переучиваться и много ли народу уже на нем кодит (легко ли нанять).
а кишки компилятора/рантайм и синтаксический сахар пусть студенты ковыряют
При этом невозможно занести сумму в x, ведь это неизменяемое значение. Почему не константа? Константами в Rust именуется ещё одна, третья сущность, обозначающая константы времени компиляции, те что в Си обычно определяются через define:
Что тут такого? В С++ также: переменная, const переменная и constextr времени компиляции.
Далее про обязательный mut для изменяемых переменных — а почему бы и нет? В С++ надо не забывать вставлять const, а тут не забудешь.
Ну и т.д.
Здравствуйте, Michael7, Вы писали:
M>Обсудим статью? http://rustmustdie.com/
Автор некомпетентен.
Итераторы — это по его мнению сложная конструкция. Подсчет ссылок — это уже сборщик мусора.
Я сам раст не особо знаю, только начал решать на нем adventofcode в этом году и всё. Было бы интересно почитать по недостатки. Но здесь просто брюзжание человека, который дальше С++ не ходил, да и его скорее всего не знает.
Статья — полнейший КГ/АМ.
Я скипнул на месте, где автор путает процедурные макросы и macro_rules
Народ, а там будет нытьё на тему "а вот в сишке сложные функциональные типа объявлялись через жопу по правилу улитки, а в Расте не так, это плохо, я хочу чтоб в Расте типы тоже объявлялись через жопу, потому что я привык делать это как в сишке и не могу переучиться"?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, kaa.python, Вы писали:
KP>Язык программирования в котором разработчик выполняет работу компилятора по доказанию клрректности времени жизни объектов — это нонсенс.
В общем случае компилятор не может предсказать, куда денется ссылка на объект. Поэтому либо переносится нагрузка на рантайм, либо добавляется куча жёстких правил в языке.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>В общем случае компилятор не может предсказать, куда денется ссылка на объект. Поэтому либо переносится нагрузка на рантайм, либо добавляется куча жёстких правил в языке.
Да если бы оно работало А то выходят монстры из портянок с Box/Rc/Arc/Cell которые надо хитро использовать в разных случаях что бы компилятор остался доволен, но они еще и до кучи херят гарантии времени компиляции, добавляют кучу боли, но не делают код безопаснее куда как более простого кода на C++.
Я вообще не могу себе представить причину которая сегодня побудила бы взять Rust, если есть Go, C++, Elixir и куча языков на JVM. ичсх ни один из них не перекладывает работу компилятора на разработчика, даже C++ с его тяжелым наследием.
Лень читать. Если вкратце по языку, то язык годный. Но он не взлетит даже не потому, что для плюсистов он неинтересный, а для сишников сложный, а потому что на нём нельзя "херак-херак и в продакшен"
Здравствуйте, kaa.python, Вы писали:
KP>Да если бы оно работало А то выходят монстры из портянок с Box/Rc/Arc/Cell которые надо хитро использовать в разных случаях что бы компилятор остался доволен, но они еще и до кучи херят гарантии времени компиляции, добавляют кучу боли, но не делают код безопаснее куда как более простого кода на C++.
Ну в общем случае — да, приходится сводить всё к Rc<RefCell>, в С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер".
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Ну в общем случае — да, приходится сводить всё к Rc<RefCell>, в С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер".
В современном мире такое может быть только если команда C++ Core Guidelines не осилила. Последний раз такое лет, наверное 10 назад видел, еще до того как C++11 начал массово проникать в плюсовое сообщество.
А вот получать удовольствие от зоопарка Rc<RefCell> в Раст надо как раз сейчас, что собственно и дико выглядит.
Разве "Раст" — это не такая же тухлая тема, как МММ? ДАВНО уже стало ясно (ещё с первых недель появления ржавчины в Тырнетах), что язык — полное гогно. Вернее, его изящно закамуфлированная "мозго_й_опка с памятью", которую разрабы аккуратно вывалили на бедного погромизда. Напомню — в C# и то находятся лабухи, ловящие NRE! И это при том, что язык насквозь безопасный и берущий на себя почти всю работу с памятью! Погромизду остаются ТОЛЬКО моменты, где память надо выделять (что в принципе довольно простая проблема). В Расте же на разраба свалена ВСЯ работа, да ещё с хитроподвывертом.
И поняв, что это гогно "никак не взлетает", по форумам стали запускать "Лёней Голубковых", которые враньём/агитацией макают всех в свои ржавые помои. Собственно, даже обсуждение "какое это гогно" — косвенная агитация и излишний хайп/цитируемость к этому дерьму. (вот почему минус) Может, хорош уже насиловать стюардессу?! Один раз закопали — И ХВАТИТ!
Здравствуйте, kaa.python, Вы писали:
KP>В современном мире такое может быть только если команда C++ Core Guidelines не осилила. Последний раз такое лет, наверное 10 назад видел, еще до того как C++11 начал массово проникать в плюсовое сообщество.
Ага, конечно, надо "просто помнить" кучу правил инвалидации итераторов.
А ещё очень круто, когда у тебя есть проект, в котором спокойно указатели используются в качестве ключей хеш-мапы, это наверное команда не осилила гайды. Проект называется LLVM, если что.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Michael7, Вы писали:
BFE>Я Rust не знаю, но как я понял, единственная реальная претензия — это неэффективный генерируемый код.
Так там автор (ученик самого Столярова) не осилил ключ компилятора -O
Здравствуйте, T4r4sB, Вы писали:
TB>Ага, конечно, надо "просто помнить" кучу правил инвалидации итераторов. TB>А ещё очень круто, когда у тебя есть проект, в котором спокойно указатели используются в качестве ключей хеш-мапы, это наверное команда не осилила гайды. Проект называется LLVM, если что.
Здравствуйте, rollcoin, Вы писали:
R>Так там автор (ученик самого Столярова) не осилил ключ компилятора -O
Он не неосилил. Он его не хочет использовать:
> Мне кажется нерепрезентативен как раз оптимизированный код, но спасибо за предложение. Поясню почему оптимизированный код мне сравнивать кажется неверным решением:
> Прежде всего, он менее ясен, часто существенно менее ясен -- разобраться и понять, как исходный код стал полученным машинным становится сложно. Поэтому и разобраться в нём становится сложней, а значит и сравнивать.
> Кроме того, тогда вместо языков мы скорее сравниваем искусство оптимизации компиляторощиков -- чего мне тоже не хотелось бы.
> Наконец -- можно и включить оптимизации, результат изменится не принципиально -- код будет всё так же больше и всё так же медленней в случае Раста, особенно в случае Раста "эталонного".
Т.е. он несёт какую-то чушь и при этом, возможно, откровенно врёт, т.к. я смотрел генерируемый Rust-ом код на итераторах и он там был ровно такой же, какой сгенерируется из обычного C++-цикла. Я думаю, что если хорошо постараться со всякими фильтрами и мапами, то можно запутать оптимизатор, но типовой код вполне себе максимально эффективный.
Здравствуйте, T4r4sB, Вы писали:
TB>в С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер".
Шта? Это С но не С++
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Вот есть dlang.org
его написали два крутых чувака из мира C|C++
Причем читая книгу Александреску понимаешь что ЯП разрабатывался
именно с учетом реалий (многопоточка, перформанс и в тоже время простота программирования),
о которых он прекрасно знает из практики.
Здравствуйте, T4r4sB, Вы писали:
TB>Ага, конечно, надо "просто помнить" кучу правил инвалидации итераторов.
А зачем их вообще помнить? Не храни итераторы за пределами текущей области видимости. Не удаляй объекты из коллекции в цикле. Если следовать этим двум простым принципам ты никогда не получишь проблемы с итераторами. Ситуация когда тебе эти два правила надо нарушить невероятно редкая (я реже чем раз в год сталкиваюсь), ну и если уж случилось такое — перечитать правила инвалидации итератора для конкретного контейнера дело 5-ти минут. Это вообще ничто по сравнению с усилиями на ублажение компилятора Rust.
TB>А ещё очень круто, когда у тебя есть проект, в котором спокойно указатели используются в качестве ключей хеш-мапы, это наверное команда не осилила гайды. Проект называется LLVM, если что.
Ну бывает, проект древний, с очень серьезными требованиями к скорости. Это всяко единичный случай.
KP>Честно говоря, до усрачки их. Причем ОС на D все дохлые, а на Rust пара вполне себе развивается.
да, возможно вы правы.
но я лишь хотел сказать, что и на ди и на обероне(причем реалтайм) ОС пишутся не смотря на наличие GC.
но при этом все же они намного проще синтаксически и семантически. т.е. если нужно выжать максимум из железа по-моему проще на сях это сделать.
раст я так понимаю привлекает молодежь падкая на рекламу. если же инженер уже знает си, то ему проще написать на нем. чем учить новый сложный яп.
Здравствуйте, vaa, Вы писали:
vaa>Сколько ОС на расте написано?
А нафига?
ОС это сугубо утилитарная штука, которая нафиг не нужна без аппликух под неё.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, vaa, Вы писали:
vaa>>Сколько ОС на расте написано? CC>А нафига? CC>ОС это сугубо утилитарная штука, которая нафиг не нужна без аппликух под неё.
Rust вроде бы системный? даже протолкнули в ядро линукса.
как раз непонятно, зачем писать прикладное по на нем, если ди или даже сишапр с ее ВМ уже достаточно шустры для этого?
смысл?
Здравствуйте, vaa, Вы писали:
vaa>но при этом все же они намного проще синтаксически и семантически. т.е. если нужно выжать максимум из железа по-моему проще на сях это сделать. vaa>раст я так понимаю привлекает молодежь падкая на рекламу. если же инженер уже знает си, то ему проще написать на нем. чем учить новый сложный яп.
Не знаю починили ли в Rust главную проблему — непредсказуемые паники, но на данный момент для серьезных задач (авиация, автомобилестроение, космос) он банально не подходит. Хотя я 100% уверен что с ним было бы спокойнее писать компоненты где требуются гарантии уровня DAL-B/A или ASIL-D. Там даже можно было бы пойти на ублажение компилятора ради увеличившийся безопасности решения. Но, увы и ах, его даже Глав Пингвин забанил, ожидать что Blackberry пропустит в QNX вообще не реально
Здравствуйте, CreatorCray, Вы писали:
vaa>>Сколько ОС на расте написано? CC>А нафига? CC>ОС это сугубо утилитарная штука, которая нафиг не нужна без аппликух под неё.
Не так давно была новость про работы над POSIX-совместимой ОС, которая позоляла запускать всего одно приложение и позицировалась она построения кластеров. Не могу сейчас найти детали, к сожалению. Но в целом идея потенциально хороша, ты убираешь все левые механизмы связанные с переключением задач и оставляешь минимум. Проще с аудитом, надежностью и т.д. Аппликухи — любой POSIX, в теории.
Здравствуйте, kaa.python, Вы писали:
KP>Не так давно была новость про работы над POSIX-совместимой ОС, которая позоляла запускать всего одно приложение
Тогда это не ОС, это runtime
KP>ты убираешь все левые механизмы связанные с переключением задач и оставляешь минимум.
Ну т.е. по сути это прошивка.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kaa.python, Вы писали:
KP>Не знаю починили ли в Rust главную проблему — непредсказуемые паники
Паники ровно в той же степени непредсказуемы как std::abort или throw 1 в сторонних библиотеках. То есть, встретиться могут и да, нет механизма контроля (с оговорками), но обычно так делать не принято. Есть некоторое количество исключений вроде доступа по индексу. Против таких методов из стандартной библиотеки помогает (изкоробочный) линтер.
Ну и проблемой была не непредсказуемость, а отсутствие возможности обработать выделение памяти. Это "починили" добавив новые функции.
Здравствуйте, kaa.python, Вы писали:
KP>Не знаю починили ли в Rust главную проблему — непредсказуемые паники, но на данный момент для серьезных задач (авиация, автомобилестроение, космос) он банально не подходит. Хотя я 100% уверен что с ним было бы спокойнее писать компоненты где требуются гарантии уровня DAL-B/A или ASIL-D. Там даже можно было бы пойти на ублажение компилятора ради увеличившийся безопасности решения. Но, увы и ах, его даже Глав Пингвин забанил, ожидать что Blackberry пропустит в QNX вообще не реально
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, T4r4sB, Вы писали:
KP>Да если бы оно работало А то выходят монстры из портянок с Box/Rc/Arc/Cell которые надо хитро использовать в разных случаях что бы компилятор остался доволен, но они еще и до кучи херят гарантии времени компиляции, добавляют кучу боли, но не делают код безопаснее куда как более простого кода на C++.
А чем это отличается от unique_ptr/shared_ptr/atomic_shared_ptr ?
Здравствуйте, DarkEld3r, Вы писали:
DE>Паники ровно в той же степени непредсказуемы как std::abort или throw 1 в сторонних библиотеках. То есть, встретиться могут и да, нет механизма контроля (с оговорками), но обычно так делать не принято. Есть некоторое количество исключений вроде доступа по индексу. Против таких методов из стандартной библиотеки помогает (изкоробочный) линтер.
Паники отключаются? Критический код не может содержать исключений (паник и всего на них похожего) и динамического выделения памяти.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, DarkEld3r, Вы писали:
DE>>Паники ровно в той же степени непредсказуемы как std::abort или throw 1 в сторонних библиотеках. То есть, встретиться могут и да, нет механизма контроля (с оговорками), но обычно так делать не принято. Есть некоторое количество исключений вроде доступа по индексу. Против таких методов из стандартной библиотеки помогает (изкоробочный) линтер.
KP>Паники отключаются? Критический код не может содержать исключений (паник и всего на них похожего) и динамического выделения памяти.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Zhendos, Вы писали:
Z>>А чем это отличается от unique_ptr/shared_ptr/atomic_shared_ptr ?
KP>В точку! Та же хренота, но в других местах ты еще и компилятор ублажаешь, вместо того что бы код писать.
Не знаю, у меня опыт противоположный. Компилятор именно помогает,
была довольно много случаев когда была неочевидная зависимость данных друг от друга (тип тут "callback"
менят то-то, тут вызывается эта функция и в итоге меняется то-то)
и компилятор это выявлял. Правда я долго разбирался что не нравиться компилятору.
Но так же я бы это делал и в C++ только под давлением стресса, так как у меня был бы "core dump",
и пользователи интересующиеся "а когда же это починят".
А вот "Cell" очень редко приходилось использовать, и только в начале использования Rust,
потом пересмотрел архитектуру и как-то незаметно вообще прекратил его использовать.
Здравствуйте, Zhendos, Вы писали:
Z>Есть такой "crate" для валидации на стадии компиляции что данная функция не может Z>вызывать "panic": https://docs.rs/no-panic/latest/no_panic/
Этого мало, нужна возможность собрать приложение "без паник" целиком. C++ позволяет собрать код с выключенными исключениями.
Здравствуйте, Zhendos, Вы писали:
Z>была довольно много случаев когда была неочевидная зависимость данных друг от друга (тип тут "callback" Z>менят то-то, тут вызывается эта функция и в итоге меняется то-то) Z>и компилятор это выявлял. Правда я долго разбирался что не нравиться компилятору. Z>Но так же я бы это делал и в C++ только под давлением стресса, так как у меня был бы "core dump", Z>и пользователи интересующиеся "а когда же это починят".
Юнит тесты не пишешь что-ли? Детская ошибка которую всегда ловят тесты
UPD. а вот такой подход приносит проблемы в любом языке:
тип тут "callback" менят то-то, тут вызывается эта функция и в итоге меняется то-то
И от проблемного дизайна Rust не спасает, а вот функциональщина тебя бы тут как раз спасла.
Здравствуйте, T4r4sB, Вы писали:
TB>У вас там всё на shared_ptr + weak_ref , я так понимаю?
Мой С++ код вообще не использует std::
Но тем не менее всё по контейнерам и голых королей указателей наружу не торчит
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
vaa>>его написали два крутых чувака из мира C|C++ DE>И ты ещё говоришь о "молодёжи падкой на рекламу". (:
Реклама — это когда чуваки с огнм в глазах рассказывают что то что они сделали — огого!
А когда чуваки сделавшие проверенное на практике огого и не единожды, делают очередное нечто, небрежно выкладывая его в репозиторий — это авторитет и репутация.
Не надо путать рекламу с репутацией.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Какой знакомый аргумент
Ты взрослый дядя, нормальный аргумент. В старых проектах бывает всяко. В новых не бывает, если разработчики следуют хорошим практикам, и для плюсов это C++ Core Guidelines. Вот тут
KP>Ты взрослый дядя, нормальный аргумент. В старых проектах бывает всяко. В новых не бывает, если разработчики следуют хорошим практикам, и для плюсов это C++ Core Guidelines. Вот тут
Здравствуйте, ononim, Вы писали:
KP>>Ты взрослый дядя, нормальный аргумент. В старых проектах бывает всяко. В новых не бывает, если разработчики следуют хорошим практикам, и для плюсов это C++ Core Guidelines. Вот тут
Здравствуйте, kaa.python, Вы писали:
KP>Паники отключаются?
Что значит отключаются? Сейчас доступны две стратегии обработки паники: "обычная" (размотка стека и т.д.), и моментальный abort. Вторая позволяет не генерировать лишний код. Запретить паниковать стороннему коду, как и в С++, нельзя. Есть только костыльный способ проверить может ли код выбрасывать панику. Ну и линтер умеет предупреждать об использовании таких методов из стандартной библиотеки.
Здравствуйте, kaa.python, Вы писали:
KP>C++ позволяет собрать код с выключенными исключениями.
С++ как раз не позволяет (в стандарте про это ни слова), позволяют отдельные реализации. Если мы говорим о штуках вроде -fno-exceptions, то так (заменять исключения на аборт и выкидывать код размотки стека) и раст умеет.
Здравствуйте, landerhigh, Вы писали:
L>Архитектура "на shared" указателях — это отсутсвие архитектуры.
Ну т.е. выходит куча managed языков да и вообще всё, где есть GC — с отсутствующей архитектурой.
В том числе шарп и жаба, потому как хоть там и нет явных shared указателей объект жив пока на него хоть кто то ссылается.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kaa.python, Вы писали:
KP>А зачем их вообще помнить? Не храни итераторы за пределами текущей области видимости. Не удаляй объекты из коллекции в цикле. Если следовать этим двум простым принципам ты никогда не получишь проблемы с итераторами. Ситуация когда тебе эти два правила надо нарушить невероятно редкая (я реже чем раз в год сталкиваюсь), ну и если уж случилось такое — перечитать правила инвалидации итератора для конкретного контейнера дело 5-ти минут. Это вообще ничто по сравнению с усилиями на ублажение компилятора Rust.
Ну, вообще-то, если удалять в цикле — то это часто оптимальнее. Но да, тут надо почитать немного о правилах инвалидации для конкретного типа контейнера. И безусловно, это гораздо проще, чем постоянная борьба с языком, как в случае раста.
В любом случае, всегда есть что-то типа std::transform
TB>>А ещё очень круто, когда у тебя есть проект, в котором спокойно указатели используются в качестве ключей хеш-мапы, это наверное команда не осилила гайды. Проект называется LLVM, если что.
KP>Ну бывает, проект древний, с очень серьезными требованиями к скорости. Это всяко единичный случай.
LLVM — Первый выпуск — 24 октября 2003
GCC — Первый выпуск — 23 мая 1987
Это смотря с чем древность сравнивать. GCC, кстати, как я слышал, таки переехал/переезжает на плюсики. А LLVM вроде изначально плюсовый, хоть и стартовал на весьма старой на текущий момент версии плюсиков. Хотя и 0x03 были весьма годными.
А указатели как ключи мапы — вообще не вижу криминала, если это целесобразно требованиям производительности. Немного аккуратности, завернуть это в безопасный API — и нет проблем, можно хоть индусам давать в использование
Здравствуйте, kaa.python, Вы писали:
KP>>>Ты взрослый дядя, нормальный аргумент. В старых проектах бывает всяко. В новых не бывает, если разработчики следуют хорошим практикам, и для плюсов это C++ Core Guidelines. Вот тут
я как раз про это и говорил. O>>На самом деле в современных плюсах не хватает режима который бы их энфорсил, запрещая голые указатели и т.п.
KP>Совсем прям их не запретить, как мне кажется, но сильно сократить острые места можно через интеграцию clang-tidy с CI.
В каких-то абстрактных алгоритмах я и в 0x03 голыми не пользовался. Если под большую платформу что-то пишу, даже и не вспоминаю про них. Код под STMку — да, там и массивы, и указатели голые иногда бывают
Здравствуйте, CreatorCray, Вы писали:
L>>Архитектура "на shared" указателях — это отсутсвие архитектуры. CC>Ну т.е. выходит куча managed языков да и вообще всё, где есть GC — с отсутствующей архитектурой.
Ну, обычно ващет именно так дело и обстоит
CC>В том числе шарп и жаба, потому как хоть там и нет явных shared указателей объект жив пока на него хоть кто то ссылается.
Здравствуйте, Zhendos, Вы писали:
Z>А вот "Cell" очень редко приходилось использовать, и только в начале использования Rust, Z>потом пересмотрел архитектуру и как-то незаметно вообще прекратил его использовать.
Тормозиллу на расте уже переписали? Или опять не осилили?
KP>UPD. а вот такой подход приносит проблемы в любом языке: KP>
тип тут "callback" менят то-то, тут вызывается эта функция и в итоге меняется то-то
KP>И от проблемного дизайна Rust не спасает, а вот функциональщина тебя бы тут как раз спасла.
И в C++ есть все средства для этого.
ЗЫ Мне в кути вот эта вот слот-сигнальщина и не нравится — если на неё плотно завязаться, то там сам чёрт собаку сломит. Поэтому — только C++, слот-сигналы только на границах взаимодействия
Здравствуйте, kaa.python, Вы писали:
L>>Нормальная архитектура подразумевает четкую модель владения данными KP>Если уж настолько придираться к словам, то архитектура приложения и умные указатели вообще никак не связаны друг с другом.
Здравствуйте, CreatorCray, Вы писали:
CC>Ну т.е. выходит куча managed языков да и вообще всё, где есть GC — с отсутствующей архитектурой.
При чем тут архитектура языков?
CC>В том числе шарп и жаба, потому как хоть там и нет явных shared указателей объект жив пока на него хоть кто то ссылается.
T4r4sB спрашивал "С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер" и "Ок, архитектура на шаредак и слабых указателях, получается?". У человека PTSD от отсутсвия GC.
Я подобное видел лет 15 назад на одном проекте. Получив в паре мест по сегфолту, все, вообще все завернули в shared_ptr, лишь бы не надорваться над продумыванием стратегии владения данными. Понятное дело, что вместо регулярной рассеянной стрельбы по ступням получили редкий, но прицельный выстрел в бедро
Попытка строить архитектуру системы методом "объявим сущность А серебряной пулей и понеслась", приводит примерно к одинаковому гну на выходе вне зависимости от языка.
Здравствуйте, Marty, Вы писали:
M>И в C++ есть все средства для этого.
А что в C++ есть для решения проблемы с изменением одного состояния из разных мест? Что-то типа CAF? Оно как бы да, частично решает такую проблему, но ты всё равно имеешь все возможности изменить данные из разных мест. Полноценное решение будет только в функциональном языке типа Erlang как не крути.
Здравствуйте, kaa.python, Вы писали:
M>>И в C++ есть все средства для этого.
KP>А что в C++ есть для решения проблемы с изменением одного состояния из разных мест? Что-то типа CAF? Оно как бы да, частично решает такую проблему, но ты всё равно имеешь все возможности изменить данные из разных мест. Полноценное решение будет только в функциональном языке типа Erlang как не крути.
Прошу простить мою дремучесть, но я не в курсе, о какой проблеме ты говоришь. Но вообще в C++ есть средства для решения любых проблем
Здравствуйте, Marty, Вы писали:
M>Прошу простить мою дремучесть, но я не в курсе, о какой проблеме ты говоришь. Но вообще в C++ есть средства для решения любых проблем
Не любых, параллельная обработка данных в C++ это то еще хождение по граблям. Предположим у тебя есть структура данных и указатель на неё. Ты всегда можешь передать этот указатель куда-то еще (другой поток, асинхронно возникающее событие и т.п.) и одновременно изменить данные из разных мест. При достаточно хорошем покрытии кода тестами ThreadSanitizer скорее всего отловит такую ошибку, но у тебя нет возможности её избежать в общем случае.
Здравствуйте, kaa.python, Вы писали:
M>>Прошу простить мою дремучесть, но я не в курсе, о какой проблеме ты говоришь. Но вообще в C++ есть средства для решения любых проблем
KP>Не любых, параллельная обработка данных в C++ это то еще хождение по граблям. Предположим у тебя есть структура данных и указатель на неё. Ты всегда можешь передать этот указатель куда-то еще (другой поток, асинхронно возникающее событие и т.п.) и одновременно изменить данные из разных мест. При достаточно хорошем покрытии кода тестами ThreadSanitizer скорее всего отловит такую ошибку, но у тебя нет возможности её избежать в общем случае.
Средства для решения любых проблем — таки есть. Просто не все видят проблемы, и не все пользуются средствами.
Кто мешает написать прокси-объект, который разруливает атомарность доступа?
Голенькие указатели — да, не совсем безопасны, особенно в руках всяких индусов. Так индусы всё что угодно поломают, не вижу, чем C++ тут так уникален
Здравствуйте, Marty, Вы писали:
M>Средства для решения любых проблем — таки есть. Просто не все видят проблемы, и не все пользуются средствами. M>Кто мешает написать прокси-объект, который разруливает атомарность доступа?
Это не средство решение проблемы, это способ поставить табличку "не входи — убьет" и надеется что её прочитают.
M>Голенькие указатели — да, не совсем безопасны, особенно в руках всяких индусов. Так индусы всё что угодно поломают, не вижу, чем C++ тут так уникален
Индусы тебе чем не угодили-то? У меня сейчас в коллегах не мало индийцев с PhD и без, людей равных которым по уровню в российских компаниях я просто не видел. А вот говнокода и говнокодеров в российских компаниях, причем крупных и на слуху я повидал мягко говоря не мало.
Здравствуйте, kaa.python, Вы писали:
M>>Средства для решения любых проблем — таки есть. Просто не все видят проблемы, и не все пользуются средствами. M>>Кто мешает написать прокси-объект, который разруливает атомарность доступа?
KP>Это не средство решение проблемы, это способ поставить табличку "не входи — убьет" и надеется что её прочитают.
Ну, я не знаю, как ты это готовишь. Если у тебя только такие варианты — ну ССЗБ, что могу сказать
M>>Голенькие указатели — да, не совсем безопасны, особенно в руках всяких индусов. Так индусы всё что угодно поломают, не вижу, чем C++ тут так уникален
KP>Индусы тебе чем не угодили-то? У меня сейчас в коллегах не мало индийцев с PhD и без, людей равных которым по уровню в российских компаниях я просто не видел. А вот говнокода и говнокодеров в российских компаниях, причем крупных и на слуху я повидал мягко говоря не мало.
Ну, хорошо, замени индусов на таджиков или узбеков, и облегчись
Здравствуйте, Marty, Вы писали:
M>Ну, я не знаю, как ты это готовишь. Если у тебя только такие варианты — ну ССЗБ, что могу сказать
Может быть потому, что проекты обычно не в одно рыло и не на один раз пишут. А большой командой, потом еще поддерживают?
M>Ну, хорошо, замени индусов на таджиков или узбеков, и облегчись
А может я хочу на русских говнокодеров заменить. Так можно, рассистик ты наш?
Здравствуйте, kaa.python, Вы писали:
M>>Ну, я не знаю, как ты это готовишь. Если у тебя только такие варианты — ну ССЗБ, что могу сказать
KP>Может быть потому, что проекты обычно не в одно рыло и не на один раз пишут. А большой командой, потом еще поддерживают?
Ну, так обложить проксями ещё больше и чаще, в чем проблема? Язык позволяет. И при этом нормальный компилятор выдаст минимальный оверхед
M>>Ну, хорошо, замени индусов на таджиков или узбеков, и облегчись
KP>А может я хочу на русских говнокодеров заменить. Так можно, рассистик ты наш?
Да меняй на кого угодно. Если я тупых говняков марсианами буду называть, ты успокоишься, или BLM стучит в твоём сердце?
Здравствуйте, Marty, Вы писали:
M>Ну, так обложить проксями ещё больше и чаще, в чем проблема? Язык позволяет. И при этом нормальный компилятор выдаст минимальный оверхед
т.е. ты считаешь чем больше поставить табличек "не входи — убьет", тем менее убьет в итоге?
M>Да меняй на кого угодно. Если я тупых говняков марсианами буду называть, ты успокоишься, или BLM стучит в твоём сердце?
А почему ты считаешь что оскорбление по национальному признаку имеет что-то общее с BLM?
Здравствуйте, kaa.python, Вы писали:
M>>Ну, так обложить проксями ещё больше и чаще, в чем проблема? Язык позволяет. И при этом нормальный компилятор выдаст минимальный оверхед
KP>т.е. ты считаешь чем больше поставить табличек "не входи — убьет", тем менее убьет в итоге?
В нормальном C++ гавно просто не соберётся
M>>Да меняй на кого угодно. Если я тупых говняков марсианами буду называть, ты успокоишься, или BLM стучит в твоём сердце?
KP>А почему ты считаешь что оскорбление по национальному признаку имеет что-то общее с BLM?
Извини, если индусы тебе так дороги. Если я возьму "индусов" в кавычки — это что-то изменит? Против марсиан у тебя нет претензий? У нас в РФ и негра негром назвать не криминал — просто потому, что это заметный отличительный признак. У нас негров мало. Даже меньше, чем конных бурят в ушанках, и тем более — узкоглазых.
Здравствуйте, kaa.python, Вы писали:
KP>А зачем их вообще помнить? Не храни итераторы за пределами текущей области видимости. Не удаляй объекты из коллекции в цикле.
И не добавляй объекты в коллекцию в цикле. И зависит от коллекции, надо знать в каких можно, а в каких нет.
KP>Если следовать этим двум простым принципам ты никогда не получишь проблемы с итераторами.
Принципы простые, но соблюсти их в большом проекте непросто. Добавил вызов функции в цикл, надо лезть в её недра, скакать по графу вызовов, смотреть нет ли там какого-нибудь вызова, где есть модификация коллекции. Поменял двусвязный список на вектор, проверяй все места, где есть итераторы и пр.
Здравствуйте, kaa.python, Вы писали:
НС>>Какой знакомый аргумент KP>Ты взрослый дядя, нормальный аргумент. В старых проектах бывает всяко.
Бывает. Только проекты на С++ почти все — старые.
KP> В новых не бывает, если разработчики следуют хорошим практикам, и для плюсов это C++ Core Guidelines.
Вот я и говорю, что знакомый аргумент. На форуме чуть ли не каждый первый рассказывает про прекрасный С++, но в дикой природе почему то попадается исключительно треш и содомия. Из свежих наблюдений — Архикад, который течет как не знаю что.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот я и говорю, что знакомый аргумент. На форуме чуть ли не каждый первый рассказывает про прекрасный С++, но в дикой природе почему то попадается исключительно треш и содомия. Из свежих наблюдений — Архикад, который течет как не знаю что.
Ты ничего не понимаешь. Он течёт, потому что в самом соку
Здравствуйте, kaa.python, Вы писали:
KP>Предположим у тебя есть структура данных и указатель на неё. KP>Ты всегда можешь передать этот указатель куда-то еще (другой поток, асинхронно возникающее событие и т.п.)
Как const.
KP> и одновременно изменить данные из разных мест.
Не сможешь, ибо const
Если паблик морозов будет напрямую из разных потоков напрямую фигачить в одну и ту же память то будет каша, да.
И это будет исключительно по причине рукожопия говнокодера.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kaa.python, Вы писали:
M>>Кто мешает написать прокси-объект, который разруливает атомарность доступа?
KP>Это не средство решение проблемы, это способ поставить табличку "не входи — убьет" и надеется что её прочитают.
Дюд, это ты не про С++ а про С вещаешь.
В С++ делаешь набор классов, которые рулят доступом к данным, и возможности лазить в данные на запись напрямую банально нет и на этом всё.
Придётся ходить через API, который будет уже разруливать.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, landerhigh, Вы писали:
L>Я подобное видел лет 15 назад на одном проекте. Получив в паре мест по сегфолту, все, вообще все завернули в shared_ptr, лишь бы не надорваться над продумыванием стратегии владения данными.
"Продумывание стратегии" довольно плохо вяжется с современными методологиями программирования
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
L>>Я подобное видел лет 15 назад на одном проекте. Получив в паре мест по сегфолту, все, вообще все завернули в shared_ptr, лишь бы не надорваться над продумыванием стратегии владения данными. TB>"Продумывание стратегии" довольно плохо вяжется с современными методологиями программирования
Ну это к ЯП вообше не относится.
Вон, тут Боинг учудил недавно.
была довольно много случаев когда была неочевидная зависимость данных друг от друга (тип тут "callback" менят то-то, тут вызывается эта функция и в итоге меняется то-то)
И я признаю что на C++ так сделать можно и народ делает. Так же я говорю о том что в функциональных языках так сделать (обычно) нельзя.
CC>В С++ делаешь набор классов, которые рулят доступом к данным, и возможности лазить в данные на запись напрямую банально нет и на этом всё. CC>Придётся ходить через API, который будет уже разруливать.
Да, если по-уму то так и делаешь, но язык тебе оставляет сделать возможность через жопу. А как видишь выше из цитаты люди такой возможностью активно пользуются, когда по не знаю, когда случайно, всё бывает. Да блин, будто у тебя никогда такой хтони не выходило за годы работы
Здравствуйте, T4r4sB, Вы писали:
TB>И с ассёртами (то есть абортами в дебаге и игнором в релизе) в куче операторов. TB>То есть в Расте достаточно ввести режим игнора паник, я верно понял?
Коды возврата нужны вместо вообще всех паник и исключений, в этом плане Раст выглядит соблазнительно со своими Result.
Здравствуйте, T4r4sB, Вы писали:
TB>"Продумывание стратегии" довольно плохо вяжется с современными методологиями программирования
А почему плохо? Что с современными методиками? Помню как во времена водопадов мы пытались затянуть в проекты RUP что бы хоть как-то сократить цикл выпуска продуктов и получить предсказуемость. Текущий вариант с короткими спринтами это как раз дает, главное не забывать включать дизайн и архитектуру перед началом работы. И что хорошо, по современным методикам тратить время на дизайн и архитектуру или нет отдается на откуп командам.
Здравствуйте, kaa.python, Вы писали:
KP>Коды возврата нужны вместо вообще всех паник и исключений
Даже такой нелюбитель исключений как я таки признаёт что есть случаи когда они бывают весьма полезны. Например если есть глубокий стек, который крайне редко "ошибается" а по основному пути должен работать максимально быстро то исключения (в табличной их реализации) оказываются весьма удобным инструментом.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Форум таки древовидный, и на какое сообщение отвечать непосредственно влияет на то, как тебя поймут.
Кроме того при ответе ты цитируешь на что отвечаешь, что задаёт контекст беседы.
И если ты процитировал одно но имел в виду не процитированное а что то своё — твой ответ будет понят совсем не так как ты себе ожидаешь.
KP> Да, если по-уму то так и делаешь, но язык тебе оставляет сделать возможность через жопу.
Потому этот язык и не для маппетов.
KP> Да блин, будто у тебя никогда такой хтони не выходило за годы работы
Вот чтоб такой — не выходило, ибо всех, кто пытался применять паттерн public morozoff без затей вышибали на мороз до того как они успевали пустить корни.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kaa.python, Вы писали:
KP>Паники отключаются? Критический код не может содержать исключений (паник и всего на них похожего) и динамического выделения памяти.
Прикольно, я пару лет назад как раз работал над критическим кодом на C++ и мы отказались от исключений только из-за не предсказуемой задержки. И угадай, что ввели вместо них? Сюрприз, сюрприз! Паники
Здравствуйте, vaa, Вы писали:
vaa>Rust вроде бы системный? даже протолкнули в ядро линукса.
Еще нет, но какие-то извращенцы постоянно его туда проталкивают. Пока только для того, чтобы писать на нем драйвера. Недавно в рассылке что-то было на эту тему. Лично я против этого, не потому что не люблю Раст, я его люблю. Я против того, чтобы разводить зоопарк.
vaa>как раз непонятно, зачем писать прикладное по на нем, если ди или даже сишапр с ее ВМ уже достаточно шустры для этого? vaa>смысл?
А ты смотрел на Раст? Он вполне местами более высокоуровневый чем C#, скорее всего имеется ввиду его близость к железу, zero-cost абстракции и все в таком духе. Но это никак не мешает писать прикладное ПО.
Здравствуйте, kaa.python, Вы писали:
M>>Подводя итоги: не зря Mozilla сократила команду, работавшую над Rust. [/q]
KP>Язык программирования в котором разработчик выполняет работу компилятора по доказанию клрректности времени жизни объектов — это нонсенс.
В этом языке вопрос о корректности программы решается, как в суде, путем состязательного процесса. В качестве прокурора и судьи выступает компилятор.
Здравствуйте, blacktea, Вы писали:
B>Прикольно, я пару лет назад как раз работал над критическим кодом на C++ и мы отказались от исключений только из-за не предсказуемой задержки. И угадай, что ввели вместо них? Сюрприз, сюрприз! Паники
И на соответствие каким стандартам безопасности и какого уровня вы его собрались сертифицировать? Сюрприз, сюрприз! Никаким?
Здравствуйте, blacktea, Вы писали:
vaa>>смысл?
B>А ты смотрел на Раст? Он вполне местами более высокоуровневый чем C#, скорее всего имеется ввиду его близость к железу, zero-cost абстракции и все в таком духе. Но это никак не мешает писать прикладное ПО.
Смотрел, в целом он конечно в разы проще плюсов(глянул вчера гайд корэ страуса и мне поплохело)
и он даже иногда прикольный.
но объективно становлюсь на сторону Александреску https://habr.com/ru/post/460989/
После чтения некоторого количества кода на Rust возникают анекдоты типа
«Чувак пропускал дни кача ног», иллюстрируемых комиксами с людьми с
перекачанным торсом но ногами-спичками (прим.перев. По-русски, «Колосс на
глиняных ногах», но неточно) Rust ставит на первое место точное и
безопасное управление памятью и представляет это центром мира. Внезапно,
это редко является проблемной областью, что приводит к тому, что большая
доля планирования и кодирования уделяется, по сути, канцелярской работе
(которую языки с GC автоматизируют не глядя). Безопасное, предопределенное
переиспользование памяти — серьезная задача, но не единственная, или как
минимум не самая важная в программе. В итоге Rust тратит непропорциональное
количество ресурсов языкового дизайна только на это. Было бы интересно
посмотреть, насколько Rust разбухнет ради других аспектов языка;
единственный вариант это расширение языка, но вопрос в том, насколько
абстракции смогут помочь с неприятной необходимостью контролировать ресурсы
на всех уровнях.
Здравствуйте, CreatorCray, Вы писали:
CC>Даже такой нелюбитель исключений как я таки признаёт что есть случаи когда они бывают весьма полезны. Например если есть глубокий стек, который крайне редко "ошибается" а по основному пути должен работать максимально быстро то исключения (в табличной их реализации) оказываются весьма удобным инструментом.
Я люблю исключения и считаю их лучшим способом информировать об ошибках нежели коды возврата. Просто иногда ты никак не можешь использовать по независящим от тебя причинам.
Здравствуйте, kaa.python, Вы писали:
KP>И на соответствие каким стандартам безопасности и какого уровня вы его собрались сертифицировать? Сюрприз, сюрприз! Никаким?
Да, пока никаким, потому что если с самого начала такого research heavy проекта заморачиваться бюрократией, то можно десятилетиями на месте топтаться.
Здравствуйте, blacktea, Вы писали:
B>Да, пока никаким, потому что если с самого начала такого research heavy проекта заморачиваться бюрократией, то можно десятилетиями на месте топтаться.
Ну вот как сертифиуируете по какому-то серьёзному процессу, так и расскажешь про паники в критичном коде.
Здравствуйте, blacktea, Вы писали:
B>PS: кстати, мы с тобой в одной области вроде даже работаем (то есть, я работал), SDC
Я, честно говоря, не знаю что такое SDC
У меня как бы autonomious vehicle, но к самому autonomious не имею, у меня это своего рода фронтэнд и бэкенд на колесах
Здравствуйте, kaa.python, Вы писали:
KP>Я, честно говоря, не знаю что такое SDC KP>У меня как бы autonomious vehicle, но к самому autonomious не имею, у меня это своего рода фронтэнд и бэкенд на колесах
Здравствуйте, kaa.python, Вы писали:
KP>Я люблю исключения и считаю их лучшим способом информировать об ошибках нежели коды возврата.
Обработка их уж очень геморная. Весь код оказывается густо засран try/catch
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, T4r4sB, Вы писали:
TB>в С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер".
Недаром у C++ два плюса в названии. Видимо, мы с Вами пишем на разных — кто-то на левом, а кто-то на правом.
MD>Недаром у C++ два плюса в названии. Видимо, мы с Вами пишем на разных — кто-то на левом, а кто-то на правом.
Да-да, расскажи, что делаешь ты, когда у тебя есть "движок"-владелец объекта, и тебе нужен временный указатель на объект. Ты делаешь weak_ref? Или выдаёшь сырой указатель?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, kaa.python, Вы писали:
KP>>Я люблю исключения и считаю их лучшим способом информировать об ошибках нежели коды возврата. CC>Обработка их уж очень геморная. Весь код оказывается густо засран try/catch
Насколько я понял из разговора с их сторонниками — надо не засирать код try/catch, а поставить один try/catch вокруг функции, написанной джуном, чтоб она не повалила остальное.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, blacktea, Вы писали:
B>Да, все верно, философия fail fast.
Тогда у тебя должна быть куча процессов, что добавляет накладные runtime расходы по их взаимодействию
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, T4r4sB, Вы писали:
TB>Насколько я понял из разговора с их сторонниками — надо не засирать код try/catch, а поставить один try/catch вокруг функции, написанной джуном, чтоб она не повалила остальное.
А остальные функции никогда не ошибаются никогда что ли?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, T4r4sB, Вы писали:
TB>Можно в главном цикле поставить один большой трай. Типа главный цикл можно отладить нормально 1 раз.
Это не программа а кусок говна получается.
Можно тогда уже просто тупо падать по ошибке
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, T4r4sB, Вы писали:
TB>>Можно в главном цикле поставить один большой трай. Типа главный цикл можно отладить нормально 1 раз. CC>Это не программа а кусок говна получается. CC>Можно тогда уже просто тупо падать по ошибке
Что лучше — говно, которое кое-как работает, или говно, которое сразу падает?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
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>Что лучше — говно, которое кое-как работает, или говно, которое сразу падает?
Конечно же то, что сразу падает.
Тогда быстро выпишут живительных звездюлей, говнодела выкинут на мороз а это говно отправят на переделку.
Иначе же говна будет становиться всё больше.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, hi_octane, Вы писали:
_>Try/Catch нужно ставить только там где ты можешь разумно исправить ситуацию. Например ты отправляешь запрос в сеть и ожидаешь что в ответ прилетит тонна упакованного Json — нет никакого смысла оборачивать в try/catch каждое чтение из сокета, парсинг токенов, и т.п. Оборачиваешь в один try/catch всё скопом — и запрос, и распаковку, и парсинг. Если что-то сломалось — верхнему уровню пофиг на нюансы — исключение в лог, операцию повторить.
Сильно зависит что ты пишешь. У меня например достаточно кода в котором результат операции "не success" это одно из допустимых состояний. Так что с try/catch код превращается в плохочитаемую кашу очень быстро. Так что в таком раскладе if выходит куда предпочтительнее а исключения остаются для гм, исключительных случаев типа "глубоко в недрах Мории случилась уж совсем полная жопа и надо всё бросать и свистать всех наверх".
_> После нескольких попыток исключение летит выше, и там кто-то или юзеру напишет "проверьте подключение", или там наверху само переключится на резервный url и вызовет ещё раз.
Вот так и получаем софт который просто пишет "ашыпка, нисмагла", а где сломалось и почему — догадайся сам. В лучшем случае — на тебе стек где случилась обосратушка, без состояния.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
KP>>Я люблю исключения и считаю их лучшим способом информировать об ошибках нежели коды возврата. CC>Обработка их уж очень геморная. Весь код оказывается густо засран try/catch
try/catch всегда можно поставить поменьше, только в местах где можно обработать ошибки разом и повторить действие/отказаться в зависимости от обстоятельств. С кодами ошибок же всё засирается на порядок быстрее, тот же код на Go — это сплошные сопли из if/else для обработки кодов возврата. Да, оно проще читается и создает меньше возможностей для ошибок т.к. ты всегда знаешь где и что было обработано, но вот "засрано" — это точно не про исключения
Здравствуйте, 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>Здравствуйте, T4r4sB, Вы писали:
TB>>Что лучше — говно, которое кое-как работает, или говно, которое сразу падает? CC>Конечно же то, что сразу падает. CC>Тогда быстро выпишут живительных звездюлей, говнодела выкинут на мороз а это говно отправят на переделку. CC>Иначе же говна будет становиться всё больше.
Перенесём вопрос на уровень выше. Ты пишешь ОСь. Ты пытаешься разобрать случай, когда юзерское говноприложение падает. Будешь ронять систему, или попытаешься закрыть все открытые юзером хендлы и продолжить работу?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Перенесём вопрос на уровень выше. Ты пишешь ОСь.
Это будет уровень ниже.
TB> Ты пытаешься разобрать случай, когда юзерское говноприложение падает. TB> Будешь ронять систему, или попытаешься закрыть все открытые юзером хендлы и продолжить работу?
Ты как то странно понимаешь как в принципе работает ОС.
Если приложение "падает" в usermode — происходит банальная терминация процесса, и там уже не суть важно по какой причине оно случилось — все запрошенные им ресурсы будут автоматически освобождены.
Если приложение каким то образом ныряет в кернел и вызывает панику там — схлопнется вообще всё.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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>Если приложение каким то образом ныряет в кернел и вызывает панику там — схлопнется вообще всё.
А теперь представь, что есть приложение с главным циклом, надёжность которого надо обеспечить любой ценой, и есть модуль, пишущийся джуном. И желательно чтоб после ошибок джуна приложение как-то работало, разумеется, выдав сообщение, что "плагин джуна сдох по такому-то адресу, продолжаю работу"
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>А теперь представь, что есть приложение с главным циклом, надёжность которого надо обеспечить любой ценой, и есть модуль, пишущийся джуном. И желательно чтоб после ошибок джуна приложение как-то работало, разумеется, выдав сообщение, что "плагин джуна сдох по такому-то адресу, продолжаю работу"
Разделить приложение по разныим процессам как в Chrome, Firefox и пр., вынести плагин джуна в отдельный процесс.
Здравствуйте, T4r4sB, Вы писали:
TB>А теперь представь, что есть приложение с главным циклом, надёжность которого надо обеспечить любой ценой, и есть модуль, пишущийся джуном.
Вот такую комбинацию ну никак не представляю.
В таком раскладе ошибка в ДНК тех, кто пускает джунов в критическую систему
TB> И желательно чтоб после ошибок джуна приложение как-то работало, разумеется, выдав сообщение, что "плагин джуна сдох по такому-то адресу, продолжаю работу"
Только выносить в отдельный, изолированный процесс с жёсткими квотами на ресурсы. А ещё лучше — на отдельный хост.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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.
А, ну понятно теперь почему иногда теслы убивают своих водителей
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
C>>Весь более-менее интересный современный код (self-driving и прочее) вообще не использует ASIL. CC>А, ну понятно теперь почему иногда теслы убивают своих водителей
Похоже что так. В конце цепочки принятия критических решений, подтверждение выбранной тректории, подтверждение отсутствия препятствия, экстренное торможение и т.д. как раз код ASIL-D работающий на железе ASIL-D. Доверять машине в которой это не так идея так себе. Но да, не интересно, не современно, ага
vaa,
vaa>да, возможно вы правы. vaa>но я лишь хотел сказать, что и на ди и на обероне(причем реалтайм) ОС пишутся не смотря на наличие GC. vaa>но при этом все же они намного проще синтаксически и семантически. т.е. если нужно выжать максимум из железа по-моему проще на сях это сделать. vaa>раст я так понимаю привлекает молодежь падкая на рекламу. если же инженер уже знает си, то ему проще написать на нем. чем учить новый сложный яп.
У вас несколько иллюзорные представления. На Rust работает масса опытных специалистов. Вы разберитесь, за термином Rust не только реклама и новые буквы в синтаксисе, а очень хорошие и проверенные на практике идеи написания безопасного кода. Ни в C, ни в C++ не смогут никогда решить свои внутренние проблемы по причине обратной совместимости, а новые стандарты не только не решают, а больше ухудшают состояние экосистемы.
Artem Korneev,
AK>Всё это выливается в боль и страдания, но код получается значительно безопаснее аналогичного на Си. Вот отсюда и весь хайп, а вовсе не из рекламы.
AK>На мой взгляд, Rust это как раз то, в какую сторону должны двигаться современные системные компилируемые языки. Синтаксис его мне, правда, не очень нравится. Но пока что есть, то есть.
Да и боль со страданиями сильно преувеличены, по крайней мере для обычного кода. Вот с асинками часто весьма неочевидные сообщения об ошибках, но тут помогает навык создания MRE и ошибки улучшаются от релиза к релизу.
В целом, как человеку, работающему на Rust мне довольно комфортно, а вот каждое заныривание в C++ действительно приносит боль и страдания, уж извините.
А то выходят монстры из портянок с Box/Rc/Arc/Cell которые надо хитро использовать в разных случаях что бы компилятор остался доволен, но они еще и до кучи херят гарантии времени компиляции, добавляют кучу боли, но не делают код безопаснее куда как более простого кода на C++.
Не храни итераторы за пределами текущей области видимости. Не удаляй объекты из коллекции в цикле. Если следовать этим двум простым принципам ты никогда не получишь проблемы с итераторами. Ситуация когда тебе эти два правила надо нарушить невероятно редкая (я реже чем раз в год сталкиваюсь), ну и если уж случилось такое — перечитать правила инвалидации итератора для конкретного контейнера дело 5-ти минут. Это вообще ничто по сравнению с усилиями на ублажение компилятора Rust.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
