Потому что "привносят" функционал, отличаются от интерфейсов, которые по-идее, лишь объявляют сигнатуры. С другой стороны в том же .NET уже появились интерфейсы с функционалом по-умолчанию.. Всё смешивается постепенно. Хотя я сам старался держать в голове что трейт - это интерфейс, чтобы поначалу не забыть, что это вообще такое... Потом привык. )))
Встроенное тестирование, встроенное документирование - понравилось, что подумали обо всём и позаботились. Но сложновато для входа, особенно, если это первый язык.
Вишенкой на торте, помню, было, когда узнал, что текст примера вызова метода перед его объявлением тоже тестируется, чтобы он реально соответствовал тому, что делает метод.
А там для каждой странной на первый взгляд концепции нужно объяснять почему так, а не по другому. Поэтому наверное сложно. То есть тебя водят по сравнениям раста с С
я чуть опечатся, но потом поправил "трейты НЕ интерфейсы". А гибче потому что, например ты можешь любому типу прикрепить поведение даже если у тебя нет доступа к нему (бибилиотечный тип) и он будет отлично коннектится с твоей системой. интферфейсы в джаве или шарпе такого не могут, ты не можешь изменить цепочку наследования библиотечного класса, а следоавтельно вынужден плодить классы обертки на каждый чих и желательно следуя заветам солид, что бы ненароком не отстрелить себе ногу
Я тут так подумав, що використовувати блоки try-catch в тілі функції — це погана практика. Шкодить читабельності, couples business logic with data validation. Якщо подумати обробка помилок — це ж валідація вихідних даних. Краще обгортати бізнес логіку декоратором, так якось чистіше буде