Hacker News Digest

Библиотека crossfire-rs предоставляет безблокировочные (lock-free) реализации очередей MPMC (множественные производители/потребители) и MPSC (множественные производители/один потребитель) для асинхронного программирования на Rust. Проект основан на популярной библиотеке crossbeam, которая специализируется на низкоуровневых примитивах параллелизма.

Основное преимущество crossfire-rs - это высокая производительность благодаря использованию безблокировочных алгоритмов, что позволяет избежать накладных расходов на блокировки. Библиотека особенно полезна для высоконагруженных систем, где производительность и параллелизм являются критически важными факторами. Реализации поддерживают асинхронный контекст, что делает их идеальными для использования в современных асинхронных приложениях на Rust.

• Обсуждение вращается вокруг тонких различий между различными моделями каналов (SPSC, MPMC и т.д.) и их влиянии на безопасность отмены и производительность.
• Участники обмениваются ссылками на документацию и обсуждают, какие именно гарантии предоставляет каждая реализация.
• Появляется вопрос о том, как именно Kanal и другие библиотеки реализуют оптимизации, которые могут влиять на безопасность отмены.
• Участники обсуждают, какие именно факторы производительности (например, latency vs throughput) имеют наибольшее значение для их конкретного варианта использования.
• В конце обсуждение сводится к тому, что выбор канала зависит от специфики рабочей нагрузки и что сравнительные бенчмарки могут не отражать реальную эффективность в продакшене.

• SQLite не поддерживает параллельную запись; WAL-режим лишь разрешает параллельное чтение, но не пишущие транзакции.
• Проблема SQLITE_BUSY чаще всего возникает из-за длительных транзакций, которые не закрывают файл, и не из-за реальной конкуренции за доступ.
• Не стоит забывать, что SQLite — это встроенная СУБД, а не серверная СУБД, и что она не предназначена для высоконагруженных веб-приложений.
• В отличие от PostgreSQL, MySQL и других серверных СУБД, SQLite не поддерживает параллельную запись, и поэтому не может быть использована в ситуациях, где требуется высокая параллельность.

В статье описывается концепция "futurelock" — особый тип дедлока, возникающий в асинхронном Rust, когда ресурс, принадлежащий Future A, требуется для Future B, а задача, ответственная за оба Future, перестала опрашивать A. Oxide обнаружила эту проблему в проекте omicron.

Пример демонстрирует программу, которая надежно замирает: фоновая задача захватывает блокировку на 5 секунд, основная задача использует tokio::select! для ожидания двух конкурентных Future. Один Future ждет блокировку, другой — таймаут. Когда таймаут срабатывает, создается новый Future, который также ждет блокировку, но задача больше не опрашивает исходный Future, что приводит к дедлоку.

• Проблема в том, что tokio::select! отменяет все futures, кроме одного, и это может привести к deadlock, если оставленные в стороне future владеет ресурсом (например, MutexGuard).
• Возможность отмены future в Rust в целом не определена, и это приводит к тому, что tokio::select! ведёт себя непредсказуемо для разработчика, что может привести к утечке ресурсов или deadlock.
• В отличие от других языков, где отмена future ведёт к её уничтожению, в Rust модель владения и заимствования не позволяет гарантировать, что ресурсы будут очищены.
• Это приводит к тому, что в Rust нет способа защититься от таких ситуаций на уровне языка, и единственное, что может сделать разработчик - это не использовать select! и вместо этого вручную управлять состоянием.
• В конце концов, это делает async Rust более сложным в использовании, чем он должен бы быть, и создаёт уязвимости, которые не существовали бы в других моделях параллельности.

Инженер с опытом работы в Intel и Sun развенчивает популярные мифы о CPU-кэшах. Многие разработчики ошибочно полагают, что разные ядра могут иметь устаревшие значения в своих кэшах, а ключевое слово volatile в Java заставляет читать/писать данные напрямую в оперативную память. На самом деле, даже одноядерные системы подвержены проблемам конкурентности без правильных синхронизационных конструкций, а volatile-операции могут быть такими же быстрыми, как доступ к L1-кэшу (в 200 раз быстрее, чем к оперативной памяти), а не к основной памяти.

