Каких вещей следует избегать в Rust?

Question

[Имя]

Я знаю, что следует избегать всяких "продвинутых" штук из ряда связных списков, самореферентных структур и т.п.
Ещё я обнаружил, что создание больших структур, с методами, с кучей полей, обычно приводит к проблемам с borrow checker. А если в структуре будет ссылка или иное заимствование, то это гарантированные проблемы.

Насколько я понимаю, самым рабочим выглядит чисто функциональный подход, а не структур с методами.
И правильно ли я понимаю, что следует избегать структур хранящих ссылки и имеющими лайфтайм?
Так, наличие в умеренных размерах программе, которая по сути была одной функцией, лишь одной структуры хранящей ссылку, поставило крест на попытке структуризации программы в более человеческий вид.
И очень часто в Rust программах, мне приходится идти на более уродливую архитектуру, дабы избежать проблем с (почти ненужным в однопоточном коде) borrow checker.
И в вопросе о borrow checker, разве не является тот факт, что большинство библиотек избегает &mut self в изменяющих что-то методах, звоночком к наличию большим проблем в языке?

В общем, посоветуйте что-то что-бы помогало меньше бороться с borrow checker, потому что сейчас я очень много времени трачу именно на это.

Comments

[Сергей Горностаев]

факт, что большинство библиотек избегает &mut self в изменяющих что-то методах, звоночком к наличию большим проблем в языке

В современных языках иммутабельность - это дефолт, мутабельность должна быть неудобной.

[Василий Банников]

И в вопросе о borrow checker, разве не является тот факт, что большинство библиотек избегает &mut self в изменяющих что-то методах, звоночком к наличию большим проблем в языке?

&mut self значит, что в момент вызова этого метода - на структуру не может быть других ссылок. Естественно этого избегают по возможности почти всегда

[Имя]

Сергей Горностаев, иммутабельность это круто, но тут же по задумке если метод что-то изменяет, то должен быть &mut self, но есть куча библиотек которые везде использует &self, видимо по той причине, что следуя они этому правилу, то писать было бы невозможно.

[Василий Банников]

Имя,

но тут же по задумке если метод что-то изменяет, то должен быть &mut self,

Есть internal mutability.

видимо по той причине, что следуя они этому правилу, то писать было бы невозможно.

Если бы можно было бы изменять данные внутри структуры без &mut и без синхронизации, то тогда компилятор бы не смог гарантировать безопасность многопоточного кода.

[Имя]

Василий Банников, спасибо, что она есть, но разве это не выглядит как костыль?

[Василий Банников]

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

Answer 1

[Дмитрий Беляев]

Я знаю, что следует избегать всяких "продвинутых" штук из ряда связных списков, самореферентных структур и т.п.

Односвязные списки никаких проблем не доставляют (ну кроме того, что они плохо ложатся на процессорный кэш). Для двусвязных списков и самореферентных структур придётся использовать сырые указатели и unsafe.

Ещё я обнаружил, что создание больших структур, с методами, с кучей полей, обычно приводит к проблемам с borrow checker.

Borrow checker абсолютно плевать на размер структур. Это никак не связано.

А если в структуре будет ссылка или иное заимствование, то это гарантированные проблемы.

Нет ни каких проблем.

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

Одно другому никак не противоречит.

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

Не правильно.

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

Что-то делаете не так. Без конкретных примеров кода сказать сложно.

И очень часто в Rust программах, мне приходится идти на более уродливую архитектуру, дабы избежать проблем с (почти ненужным в однопоточном коде) borrow checker.

Что-то делаете не так. Скорее всего просто не понимаете borrow checker и пытаетесь писать на новом языке так, как привыкли в каком-то другом.

И в вопросе о borrow checker, разве не является тот факт, что большинство библиотек избегает &mut self в изменяющих что-то методах, звоночком к наличию большим проблем в языке?

О каком большинстве речь? Библиотеки используют мутабельные ссылки там где это нужно. Если метод действительно что-то меняет, то будет мутабельная ссылка ну и иногда будет использоваться interior mutability там где это необходимо. В языке нет проблем с мутабельными ссылками.

В общем, посоветуйте что-то что-бы помогало меньше бороться с borrow checker, потому что сейчас я очень много времени трачу именно на это.

Для начала понять его. Понять какую проблему он решает. Почитайте, что такое undefined behavior. Почитайте, что такое алиасинг.

Возможно где-то альтернативой мутабельным ссылкам будут Cell/RefCell в однопоточном коде и Mutex/RwLock в многопоточном.
Возможно если покажете примеры кода, где у Вас проблемы, то можно будет подсказать что-то более конкретное.

Comments

[Имя]

Что-то делаете не так. Без конкретных примеров кода сказать сложно.

Вот пример: Как раздельно инициализировать структуру?

[Дмитрий Беляев]

Имя, типичная проблема self reference структуры. Проблема с такой структурой в том, что её нельзя перемещать, так как ссылка станет невалидной. Rust защищает от этого. В тех же плюсах у Вас молча бы получился UB и удачного дебага потом...

Ну и решение подсказали там в ответе - использовать счетчик ссылок (Arc/Rc).

[Имя]

Дмитрий Беляев, понял, спасибо.

Answer 2

[Василий Банников]

Сложно сказать, чего стоит избегать, но точно не стоит избегать чтения растбука

Comments

[Имя]

Читал-читал

[Василий Банников]

Имя, тогда у тебя уже есть ответ на вопрос