Но процмакросы бы были нормальными

ну честно я лимс изучал в универе когда ваще нихера в нм не шарил

когда понял что это было он уже в прошлом оказался

так что н езнаю его возможностей

Процмакросы в расте это тихий ужас
Их пишут просто от полной безысходности

Начиная с необходимости создавать крейт для каждого процмакроса и заканчивая имплементацией парсинга и псевдоцитирования на стороне библиотек
И само псевдоцитирование тоже такое, потому что синтаксис сложный, его сложно генерировать

Хм... всё познаётся в сравнении. Мне вот после Го вообще топ. Вот там с кодогенерацией были(есть?) вообще конкретные проблемы. Ни либ (сейчас мб подвезли уже), вообще нихера.

А как ещё лучше?

В PHP8 назовозили фич дофига. Половина синтаксически выглядит Rust'ом: match, аттрибуты...

Вот тебе и тренды)

а поддержки юникода как кот наплакал

я тебе скажу больше это уже работает!!

то есть ты когда пишешь код, ты же как–то его тестируешь?

у меня до недавнего времени весь тестировочный код почему–то всегда сразу где–то в какой–то демке, примере или типа того примере или типа того находился рядом

сейчас начал сразу делать все в тестах. то есть сочинил какую–то структуру с неочевидным поведением? пока я ее пишу, я сразу захуярил тест, который в пассивном режиме проверяет какие–то ключевые значения по таблице, а в активном режиме позволяет зондировать чето конкретное и user–defined через терминал.

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

как я уже говорил, есть две вещи которые ты можешь мерять. это ∆t и ∆d/∆t в принципе ничего третьего не дано. тест–suite в го, например, уже умеет считать аллокации/ ему можно давать инфу о пропускной способности, а так же вводить user–defined метрики.
это полезно потому что если ты хочешь изменить какой–то функционал, то ты знаешь сразу как безопасно (я знаю вам нравится это слово!) и главное четко это сделать:
1. ты выделяешь функционал в самостоятельную функцию или самостоятельную структуру с множеством функций
2. создаешь новую структуру для улучшенного функционала
3. пишешь состязательный бенчмарк где меряешь буквально все, что можешь измерить в разных сценариях.
4. cмотришь результаты
5. сильнейший побеждает

чуваки

как пофиксить?

единственный сайд–эффект это то, что такая методология быстро распидорасит тесты до 10х размера в сравнении с самим кодом, который он тестирует. макака будет в восторге, потому что теперь он сможет проецировать на коллег что он ответственный программист, но понравится ли это его коллегам–шимпанзе? сложно сказать. я лично никогда не был в восторге от тест–выскочек которые пихают свои тесты по всем щелям, в основном из–за тупости, сопряженной с таким фанатическом поведением. тупостью уровня assert(add(2, 2), 4) тупостью которая просто мусорила мое внимание. да синтетические тесты это полная хуета, слава богу можно писать настоящие тесты, по которым можно проследить ход твоих мыслей, как ты задумал и что ты делаешь с кодом пока его пишешь и т.д. то есть в этом красота что git подобную информцаию преподносит очень красиво, с визуализацией и т.д. но тем не менее, кодеры почему–то стесняются использовать тесты.