> rust прикручивается к чему угодно. Сложнее чем C, потому что по-любому придётся
> на rust'е крафтить адаптер -- внешний API для библиотеки,

Ну и вот это вот - не, на плюсах так тоже делают, но вообще это грабли. Получаются (полу)замкнутые экосистемы которые между собой не дружат.

> Вот это может быть. В rust библиотека -- это что-то гораздо менее
> значимое, чем в C++. В C++ если библиотека, то значит что-нибудь
> весомое, над чем работали годами несколько человек.

Не обязательно. Но все-таки это логически завершенная сущность. А несколько лет работы означают что она хоть кем-то хоть немного протестирована, блин, и не является откровенной домашкой по информатике очередного студебеккера.

> В rust пакет может, например, состоять из нескольких функций/типов работы со временем,

И без нескольких лет - можно будет узнать много нового и интересного. О времени, направлении его хода, числе секунд, дней в году и проч. На своей шкуре! Если это лаба по информатике - сработало у препа и черт с ним потом! А если в продакшн? Вылавливать за студебеккером все глюки наивного чукотского юноши, когда leap second накинут или daylight saving time активируется или ntpd время подбросит? В этом месте мы узнаем что качество софта не достигается за 5 минут.

> или сводиться к генератору случайных чисел, или быть ещё чем-нибудь,

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

> что делается за два вечера одним человеком.

Ты привел пару отличных примеров того что делается за два вечера одним человеком. Я воспользовался ими чтобы показать как это потом будет работать на практике, ибо плавали-знаем. Бонусом ты показал кто ЯПом пользуется и что ожидать... :\

> В этом есть свои плюсы, но публиковать здесь
> все новинки с crates.io, конечно же, далеко не лучшая идея.

Вообще, такой карго-культ как мне кажется чреват. Если безбашенно подключать wannabe-либы писаные студнями за вечер, там будет глюк на глюке, а пара либ еще систему хакнет заодно при случае. Потому что автор только вчера появился и накатал ништяк. Код толком никто прочитать еще не успел, на чем кто-нибудь хитрый попробует получить профит, например. Как со всякими pip и npm. Интересно, это карго содержится столь же хипстерско-раздолбайски?

> что есть вероятность того, что я когда-нибудь задумаюсь об его использовании.

Мне когда-то была бы полезна подобная штука, но - не в таком виде. Не думаю что хипстеры с горящими глазами резко переписут кондовый с++ бинарь на мегабайты, в котором многие человекогоды.

> На самом деле я уже задумался об этом -- поверх этой
> штуки можно же сделать fuse-файловую систему,

Вообще вариант. Fuse к тому же вроде достаточно кроссплатформенный.

> Перегнать Claws-Mail на защищённое храненение почты, не влезая в код ClawsMail вообще?

Проще наверное файлуху шифрованую сделать.

> Или может для того, чтобы создать решение, которое позволит пользователю,
> работая с любой фс, шифровать выбранные директории, храня при этом ключи
> на флешке или сталкиваясь с запросами паролей при первой попытке доступа?

В андроиде половину этого сделали, собственно. Цепляют шифрованные блочные девайсы с юзерскими данными в диры. Немного зоопарк блочных девайсов но работает и так оверхеда мало.

> минут бездействия, а для приложений прозрачно и выглядит как заурядная директория.

Если честно, мне такое будет проще настроить средствами пингвина, почти без програмизма или с каким-то совсем минимумом оного. И наверняка там продолбов будет в 20 раз меньше.

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

Это да, хорошие размышления. Но половину уже придумали раньше и даже активно используют.

> писать код нагруженный криптографией не будучи экспертом в криптографии -- это
> совершенно не блестящая идея, но opensource библиотечка на github'е (даже если
> написана не экспертом), имеет достаточно шансов попасть в поле зрения экспертов

Экспертов обычно к сожалению хватает на аудит core алгоритма. Остальное - не их. И вот там случаются ляпы. Крипто вообще штука очень деликатная, со множеством неожиданностей. Я бы сказал что там простое API и донесение как им правильно пользоваться очень важно. Как у DJB в TweetNaCl. Там трудно ошибиться даже дилетанту. А сделай api и алгоритмику как openssl - и в нем наломает дров кто угодно, на любом ЯП. Потому что для понимания что оно там делает и какие есть способы лажануться надо очень серьезно интересоваться областью. А это не про типового прикладника, которому это до кучи надо и он думает что за него дескать авторы либы подумали. А порой оказывается что фиг. И вот заметь, выдержка openssl сколько-то лет показала что это гэ. Отрицательный результат - тоже результат.

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

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

> То есть, после того как я прочитал новость, я, по-любому, никогда не буду писать код,
> шифрующий файлы или sql-базы данных. Даже если мне это понадобится, я
> свалю всю работу на Zbox, вне зависимости от того, на чём там я буду писать -- на
> rust, C, python, lisp или чём угодно ещё.

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

> Я не могу просто полагаться на своё мнение, которое сводится к
> тому, что новость была мне полезной.

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