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

отсутсвие вменяемой системы загрузки

Что это значит?

многодневные попытки переместить переменную из одной функции в две другие для каждого такого кейса

Для каждого какого кейса?.. Безусловно, у раста порог входа выше, чем у го, но кажется конкретно про эту проблему "Рабинович напел".

Java — абстрактная фабрика абстрактных фабрик

Современная джава уже не так страшна плюс есть котлин.

На примере Rust по идее не вышло бы про типы-объединения рассказать, так как в нём они не поддерживаются, потому что Rust компилируемый язык, а при компиляции всегда нужно знать, какой тип у переменной

На всякий случай, уточню, что union аналигичный сишному в расте есть. Мне кажется, что этого достаточно чтобы продемонстрировать типы-объединения. Я бы даже сказал, что получение реального типа в рантайме из метаинформации — это читерство. Ведь по факту у нас тег есть, просто его хитро хранит рантайм.

В расте разве отсутствует сишный typeid().name() для проверки типа?! O_O

Есть и std::any::type_name и TypeId::of(), но и в расте и в С++ это никак не поможет для определения, что именно сейчас находится внутри union — в рантайме этой информации нет.

На других сайтах, RAII не привязывется непосредственно к C++, при этом приводятся примеры на очень даже managed языках.

Можно ссылку или по каким ключевым словам загуглить? Спрашиваю просто из любопытства — интересно почитать другие мнения. Вижу в (английской) википедии оговорки, что мол если сборка мусора сделана через подсчёт ссылок, то она детерминирована и можно использовать RAII. Справедливо, правда сами примеры не очень убедительны (например, отдельная реализаций питона).

В управляемых языках, время жизни может быть задано в виде лямбды, в которую передаётся объект или в виде thunk с параметром.

Я что-то упускаю или управляемость тут не при чём? В С++ или расте можно сделать такой же интерфейс для работы с ресурсами.

Я не специалист в C++, но догадываюсь, что там можно запретить move конструктор и компилятор просто не даст скопировать объект

Стоит разделять копирование и перемещение. В С++ их запрещать можно отдельно. Собственно, с перемещением как раз никаких проблем нет: перемещать объект-ресурс наоборот удобно. Это может быть возврат или передача (владения) в функцию, положить/забрать из контейнера, перемещать как часть другого объекта и т.д. Лично я именно это беспроблемное использование и вижу "киллер фичей" RAII, альтернативы такого не предлагают. Опять же, если придираться, то где в приведённом изначально схемовском апи собственно инициализация?

И GC тут не при чём.

По прежнему считаю, что называть разные механизмы одинаково не очень полезно, а скорее вредно так как усложняет обсуждение. В языках с GC можно устроить ручное управление памятью — заводим кусок памяти, который никогда не освобождается и руками размещаем там объекты. Но кому будет лучше, если мы станем называть джаву языком с ручным управлением памятью?

GC тут, как минимум, при том, что он заставляет придумывать новые механизмы, а не полностью повторять плюсовый.

Дык, при наличии GC традиционных деструкторов обычно и нет, только "финализаторы", которые непонятно когда будут вызваны. Но похоже каждый из нас останется при своём мнении. (:

Допустим, но в таком случае RAII есть и в С и вообще везде где можно передать аргументом функцию:

void with_file(const char *file_name, const char *access_mode, void proc(FILE*));

Но такая классификация теряет смысл. Плюс сила RAII в том, что такие объекты не требуют специального обращения. Их можно хранить в контейнерах или положить полем в другой объект, а с данным механизмом так не получится.

Да ладно? Как язык помешает мне вместо with-output-to-file использовать open-output-file?

n..m, ограничив его только для интов.

Это не совсем так. В найтли доступен трейт Step.

В любой живой язык добавляют новое, от этого никуда не деться...

Это не RAII — аналог такого и в C#/джаве есть (using/try with resources).

Потом правда вроде передумали

И зря.

Итераторы ленивые, так что тут всё хорошо. Правда не очень понял пример выше: если мы можем всё записать в виде цепочки итераторов, то тут проблем не будет, если конечно посредине не делать collect, но в этом нет никакого смысла. Если же мы из базы получили данные в виде вектора, то тут тоже без разницы — обрабатывать их циклом или нет.

Можно ли сказать, что я "перешел с раста", скажем, на те же плюсы? Фактически да :)

Не согласен. Любой разработчик с достаточным опытом (при отсутствии зашоренности) неизбежно пощупает кучу языков и технологий. Если я прочитал несколько книг по хаскелю и худо-бедно могу на нём что-то писать, но не делаю этого, не значит, что я "перешёл с хаскеля". Не нашёл применения или предпочитаю другие языки — да. Аналогично, если я стараюсь по возможности избегать динамически типизированных языков, это не значит, что я перешёл, скажем, с питона.

Crate — это так в rust называются библиотечные модули, иногда их называют пакетами.

Немного не так. Crate — "единица компиляции", это может быть как библиотека, так и исполняемый файл. Подробнее вот тут.

Rust — типобезопасный язык программирования, код которого проверяется пакетным менеджером cargo ещё до сборки.

Никто ещё не придрался?.. Ладно, первым буду: код проверяет компилятор, а не карго. (:

А под какими именами публикуют такие пакеты?.. Что-нибудь типа @vasya/hello_world? Ну будет на crates.io вместо этого vasya_hello_world. Неужели правда хуже?