Современные CPU x86 поддерживают когерентность кэшей на аппаратном уровне через сложные протоколы, такие как MESI. Каждая строка данных в кэше помечается одним из состояний: Modified (измененные данные, источник правды), Exclusive (синхронизированные данные, нет копий в других кэшах) или Shared (синхронизированные данные, присутствуют в других кэшах). Понимание этих механизмов помогает лучше проектировать распределенные системы и избегать ложных представлений о производительности и конкурентности.

Here's my favorite practically applicable cache-related fact: even on x86 on recent server CPUs, cache-coherency protocols may be operating at a different granularity than the cache line size. A typical case with new Intel server CPUs is operating at the granularity of 2 consecut

Zig представил новую асинхронную систему ввода-вывода, которая войдет в версию 0.16.0 через 3-4 месяца. Новый интерфейс std.Io позволяет писать асинхронный код с помощью ключевых слов async и await, декопируя вызов функции от ее возврата. Как и аллокаторы, std.Io настраивается один раз в main() и передается через приложение. В примерах показана эволюция от простого синхронного кода до полноценного асинхронного, где операции могут выполняться параллельно, сокращая реальное время выполнения.

Система включает реализацию на основе потоков (std.Io.Threaded), которая позволяет выполнять две односекундные операции за одну секунду реального времени. Примеры демонстрируют обработку ошибок в асинхронном контексте - при возникновении ошибки в одной из задач, другие продолжают выполняться. Новый подход делает код более выразительным и эффективным, позволяя Zig-приложениям лучше использовать современные возможности операционных систем.

• Zig's async model is a radical departure from traditional async/await, emphasizing explicit I/O objects and no hidden control flow, but it has sparked debate on whether this is the right direction for the language.
• The discussion revealed that the lack of a standard async runtime and the decision to make the async/IO interface a public API has raised concerns about ecosystem fragmentation and the burden on library authors.
• Participants questioned whether the new model truly solves the "function color" problem or merely shifts it to a different place, and whether it will be able to scale to the ecosystem.
• The debate also touched on the risk of fragmentation if the community fails to converge on a de-facto standard library for async I/O, and the potential for a "left-pad" moment if the ecosystem becomes too fragmented.
• Some expressed concern that the lack of a blessed standard library could lead to a situation where "every game ships its own copy of DirectX" in the form of vendored async implementations, which could be a barrier to adoption.

Автор изначально не интересовался Zig, считая его нишевым языком для аудиопрограмм, но решил переписать индекс AcoustID на Zig как возможность изучить новый язык. Результат превзошёл ожидания — новая версия оказалась быстрее и масштабируемее, чем предыдущая на C++. Однако при добавлении серверного интерфейса возникли сложности с сетевыми возможностями Zig, что привело автора к созданию библиотеки Zio — асинхронной I/O и библиотеки для конкурентности в стиле Go.

Zio реализует стековые корутины с фиксированным размером стека, поддерживает асинхронную сетевую и файловую I/O, примитивы синхронизации и каналы в стиле Go. Главная особенность — контекстный переключение практически бесплатен, сравним с вызовом функции. В однопоточном режиме Zio обгоняет все протестированные фреймворки, включая Go и Rust Tokio. Интересно, что благодаря стандартным интерфейсам reader/writer, внешние библиотеки могут использоваться без модификаций, даже не зная, что работают внутри Zio.

• Обсуждение показало, что Zig не имеет встроенной поддержки async/await, а вместо этого используется библиотечный код, что вызывает вопросы о том, как это скажется на производительности и удобстве использования.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.

