Как стать автором
Обновить

Комментарии 16

Парочка полезных крейтов чисто для разработчиков:


Старался привести пример крейтов, про которые сложно загуглить, если ты о них не знаешь. Мне кажется, что byteorder будет несложно найти в гугле, если возникнет потребность в little/big endian.

Например, реализация каналов (channels) данного крейта более производительная по сравнению с каналами std (по заверению разработчиков) и позволяет иметь несколько записывающих и несколько читающих потоков (multi-producer multi-consumer) в отлиии от std каналов, которые разрешают только один читающий поток (multi-producer single-consumer).

С версии 1.67 каналы из crossbeam завезены в стандартную библиотеку

Но mpmc-версия канала в стандартной библиотеке всё равно отсутствует (точнее, присутствует — но приватна).

И 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 и подобных. Ведь это по сути расширение базы языка в каждом отдельном проекте по желанию разработчика.

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

Соглашусь, что повышают порог входа, но:

  1. Это библиотеки, а не фреймворки. То есть они все ещё действуют в рамках правил языка. В моём понимании, фреймворки отличаются от библиотек тем, что у них есть большой набор правил, которые нужно знать. То есть, чтобы использовать Spring в Java, нужно сначала понять, как его использовать, просто знать джаву недостаточно.

  2. У них небольшая документация. То есть беглое ознакомление займёт максимум 5-15 минут.

  3. Множество библиотек-улучшателей кода весьма популярны. Есть шанс, что даже новички будут иметь опыт работы с ними после пет-проектов, например. Тот же strum прям очень полезный крейт. Если бы создатели языка добавили способ генерировать такие же полезные методы енамам, как генерирует strum, то пришлось бы их учить как часть языка, а не библиотеки. То есть кажется, что от перемены мест слагаемыми ничего не поменялось бы.

Суммируя, мне кажется, что немного повышенная сложность - разумная цена за удобство.

Если бы создатели языка добавили способ генерировать такие же полезные методы енамам, как генерирует strum

Так может потому и не добавляют прямо в язык, что это перегружает его?

Думаю, что дело в другом: вот сериализация — вещь очень базовая и нужна всем, но если бы её поспешили добавлять в стд (про язык и не говорю), то это пришлось бы тащить ради совместимости "вечно". Помню до serde была другая библиотека с каким-то очень банальным названием вроде rust-serialize или типа того. Некоторый переходной период библиотеки поддерживали и её и серде. В общем-то и сейчас не всех серде устраивает, поэтому такие вещи лучше не тащить прям в "ядро языка".


И тем не менее, серде все используют и не парятся, что это дополнительная штука, которую надо изучить. Удобство перевешивает.

Поддерживаю. В разделе Preface я упямянул, почему не всегда уместно добавлять функционал в стандартную библиотеку. Раньше был популярен подход "batteries included". В современном мире уместно многие вещи поддерживать как third party зависимости.

const_format - позволяет конкатенировать и форматировать строки во время компиляции;
secret-value - скрывает из логов секретные значения;
inquire - для быстрого создания интерактивных консольных интерфейсов (полезно для демо или ручного тестирования);
parking_lot - примитивы синхронизации, более производительные и более гибкие, чем в std;
named_type - генерирует метод, возвращающий имя своего типа;
itertools - дополнительные методы для работы с итераторами;
governor - реализация рейт-лимитера;
flume - производительные mpmc-каналы;
arc-swap - делает атомарным обращение к содержимому Arc;
function_name - позволяет получить имя функции внутри неё;
tiny_file_server - очень простой файловый сервер;
truba - минималистичные акторы на базе tokio.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации