Скорее компромис.

Для разработчиков языка это удобно, т.к. им нужно меньше думать об обратной совместимости и о дизайне стандартной библиотеки.

Но пользователям, имхо, от этого хуже. Когда ты используешь community-крейт, тебе нужно читать сорц, смотреть, как оно работает под капотом. Иначе откуда ты знаешь, какого качества там код?
Плюс надо следить за апдейтами этого крейта, чтобы не нарваться на проблемы при случайном обновлении.

С другой стороны, решение стандартной библиотеки может не подходить всем, и придётся писать доп.либы. Другой алгоритм структур данных (в полуха слышал, что в плюсах переписывают строку все кому не лень), другой gui (java с её swing и fx), другой парсер (стандартный парсер json в питоне и сторонний, который в несколько раз быстрее)

Но тебе надо читать сорцы и стандартной библиотеки, чтобы знать как оно работает под капотом и ты не знаешь, не накосячили ли там разработчики Rust-а и подходит ли тебе их решение

Т.е. есть serde - это крейт по умолчанию для сериализации и десериализации. А есть borsh - для более спецефичных случаев. В чем я, как разработчик выиграю если один из них будет в std?

Ну и обновления то не случайные, ты же сам их обновляешь в Cargo

Т.е. я не про то, что это топ решение, все так делайте и вообще только так и надо, но вполне себе удобное решение. Особенно в no-std окружение

> С другой стороны, решение стандартной библиотеки может не подходить всем, и придётся писать доп.либы.

Такие кейсы встречаются не так часто. И само наличие стабильной и качественной стандартной библиотеки — большой плюс для разработчика.

>  плюсах переписывают строку все кому не лень

Сейчас это не так актуально, скорее, это было распространено, когда std::string был cow.

> Но тебе надо читать сорцы и стандартной библиотеки, чтобы знать как оно работает под капотом и ты не знаешь, не накосячили ли там разработчики Rust-а и подходит ли тебе их решение

В большинстве случаев — не надо, пока я не столкнусь с конкретной проблемой в стандартной библиотеке.

Но мой поинт в том, что я могу доверять разработчикам языка и просто использовать их код. В то время как коммьюнити-трейты могут быть не такими качественными. Если же есть несколько реализаций нужной мне фичи, придётся выбирать наиболее подходящую.

И, не знаю, насколько это актуально для раста, но хорошо, когда дизайн библиотеки проектируется в одном стиле. Это упрощает её изучение и использование.

> В чем я, как разработчик выиграю если один из них будет в std?

Это спорный вопрос, что должно входить в стандартную библиотеку. Я не уверен, нужна ли там сериализация, и это всегда решение разработчика языка.

> Особенно в no-std окружение

А такое часто встречается на расте? Где? Эмбед?

Короче, как сделали так и ладно

- Так дизайн почти всего Rust - в одном стиле. Тут один гайдлайн на всю экосистему 🙃 (пока еще)

- Я просто не доверяю никому при написание кода. Есть популярные крейты, есть непопулярные, но в std библиотеке ровно так же, но не очевидно. В стороннем крейте можно хоть посмотреть статистику на crates.io

- Ну просто serde используют все. Он по факту стандартное решение, но я правда не могу придумать зачем он был бы нужен (даже на уровне интерфейсов) в std бибилотеке.

- Эмбед, спецефичные блокчейны всякие, HFT итд

Я конечно не ожидал, что randint в стд раста не будет...

Да это же спасает, когда делаешь что-то там где нет источника для случайности
Ты тогда подключаешь rand с нужной фичей и у тебя хотя-бы мок на этот рандом

> Тут один гайдлайн на всю экосистему

Можно линк?

https://doc.rust-lang.org/1.0.0/style/

Ну и прочие гайдлайны на doc.rust-lang.org + некоторые уточнения в rustbook-е.

На предыдущей работе у меня был коллега, который чтил их как закон, так я ими наелся на PR-ах.

Ага, спасибо. Чем-то напоминает core guidelines в крестах.

Ну на моем опыте в крестах все очень по разному на буквально каждом проекте (не говоря уже о C)

На Rust все одинаково везде (пока), где есть хоть один Rust Senior

Ну да, есть такое.

Мне кажется, или clangd неправильно исправляет варнинг насчет скобок в condition+assignment?
Было:
if (fd = open(fifopath, perm) == -1) {
стало:
if ((fd = open(fifopath, perm) == -1)) {

в целом, смысл не поменялся

в fd попадает 1 или 0

Выглядит как баг, да

но не файловый дескриптор

у сравнения приоритет выше чем у присваивания