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