Задать вопрос
mrjbom
@mrjbom

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

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

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

В общем, посоветуйте что-то что-бы помогало меньше бороться с borrow checker, потому что сейчас я очень много времени трачу именно на это.
  • Вопрос задан
  • 128 просмотров
Подписаться 1 Простой 6 комментариев
Пригласить эксперта
Ответы на вопрос 2
bingo347
@bingo347
Crazy on performance...
Я знаю, что следует избегать всяких "продвинутых" штук из ряда связных списков, самореферентных структур и т.п.
Односвязные списки никаких проблем не доставляют (ну кроме того, что они плохо ложатся на процессорный кэш). Для двусвязных списков и самореферентных структур придётся использовать сырые указатели и unsafe.

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

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

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

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

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

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

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

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

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

Войдите, чтобы написать ответ

Похожие вопросы