> Написать метод deref(&self) -> &ParentType? Да надо.Спасибо за наводку, но я её правда не до конца ещё осознал. Не могли бы вы привести ссылку на обучающий материал, где этот трюк используется именно для нормального наследования и нормального полиморфизма?
> И что? Интерпретатор -- это по сути API, с кучей методов. Python -- это по-сути read-eval-print в цикле, который в процессе evel дёргает этот самый API. Таким образом python как язык -- это синтаксический сахар над тем API.
Новый язык разрабатывается ради нового look&feel, и дёргание питоньего апи из C++ не даёт look&feel, который задумал его создатель.
> Отказ от первого пня в пользу i7 не сделает из тебя потреблятелем. Так же как отказ от i7 в пользу первого пня не позволит тебе прекратить быть потреблятелем.
Разумеется. Потому что потреблятель - это образ мыслей. Есть люди, считаюшие, что допустимо дискриминировать людей по наличию/отсутствию определённых вещей и что люди без определённых вещей достойны презрения. Я с этим в корне не согласен.
> Гента смогла. Поэтому я ей и пользуюсь.
Это хорошо. Значит ничего не мешает распространять бинарные пакеты и отладочную информацию к ним.
> Не, просто у пропиерастов, как правило, нет опции пересобрать. Пересобрать gtk с assert'ами? Заинжектить код в gtk, чтобы посмотреть, что из этого выйдет? Отключить/подключить опциональные депендансы? Сменить версии библиотек, уйти от stable, уйти от unstable и поставить себе последний коммит из git репо, который даже тегом не помечен, и поэтому идентифицируется лишь хешом?
В случае тяжёлых зависимостей я бы этого избегал настолько, насколько имеет смысл. В большинстве случаев пересборка мира ради возможности вставить отладочный вывод не оправдана. И тем более не имеет смысла заставлять всех разработчиков собирать все зависимости самостоятельно.
> Ну если в философию нырять, то да. Они все ущербны. dll-hell нерешённая проблема, а все попытки её решить -- костыли, а не решения.
Да дело не в dll-hell, который решается описанным мною правилом использования последних версий для всего. Проблема в бардаке и зоопарке, когда в системе несколько менеджеров, дублирующих функциональность друг друга, и одни пакеты в одном, а другие - в другом, а третьи - в третьем, и у каждого менеджера свои закидоны.
> Да. Но вот у меня крутится сайт на rust'е -- я его
> поднимал год назад под проведение психологического эксперимента. Он не нужен уже, но по инерции крутится. И если мне сейчас приспичит что-то там поменять, то я поменяю и пересоберу его, без того, чтобы нырять на несколько часов в код, обновляя его, обновляя все депендансы и всё остальное. Причём соберётся как http-сервер, так и websockets сервер, так и wasm модуль (ещё через emscripten собранный).
Несколько часов на обновление используемого API в своём коде - как-то многовато.
> Это значит, что я могу не трогать сайт, откладывая все крупные изменения, собирая их в TODO лист, с тем чтобы если придёт время менять сайт, то я сделал бы это всё за раз.
> Это хорошо звучит в теории, а на практике очень удобно иметь долю свободы, чтобы цикл разработки одной программы не был бы жёстко прибит гвоздями к циклу разработки другой программы.
Не к циклу разработки, а к изменениям API, используемых в конкретной программе/библиотеке. И изменение нутра библиотеки зависимые от неё проекты скорее всего вообще не затронет.
>> Я имею в виду что со CLangом не нужен десяток тулчейнов, нужен
>> 1 шланг + стандартная библиотека для платформы. Один и тот же
>> шланг строит и под винду используя MinGW, и под винду, используя
>> msvcrt, и под линукс x86, используя мюсл, и под ведро, и
>> под карты NVidia, и под карты AMD и под айфоны. Почему
>> так не сделано для раста?
>возможность собрать rust на одном системном llvm есть. Но не в rustup.
Решит ли это проблему зоопарка тулчейнов?
