Ещё один, если можно, отдельный вопрос. Более концептуальный. У меня

реальная работа идёт с моделями, которые очень ООПшные по своей структуре. Конвертируя в игровые термины(так забавнее): есть орк. У орка есть кол-во здоровья и монет. Орк бывает воин, пивовар и царь. Воин может награбить монет, отдать их пивовару, а царь берёт налог. При этом у всех есть кол-во здоровья и монет. И каждый может получить урон и помереть, если здоровье < 0. Воин бывает с топором и с луком. Ну, вы поняли идею.
Я учу про трейты, но не понимаю вот что: даже с реализациями по умолчанию, мне всё равно нужны в каждом типе одинаковые переменные для здоровья и богатства. Как избегать необходимости прописывать все переменные вручную в каждой структуре? В реальных задачах там же целый лес получится. Я знаю, что наследование можно заменять агрегацией. Создать структуру "Тело орка" со здоровьем и богатством, и включать её как переменную в структуры "ОркВоин" и "ОркЦарь". Так и предполагается поступать в Расте?

Entity component system. Вот это можно почитать: https://ianjk.com/ecs-in-rust/

Спасибо, это интересно. Прочитал до середины второй части, дальше повис. Но общую идею я понял, хотя и не понял, почему реализовано именно так. Создаётся суперобъект ,который может иметь комбинацию любых свойств. Только вместо массива struct c полями Option, создаётся массив массивов Option. Зачем так - я и не понял. Но всё равно это же типичная реализация ООП для Си. Где-то хорошо сработает, а мне придётся слишком много Option<None> хранить. Как Option<u8> выглядит в памяти? Один байт на флаг Some/None и один на значение?

да, байт на флаг и байт на значение но есть NonZeroU8, для него Option<NonZeroU8> занимает один байт