Wren — это маленький, быстрый, объектно-ориентированный скриптовый язык с поддержкой concurrency. Его реализация занимает менее 4000 строк кода, что позволяет изучить весь код за один день. Язык сочетает в себе идеи Smalltalk, Lua и Erlang, предлагая современный и понятный синтаксис. Wren использует быстрые однопроходный компилятор в байт-код и компактное представление объектов, что позволяет ему конкурировать с другими динамическими языками.

Особенностью Wren является акцент на классах как основной парадигме и встроенная поддержка легковесных волокон (fibers) для организации программы в набор взаимодействующих корутин. Язык создан для встраивания в приложения — он не имеет зависимостей, имеет небольшую стандартную библиотеку и простой C API. Wren компилируется как C99, C++98 или более новые версии, доступен для запуска в браузере и открыт на GitHub под руководством Боба Нистрома.

• Wren — язык, который сочетает в себе лаконичность Lua и объектно-ориентированный синтаксис, но при этом остаётся компактным и легко встраиваемым.
• Пользователи отмечают, что Wren легко встраивается в C/C++ проекты, но при этом не требует сложных зависимостей, что делает его привлекательным для встраиваемых скриптовых языков.
• Некоторые участники обсуждения упоминают, что Wren может быть использован как альтернатива Lua, особенно в контексте встраивания в игровые движки и другие приложения.
• Обсуждается также, что Wren имеет активное и дружелюбное сообщество, что способствует его развитию и поддержке.

Отмена в асинхронном Rust — мощный, но сложный механизм. В синхронном коде отмену часто реализуют через проверку флагов или паники с особыми типами, но это плохо масштабируется. В асинхронной версии проблема глубже: при использовании timeout с операциями вроде tx.send сообщение может быть потеряно, если таймаут сработает во время ожидания места в канале. Это происходит потому, что будущее отменяется на определённой точке приостановки (await), не гарантируя отката уже выполненных действий.

Корень проблемы — в семантике отмены: асинхронные задачи прерываются в состоянии ожидания, но не отменяют побочные эффекты (например, частично отправленные данные). Это приводит к тонким багам, особенно при работе с ресурсами вроде каналов или сетевых соединений. Решения включают аккуратное проектирование API с явной поддержкой отмены, использование деструкторов для очистки и внедрение идиом вроде "отмены через прерывание" с гарантиями целостности.

• Обсуждаются проблемы безопасности отмены (cancel safety) в асинхронном Rust, когда операции могут прерываться в точке .await, что приводит к неожиданным побочным эффектам и потере данных.
• Поднимается вопрос о необходимости "асинхронного Drop" и более строгих гарантий выполнения для критических секций кода, которые не должны прерываться.
• Отмечается, что семантика отмены сильно зависит от контекста, и термин "cancel safety" может вводить в заблуждение, так как не относится к безопасности памяти (safety) в Rust.
• Участники делятся практическими примерами ошибок, связанных с отменой, и предлагают решения, например, буферизацию сообщений или явную пометку функций в документации.
• Обсуждается сложность ручного управления состоянием при реализации асинхронных структур и проводятся параллели с аналогичными проблемами в других языках, например, в Go.

Lone Lisp теперь поддерживает ограниченные продолжения — мощный механизм управления потоком выполнения. Это позволяет сохранять и восстанавливать состояние вычислений в определённых точках, что открывает путь к реализации генераторов, обработки исключений и других сложных конструкций. Пример кода демонстрирует, как control и transfer работают вместе: (control ...) захватывает контекст, а (transfer ...) передаёт управление, позволяя гибко манипулировать выполнением.

Изначально проблема возникла при реализации итераций: из-за рекурсивной природы интерпретатора и управления стеком на уровне C было невозможно контролировать поток. Решение потребовало переосмысления архитектуры — вместо байткода или трансформаций в стиле продолжений автор выбрал подход, сохраняющий списковую структуру Lisp. Это сложный, но фундаментальный шаг, вдохновлённый классическими работами вроде SICP.

