Ну да, действительно, что-то интегрировали, папочка servo появилась, но по сравнению с активностью в репозитории gecko-dev servo выглядит мертвецом. Потыкал в несколько коммитов наугад в gecko-dev - либо C++, либо js, либо служебные скрипты на питоне, активной разработки на расте не видно.

Нет, servo так и не взлетел и остался экспериментальным движком, а затем растаманы были уволены из умирающей Mozilla в большинстве своём. Сейчас судя по истории коммитов servo пилится парой человек с большими перерывами - месяцами там вообще не бывает коммитов за исключением автокоммитов от dependabot'а.

Так проблем там одна -- запрещено копирование по значению.

Если вы про "стандартный" PIMPL через кучу, то да, увы. Жизнь могли бы скрасить конструкторы копирования и operator=(), если бы не вопросы к стабильности ABI.

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

Чтобы не выделять через кучу.

Ну так оно же не работает так, как должно. Проблем не оберешься.

Простите, но нафига городить такое чудо, которое мало того что UB на UB, и UB погоняет, так еще и бессмысленно? PIMPL нужен для того, чтобы размеры объектов на стеке никогда не менялись, а здесь, стоит не дай бог чему-то серьезно поменяться, и уже нужно увеличивать ваш волшебный sizeOfImpl, место на стеке стало требоваться другое, код, который был собран с предыдущей версией библиотеки, начал крашиться.

Я точно не знаю как это работает

Ну и плохо. После завершения main() ваша "безопасная очередь" будет уничтожена вместе со всеми своими примитивами синхронизации, а поток, который на них ждет, еще некоторое время завершен не будет. Уничтожение того же заблокированного мутекса - это undefined behavior, любое обращение из потока к уже уничтоженному объекту очереди - тоже. Просто у вас появится гейзенбаг - игра иногда на некоторых системах может начать падать при выходе. Потоки должны быть корректно завершены до завершения main().

но оно работает!

Это пока.

Я к тому, что в любом языке существует возможность легко, но жестоко ошибиться. Те, кто делит языки на "апастные" и "бизапастные", либо преследуют цели продвижения чего-то в неких целях, весьма слабо связанных с "безопасностью для пишущего", либо просто недоумки. Любой язык может быть как "опасным", так и "безопасным", в зависимости от того, кто на нем пишет. И я бы сказал, что чем ниже у языка порог входа, тем бОльший процент его "пользователей" склонен не обращать внимания на детали написанного.

Rust тоже написан поверх LLVM, который написан... Да-да. А впрочем, эти "рекомендации анб" напоминают мне фразу "нужно делать так, как нужно, а как не нужно - делать не нужно".

Эт точно. Помню про одну "простую ошибку", когда в питончике можно было написать yaml.load(...)и получить все, что угодно, вплоть по RCE, на untrusted input. Многие писали, а не использующие линтеры и до сих пор пишут. Но "это другое", да.

"Встречают по одёжке, провожают по уму" - не антипаттерн, а констатация факта. Впрочем, у многих и то, и другое находится в неудовлетворительном состоянии.

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

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

Если они избегают излагать свои решения письменно за своей подписью, а заставляют вас подписывать их решения якобы от вашего имени - у вас проблемы.

P.S. Не удивлен количеством инфантилов на хабре.

Но это не добавляет объективности (Rational? :D ) вашим статьям.

Вы забыли употребить "токсичный" и прочие баззворды.

Касательно самой г-жи Эллисон: она на фотке хоть и странная, но ни в вашей статье, нигде - не очень понятно, в чем именно был её косяк. И действительно ли это был её косяк, или она действовала по указке SBF, который говорил ей что делать, и как делать? 

Если вы согласитесь "порулить" тем, в чем ни ухом, ни рылом, причём решения будете принимать даже не вы, а какой-то дядя (но подписи на документах будут ваши, а не дяди), то у меня для вас плохие новости. Вы будете странным не только на фотке.

А то, что она не компетентна - так это косяк не её, а SBF, который её туда посадил.

Он её именно поэтому туда и посадил - потому, что она некомпетентна, и будет подписывать все, что ей скажут, неужели непонятно. This is by design.

Объявление: "Юридически подкованный пенсионер задолбает кого угодно по вашему выбору, письменно или по телефону, за символическое вознаграждение."

Ну, не совсем так. Список, который list - тот да, специально отформатированная строка. Ассоциативный массив же, который array - тот нет, это opaque variable, который можно превратить в строку-list (и обратно) через array get/array set.

В Tcl вообще нет понятия "цифра" или "число", есть только "строка". С его точки зрения 1234 - это точно такая же строка как и ABCD, никакой принципиальной разницы между ними нет. Просто в некоторых контекстах, скажем, в рамках выражения expr 1 + 2, строки 1 и 2 могут интерпретироваться как числа.

В Tcl то, где переменная, а где - литерал, зависит от контекста:

# Literal
set Hello 5
puts $Hello
# Variable
set 5 Hello
puts $5

Никаких неоднозначностей не возникает.

По Qt-аналогам того, что используется конкретно в этом примере: QHttp был ещё в Qt 3.x (это начало нулевых), в более поздних версиях его заменили на QNetworkAccessManager. Причём оба были изначально асинхронные, а в примере по вашей ссылке Execute блокирующий, насколько я понимаю (на Delphi не писал уже сто лет, не знаю, как там с этим было в 2013-м, если реально не было асинхронного варианта сделать REST-запрос без запуска отдельного потока, то это никуда не годится). QJsonObject с присными появился в Qt 5.0, это 2012 год, но ещё в Qt 4.7 (2010 год) был QML с полагающимся в ECMAScript-языке JSON.parse().

Qt 5.8 вышел в январе 2017-го, пять с половиной лет назад.