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

Принцип наименьшего удивления, если присмотреться, субъективный в своей основе, в том смысле что не заглядывая в головы программистов, и в то для решения каких задач они применяют свои головы, невозможно говорить об их удивлении. В случае struc.field = some_funny_call(), программист может не помнить о том, что field занимает 1 бит. Или он может не знать об этом, потому что это поле ещё вчера утром занимало 4 байта, но вчера днём его коллега занимался оптимизациями расхода памяти, заметил, что иногда одновременно существуют миллионы инстансов этой структуры, и упаковал её покомпактнее.

А если программиста удивляет сохранение состояния, то... не, это плохо, но если есть какие-то конкретные предложения о дизайне языка, которые могут снять это удивление, то можно поговорить предметно. Если же нету, то значит с этим просто надо жить.

> Я правильно понимаю, что Rust в основе своей функциональный с императивными возможностями?

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

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

Взять к примеру PathBuf:

fn make_directories(prefix: &str) -> Result<(), io::Error>
    let mut pathbuf = PathBuf::new();
    pathbuf.push(prefix);
    pathbuf.push("bin");
    // работаем с путём $prefix/bin
    pathbuf.pop();
    pathbuf.push("share");
    // теперь с путём $prefix/share
}

Это не функционально от слова совсем. Но зато не надо под каждый путь выделять свежий кусок памяти из кучи.

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

В rust'е проблема с bool'ом не существует не из-за функциональности/императивности, а потому как bool -- это тип, который занимает 1 байт и принимает одно из двух значений {true, false}. Положить его в однобитную переменную просто так не выйдет, придётся писать обвязку, которая будет конвертать true/false в бит и обратно. И указатель в bool-переменную тоже положить не удастся, потому что он указатель, а не bool. Впрочем, у указателя есть метод is_null(), который недеструктивно конвертает указатель в этот самый bool. Короче эти проблемы решаются строгостью типизации.

А с sun'ом будет так, как его API скажет. Скажет API, что надо залочить sun, чтобы добраться до метода does_sun_shines_now, значит ты не сможешь вызвать этот метод, не залочив sun. И это можно сделать через лямбду, но можно и так -- запросив объект соответствующий залоченному Солнцу, и работая с ним с императивном стиле. Но это будет зависеть от API: как его разработчик решит делать, так и будет.