Всё это, безусловно, интересные теоретизирования, но хотелось бы рассмотреть конкретные примеры. Споткнуться в системе типов раста можно много в каких местах, я же покажу только один случай, но зато очень наглядный, который раскрывает всю суть раста в полной мере. Этот пример не про clone, а немного про другое. Я максимально упростил пример, оставив только суть. Предметная область меня не сильно интересует, однако в реальной практике такое случается довольно часто. Не просто же так я этот пример "придумал".Итак, задача: хочу написать простой тип Grouper, который будет группировать значения по определённому ключу и будет иметь два основных метода:
// Устанавливает ключ текущей группы
fn set_current_group(&mut self, current_group: String)
// Вставляет значение в текущую группу, вернёт true в случае успешной вставки
fn add_to_group(&mut self, value: i32) -> bool
Реализация: https://play.rust-lang.org/?version=stable&mode=debug&editio...
И правда, всё просто и даже никаких лайфтаймов не нужно. Круто!
Получившийся тип определяется так:
struct Grouper {
groups: HashMap<String, Vec<i32>>,
current_group: String,
}
Но такая реализация далеко не самая эффективная. Можно заметить, что в методе add_to_group мы каждый раз ищем один и тот же ключ (current_group) в хешмапе. Всё же, мы пишем на производительном расте, а не на каком-то там медленном питоне. Хочется закешировать текущую группу и обращаться к ней напрямую. Попробуем это как-то изобразить:
struct Grouper {
groups: HashMap<String, Vec<i32>>,
current_group: Option<&'huh? mut Vec<i32>>,
}
Вот тут и появляются те самые пляски и приседания. Реализовать подобную структуру без костылей просто невозможно. Ну, конечно, наверняка найдутся растеры с 20 лет опыта за спиной и покажут как правильно решить подобную простую задачу, которая в других языках вообще не явлется проблемой. С удовольствием посмотрю и может тогда, наконец, прозрею и познаю все тайны безопасного программирования. Ну а пока влезу в шкуру растера и попробую всё же "решить" эту проблему. Предлагаю несколько вариантов:
* Просто забить. И таак сойдёт..
Довольно разумное решение, которое оставляет за собой много философских вопросов: а зачем мне вообще в таком случае нужен раст? Какие проблемы он решает? Не даёт мне писать производительный код? Ради чего? Ради т.н. "безопасности"? Стоит ли это того?
* Вспомнить "свои старые привычки", то есть просто использовать RefCell. Решение: https://play.rust-lang.org/?version=stable&mode=debug&editio...
Ну то есть, такие полезные типы как Rc и RefCell всё же бывают нужны. Не просто так они добавлены в std. Да, тут растеры будут уверять вас, что их нужно использовать редко и только в действительно "редких" случаях как этот. Только с каких пор простое кеширование значения стало чем-то редким? Ну хорошо, всегда можно найти себе оправдание всякими умными словами "преждевременная оптимизация" (то есть вернуться к первому решению), но поймите, к примеру в C++ это вообще не является проблемой. Иногда, и довольно часто, нужно написать такой код и от этого не уйти. Тем более, даже так это решение не самое оптимальное, ибо RefCell это по своей сути динамический бороу чекер, который проверяет возможность досупа к значению в рантайме, то есть имеет ненулевую стоймость, в отличии от простого указателя. К слову об этом, рассмотрим третье решение.
* Да, unsafe! Решение: https://play.rust-lang.org/?version=stable&mode=debug&editio...
Самое сложное из всех представленных. Осмелиться на такое потребует от вас небывалой стойкости духа. Мне приходилось постоянно убирать пот со лба полотенцем, пока я писал это решение, стараясь нигде не разыменовать null и не вызвать UB. Конечно, поскольку этот код использует unsafe, полагаться на его корректность никак нельзя. Я уверен, там куча багов, на которые мне конечно же укажут прошаренные растеры и заклинят меня удалить компилятор и больше не производить на свет подобную ересь.
* Использовать 100% safe и zero cost абстракцию, которая решает данную проблему и требует всего лишь подрубить дополнительную зависимость с crates.io
И правда, зачем делать полноценный язык программирования, если можно сделать недоделку и предоставить удобнейший магазин костылей на любой вкус?
* А может ну его? Почему бы просто сразу не писать на питоне? Решение: https://www.online-python.com/A4H621D8Og
Иронично, но написать оптимальное решение можно без всяких приплясок даже на питоне!
Думаю, это самое лучшее решение из всех приведённых. Да, это будет не так быстро, но если нужна скорость то почему бы не взять C++? Опять же, никаких подобных проблем в C++ нет. Конечно, каждый язык имеет свои слабые стороны, но хотя бы они, в отличии от раста, не затрагивают существенную часть повседневных нужд и доказали временем свою состоятельность. Они позволяют писать рабочий код, без пафоса повсеместной "безопасности", а просто код, который работает. Да, не идеально, но он работает. Баги есть и будут везде, в том числе и в расте. Я расстрою растеров, но волшебства не существует, простите. Чем раньше вы это поймёте, тем меньшее разочарование в конечном счёте испытаете.
Для остальных хочу сказать, каждый раз, когда любители раста рассказывают вам сказки про "не будет ни лишних clone, ни проблем с лайфтаймами", не стоит сразу смеятся им в лицо. Эти люди живут в своём "безопасном" мире, а для них вы лишь недалёкий неуч с опеннета, не важной какой опыт у вас за спиной. Отнеситесь с пониманием. Человеку свойственно умнеть со временем, узнавая что-то новое. К сожалению, не у всех это получается, но терять надежду не стоит. Вот даже в Linux их приняли, лишь бы поменьше обижались. Того гляди, начнут учить нормальные языки вроде Си и научатся писать нормальный код, без тонны костылей и подпорок.
