История изменений

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

Ты, как и все фанбои раста, Си, C++ глубоко и безнадежно застряли в идеологии программирования 80-х, когда любая операция выполняется условно атомарно, мгновенно, синхронно. То есть, сделал чтение из файла — оно сразу завершилось. Выделил память — она сразу выделилась. Взял блокировку в стэке, сделал мгновенную операцию, отпустил блокировку. Эта модель неактуальна уже лет 20, потому что программа просто-таки обязана делать еще десяток задач параллельно со «взял блокировку» и «прочитал файл».

В Rust есть примерно ноль инструментов для того, чтобы давать какие-то гарантии по лайфтауму того же связанного списка. Да, выше упомянули Rc<RefCell<_>> — но это СТЭК-ОРИЕНТИРОВАННАЯ структура данных: при доступе из многопоточного кода к структуре с подсчетом ссылок ты должен залочить родительскую структур, записать лок в стэк, увеличить счетчик ссылок, достать из стэка лок, разлочить его, вернуть значение с увеличенным счетчиком вызвавшему коду. Вызывающий код, если делает операцию над ячейкой со счетчиком, аналогично в стэке будет увеличивать счетчик под блокировкой, запоминать это в стэке, и уменьшать счетчик под блокировкой. Или брать единую блокировку на все операции. Всё это чудовищно неэффективно, потому во всяких JVM, CLR, Go, и прочих высокопроизводительных многопоточных системах не используется.

Вот и для кого все эти лайфтаймы вообще делались? Для какого кода, если с асинхронностью и многопоточностью у тебя почти всегда будет нарушение лайфтаймов, то есть unsafe. Если тебя не впечатлила многопоточность, то я могу вспомнить БД, которые вообще сделаны из одного сплошного небезопасного состояния. Или что-то железное, вроде тех же ОС, которые опять-таки нет смысла писать на Rust, потому что там всё один сплошной unsafe.

Вот прямо как в Haskell: идеальная модель программирования, но, к сожалению, на этой идеальной модели можно написать только бесполезный код. Код с прикладной ценностью обильно вываливается из идеальной модели в unsafe/impure/imperative, и модель становится уже не столько помощником, сколько обузой, через которую приходится перешагивать по двадцать раз в день. А потом говорить «да мне не тяжело, я не замечаю».

Только не надо думать, что я считаю, что в Rust нет ничего хорошего. Мне давно не хватает в C/C++ норм базовых структур данных и возможности их применить в тех же прототипах функций — эта штука почти годно была бы сделана в Rust, если бы среди разрабов Rust был хотя бы один человек, понимающий в оптимизации компиляторов, как это было при разработке Pascal. Но этот парад абсурда с борроу чекером и «безопасностью» — это контрпродуктивная наркомания, которая сделала Rust специализированным языком для написания браузеров, то есть, очень хорошо проработаны фичи, связанные с разработкой браузеров, и никак не проработаны отдельные фичи, не связанные с браузерами. Вроде скорости компиляции, побочных эффектов, глобального состояния, lock-free и персистентных структур данных ,и так далее.

Собственно раст от си отличается тем, что в C вся эта же информация описана в документации или комментах, и компилятор не следит за её актуальностью

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

Так что в этой области у него не хуже чем у других

Апелляция к «у C++ еще хуже». Потому что C/C++ — говно, а не ЯП. Потому корректно говорить «у Rust всё так же плохо, как у других» — то есть, он по прежнему застрял в 80-х, это не ЯП 21-го века, это просто ремейк C++.

В большинстве случаев чтоб программа на расте упала по панике её нужно об этом попросить. И подобные просьбы легко можно грепом отыскать

К сожалению, грепать и вычитывать тебе придется также стандартную либу, которая тоже весьма любит паниковать. Если я не ошибаюсь, есть даже встроенные в компилятор паники — вроде доступа к строке по индексу.

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

Ты, как и все фанбои раста, Си, C++ глубоко и безнадежно застряли в идеологии программирования 80-х, когда любая операция выполняется условно атомарно, мгновенно, синхронно. То есть, сделал чтение из файла — оно сразу завершилось. Выделил память — она сразу выделилась. Взял блокировку в стэке, сделал мгновенную операцию, отпустил блокировку. Эта модель неактуальна уже лет 20, потому что программа просто-таки обязана делать еще десяток задач параллельно со «взял блокировку» и «прочитал файл».

В Rust есть примерно ноль инструментов для того, чтобы давать какие-то гарантии по лайфтауму того же связанного списка. Да, выше упомянули Rc<RefCell<_>> — но это СТЭК-ОРИЕНТИРОВАННАЯ структура данных: при доступе из многопоточного кода к структуре с подсчетом ссылок ты должен залочить родительскую структур, записать лок в стэк, увеличить счетчик ссылок, достать из стэка лок, разлочить его, вернуть значение с увеличенным счетчиком вызвавшему коду. Вызывающий код, если делает операцию над ячейкой со счетчиком, аналогично в стэке будет увеличивать счетчик под блокировкой, запоминать это в стэке, и уменьшать счетчик под блокировкой. Или брать единую блокировку на все операции. Всё это чудовищно неэффективно, потому во всяких JVM, CLR, Go, и прочих высокопроизводительных многопоточных системах не используется.

