#prog #rust #performancetrap #article

Статья о том, как апгрейд до новой версии tokio привёл к тому, что сервер, обычно отвечающий меньше, чем за миллисекунду, начал отвечать ровно за 40 миллисекунд. Спойлер: как всегда в подобных случаях, баг образовался из-за взаимодействия нескольких механизмов, включая части из linux.

Я говорил это ранее и скажу ещё раз: Вафель умница. Вскоре после того, как я выложил этот пост, он опубликовал вариант starts_with_ignoring_case с более простой реализацией.

#prog #rust #rustlib

Библиотека spirit — для снижения количества бойлерплейта при написании долгоживущих серверов. Логгирование, перечитывание конфигов при изменении, реагирование на сигналы, оборачивание в демоны — вот это вот всё.

#prog #rust #rustlib #amazingopensource

Заметки о библиотеке для использования постфиксных макросов, с изложением мотивации для её создания, истории вопроса и немного о реализации.

use postfix_macros::{postfix_macros, unwrap_or};

fn main() {
    postfix_macros! {
        let urls = ["https://rust-lang.org", "https://github.com"];
        for url in urls.iter() {
            let mut url_splitter = url.splitn(2, ':');
            let scheme = url_splitter.next().unwrap();
            let _remainder = url_splitter.next().unwrap_or! {
                println!("Ignoring URL: No scheme found");
                continue;
            };
            println!("scheme is {}", scheme);
        }
    }
}

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

Ответ очень прост: я выкладываю некачественный контент.

#psy

О том, как правильно извиняться. Написано в контексте брака, но, на мой взгляд, вполне применимо и в более общих ситуациях.
TL;DR: Извиняетесь, но не заставляйте просить прощения

В этот раз ссылка на приватный канал в Telegram, так что вот вам сначала инвайт, а потом уже и ссылка на сам пост.

блять, опять я всё своё свободное время потратил в телегу и нихера не напрогал. Надо удалять её нафиг

#prog #cpp

twitter.com/AffectiveCpp — лучший твиттер-аккаунт о C++. Полезен даже профессионалам, а новичкам так и вовсе практически обязателен.

#prog #cpp

Действительно, выразительный.

https://twitter.com/Nekrolm/status/1326175405397651457

#prog #rust #compiler #article

Восхитительная длинная статья от Крендель-молота про написание компилятора brainfuck под x86_64, ARM64, WASM и LLVM IR.

github.com/pretzelhammer/rust-blog/blob/master/posts/too-many-brainfuck-compilers.md

#prog #rust tip: спецификатор фрагмента vis в макросах сопоставляется с описанием видимости определения, в том числе и пустым.

К примеру, следующий код компилируется:

macro_rules! accept_with_vis {
    ($vis:vis struct $name:ident;) => {}
}

accept_with_vis!{struct Foo;}

...Но не когда нужно сопоставиться только с спецификатором видимости (thanks @sajitar, который и заполнил issue). Вот этот код не компилируется:

macro_rules! accept_just_vis {
    ($vis:vis) => {}
}

accept_just_vis!{}

#prog #rust #моё

Как многие из вас знают (а если не знаете — узнаете сейчас), в Rust нельзя перемещать (move) поля из значения типа, имеющего нетривиальную реализацию Drop. В частности, значение типа, реализующего Drop, нельзя деструктурировать. Однако надо отметить, что если тип поля реализует Copy, то к этому полю можно обратиться, в том числе и пре деструктуризации, при этом значение этого поля скопируется. Проиллюстрирую только что сказанное:

struct NonCopy;

struct Dropping<T>(T, NonCopy);

impl<T> Drop for Dropping<T> {
fn drop(&mut self) {
println!("dropped");
}
}

fn main() {
// ⬇️ если раскомментировать эту строку, то программа не скомпилируется с E0509
// let Dropping(_non_copy, _) = Dropping(NonCopy, NonCopy);

// А вот это — компилируется и печатает "dropped".
// Обратите внимание, паттерн `_` *не* перемещает значение.
let Dropping(_x, _) = Dropping(0_u32, NonCopy);
}

Где это может выстрелить? При написании биндингов к сишным либам. Одна их техник обеспечения инкапсуляции в C — это определение структуры в заголовочном файле без определения её полей. Это позволяет получить доступ к полям структуры только там, где дано её определение, а внешний код может обращаться к ней лишь по указателю. И указатель — это Copy-тип, да.

Пусть это выглядит примерно так:

extern "C" {
// extern types ещё не стабилизированы, так что
// в реальной библиотеке, скорее всего, будут использовать *mut std::ffi::c_void


    type Some_C_Struct;
    fn c_lib_release_resources(arg: *mut Some_C_Struct);
}

struct Handle(*mut Some_C_Struct);

impl Drop for Handle {
    fn drop(&mut self) {
        unsafe { c_lib_release_resources(self.0) }
    }
}

Что произойдёт, если мы попытаемся деструктурировать Handle? Скажем, нам зачем-то потребовалась реализация метода leak:

impl Handle {
    fn leak(self) -> *mut Some_C_Struct {
        // Здесь мы разбираем значение, но так как указатель — Copy-тип,
        // имя ptr привязывается к копии значения, перемещения не происходит.
        let Handle(ptr) = self; // <-- после этой точки с запятой кончается время жизни self, и вызывается деструктор
        // Ура, у нас на руках невалидный указатель!
        ptr
    }
}

Что можно с этим сделать? Использовать ManuallyDrop. Этот тип предотвращает вызов деструктора (а также деструктуризацию, поскольку у него приватные поля), но при этом не предотвращает доступ к полям значения внутри (через Deref). Возникает вопрос, почему не использовать std::mem::forget? В принципе, в документации подробно расписано, но если коротко, то std::mem::forget значительно сложнее корректно использовать.

Сишный код в двух словах:

Бе ды
с
вла дением

Прошу прощения, в предыдущем опросе один диапазон возрастов просто не был представлен

Если вы не можете, потому что у вас лапки — значит, вы котик.