• Wat реализует стек вызовов в пользовательском пространстве для поддержки ограниченных продолжений, что позволяет создавать исключения, ветвление и файберы.
• Вопрос о практическом применении ограниченных продолжений за пределами хобби-проектов и их реальном использовании в промышленности.
• Примеры использования в Ocaml 5 (библиотека Eio), Haskell (GHC, работа приостановлена) и Racket (стандартная модель для обработки ошибок и прерываний).
• Java использует ограниченные продолжения как основу для своих новых "зеленых" потоков (виртуальных потоков).
• Обсуждение потенциальных сфер применения, таких как встраиваемые системы.

В Rust есть встроенная атомарная операция fetch_max, которая отсутствует в Java и C++. Она позволяет безопасно обновлять максимальное значение в многопоточной среде без явного написания цикла CAS. Исследование показало, что fetch_max генерируется макросом atomic_int! в стандартной библиотеке Rust, который создаёт методы для атомарных типов.

На уровне компиляции LLVM эта операция превращается в цикл сравнения и обмена, скрытый от программиста. Это демонстрирует, как Rust абстрагирует сложные низкоуровневые детали, предоставляя удобные и безопасные примитивы для конкурентного программирования.

• Автор обнаружил, что Rust имеет встроенную атомарную операцию fetch_max, которой нет в Java и C++ (хотя она планируется в C++26).
• Обсуждение затронуло технические детали реализации атомарных операций (например, на ARM и x86), их производительность при высоком уровне конкуренции и возможность компилятором оптимизировать циклы CAS в нативные инструкции.
• Участники отметили, что подобные низкоуровневые операции существуют и в других средах, таких как GPU (HLSL/GLSL/CUDA) и RISC-V.
• Многие выразили признательность автору за познавательную статью, углубившую их понимание модели памяти и атомарных операций.
• Несколько человек поинтересовались, был ли нанят кандидат, упомянутый в исходной статье, на что автор ответил, что тот не подошел по культуре.

В Wild-линковщике для Rust применяют несколько продвинутых техник оптимизации параллельной работы. Например, используют split_off_mut для безопасного разделения мутабельных срезов Vec<SymbolId> между потоками, что позволяет обрабатывать символы каждого объекта параллельно без блокировок, сохраняя кэш-локальность.

Для инициализации вектора без задержек на основном потоке задействуют крейт sharded-vec-writer: предварительно аллоцируют память, разбивают её на сегменты по числу символов в объектах и заполняют их параллельно через VecWriter, что ускоряет стартовую фазу.

В случаях, когда требуются случайные записи в общий вектор (например, для обработки дубликатов символов в C++), переходят на атомарные операции. Вместо стабильного, но ограниченного AtomicU32::from_mut_slice (только nightly) или постоянного использования атомиков (что снижает производительность), временно преобразуют &[SymbolId] в &[AtomicSymbolId] через unsafe-конверсию, экономя на издержках синхронизации в основном коде.

• Обсуждаются оптимизации Rust, такие как преобразование Vec в IntoIter и обратно для эффективного повторного использования аллокации, что реализовано в стандартной библиотеке как специальный случай.
• Высказываются предостережения против некоторых "трюков производительности", например, перемещения аллокации в другой поток для освобождения, из-за особенностей работы аллокаторов и сомнительной выгоды.
• Поднимается вопрос о надёжности оптимизаций компилятора (LLVM) в релизных сборках, которые могут меняться между версиями и сложны для верификации, что контрастирует с медленными debug-сборками.
• Отмечается, что многие трюки направлены на обход ограничений borrow checker для получения разрешения на выполнение операций, а не на решение аппаратных задач производительности.
• Обсуждается преимущество Rust в безопасном параллелизме (например, с Rayon) по сравнению с C/C++, где обеспечение потоковой безопасности значительно сложнее.

