#prog #article

Статья о задачах на пути к созданию GUI-фреймворка (спойлер: их дофига)

#prog #rust

Наглядный пример, объясняющий вариантность в контексте Rust (см. также соответствующую главу Растономикона).

(thanks @wafflelapkin)

xxx: можно же было в стд сделать одеяло-имплементацию

#quotes #трудовыебудни #justrustaceanthings

log(😅) = 💧log(😄)

Согласно мнению одного человека, я — упырь 👌😐

Посуда бьётся к счастью. А сердечки?

#prog #rust

Как вам, наверное, известно, сырые указатели *mut T и *const T не реализуют Send и Sync. Кто-то может сказать: "Но это же просто адреса, к чему эти дурацкие ограничения? К тому же, они тривиально обходятся обёртками с ручными unsafe impl Send/Sync". На это есть две причины.

Первая: Send и Sync — это авто-трейты: если все поля типа реализуют Send (Sync) и у него нету явного impl-а Send (Sync), то и сам тип реализует Send (Sync). Крайне редко сырые указателя используются как поля, которые просто передаются дальше — почти всегда из используют тем или иным способом — и при том не всегда потокобезопасным. Если бы сырые указатели реализовывали бы эти трейты, то слишком много типов автоматически считались бы Send (Sync) не смотря на то, что они таковыми не являются. Например, Rc<T> выглядит примерно так:

struct Rc<T> {
ptr: *const RcBox<T>
}


struct RcBox<T> {
    strong: usize,
    weak: usize,
    val: T,
}

С "упрощающим" изменением Rc<T> всегда бы реализовывал бы Send и Sync, что, очевидно, неправильно — в действительности же Rc<T> не реализует ни один из этих трейтов, поскольку использует не атомарный счётчик ссылок.

Вторая: явное выделение ответственности. Если вам требуется переслать сырой указатель из одного потока в другой или расшарить его с несколькими потоками, то у вас наверняка есть некоторые соображения, почему это можно сделать. Эти соображения, очевидно, работают не для всех указателей. Обычно мы разделяем данные с одним и тем же представлением, но разной семантикой в разные типы. Так почему мы не должны делать то же самое для указателей? Мало того, что это позволяет переместить утверждения в справедливости из невидимых компилятору комментариев в проверяемые компилятором типы, так оно ещё и помогает людям видеть, где необходимые предусловия и инварианты и впрямь соблюдены. А выделение специальных конструкторов над обёртками сырых указателей позволяет на практике реализовать принцип parse, don't validate.

Дети по-античному просты.

Я стоял в очереди в зоомагазине, а передо мной семилетний (скажем) мальчик что-то объяснял матери. Ребенку приходилось кричать, так как все звери в этом зоомагазине были полны энергии. Мама, отвлеченная щебетом попугаев, что-то переспросила, и ребенок разгневался.

— Птицы, молчите! — вскрикнул он голосом персидского царя.

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

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

​​​​Пошел купить лук, была очередь а касса самообслуживания зависла. От нечего делать полазил по сервисному меню, вышел в шелл. Все работает под админом. Тачскрин пашет. Дайте мне это развидеть.

In IoT S is for security. Но я человек честный, просто бутнул.

#psy #article

Actual impostors don't get impostor syndrome
Wondering whether you're a fraud? That probably means you're not.

(thanks @jemalloc)

Передовые разработки автоматизации

У меня сегодня забавный паттерн получился.

&mut &[x, ref xs @ ..]

Пояснение: это был матч на &mut &[T]. x — копия первого элемента (T), xs — ссылка на последующие элементы (&[T]).

#prog #c #article

C is not a low-level language

#rust

Там Вафелька собирает клёвые штуки раста, помогите ему, пожалуйста.

#prog #performancetrap #article

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

#prog #csharp #article

Тут вот на Хабре недавно была статья про тестовое задание, суть которого сводилось к тому, чтобы распарсить расписание в cron-подобном формате и потом иметь возможность делать к нему запросы на ближайший описываемый расписанием момент времени относительно заданного аргумента, причём как в будущее, так и в прошлое. Аффтар Автор негодовал из-за того, что он это тестовое задание выполнил, но его решение завернули без внятного фидбека, поэтому он выложил свой вариант на всеобщее обозрение. Зрелище, мягко говоря, не для слабонервных: практически нулевая декомпозиция, куча сложной логики с копипастой и if-ы с семикратной (!) вложенностью. Вдобавок, автор почему-то оптимизировал парсинг, а не получение моментов времени.

Сама задачка, однако, всё же застряла у меня в голове, и у меня были идеи, как можно красиво сделать как минимум парсинг формата расписания. К сожалению, у меня так и не дошли руки до написания кода. А вот у PsyHaste, известного в телеге, как @Psilon — дошли. Используя тот же язык, что и у автора оригинальной статьи — C# — он написал своё решение, с монатками монадками и, внезапно, обоснованным goto (который, впрочем, потребовался исключительно в силу отсутствия в C# оператора continue по метке). Вышло на редкость понятно и читаемо. Об этом он написал свою статью, которую я вас и приглашаю прочитать — и не только в силу технических решений, но и потому, что у Алекса довольно приятный слог.

(тут должна быть рекомендация блога Алекса, но его нету)