фанфакт: на macro_rules! макрос можно навесить сколько угодно #[macro_export]

замечательно

Очень забавная история про ботнет Cereals, который ломал NAS и NVR D-Link.

Сейчас он уже почти прекратил своё существование, но интересна основная цель этого ботнета. Он не занимался DDOS'ом, кражей пользовательских данных или чем-то ещё. Он просто и методично скачивал аниме на dedicated-сервера.

— Какова моя цель, создатель? Украсть ключи от ядерного оружия? Взломать банковские счета или крипто-биржи?
— Нууууу, как тебе сказать...

Welcome!

(пост из их группы в вк)

питонисты похоже сразу пишут обфусцированный код...

Прочитал все доступные на данный момент (1, 1A, 2) части статьи и вау. Вдохновляет сделать подобную дичь (если у вас есть идеи — пишите :P)

Макросы в русте — это конечно страшная штука

https://blog.m-ou.se/writing-python-inside-rust-1/

> Quite a few of my programming adventures start with “this sounds impossible, let’s do it!"

(C) Mara: Writing Python inside your Rust code — Part 1A

У меня тоже самое =)

У каждого программиста на расте наступает такой момент, когда он открывает что-то вроде и очевидное, но неожиданное.

Среди такого можно отметить например .collect::<Result<Vec<_>, _>> или упомянутые в статье ниже Option::as_deref{,_mut} (ну и Result::as_deref{,_mut}{,_err})

Много таких приятных штук в std :)

#prog #rust

Хозяйке на заметку

Если вы когда-нибудь писали на Rust какую-нибудь рекурсивную структуру, то у вас там наверняка было поле вроде Option<Box<Self>> или Option<Rc<Self>>. Для обхода подобной структуры требуется получить ссылку из поля такого типа. В принципе, можно писать что-то вроде

if let Some(relative) = &self.relative {
    // здесь можно работать с relative как с &Self благодаря deref coercion
}

, но если по каким-то причинам требуется Option<&Self>, то это уже не сработает из-за несовпадения типов. Приведение типов в подобной ситуации выглядит как field.as_ref().map(<_>::deref), или того хуже, field.as_ref().map(|x| &**x). Как я недавно с некоторым удивлением для себя обнаружил, это достаточно распространённый паттерн, чтобы для него были отдельные методы: Option::as_deref и Option::as_deref_mut. Что они делают — очевидно по типам:

fn as_deref(&self) -> Option<&<T as Deref>::Target>;
fn as_deref_mut(&mut self) -> Option<&mut <T as Deref>::Target>;

Есть резон не использовать эти методы? Если у вас стоит задача поддерживать старые версии rustc, то да, есть: эти методы были добавлены в Rust 1.40.0 (видимо, по этой причине я раньше про них и не знал). Конечно, ничто не мешает написать extension trait для добавления этих методов, только имейте в виду: если одно и то же выражение может быть как вызовом собственного метода типа, так и вызовом метода трейта, то предпочтение всегда отдаётся собственному методу типа.

Хм, тут появилась идея сделать очень очень очень маленький крейтик, чтобы

1. накостылять решение проблемы с PhantomData<fn(T) -> T> которую нельзя создать в const fn [^1]

2. сделать код более читаемым, именую непонятные типы

Упрощённо идея такая:

type Invariant<T> = PhantomData<fn(T) -> T>;
type Covariant<T> = PhantomData<fn() -> T>;
type Contravariant<T> = PhantomData<fn(T) -> ()>;

(+ дока с объяснениями и хак для const fn)

Что думаете?

Собственно при написании typed_phy мне чего-то такого не хватало, поэтому и задумался

(reddit)

Вот знаете, иногда смотрите на что-то (слово например), что видели много раз, и вдруг понимаете почему так...

Я только что понял что lt и gt это less than и greater than (вафель 17 годиков)

Нам нужна большая поставка типов 😂😂😂