> Это типа отношение has?
> О какой "горизонтальной композиции" идет речь,И отношение типа has тоже. Но мерками ООП невозможно оценивать не-ООП подход к программированию. Как ты опишешь монад в ООП терминах? Монады можно использовать в ООП программе, но нельзя описать их в ООП терминах.
Раст -- это статическая типизация, это параметризованные типы, это ближе к Ocaml, Haskell и C++, чем к Java и C#. Я тут читал статью-туториал про комбинаторы парсеров[1] -- вынос мозга. Правда в процессе развития событий в туториале rust'у стало плохо, когда дело дошло до парсинга атрибутов со значениями, а когда парсинг атрибутов был объединён с парсингом тега, то rust'у просто сорвало планку, потому что создаваемые рекурсивные типы оказались слишком безумны в своей вложенности, и автору пришлось переходить к Box<dyn Trait>, для того чтобы ценой некоторых (несущественных в том случае) потерь производительности в рантайме обойти ограничения компилятора как по памяти, так и по времени компиляции.
Понятно, что парсер можно написать классически на конечном автомате, и не нужно никаких виртуальных вызовов для этого, но я не к тому, что парсеры надо писать именно так, а в ответ на вопрос "что такое горизонтальная композиция". В туториале пример тому. Но если это действительно интересно, я бы рекомендовал повтыкать в ocaml или в haskell. Или в rust, но rust насоздаёт тебе дополнительных проблем изучения, которые напрямую не относятся к горизонтальной композиции, типа лайфтаймов с borrowing'ом. Или в "современный" C++[2]. И я в целом рекомендую это сделать, даже если это не очень интересно: знать другие подходы к программированию полезно, потому что это даёт возможность думать о создаваемом коде несколько иначе.
[1] https://bodil.lol/parser-combinators/
[2] https://github.com/rigtorp/awesome-modern-cpp
> и чем это лучше упомянутых ранее языков?
Больше статических гарантий относительно кода. Работает быстрее. Гибче, то есть не прибито гвоздями к ООП и даёт больше выразительных возможностей, для описания своего замысла.
