1.93K subscribers
3.68K photos
138 videos
15 files
3.88K links
Блог со звёздочкой.

Много репостов, немножко программирования.

Небольшое прикольное комьюнити: @decltype_chat_ptr_t
Автор: @insert_reference_here
Download Telegram
#prog #rust #article

How to stop fighting with coherence and start writing context-generic trait impls

Транскрипт выступления, если что. Мне помогло понять, что же всё-таки такое context-generic programming, как это называет автор
🔥4
#prog #article

Мой плохой код — это ваша вина

Очередной плач про то, как в этом вашем IT всё криво

(от @blog_pogromista)
🤡6🔥5
#prog #article

I’m a former CTO. Here is the 15 sec coding test I used to instantly filter out 50% of unqualified applicants.

TL;DR: тест представлен в виде куска кода с циклом на три итерации, нужно сказать значение одной из переменных после него. Некоторые особо неквалифицированные люди просто пастят код в своего любимого AI-ассистента и получают неверный ответ, потому что копируют символ "=" в условии внутри цикла, меняя условие с ">" на ">=". При этом знак равно в условии средствами HTML скрыт и имеет нулевой размер шрифта, поэтому людям не виден.
😁20🤡5🔥1
#prog #rust #article

symbolic derivatives and the rust rewrite of RE#

Растовая версия очень быстрого движка для регулярных выражений, который поддерживает, помимо прочего, конъюкцию (пересечение результатов подвыражений), отрицание и lookahead и при этом работает за линейное от входных данных время. По производительности на выражениях с большим количеством состояний обгоняет regex, особенно для поиска без учёта регистра.

Теория, поддерживающая этот движок — это развитие идей Brzozowski, но вместо того, чтобы считать производную от регулярного выражения для разных символов и потом объединять их по классам эквивалентности, новый подход считает т. н. символическую производную — производную для всех возможных входных символов сразу.

Из-за того, что данный подход поддерживает конъюкцию, движок может работать на байтах и при этом поддерживать UTF-8 просто за счёт добавления правила, которое ограничивает вход до валидных UTF-8 последовательностей:

// \p{utf8} expands to:
// ([\x00-\x7F]
// | [\xC0-\xDF][\x80-\xBF]
// | [\xE0-\xEF][\x80-\xBF]{2}
// | [\xF0-\xF7][\x80-\xBF]{3})*


Пример кода:

use resharp::Regex;

// basic matching
let re = Regex::new(r"hello.*world").unwrap();
assert!(re.is_match("hello beautiful world"));

// intersection: contains both "cat" and "dog", 5-15 chars
let re = Regex::new(r"_*cat_*&_*dog_*&_{5,15}").unwrap();

// complement: does not contain "1"
let re = Regex::new(r"~(_*1_*)").unwrap();
👍15🔥82
#prog #rust #rustlib #article

🦀Building Rust Procedural Macros Without quote!: Introducing zyn

I've been writing proc macros for a while now. Derive macros for internal tools, attribute macros for instrumentation. And every time, the same two problems: quote! doesn't compose (you end up passing TokenStream fragments through five layers of helper functions and writing hundreds of let statements), and debugging generated code means cargo expand and then squinting at unformatted token output hoping something jumps out.

Because of this I ended up writing the same helper methods, composite AST parsing and tokenizing types, extractors etc. I would have to copy these from project to project as needed, and eventually just decided to publish a crate so I never have to do it again.

So I built zyn — a proc macro framework with a template language, composable components, and compile-time diagnostics.


I wrote the debug system after spending two days on a bug where a generated impl block was missing a lifetime bound. cargo expand spat out 400 lines of tokens and I couldn't find it, so I built a debug system.
🤔51👍1🤡1