#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 по метке). Вышло на редкость понятно и читаемо. Об этом он написал свою статью, которую я вас и приглашаю прочитать — и не только в силу технических решений, но и потому, что у Алекса довольно приятный слог.

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

#prog #rust #parsing #article

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

#prog #rust #gamedev

Движок Bevy отмечает свой первый юбилей. Для тех, кто не в курсе — это движок, который изначально разрабатывался с фокусом на производительность и быстрые итерации разработки при помощи замены кода сцен на ходу (thanks @lomain за исправление). Когда Bevy только появился, он произвёл небывалый фурор в расто-геймдево кругах, и за год оброс крутыми фичами (о которых рассказано в посте) и сменил версии с 0.1 до 0.5 — и при этом скоро выходит 0.6! Всё во имя святого Грааля игровых движков, так сказать.

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

Забавно, в итоге получилось похоже на то, что используется в стандартной библиотеке Rust для парсинга IP-адресов.

#prog #rust #amazingopensource

Один человек попытался реализовать некоторые из стандартных коллекций при помощи GhostCell. Получилось вроде даже неплохо.

github.com/matthieu-m/ghost-collections

Окей, гугл, как перестать эмоционально привязываться к малознакомым людям

#prog #soc #ml

Антон разобрался в теме лучше меня, тормоза, и весьма внятно расписал ситуацию. Спасибо, Антон.

Недавно некоторые СМИ писали и перевсполошились, что Apple теперь будет искать снимки и видео с насилием над детьми автоматически и сообщать куда надо. Но нас интересует не эта этически-правовая сторона вопроса, а техническая реализация.

Чтобы снимки никуда не отправлялись (представьте заголовки “Apple решила собрать самую большую библиотеку медиа насилия над детьми”), это будет происходить на устройстве. Для каждой фотографии будет считаться NeuralHash. И это такой вот алгоритм (Neural как бы уже говорит про ML), который умеет не обращать внимания на кропы/шумы/вотермарки и возвращать одинаковый хеш для двух одинаковых по контенту фотографий. Работает он на удивление хорошо. В идеале: помечаешь один раз непотребство, а потом оно само начинает мониториться по хешу. Но есть проблема.

Hash в названии алгоритма отвечает, как можно догадаться, за собственно хеш изображения/контента на фотографии/называйте как хотите. Мораль истории в том, что одна из самых прекрасных вещей в хеш-функциях (даже если они Neural) — коллизии.

Умные люди поковырялись и выяснили, что оказывается для NeuralHash существует два типа коллизий: естественные и искусственные.

С искусственными все просто: есть картинка и мы на нее таким образом накладываем шум, чтобы ее хеш был равен хешу необходимой картинки. В общем это все очень старо и применялось еще в безопасности, когда зараженные файлы пытались прикинуться здоровыми, добавляя себе такие байты, чтобы хеш был равен исходному, и антивирус считал, что с файлом все хорошо. Ну и все современные Adversarial Attacks создаются таким же механизмом.

Другое дело естественные коллизии. Только в ImageNet’e их нашлось аж 2 пары: топор-нематода и гвоздь-горная лыжа. Есть даже репозиторий с обновляемым списком найденных коллизий.

Интересно, когда уже Adversarial Attacks перестанут быть маргинальными игрушками (прости, Свят) и станут серьезной дыркой в безопасности крупных корпораций. Еще интереснее, как с этим будут бороться, потому что сейчас собираются затыкать человеком с другой стороны, который глазками отсмотрит всю непотребщину, что вызывает такие же этические вопросы, как и модераторы Facebook, страдающие от депрессии и шутящие над пришедшим на модерацию суицидом.

В СМЫСЛЕ УЖЕ СЕНТЯ а не, рано