Fil-C — это C/C++-совместимый язык с безопасной памятью и современным инструментарием. Его сердце — FUGC, параллельный, конкурентный, точный, неперемещающий сборщик мусора.

Ключевые черты FUGC

• Параллельность: маркировка и очистка выполняются на всех ядрах.
• Конкурентность: потоки-мутаторы не останавливаются; блокировки только на медленных путях аллокации.
• On-the-fly: нет глобальной паузы; «мягкие рукопожатия» просят потоки асинхронно сканировать стек.
• Grey-stack: повторное сканирование стеков до фикс-поинта; барьер только при записи, быстрая сходимость.
• Dijkstra-barrier: при записи указателя объект помечается CAS-relaxed.
• Точность: LLVM-плагин FilPizlonator точно знает, где все указатели.
• Неперемещаемость: объекты не двигаются; освобождённые блоки «перенаправляются» через InvisiCap.

Safepoint-механизм

• Компилятор вставляет pollcheck: быстрая проверка или колбэк для GC.
• «Мягкое рукопожатие» запускает колбэк на всех потоках.
• Состояния enter/exit позволяют блокироваться в syscall без pollcheck’ов; GC сам выполняет колбэк для «exited» потоков.
• Safepoint защищает от гонок: загруженный указатель будет жив до следующего safepoint’а.

По желанию можно включить полный stop-the-world (FUGC_STW=1) для fork(2) или отладки.

• Fil-C — это С-компилятор с точным параллельным GC (FUGC) и capability-указателями, позволяющий запускать «как есть» CPython, SQLite, OpenSSH и др., теряя в худшем случае 4× производительности.
• Вместо ручного free и UB-оптимизаций LLVM код живёт под барьером Дейкстры и soft-handshake safepoint’ами; указатели превращаются в «InvisiCap» (base+offset), теряющие силу при приведении к integer.
• Проект исследовательский, но уже промышленно полезен: нет сборок под 32-бит, Windows и embedded без MMU, нет пока поколенческого GC и ARM/RISC-V.
• Споры: «lock-and-key» предсказуемее RAM, но требует атомиков; GC = «мусор потом» vs compile-time проверки; можно ли дождаться AI-стат-анализа вместо Rust-переписей.

• Эволюция OCaml – Ashoka Univ, сент 2025 [pdf][key]
• Авто-проверка реплиц. типов – NUS, авг 2025 [pdf][key]
• AI-инструменты для исследований – IIT Madras, июль 2025 [pdf][key]
• Параллельный рантайм OCaml – Chalmers, май 2025 [pdf][key]
• Авто-проверка реплиц. типов – WG 2.8, май 2025 [pdf][key]
• Параллельный OCaml 5 – Bloomberg, мар 2025 [pdf][key]
• Параллельный OCaml 5 – IIT Gandhinagar, мар 2025 [pdf][key]
• Параллельный OCaml 5 (ч.1) – PACE Lab, фев 2025 [pdf][key]
• Безопасность памяти и ЯП – Schaeffler @ IITM, фев 2025 [pdf][key]
• Мини-ОС через Unikernels – Daekin–IITM, янв 2025 [pdf][key]
• Безопасные Unikernels с аппаратной поддержкой – CAIR DRDO, ноя 2024 [pdf][key]
• Параллельный OCaml 5 – Meta London, сен 2024 [pdf][key]
• Зачем OCaml? – Rezilyens, авг 2024 [pdf][key]
• Эффекты и конкурентность – Chalmers, май 2024 [pdf][key]
• Безопасность функциональных программ – WG 2.8, апр 2024 [pdf][key]
• Композиция библиотек конкурентности – EHOP, июл 2023 [pdf][key]
• Сливаемые реплиц. типы – Collège de France, апр 2023 [pdf][key][видео]
• OCaml 5.0 – OCaml Workshop, сен 2022 [pdf][key]
• Ретрофит конкурентности – ICFP keynote, сен 2022 [pdf][key][видео]
• Сертифицированные сливаемые типы – PLDI, июн 2022 [pdf][key][видео]
• Сертифицированные сливаемые типы – Nomadic Labs, апр 2022 [pdf][key][видео]
• Параллелизм в OCaml – Marigold, дек 2021
• Эффекты в OCaml 5 – Huawei STW, окт 2021 [pdf][key]
• Эффекты в OCaml – SimCorp, сен 2021 [pdf][key]
• Параллелизм в OCaml – SimCorp, сен 2021 [pdf][key]
• ParaFuzz: фаззинг многопоточных программ – Dagstuhl, 2021