Вот и для кого все эти лайфтаймы вообще делались? Для какого кода, если с асинхронностью и многопоточностью у тебя почти всегда будет нарушение лайфтаймов, то есть unsafe. Если тебя не впечатлила многопоточность, то я могу вспомнить БД, которые вообще сделаны из одного сплошного небезопасного состояния. Или что-то железное, вроде тех же ОС, которые опять-таки нет смысла писать на Rust, потому что там всё один сплошной unsafe.

Вот прямо как в Haskell: идеальная модель программирования, но, к сожалению, на этой идеальной модели можно написать только бесполезный код. Код с прикладной ценностью обильно вываливается из идеальной модели в unsafe/impure/imperative, и модель становится уже не столько помощником, сколько обузой, через которую приходится перешагивать по двадцать раз в день. А потом говорить «да мне не тяжело, я не замечаю».

Только не надо думать, что я считаю, что в Rust нет ничего хорошего. Мне давно не хватает в C/C++ норм базовых структур данных и возможности их применить в тех же прототипах функций — эта штука почти годно была бы сделана в Rust, если бы среди разрабов Rust был хотя бы один человек, понимающий в оптимизации компиляторов, как это было при разработке Pascal. Но этот парад абсурда с борроу чекером и «безопасностью» — это контрпродуктивная наркомания, которая сделала Rust специализированным языком для написания браузеров.

Собственно раст от си отличается тем, что в C вся эта же информация описана в документации или комментах, и компилятор не следит за её актуальностью

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

Так что в этой области у него не хуже чем у других

Апелляция к «у C++ еще хуже». Потому что C/C++ — говно, а не ЯП. Потому корректно говорить «у Rust всё так же плохо, как у других» — то есть, он по прежнему застрял в 80-х, это не ЯП 21-го века, это просто ремейк C++.

В большинстве случаев чтоб программа на расте упала по панике её нужно об этом попросить. И подобные просьбы легко можно грепом отыскать

К сожалению, грепать и вычитывать тебе придется также стандартную либу, которая тоже весьма любит паниковать. Если я не ошибаюсь, есть даже встроенные в компилятор паники — вроде доступа к строке по индексу.

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

Ты, как и все фанбои раста, Си, C++ глубоко и безнадежно застряли в идеологии программирования 80-х, когда любая операция выполняется условно атомарно, мгновенно, синхронно. То есть, сделал чтение из файла — оно сразу завершилось. Выделил память — она сразу выделилась. Взял блокировку в стэке, сделал мгновенную операцию, отпустил блокировку. Эта модель неактуальна уже лет 20, потому что программа просто-таки обязана делать еще десяток задач параллельно со «взял блокировку» и «прочитал файл».

В Rust есть примерно ноль инструментов для того, чтобы давать какие-то гарантии по лайфтауму того же связанного списка. Да, выше упомянули Rc<RefCell<_>> — но это СТЭК-ОРИЕНТИРОВАННАЯ структура данных: при доступе из многопоточного кода к структуре с подсчетом ссылок ты должен залочить родительскую структур, записать лок в стэк, увеличить счетчик ссылок, достать из стэка лок, разлочить его, вернуть значение с увеличенным счетчиком вызвавшему коду. Вызывающий код, если делает операцию над ячейкой со счетчиком, аналогично в стэке будет увеличивать счетчик под блокировкой, запоминать это в стэке, и уменьшать счетчик под блокировкой. Или брать блокировку на все операции. Всё это чудовищно неэффективно, потому во всяких JVM, CLR, Go, и прочих высокопроизводительных многопоточных системах не используется.

Вот и для кого все эти лайфтаймы вообще делались? Для какого кода, если с асинхронностью и многопоточностью у тебя почти всегда будет нарушение лайфтаймов, то есть unsafe. Если тебя не впечатлила многопоточность, то я могу вспомнить БД, которые вообще сделаны из одного сплошного небезопасного состояния. Или что-то железное, вроде тех же ОС, которые опять-таки нет смысла писать на Rust, потому что там всё один сплошной unsafe.

Вот прямо как в Haskell: идеальная модель программирования, но, к сожалению, на этой идеальной модели можно написать только бесполезный код. Код с прикладной ценностью обильно вываливается из идеальной модели в unsafe/impure/imperative, и модель становится уже не столько помощником, сколько обузой, через которую приходится перешагивать по двадцать раз в день. А потом говорить «да мне не тяжело, я не замечаю».

Только не надо думать, что я считаю, что в Rust нет ничего хорошего. Мне давно не хватает в C/C++ норм базовых структур данных и возможности их применить в тех же прототипах функций — эта штука почти годно была бы сделана в Rust, если бы среди разрабов Rust был хотя бы один человек, понимающий в оптимизации компиляторов, как это было при разработке Pascal. Но этот парад абсурда с борроу чекером и «безопасностью» — это контрпродуктивная наркомания, которая сделала Rust специализированным языком для написания браузеров.

Собственно раст от си отличается тем, что в C вся эта же информация описана в документации или комментах, и компилятор не следит за её актуальностью

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

Так что в этой области у него не хуже чем у других

Апелляция к «у C++ еще хуже». Потому что C/C++ — говно, а не ЯП. Потому корректно говорить «у Rust всё так же плохо, как у других» — то есть, он по прежнему застрял в 80-х, это не ЯП 21-го века, это просто ремейк C++.

В большинстве случаев чтоб программа на расте упала по панике её нужно об этом попросить. И подобные просьбы легко можно грепом отыскать

К сожалению, грепать и вычитывать тебе придется также стандартную либу, которая тоже весьма любит паниковать. Если я не ошибаюсь, есть даже встроенные в компилятор паники — вроде доступа к строке по индексу.