Comments 16
Парочка полезных крейтов чисто для разработчиков:
- pretty_assertions — diff-ы в
assert_eq
- document-features — документирующие комментарии для фич
Например, реализация каналов (channels) данного крейта более производительная по сравнению с каналами std (по заверению разработчиков) и позволяет иметь несколько записывающих и несколько читающих потоков (multi-producer multi-consumer) в отлиии от std каналов, которые разрешают только один читающий поток (multi-producer single-consumer).
С версии 1.67 каналы из crossbeam завезены в стандартную библиотеку
И eyre пришел на смену anyhow для application level error handling. Не помню была ли аналогичная ситуация с thiserror.
Ещё из полезных вспоминается dirs/directories для работы со стандартными директориями (home, cache, config, runtime etc).
clap для cli (и structopt больше не нужен iirc)
А почему пришёл на смену? Чем он лучше?
Это форк с некоторыми дополнительными фичами. Лично я бы не сказал, что eyre
прям вытеснил anyhow
. Мы у себя по в проекте по прежнему используем последний, crates.io показывает 1,772,950 "недавних" скачиваний у eyre
и 14,839,310 у anyhow
.
Да, плохая фраза "пришёл на смену". anyhow
популярен на порядок больше чем eyre
и, возможно, реализует некоторые фичи из последнего (типа аналога EyreHandler
).
В целом eyre
поддерживает чуть больше кастомизации и имеет интеграцию с tracing
.
А не кажется вам, что все эти крейты-улучшатели кода на самом деле сильно повышают порог входа? И новичков в язык, и новых разрабов в проект.
Ведь там получается 2 пишем, 5 в уме. Кроме самого языка и стандартной библиотеки надо знать 320 крейтов, которые генерят новые методы и так далее.
Я не говорю о функциональности, например про numcpus, а о таких как tap
, strum
и подобных. Ведь это по сути расширение базы языка в каждом отдельном проекте по желанию разработчика.
Соглашусь, мне тоже не понятно как разные команды в проекте синхронят кодстайл, но в расте почти все крейты такие, по каждому надо доку курить отдельно
Соглашусь, что повышают порог входа, но:
Это библиотеки, а не фреймворки. То есть они все ещё действуют в рамках правил языка. В моём понимании, фреймворки отличаются от библиотек тем, что у них есть большой набор правил, которые нужно знать. То есть, чтобы использовать Spring в Java, нужно сначала понять, как его использовать, просто знать джаву недостаточно.
У них небольшая документация. То есть беглое ознакомление займёт максимум 5-15 минут.
Множество библиотек-улучшателей кода весьма популярны. Есть шанс, что даже новички будут иметь опыт работы с ними после пет-проектов, например. Тот же strum прям очень полезный крейт. Если бы создатели языка добавили способ генерировать такие же полезные методы енамам, как генерирует strum, то пришлось бы их учить как часть языка, а не библиотеки. То есть кажется, что от перемены мест слагаемыми ничего не поменялось бы.
Суммируя, мне кажется, что немного повышенная сложность - разумная цена за удобство.
Если бы создатели языка добавили способ генерировать такие же полезные методы енамам, как генерирует strum
Так может потому и не добавляют прямо в язык, что это перегружает его?
Думаю, что дело в другом: вот сериализация — вещь очень базовая и нужна всем, но если бы её поспешили добавлять в стд (про язык и не говорю), то это пришлось бы тащить ради совместимости "вечно". Помню до serde
была другая библиотека с каким-то очень банальным названием вроде rust-serialize или типа того. Некоторый переходной период библиотеки поддерживали и её и серде. В общем-то и сейчас не всех серде устраивает, поэтому такие вещи лучше не тащить прям в "ядро языка".
И тем не менее, серде все используют и не парятся, что это дополнительная штука, которую надо изучить. Удобство перевешивает.
const_format - позволяет конкатенировать и форматировать строки во время компиляции;
secret-value - скрывает из логов секретные значения;
inquire - для быстрого создания интерактивных консольных интерфейсов (полезно для демо или ручного тестирования);
parking_lot - примитивы синхронизации, более производительные и более гибкие, чем в std;
named_type - генерирует метод, возвращающий имя своего типа;
itertools - дополнительные методы для работы с итераторами;
governor - реализация рейт-лимитера;
flume - производительные mpmc-каналы;
arc-swap - делает атомарным обращение к содержимому Arc;
function_name - позволяет получить имя функции внутри неё;
tiny_file_server - очень простой файловый сервер;
truba - минималистичные акторы на базе tokio.
32 полезных Rust крейта, о которых вы могли не знать