• Доклад — субъективный взгляд на 10-летнюю эволюцию OCaml; цель — убрать мистику вокруг разработки компилятора и заманить новых контрибьюторов.
• Главный бытовой pain-point: в стандартной библиотеке исключения — часть API, и они не типизированы, что подрывает «безопасность» языка.
• Выход — использовать Jane Street Core/Base (функции либо возвращают Result, либо помечены _exn), но большинство проектов всё ещё живёт на обычной Stdlib.
• «Большие» альтернативы Stdlib (Core, Base) существуют, но их значение часто преувеличено; официальная библиотека за последние годы всё-таки подросла полезными функциями.
• Новичкам в компиляторщине советуют начинать с мелких багов и мини-Pull Request’ов, а не пытаться сразу «съесть слона».

• Async в Python уже 10 лет, но до сих пор не стал мейнстримом.
• Причины:
  • ошибки «забыл await», трудно отлаживать;
  • GIL приучил не думать о параллелизме;
  • польза только при I/O-задачах, CPU-нагрузка не ускоряется;
  • фреймворки не догнали: Django ORM всё ещё синхронен, Flask тоже.
• Классический кейс — HTTP-запросы: стартуем сотни корутин, ждём ответов, не блокируем интерпретатор.
• Но дисковый I/O, CPU-задачи и другие сценарии не так выигрывают.
• Вывод: чтобы новые фичи 3.14 (free-threading, sub-interpreters) не повторили судьбу async, нужно:
  • чётко объяснять, какие задачи они решают;
  • давать простые API и инструменты отладки;
  • не ждать, пока экосистема «догонит», а сразу внедрять в популярные библиотеки.

• Async в Python пришёл «слишком поздно»: к моменту появления asyncio большинство уже решали задачи I/O через forking, multiprocessing или сторонние библиотеки.
• «Цветные функции» и необходимость переписывать весь код ради async делают его «заразным» и несовместимым с существующими синхронными библиотеками.
• Сложная семантика (event-loop, await, cancellation-исключения), плохая документация и отсутствие понятных best-practice усложняют отладку и поддержку.
• Для большинства задач Python-разработчика async не критичен: WSGI/WSGI-совместимые решения, Celery, Kafka и простое горизонтальное масштабирование покрывают потребности.
• Альтернативы (trio, anyio, gevent) и другие языки (Go, Elixir) предлагают более простые модели конкурентности без «раскрашенных» функций.

Go всё ещё плох

Кратко: автор 10+ лет критикует Go за архитектурные ошибки, которые легко было избежать.

1. Ошибки: неверная область видимости

bar, err := foo()
if err != nil { … }
if err = foo2(); err != nil { … }
// err висит до конца функции, хотя нужен только в двух строках

Читателю приходится тратить время, выясняя, где err ещё используется.

2. Два вида nil

var i interface{}
var s *S
fmt.Println(s == nil, i == nil, s == i) // true, true, false
i = s
fmt.Println(s == nil, i == nil, s == i) // true, false, true

Один «billion-dollar mistake» не хватило — сделали два.

3. Непереносимость

Условная компиляция через комментарии в начале файла — «аристотелевский» подход: теория без практики. Реальные проекты страдают.

4. append без чёткого владения

a := []string{"hello", "world", "!"}
foo(a[:1]) // внутри append
fmt.Println(a) // результат зависит от капасити слайса

