TEGRUS подтверждает, что корпоративная почта Mailion выдерживает нагрузку в 600 тысяч пользователей

6081 RPS (операций в секунду).
которые суммарно были оснащены 636 процессорными ядрами

Выходит, 10 операций в секунду на ядро?

Отчёт с митапа: PostgreSQL-as-Service — можем, умеем, практикуем

2-2,5 млн транзакций в секунду

А можно подробнее про эти транзакции? Это транзакции на запись или запросы только на чтение тоже включены сюда? Если это все вместе, каково примерно соотношение записи и чтения?

Rust 1.59.0: встроенный ассемблер, деструктурирующее присваивание, отключение инкрементальной компиляции

Пример с деструктурирующим присваиванием я бы переписал в таком песочницо-компилируемом виде:

fn main() {

    let (a, b, c, d, e);

    (a, b) = (1, 2);
    [c, .., d, _] = [1, 2, 3, 4, 5];

    struct EF {
        e: i32,
        #[allow(unused)]        
        f: i32,
    }

    EF { e, .. } = EF { e: 5, f: 3 };

    assert_eq!([1, 2, 1, 4, 5], [a, b, c, d, e]);
}

Как мы мигрировали в облако… пепла

(подсказка, мы теперь проверены).

Не уловил, что изменилось — было два смежных ДЦ, оба загорелись, а теперь ситуация какова?

Какая Луна больше — у горизонта или в зените?

Дом далеко, но он сам по себе большой — больше человека, а значит и Луна большая.

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

D' < D

Не понял, почему наблюдатель для угла D находится ближе к Солнцу, чем для D'?

Связный список на Rust в стиле С/C++

Все правильно, все справедливо. Список односвязный, как и показано на первой картинке.

В C++ можно передать кастомный аллокатор, если нет желания использовать дефолтный.

Это можно сделать штатно в Rust, но в разбираемых примерах штатный механизм работы с памятью вообще не задействован. В рамках такого подхода невозможного мало, за исключением:

Вместо этой строки должен быть растовый аналог std::aligned_storageT, а в методе push — perfect forwarding аргументов.

Пробросить параметры конструктора и собрать объект по нужному месту — нет, так нельзя. Даже в кучу поместить, гарантированно минуя стек, можно только в "ночной версии". В ряде случаев компилятор соптимизирует Box::new::(), конечно.

Собственно, как я говорил, если рассматривать Rust как "замену", то это скорее "замена" языка C, чем C++.

Мой опыт собеседования в Amazon

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

Можно более подробно про условия задачи? Также не очень понятны требования:

• Notification Service is ext
• Do not loose data

Связный список на Rust в стиле С/C++

Просто не очень понятно с чего вы решили что можно просто скопировать код из STD и он заработает.

Я разве написал, что он должен заработать? В цитате этого нет. В цитате есть "Попробуем".

Мы там увидем примерно такое:

public readonly struct Int32
{
private readonly Int32 m_value;
...
}

Тут странно. Я вижу такое:

public readonly struct Int32
{
  private readonly int m_value;
}

И это работает, по крайней мере, тут.

Связный список на Rust в стиле С/C++

Я лично уже запутался, какие у вас претензии к тому, что box не работает в пользовательсокм коде в стабильной версии Rust?

Давайте так поступим — процитируйте какое-либо мое утверждение из статьи и далее я поясню его, если это нужно.

Связный список на Rust в стиле С/C++

Это хороший подход — договориться про определения.

Нестабильный код (или unstable feature) требует особой версии компилятора — альфа, ночная и прочая. Стабильной версией (release, production) нестабильный код компилироваться не должен. Вкратце эти тезисы излагал тут.

Связный список на Rust в стиле С/C++

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

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

Есть "нестандартные штуки", т.е. другим компилятором эта библиотека может не скопилироваться.

Связный список на Rust в стиле С/C++

а разве нет?

typedef signed int __int32_t;? — Нет.

ну хорошо, вот прям ссылка на то как GCC реализация stdc++ использует кучу builtin штук компилятора

Это все компилируется стабильным компилятором
https://godbolt.org/z/8qEezhbch

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

Связный список на Rust в стиле С/C++

Выше пример не такой был

Это разве был интересующий пример нестабильного C++ в стандартной библиотеке C++?

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

Чем же лучше версия на Rust:

type Int32T = isize;

?

Связный список на Rust в стиле С/C++

Вот, например, если я знаю, что последний элемент типа T это массив, то могу ли я добавить в malloc некоторое количество элементов для него?

Можно глянуть на код для С?

Мощь Rust я понимаю больше как гарантию отсутствия race conditions в сложном многопоточном коде.

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

КМК и вне рамок многопоточности тут много "плюшек".

Связный список на Rust в стиле С/C++

На какой-то платформе соберется и будет нормально работать, на какой-то взорвется нафиг.

Вот это взорвется? https://www.onlinegdb.com/vmdoJZFgL

Поясните, из-за чего?

Мы ж про плюсы говорим

Вообще меня интересовали примеры нестабильного C++ в стандартной библиотеке C++.

Пока рассматриваем стабильный из С.

Связный список на Rust в стиле С/C++

Пример по ссылке компилируется.

Нестабильный компилироваться не должен.

Связный список на Rust в стиле С/C++

Quod licet Iovi, non licet bovi

В целом мотивация упрятать нестабильный box внутрь Box понятна, тут вопросов нет.

Нет возражений также считать код Box "надёжным", в том смысле, в каком "надёжен" код на любом ЯП — не меньше, но и не больше.

PS. Для саморазвития — можно глянуть на примеры нестабильного C++ в стд C++?

Связный список на Rust в стиле С/C++

Гм, а как вы в таком случае доверяете функциям выделения памяти в других языках?

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

Связный список на Rust в стиле С/C++

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

На картинке скорее односвязный список с локальными "побегами" одиночной длины.

Разумеется, все гарантии компилятора на него распространяются независимо от того что там внутри.

Как могут гарантии стабильного компилятора распространяться на то, что не компилируется?

Связный список на Rust в стиле С/C++

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

Работу с памятью можно практически не менять, malloc — нет проблем.

res = libc::malloc(std::mem::size_of::<T>()) as *mut T;

И понимаю, что это надо переписывать как-то совершенно по-другому.

Чтобы задействовать всю мощь Rust надо, действительно, писать несколько иначе. Но можно оставаться и во вполне "сишных" рамках, почему нет. Бонусом будет кросс-компиляция "из-коробки", для embedded скорее всего надо будет побороться с размером исполняемого модуля, недавно была статья по этой теме.