1.84K subscribers
3.42K photos
134 videos
15 files
3.66K links
Блог со звёздочкой.

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

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

You no longer need JavaScript

Демонстрация того, что можно сделать исключительно при помощи CSS. Включая виджет для выбора цвета (в статье). И включая целую игру-кликер.
🔥4🥴4
#prog #article

Towards Alias-Free Pointers (PDF)

Папир из 1995 года, про который я узнал из презентации Rust: Correctness at Large, Correctness in Motion. Уже тогда была база для основы Rust! Сама статья не столь ясна, как могла бы быть, поскольку демонстрирует примеры на основе модифицированной версии Eiffel.

In this paper we argue that pointer-induced aliasing is largely a self inflicted wound, caused by the almost universal practice in programming to transfer information by copy. As a remedy for this defect we intro duce a concept unshareable objects, and the companion concept of unique pointers, which can be moved from one place to another, but which cannot be copied. We argue that unshareable objects can be employed conveniently in many, if not most, situations where dynamic objects are being used, and without incurring their pitfalls. And we show that it takes no more than minor, and virtually costless, modifications to a typical imperative programming language to support such objects.

И ещё, как отмечает автор:
Another natural application of u-objects [unshareable objects — прим. моё] is discussed in [8], where we show how such objects can be used to implement tokens — objects that, like the capabilities of operating systems, represent certain authority. Such unshareable tokens can be utilized, in particular, for the control of sharing in software systems such as object-oriented databases.

И подобный подход действительно применяется в программах на Rust, самый наглядный пример — MutexGuard.
#prog #rust #article

From Rust to Reality: The Hidden Journey of fetch_max

Why would Rust provide fetch_max as a built-in intrinsic? Intrinsics usually exist to leverage specific hardware instructions. But x86-64 doesn't have an atomic max instruction. So there had to be a CAS loop somewhere in the pipeline.

<...>

So I started digging. What I found was a fascinating journey through five distinct layers of compiler transformations, each one peeling back another level of abstraction, until I found exactly where that loop materialized. Let me share what I discovered.
3
#prog #math #article

Ideal divisors: when a division compiles down to just a multiplication

The division instruction is one of the most expensive instruction in your CPU. Thus optimizing compilers often compile divisions by known constants down to a multiplication followed by a shift. However, in some lucky cases, the compiler does not even need a shift. I call the corresponding divisors ideal.
#prog #rust #rustlib #article

I Wrote A String Type

Статья, рассказывающая о принципиальном устройстве byteyarn — оптимизированного типа для строк, который умещается в 16 байт, имеет small string optimisation и имеет нишу, позволяющую не увеличивать размер при оборачивании в Option
👍6🤔1
#prog #go #article

How we found a bug in Go's arm64 compiler

TL;DR: для горутин с большим стеком (больше, чем может быть закодировано в литерале в одной инструкции на ARM) в эпилоге функций изменение sp, регистра, указывающего на верхушку стека, происходило через две операции ADD, обе из которых оперировали на sp непосредственно. Если переключение (preemption) между горутинами происходило между этими двумя операциями, любые операции, которые разворачивали стек — в частности, сборщик мусора — следовали вверх по стеку вызовов по частично обновлённому и потому невалидному значению из sp, и в результате предсказуемо крашились.

Может, ввести отдельный хештег для историй дебага? 🤔
🤡6👍51😱1🌚1
#prog #article

Cloudflare just got faster and more secure, powered by Rust

Про то, как в Cloudflare заменяют (пока что не довели до конца, но закончат к началу 2026 года) так называемый FL, центральный компонент своих сервисов. Заголовок несколько вводит в заблуждение: Rust определённо помогает, но большая часть хороших вещей из новой версии связана с архитектурой.

Одна из вещей, которая даёт преимущество новой версии — разделение на модули, каждый из которых сам по себе не занимается IO и явно перечисляет, что он принимает на вход и что возвращает. Это не только даёт возможность на уровне архитектуры явно видеть, как модули зависят друг от друга, но и позволило интегрировать модули в предыдущую версию FL, чтобы избежать параллельной поддержки двух версий одних и тех же функций во время перехода с одной версии на другую.

Отдельно хочу отметить, что часть про отсутствие IO язык с системой эффектов (даже такой примитивной, как в Haskell) мог бы предовтращать надёжно на уровне компилятора, а не соглашений, так что конкретно тут Rust не помогает.
👍6🤔1🤡1
#prog #article

Know your SCM_RIGHTS

TIL что в Linux (на самом деле UNIX) есть способ передавать файловые дескрипторы между процессами. И эти файловые дескрипторы могут быть в том числе TCP- и UDP-сокетами.
👍7😍3👌1🤡1
#prog #cpp #rust #article

Why we didn't rewrite our feed handler in Rust

Отдельно отмечается, что Rust в технологическом стеке в этой компании уже есть и успешно используется. Проблемы возникли с переписыванием конкретного компонента, который уже есть и написан на C++. Конкретно в тексте приведены три паттерна, которые валидны в C++ и не выразимы или выразимы неудобно на Rust.

Первое касается ограничений borrow checker-а. Вот какой пример приводят:

fn process_source(sources: Vec<Source>) {
for source in sources {
let mut buffer: Vec<&[u8]> = Vec::new();
let data: Vec<u8> = source.fetch_data();
buffer.extend(data.split(splitter));
process_data(&buffer);
}
}


Простой и понятный код — но, к сожалению, выделяющий память в цикле. Логично было бы вынести аллокацию за цикл и очищать буфер в конце — но тогда компилятор не даёт скомпилировать код:

error[E0597]: `data` does not live long enough
--> src/lib.rs:32:23
|
31 | let data: Vec<u8> = source.fetch_data();
| ---- binding `data` declared here
32 | buffer.extend(data.split(splitter));
| ------ ^^^^ borrowed value does not live long enough
| |
| borrow later used here
33 | process_data(&buffer);
34 | }
| - `data` dropped here while still borrowed


Второй паттерн — самоссылающиеся структуры, известная больная тема в Rust.

Третий паттерн — множество определений разных версий и унифицированный код для работы с ними (из-за необходимости поддержки разных версий схем обмена данных, насколько я понял). Пример из статьи на C++:

struct RecV1 {
uint32_t x;
uint32_t y;
}

struct RecV2 {
uint32_t x;
uint32_t y;
uint32_t z;
}


Унифицированный код для работы с обоими этими типами можно написать при помощи шаблонов:

template <typename T>
T InitRec() {
T res;
res.x = 1;
res.y = 2;
if constexpr(std::is_same_v<T, RecV2>()) {
res.z = 3;
}
return res;
}


Нетрудно видеть, как это обобщается на случай большего количества полей и различных версий. В Rust можно попробовать сделать нечто подобное, но это вырождается в бойлерплейт, облегчать который приходится макросами — иными словами, попытка повторить шаблоны из C++.
👍10🤡5🔥1