Мне никогда не приходилось использовать двусвязные списки в своей практике, так что я не вижу смысла решать задачи, не имеющие практического смысла, нормальный рациональный программист возьмёт Vec и не будет выпендриваться
Ага, «в расте есть RefCell и утечки ужас-ужас», «в unsafe-коде можно ошибиться ужас-ужас», «в расте куча runtime-проверок», «борроу-чекер мешает писать код» и прочая классика растосрачей, каким пунктом там cve-rs в методичке?)
1) Просто не используйте unsafe-крейты, которым вы не доверяете
2) Если вы всё же хотите или вынуждены их использовать, при получении рандомного числа из ниоткуда вы точно знаете, что виновником может быть только один из unsafe-крейтов и никто другой, что существенно сужает круг подозреваемых и ускоряет отладку — чем Rust и прекрасен в сравнении со всякими сишечками
Если перестать фокусироваться на несчастном RefCell, а взять хоть тот же условный Vec, проверки там — где надо, где они должны были бы быть и в аналогичном сишном коде тоже. Считать проблемой то, что необходимые runtime-проверки есть — глупо. Игнорировать то, что компилятор способен выкидывать runtime-проверки и обеспечивать отсутствие оверхеда, тем самым опровергая ваши утверждения, — дважды глупо
А там нечего забирать — одного контр-примера со способностью компилятора убирать runtime-проверки границ массива уже достаточно, чтобы опровергнуть оказавшееся ложным утверждение (или гипотезу, если угодно) «Оборачиваем его в runtime проверки»
Факт возможности утечки никак не отменяет факта наличия системы владения и заимствования, успешно управляющей памятью и не допускающей в Safe Rust использования ещё не инициализированной или уже освобождённой памяти
А мне и не надо заглядывать, всё уже сделано до меня — вот, например, Rust успешно выкидывает runtime-проверки границ массива с сохранением безопасности https://habr.com/ru/companies/otus/articles/718012/
Цепляться за один частный случай маловероятной на практике утечки, так же как и цепляться за один частный RefCell, старательно игнорируя многочисленные преимущества языка — как минимум глупо
Чтобы изолировать и тщательно оттестировать unsafe-код внутри этих самых смарт-указателей и прочих базовых библиотеках и чтобы миллиарды строк высокоуровневой бизнес-логики, написанной на 100% Safe Rust, не могли содержать ошибок в работе с памятью даже теоретически благодаря отсутствию в них unsafe-кода
Можно настроить одинаковое поведение
На свежеустановленном сервере никаких redis и rabbitmq тем более не существует
То есть вы потеряли микросекунды и получили проблему 2038 (или 2106) года?
Мне никогда не приходилось использовать двусвязные списки в своей практике, так что я не вижу смысла решать задачи, не имеющие практического смысла, нормальный рациональный программист возьмёт Vec и не будет выпендриваться
Ага, «в расте есть RefCell и утечки ужас-ужас», «в unsafe-коде можно ошибиться ужас-ужас», «в расте куча runtime-проверок», «борроу-чекер мешает писать код» и прочая классика растосрачей, каким пунктом там cve-rs в методичке?)
Куча CVE наглядно демонстрирует как там все начеку)
Всяко лучше чем у сишечек
Из коробки не завезли, но есть cargo-geiger какой-нибудь
1) Просто не используйте unsafe-крейты, которым вы не доверяете
2) Если вы всё же хотите или вынуждены их использовать, при получении рандомного числа из ниоткуда вы точно знаете, что виновником может быть только один из unsafe-крейтов и никто другой, что существенно сужает круг подозреваемых и ускоряет отладку — чем Rust и прекрасен в сравнении со всякими сишечками
Если перестать фокусироваться на несчастном RefCell, а взять хоть тот же условный Vec, проверки там — где надо, где они должны были бы быть и в аналогичном сишном коде тоже. Считать проблемой то, что необходимые runtime-проверки есть — глупо. Игнорировать то, что компилятор способен выкидывать runtime-проверки и обеспечивать отсутствие оверхеда, тем самым опровергая ваши утверждения, — дважды глупо
Вы использовали неинициализированную память таки в unsafe-коде, нарушив safety-требование функции assume_init
А там нечего забирать — одного контр-примера со способностью компилятора убирать runtime-проверки границ массива уже достаточно, чтобы опровергнуть оказавшееся ложным утверждение (или гипотезу, если угодно) «Оборачиваем его в runtime проверки»
Лучше оптимизировать проверки, которые изначально есть, чем потом ловить Heartbleed'ы по всему миру из-за проверки, которой изначально не было
Вы продолжаете докапываться до каких-то несущественных мелочей, игнорируя суть Rust и фундаментальные проблемы, которые он с некоторым успехом решает
Какой гипотезы? Контр-примера чему?
Факт возможности утечки никак не отменяет факта наличия системы владения и заимствования, успешно управляющей памятью и не допускающей в Safe Rust использования ещё не инициализированной или уже освобождённой памяти
А мне и не надо заглядывать, всё уже сделано до меня — вот, например, Rust успешно выкидывает runtime-проверки границ массива с сохранением безопасности https://habr.com/ru/companies/otus/articles/718012/
Сделать утечку надо ещё сильно умудриться
Цепляться за один частный случай маловероятной на практике утечки, так же как и цепляться за один частный RefCell, старательно игнорируя многочисленные преимущества языка — как минимум глупо
Я так и думал, что вы узнали про RefCell и решили ошибочно экстраполировать его особенности на весь Rust
Собственно с чего бы утечкам памяти быть UB
И здесь вы начали нести не соответствующую действительности чушь, так что можно не продолжать
Чтобы изолировать и тщательно оттестировать unsafe-код внутри этих самых смарт-указателей и прочих базовых библиотеках и чтобы миллиарды строк высокоуровневой бизнес-логики, написанной на 100% Safe Rust, не могли содержать ошибок в работе с памятью даже теоретически благодаря отсутствию в них unsafe-кода
Как будто что-то плохое