Во, еще бажина раста нашлась. Ну как всегда некорректное поведение borrow checker-а. match self.cash.do_transaction(resource_id, |resource| { match resource.cashed { Some(ref mut cashed_resource) => { let create = self.resource_heap.logical.create_resource(cashed_resource.data.deref()); closure requires unique access to self but self.cash is already borrowed из-за боровинка ОТДЕЛЬНОГО поля self.cash, причем НЕМУТАБЕЛЬНОГО и мутабельного бороввинга ОТДЕЛЬНОГО поля self.resource_heap уже мутабельного ИМХО, именно из-за некорректного, нелогичного поведения борров чеккера, раст никак не может взлететь. Ох, а сделать в расте граф, так вообще застрелиться!

вот и я им тоже говоря что раст хуйня. КАК ТАК БЛЯТЬ. У ТЕБЯ ЕСТЬЬ НЕМУТАБЕЛЬНАЯ ССЫЛКА НА СЕЛФ А ТЫ НЕ МОЖЕШЬ ВЗЯТЬ ОДНО ПУЛЕ НЕМУТАБЕЛЬНО А ДРУГОЕ МУТАБЕЛЬНО. ПЗДЦ БЛЯТЬ. БЕЗ АНСЕЙФА НА РАСТЕ НЕ ПОПРОГАТЬ. ущербный игрушечный язык!

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

переменные должны жить, пока они используются

переменные должны жить, пока они используются

Потому что логично unsafe нужно использовать, когда мы лезем куда-то в железо или извращаемся, но тут мы вынуждены обманывать borrow checker, который обожает борровить всю структуру в геттерах вида fn get_a_mut(&mut self) -> &mut A и, видимо, еще и closure так себя ведет тоже. может кто-то знает, как сделать такие геттеры более нормальными? copy, clone, assign не предлагать, нужно именно вырывать поле из из структуры. Зачем эти геттеры? А как ты сделаешь в расте что-то вида наследования? заюзаешь определенный трейт для схожих объектов.

https://github.com/rust-unofficial/patterns/blob/master/patterns/compose-structs.md оффициальный паттерн тм от кор тим раста, нужно структуры бить на подструктуры и методы объявлять для них

https://github.com/rust-unofficial/patterns/blob/master/patterns/compose-structs.md оффициальный паттерн тм от кор тим раста, нужно структуры бить на подструктуры и методы объявлять для них

официальный паттерн в репозитории под названием rust-unofficial )

и я хочу менять поля в ней как угодно

Nick Cameron nrc Research engineer at Mozilla. I hack on @rust-lang.

контрибутор

множество вариантов "кау-богу-угодно" не мапится на множество вариантов "безопасно".

Пример https://play.rust-lang.org/?gist=0d4d632d0f4d3d9b135e377b496d6ec3&version=stable

Раст вроде первый язык с борров чекером. И вроде все хорошо, когда мы юзаем всякие i32, и без классов жить легко, и логично, а на деле вылезает много острых подводных камней. Либо еще борров чеккер может заставить тебя выносить из блоков кода, копировать и тд, тем самым только уменьшая логичность и читабельность. Хорошо, что в расте хоть можно match self.field { Some(ref mut field) => do ref mut field @ None => *field=Some(..) } Хотя для этого кажись функция была некая.

https://play.rust-lang.org/?gist=81cffeba68d0d216b511b919ca6b3d26&version=stable

Раст вроде первый язык с борров чекером. И вроде все хорошо, когда мы юзаем всякие i32, и без классов жить легко, и логично, а на деле вылезает много острых подводных камней. Либо еще борров чеккер может заставить тебя выносить из блоков кода, копировать и тд, тем самым только уменьшая логичность и читабельность. Хорошо, что в расте хоть можно match self.field { Some(ref mut field) => do ref mut field @ None => *field=Some(..) } Хотя для этого кажись функция была некая.

Ну вообще-то ООП во многом верно. Ну структуры, поля, это же логично. А вот наследование да, кривая штука, композиция лучше, правда в расте она крайне неудобная из-за тысяч геттеров и сеттеров. Уход от такого "простого" ООП просто неразумен, я даже не представляю, как можно, например, сделать текстуры/буферы и работу с ними без ООП и тем более на функциональщине(сам потому не шибко её знаю) Твой вариант не универсален. А если у нас 5 полей, будем добавлять get_ab get_abc и тд? Просто криво =)

тогда зачем структуры с синтаксисом s.a вообще? можно было бы как в луа без классов обойтись(там только массивы)

Проблема с ООП заключается в том, что этим термином сейчас называют все что угодно. Привязал методы к хэшу в Perl — ООП. Наплодил в Erlang процессов, которые обмениваются сообщениями — ООП. Объявил пару-тройку функций для работы с какой-то структурой, и снова ООП. Никто уже толком не понимает, что именно сей термин означает, но все с умным видом его произносят. Стыдно же не знать! ... Лично я уже перестал понимать, что такое ООП и вообще стараюсь выкинуть этот термин из своего лексикона. Во-первых, потому что я не понимаю, о чем идет речь. Во-вторых, потому что мой собеседник тоже не понимает, и мы оба не понимаем о чем-то своем. eax.me/adt-and-traits/

тогда зачем структуры с синтаксисом s.a вообще? можно было бы как в луа без классов обойтись(там только массивы)

ИМХО, GC это кривая штука. GC лишь обходит проблему, но не решает её. Например, в жабе нужно закрывать файлы вручную, а если тровишь эксепшн, когда мутекс открыт, то.. он и не закрывается. Ну во всяком случае, как я слышал(жабу я потому и не юзаю). RAII куда логичнее. Например, раст закрывает файлы и отравляет мутексы. Второе очень полезно для написания чего-то живучего.