Поведение неочевидно и требует знания внутренностей.

5. defer вместо RAII

В Java и Python ресурс закрывается автоматически при выходе из блока.
В Go приходится вручную писать defer foo.Close() и гадать, какие ресурсы вообще требуют закрытия.

• Go хвалят за простоту, быструю компиляцию, встроенные инструменты и удобную конкурентность.
• Критикуют «двойной nil», слабую систему типов, проблемы GC, неинтуитивный defer и скудные абстракции.
• Многие считают его «достаточно хорошим» для бэкендов и CLI-утилит, особенно при скорости разработки.
• Крупные проекты жалуются на «смерть тысячей порезов» и трудности отладки из-за строгости компилятора.
• Часть сообщества видит в Go компромисс между Node/Python и Rust, другие — устаревший язык без современных фич.

Быстрый старт

Библиотека flow отделяет бизнес-логику от развёртывания: топологии, исполнения, обмена сообщениями, жизненного цикла, мониторинга и обработки ошибок.

step-fn и процессы

Логика описывается функциями step-fn, которые flow заворачивает в процессы, крутящиеся в цикле. step-fn не работают с каналами напрямую и не хранят состояние, поэтому легко тестируются и переиспользуются.

step-fn имеет четыре арности:

describe (step-fn) → descriptor

Возвращает статическое описание :params, :ins, :outs — карты имя → документация. Имена входов и выходов не должны пересекаться.

{:params {:size "Максимальный размер"}
 :ins    {:in  "Входной канал"}
 :outs   {:out "Выходной канал"}}

init (step-fn arg-map) → init-state

Один раз вызывается при старте процесса; превращает параметры из flow-def в начальное состояние.

transition (step-fn state transition) → state'

Вызывается при переходах жизненного цикла (::flow/start, ::flow/stop, ::flow/pause, ::flow/resume). Используется для управления внешними ресурсами.

transform (step-fn state input msg) → [state' {out-id [msgs]}]

Вызывается для каждого входящего сообщения. Возвращает новое состояние и карту выходных сообщений. Выход может быть пустым, но каждое сообщение — не nil. Исключения логируются в :error-chan.

Состояние процесса

Карта с любыми ключами. Дополнительно:

• ::flow/pid — идентификатор процесса
• ::flow/in-ports, ::flow/out-ports — карты cid → внешний канал (создаётся в init)
• ::flow/input-filter — предикат cid для фильтрации входных каналов

Хелперы

• lift*->step — из f(x) → coll делает step-fn с одним входом и выходом
• lift1->step — то же, но f(x) → single-value
• map->step — из карты с ключами :describe, :init, :transition, :transform строит step-fn

Запуск процесса

Функция process принимает step-fn и опции:

• ::workload — :mixed, :io, :compute
• :compute-timeout-ms — таймаут для :compute (по умолчанию 5000 мс)

• Участники обсуждают, жив ли Clojure: сообщество стабильно, но менее хайповое; NuBank расширяет core-команду и нанимает Developer Advocate.
• core.async.flow предлагает декларативный, фиксированный граф каналов для «структурированной конкурентности»; ошибки и паузы можно отслеживать, но изменять топологию на лету пока нельзя.
• Сравнивают с GenStage (Elixir), Manifold, Trio и missionary/electric; можно использовать как OS-, так и green-потоки.
• JVM-тулчейн вызывает у новичков страх, но Leiningen/deps.edn упрощают работу, а отладка всё же возможна.
• Clojure-окосистема активно развивается: Babashka, XTDB, Dyna3 и другие проекты; язык недавно получил мажорный релиз и готовится к виртуальным потокам JVM.

Hey folks, this is the 7th book in a series of readings I run over Google Groups. There are about 1800 people in the group and 300-800 join each reading. While we often read books on database internals this one seems pretty relevant to any developer working on systems that scale.