Есть с этими схемами огромная проблема. Мозг всегда где-то между ними работает, а во вторых при попытке самоанализа ещё и все эти схемы тут же искажаются.

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

Когда-то давно в Rust была идея сделать нечто похожее, но в итоге так и не получилось.

Но это как раз довольно редкий кейс.

Это какие, ни разу такое не видел?

В Расте то? Нет, там мув точно не антипаттерн. Насчёт плюсов не знаю.

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

А все же, если там небольшой сервис, то зачем так героически сражаться с Пайтоном и заниматься манкипатчингом? Не проще переделать узкое место на более дружественным к асинку языке?

В Rust он существует и сделан таки нормально

Ладно, я имел в виду все же через ссылки. Потому что иначе BC вообще не при делах.

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

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

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

В плюсах этот выбор просто даже не стоит, там всегда все опасно, даже если пишешь все через подсчет ссылок.

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

А эта другая функция ведь все равно должна быть infailable, то есть не вызывать исключения или кидать паники?

Вообще, в Расте вполне могли бы добавить поддержку кастомного финализатора в Arc, язык это более чем позволяет. Но делать этого они не стали, кейс этот довольно редкий.

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

Я не удивлюсь. Но вообще прикол с токсичными и обесценивающими комментариями в том, что большинство их как бы в шутку. А потом можно ещё жертву уколоть тем, что она и шуток то не понимает.

Nix кстати не такой уж и сложный. И работает как на Linux так и на Macos. Но вот если нужен Windows, тогда да, тогда больно.

Но вот git submodule это всегда больно.

А где видно? Я пока вижу везде только его нарастание. Ритуалов все больше становится и они все сложнее.

Вот интересно, а что вы ожидаете, когда тут пишете про 300 лет ига, а потом удивляетесь отношению в свой адрес.

Как говорится, что на входе то и на выходе.

Какое-то смешивание конфигурации как таковой и схемы ее описания. Разве не стоит их разделить?

Вопросы для каждого этапа интервью подбираются очень тщательно. Случайных вопросов тут нет и каждый вопрос, вплоть до формулировки, подобран так чтобы получить тот или иной «сигнал» от кандидата. Практически не бывает такого что интервьюер сидит и, разглядывая потолок, думает «о чем бы еще спросить?». 

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

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

А FAANG... Ну штош, там процедуры строгие, но это и хорошо и плохо. К ним нужно подготовиться , но к ним и вполне понятно как готовиться. Но что касается планов на найм. Блин эти компании кучу людей сократили, это совершенно не похоже на то, что у них был план действий.

Обычно это делают уже после всего

Дело в том, что в Microsoft отдельные группы разработки «владеют» отдельными компонентами системы, и обычно они открыто враждебны к внешним патчам. Даже если вы как разработчик компонента принимаете внешний патч, это злит вашего менеджера (из-за необходимости поддерживать этот патч и оправдывать незапланированное изменение дизайна), злит отдел тестирования (они должны убедиться, что изменение ничего не сломает, а вы только накинули им работы), а также злит менеджера проекта (из-за изменения графика разработки вследствие принятия патча). В итоге нет никаких стимулов принимать изменения, внесённые извне.

Так стоп. Это же обычная характеристика открытого софта. Никто не любит левые патчи с левой функциональностью, которая не совпадает с видением автора.

Тогда уж лучше nixos. Вся система в одном конфиге.