> нет нормального ООП, ведь в new age программерских сектах принято хаять ООПЧто ты называешь "нормальным" ООП? Как в java? Как в C++? Как в Haskell? Как в gtk? Какой из ООП нормален?
ООП -- это не язык, ООП -- это подход к программированию. Тебе никто не запрещает в rust'е писать ООП программы. Так же как никто тебе не может запретить писать ООП код на C или на ассемблере. Но при этом rust даёт тебе dyn Trait и Deref/DerefMut, то есть тебе не нужно возиться с vtable или её аналогом вручную.
> крайне отвратительный пакетный менеджер. Нет предсобраных пакетов. Вместо этого это говно пересобирает всё это. Правда пересобирает довольно быстро, но это пока в зависимостях нет чего-нибудь тяжёлого.
То есть единственная претензия к пакетному менагеру, что он не умеет бинарные пакеты таскать? По-моему, это недостаточная причина для того, чтобы характеризовать пакетный менагер как "крайне отвратительный".
> предлагается ставить язык с какого-то говносайта путём curl | bash вместо использования пакетов дистрибутива. В дистрибутиве есть какие-то пакеты, испражнённые мамонтом, но пакеты раста ими не соберёшь: в коде по-видимому захардкожено, что некоторые фичи языка можно использовать только на найтли, а большинство пакетов как раз зависит от пакетов, зависящих от ночных фич.
Да, это так. Проблема в том, что в nightly есть куча фишек, которые ещё не стабилизированы, но вкусны настолько, что растоманы не могут пройти мимо. Когда стабилизируется async/await, я подозреваю, завязки на nightly станет меньше. С дистрибутивами же, проблема в том, что использование системного пакетного менагера для установки rust'а и его библиотек, довольно затруднительно. Особенно если речь идёт о nightly. Можно, но сложно. Придётся разобрать rustup.sh на части, и написать реимплементацию к нему, каким-то образом отобразив на системный пакетный меганер его способность держать много toolchain'ов в системе одновременно (а их может быть много: количество версий rustc помножить на количество платформ и на количество архитектур), переключаясь между ними по любой прихоти. То есть тут не удастся тупо написать .deb, придётся строить целую инфраструктуру для rust'а и его библиотек. В gentoo, например, есть база для такой архитектуры, тут есть eselect, но eselect -- это не то, что нужно разработчику: я же не буду делать sudo eselect, каждый раз, когда я решаю пересобрать свой проект под другую архитектуру?
И это проблема, которую mozilla не может решить. Её могут решить лишь индивидуальные дистрибутивы, решая задачи решаемые rustup'ом так, как они считают нужным их решать. Они не считают нужным.
> пакет для Qt какая-то недоделанная альфа
Оу, в cargo.io очень много недоделанных альф. Местами настолько недоделанных, что встаёт вопрос о том, что вообще сделано. Я сейчас ваяю обёртку над ffmpeg, потому что то, что есть в cargo.io -- это, по-сути, автосгенерённые bind'ы, то есть C'шный API, со всеми его проблемами, типа необходимости знать этот API и что под ним прячется, как свои пять пальцев, потому что ошибка использования этого API приведёт к сегфолту и никакой компилятор не защитит от этого. Чтобы это победить, надо, как минимум, прописать в API все лайфтаймы, а как максимум, скажем, сделать невозможным некоторые изменения AVFormatContext в процессе записи туда, потому что эти изменения могут привести к тому, что следующий вызов функции из ffmpeg API внезапно приведёт к сегфолту. То есть, если уж делать бинды, то эти бинды должны давать гарантии, которые даёт rust, а это требует глубокого знания ffmpeg и изложения этого знания на rust'е. А это время, которого всегда не хватает.
