алло, тут не идрис

так и на плюсах не так часто попадаешь на висячую ссылку

это ты по кому судишь-то?

В Си/Си++тоже есть концепция неявных лайфтаймов. В Rust их сделали явными и композируемыми, вот всё отличие. Не понимаю что тут ворчать про то, какой плохой борроу-чекер. Указатель на объект идёт вверх по стеку - лайфтайм продолжается, вниз - лайфтайму конец, также и в Rust, но который уже явно на этапе компиляции скажет об этом. Дебаггер для отлова UB в Rust я не использовал _никогда_.

https://en.cppreference.com/w/cpp/language/lifetime

https://en.cppreference.com/w/c/language/lifetime

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

висячие ссылки почему-то имеются

ворчим потому, не всегда несколько мутабельный ссылок означают что-то плохое

дебаггер не только для ловли уб, но и для отлова ошибок в бизнес-логике

всё в типы не загонишь

По возможности, конечно. Я до Идриса раньше не осознавал, что тоже даже в Java писал теоремы в коде, именно в типах. Простейшим образом выражал, что кубик можно вставить в отверстие от кубика, а в отверстие от треугольника - нельзя. В Idris они просто более выразительные стали

ну так это делает каждый так или иначе. Но ошибки всё равно случаются

Имеются, потому что концепцию лайфтаймов нужно было сразу тщательно продумывать и делать явной. Но во времена C/C++ это скорее фантастика.

Не исключаю, но никогда не сталкивался, можно пример?

Приходим к типам. Когда в типах описываешь намерение, ошибки в бизнес-логике отлавливаться настолько проще, что в большинстве случаев даже банальны (уже не говоря о том, что их во время исполнения просто меньше, чем если бы мы не думали о типах)

Но их можно уменьшить за счёт типов. Кстати, не только логические ошибки, вообще все виды ошибок. Лайфтаймы в Rust тоже сродни линейным типам данных.

> Но во времена C/C++ это скорее фантастика.
я думаю, это не абсолютное добро, поэтому и так сойдёт. А вот сейф-ансейф было бы хорошо добавить

>Не исключаю, но никогда не сталкивался, можно пример?
пока нет, увижу - скину

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

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

Типы много проверок инвариант выносят на стадию компиляции, что и производительность увеличивает, и количество багов снижает. Насчёт «не все» - мы должно понимать разницу между меньше багов снижают или больше. Лично моя практика показывает, что логических ошибок с типами я делаю на 70% меньше, чем без типов (это в Rust конкретно). Сериализация/десериализация - это частный случай, который тоже описывается хорошо типами (см. главную страницу serde-json).

И я не понимаю как ты без лайфтаймов собрался делать safe/unsafe в языке

Их не нужно валидировать, их нужно парсить.
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

убрать в ансейф то, что запросто приводит к ub. Разыменование ссылок и простых указателей, например. Ещё туда не помешало бы запихнуть const_cast, reinterpret_cast, c style cast

Спойлер: у тебя без нечто подобного лайфтаймам не получится сделать нормальное разделение. Скорее всего, много кода всё равно в unsafe сувать придётся, т.к. safe часть не позволяет выразить в большинстве случаев хотелки.

В teloxide обобщённый код и ни одного unsafe, что как бы намекает на то, что Rust - достаточно выразительный язык, чтобы высокоуровневые части писать в полностью safe коде, а низкоуровневые закрывать под safe интерфейсом.

почему не получится? Смартпоинтеры же будут. Кроме того, можно сделать std с CoW, тогда во многих случаях можно без дополнительных аллокаций в хипе обойтись