Forem: Maksim Iakovlev

Shik — I finally feel joy writing scripts

Maksim Iakovlev — Wed, 15 Apr 2026 09:16:34 +0000

You know that feeling when the thought in your head is simple and clear — "go through files, find the right ones, move them" — but between the thought and the result there's a wall of googling flags, quoting rules, and incompatible utilities?

I've been into language design for a while — what interests me most is syntax, how form shapes thinking. When I decided to build a complete language, I picked the area where I was most frustrated and where nothing fit my taste — terminal scripting.

Where the joy disappeared

Here's a task: find files containing the string "- links", move them to a topics/ folder.

In your head, that's one sentence. In the terminal, it turns into this:

for file in *; do
    if [ -f "$file" ] && grep -q -- "- links" "$file"; then
        mv "$file" topics/
    fi
done

Every line is a small minefield. Quotes around "$file" — forget them, blow up on a space in the name. grep -q — or was it -l? Or -s? -- before the string — why? Oh, because of the dash. Five lines, four traps.

An experienced will say: grep -l "- links" * | xargs mv -t topics/ — one line! Sure. But which grep flag prints filenames — -l or -L? xargs mv — what order do the arguments go in? -t — is that target? What about spaces in names? Every single time — the task takes a second in your head, five minutes on Google or AI. Every time — not your solution, you just copied someone's code and hope it works.

Or count lines across all .rs files. In your head: "find → read → count → sum." In the terminal: find + xargs + wc + awk — four utilities, each with its own universe of flags.

Here's the thing. It's not because bash is bad. Bash is a good shell. Fish and friends (Nushell, Elvish) are reimagined shells. Python/Node.js/Ruby are powerful languages built for backend work. None of them were designed to make chaining actions in a terminal feel good to type. Each has its own focus, and scripting everyday chores is a side effect.

I didn't want another shell or another general-purpose language. I needed thoughts to flow from my head into the terminal without friction.

Where it came back

I built Shik. Here's that same task:

file.glob :./* $>
  list.filter file.is-file $>
  list.filter (fn [f] file.read f $> string.has "- links") $>
  list.iterate (file.move :topics)

Four lines. Each one is a single step. Data flows top to bottom, left to right. Pure functions only, functions return primitive data (list/string/number/bool), functions compose and curry. Reads like the thought.

Count lines:

file.glob :./src/**/*.rs $>
  list.map (file.read #> string.lines #> list.len) $>
  list.sum $>
  print

This is where I felt it: this is it. I think "find files → read → split into lines → count → sum → print" — and I type exactly that. One to one. Thought = code.

One rule for the whole language

The design grew out of Lisp and Haskell, adapted for the terminal. During development I deliberately kept using the most primitive REPL — arrow keys didn't even work. If the language is comfortable to use even under those conditions, the syntax works.

Everything is function application. + 1 2 isn't an operator — it's calling the function + with arguments 1 and 2. list.map, file.glob, string.upper — also functions. if, let, while — also functions. One rule, and you know the whole language. list.map is not a function map from module list — it's the full name of the function, the dot is part of the name!

Space is application:

file.glob :./src/**/*.rs

Literally: "apply :./src/**/*.rs to the function file.glob." Like f(x), but without parentheses.

Currying gives you free combinators. Pass fewer arguments than a function expects — get a new function back:

let lst [1 2 3 4]

lst $> list.map (+ 1)   ; [2 3 4  5]
lst $> list.map (- 1)   ; [0 1 2  3]
lst $> list.map (* 2)   ; [2 4 6  8]
lst $> list.map (^ 2)   ; [1 4 9 16]

(+ 1) is a function meaning "add one." (* 2) is "multiply by two." Uniform, no lambdas needed.

But why does (- 1) mean "subtract one" and not "subtract from one"? This is a deliberate, heretical decision! In Shik, argument order is a design choice — everything is built around currying. For arithmetic: the first argument is the modifier, the second is the base. - 1 5 = 4, because 1 is "how much to subtract" and 5 is "from what." If - worked as "first minus second," (- 1) would mean "one minus something," and you'd have to write fn [x] - x 1 or introduce flip. You can read more about the argument ordering philosophy in the docs.

Four operators — that's it. All about application, composition, and most importantly precedence — from tightest binding to loosest:

Operator	What it does	Example
(space)	function application	`f x`
`#>`	composition	`file.read #> string.lines`
`$`	low-precedence application	`print $ + 1 2`
`$>`	left-to-right pipe	`x $> f`

This is the entire flow control syntax. Nothing else. Everything else is combinations of these four things.

These operators fix the main problem with using Lisp in a terminal. Instead of:

print (list.sum (list.map (fn [path] list.len (string.lines (file.read path))) (file.glob :./src/**/*.rs)))

You write:

file.glob :./src/**/*.rs $>
  list.map (file.read #> string.lines #> list.len) $>
  list.sum $>
  print

These two are fully equivalent and both valid Shik code!

Ready out of the box: file., string., list., object., shell. — available without imports. Open the REPL and start working. help list. shows all list functions.

Syntax in five minutes

Everything you need to know:

; Literals
42                     ; number
"hello world"          ; string
:hello                 ; also a string — for words without spaces (faster to type!)
[1 2 3]                ; list
{:name :Alice :age 30} ; object
fn [arg] body          ; function

; Variables
let name :Alice
let greet fn [name] "Hello, {name}!"  ; {expression} — interpolation
print $ greet name                     ; Hello, Alice!

; Composition — gluing functions together
let read-lines (file.read #> string.lines)
read-lines :.gitignore    ; ["target" "docs" "releases"]

; Multi-line functions
let reverse fn [str] '(
    let reversed ""
    str $> string.iterate-backward (string.push reversed)
    reversed ; last expression is the result
)

; Destructuring
let head fn [[x _]] x
head [1 2 3] ; 1

; Pattern matching
match [1 2 3 4] {
  []            :empty
  [x y #rest]   "first: {x}, rest: {rest}"
}
; "first: 1, rest: [3 4]"

; External commands
shell "git log --oneline -5" $> print
shell.lines "git branch" $>
  list.filter (string.has :feature) $>
  list.iterate print

That's it. Seriously. If you've read this block, you know Shik. If you interesting in details, you can read the book!

Now — the real tasks this was all built for.

In practice

Find all TODOs in a project and print a report, sorted by count descending:

let has-todo (file.read #> string.has :TODO)
let count-todos (file.read #> string.lines #> list.filter (string.has :TODO) #> list.len)

file.glob :./src/**/*.rs $>
  list.filter has-todo $>
  ;; turn list of paths into [path todo_count]
  list.map (fn [f] [f (count-todos f)]) $>
  list.sort (fn [[_ a] [_ b]] - a b) $>
  list.iterate (fn [[file n]] print "{file}: {n} TODOs")

Seven lines. has-todo and count-todos are assembled by gluing existing functions with #>. No classes, objects, modules, or imports. Just: "read → check" and "read → split → filter → count."

Config backup across machines — the script I used to debug the entire language:

let HOME shell.home
let make-path fn [dir] "{HOME}/.config/{dir}"
let$ [KITTY-PATH FISH-PATH] [(make-path :kitty) (make-path :fish)]

let FISH-FILES [:fish_plugins :functions/start.fish :functions/gr.fish]
let KITTY-FILES $ file.list KITTY-PATH
let HOME-FILES [:.ghci :.gitconfig]

let make-copier fn [files from dest] fn [] '(
  files $> list.iterate fn [file] '(
    print "Copy: {from}/{file} -> {dest}/{file}"
    file.copy "{dest}/{file}" "{from}/{file}"
  )
)

let sync-fish  $ make-copier FISH-FILES FISH-PATH :fish
let sync-home  $ make-copier HOME-FILES HOME :home
let install-fish  $ make-copier FISH-FILES :fish FISH-PATH
let install-home  $ make-copier HOME-FILES :home HOME

; Run: shik backup.shk sync fish home
let options $ list.drop 2 shell.args
let mode $ list.head options
let targets (if (list.empty? $ list.tail options) [:fish :home :kitty] (list.tail options))

targets $>
  list.map (+ "{mode}-" #> var.get) $>
  list.iterate fn.invoke

The last three lines are my favorite part. (+ "{mode}-") prepends a prefix, var.get turns the string "sync-fish" into the variable sync-fish, fn.invoke calls it. Strings → names → functions → result. Shik deliberately trades strictness for flexibility — and that's exactly the tradeoff that makes scripting fun.

Performance

Shik is written in Rust. I didn't make performance the primary focus, but I optimized where it didn't add complexity.

It has its own parser and tree-walk interpreter, no tracing GC — memory management via Rc/RefCell, all built-in functions are written in Rust. IO-bound operations run fast. Line counting across the Shik project itself (~9,800 lines, 37 files):

Shik:

file.glob :./src/**/*.rs $>
  list.map (file.read-lines #> list.len) $>
  list.sum $> print

Bash:

find ./src -name '*.rs' -exec cat {} + | wc -l

Python:

from pathlib import Path
print(sum(len(f.read_text().splitlines()) for f in Path('./src').rglob('*.rs')))

Benchmarks via hyperfine --warmup 3 -N, macOS, Apple Silicon:

Shik:
- Time: 4.4 ms
- Memory: 2.6 MB
Bash:
- Time: 9.1 ms
- Memory: 2.1 MB
Python:
- Time: 30.3 ms
- Memory: 12 MB

However, on CPU-bound algorithmic work with heavy application and branching — e.g. a dice game win calculator — Shik loses to Python by roughly 10x. Optimization is planned, but the focus will always be on syntax ergonomics and writing comfort.

Try it

# Via cargo
cargo install shik

# macOS / Linux
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/pungy/shik/releases/latest/download/shik-installer.sh | sh

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://github.com/pungy/shik/releases/latest/download/shik-installer.ps1 | iex"

shik              # REPL — try typing help inside
shik script.shk   # run a file

The project is in active development (v0.7.1). This is not a production-ready tool — it's a thing I use every day and genuinely enjoy using.

Planned: shebang support, regex, JSON parsing, networking, try/catch, multithreading.

Shik won't replace bash — it's not a shell. It won't replace Python for bots. But if every couple of days you need to move, filter, rename, or generate a report — and every time you spend more time fighting the tool than solving the problem — give it a shot. You might find some joy in it too.

GitHub
Shik Book

Type Variance Clearly

Maksim Iakovlev — Wed, 17 Sep 2025 11:47:42 +0000

In type theory, variance describes the relationship between two generic types. For example, it defines the circumstances under which a parent type can be replaced by a child type, and when it cannot, and so on.

You can find many resources on this topic, especially ones that are lengthy and written in a complex, formal, and architectural language. I wanted to create a short and simple cheat sheet (with a few sprinklings of formalism) that you can easily refer back to if you happen to forget the details.

Covariance

A covariant relationship represents the usual subtype relationship, where a narrower/child type can be used where a wider/parent type is expected. For example:

I can place a Cat where any Animal can be.
But I cannot place any Animal where only a Cat can be.

class Animal {
    genus: string;
}
class Cat extends Animal {
    clawSize: number;
}

function move(animal: Animal) {}
function meow(cat: Cat) {}

move(new Cat()); // Any cat can move
meow(new Animal()); // Not every animal can meow

Formally: You can use B where A is expected if B is a subtype of A (B < A).

// V is in the return value position (output)
type Covariant<V> = () => V;

// Where Animal is the wider type (W), and Cat is the narrower type (N)
function covariance(
    covW: Covariant<Animal>,
    covN: Covariant<Cat>,
) {
  covW = covN; // OK. A function that returns a Cat can replace a function that returns an Animal.
  covN = covW; // Error! You can't be sure that a function returning an Animal will return a Cat.
}

Contravariance

Contravariance is the opposite of covariance. It is, perhaps, the most difficult type of variance to understand. In the case of contravariance, a wider/parent type can be used where a narrower/child type is expected.

Under what circumstances might this happen? Imagine a processor. For example, a processor for general animal food that enriches it with protein (let's assume this is beneficial for any animal). And a processor for cat food that gives it a fishier taste (silly, but it doesn't matter).

So, can you process cat food with a general animal food processor? Of course, more protein won't harm a cat.
And can you process any animal food with a cat food processor? I think not—not everyone likes a fishy taste.

Let's repeat:

I can process Cat food in the same way that any Animal food is processed.
But I cannot process Animal food in the same way that Cat food is processed.

class AnimalFood {
  protein: number = 0
}
class CatFood extends AnimalFood {
  fishness: number = 0
}

function processAnimalFood(animalFood: AnimalFood): void {
  // Add some protein //
}
function processCatFood(catFood: CatFood): void {
  // Give it a fishy taste //
}

/**
 * We process the food before serving
 */
function serveAnimalFood(processor: (food: AnimalFood) => void): void {
    const food = new AnimalFood();
    processor(food);
}
function serveCatFood(processor: (food: CatFood) => void): void {
    const food = new CatFood();
    processor(food);
}

// We can't use the cat food processor to serve animal food!
// Not all animals like a fishy taste!
serveAnimalFood(processCatFood);

// You can use the general animal food processor to serve cat food.
// The protein will be good for the cat.
serveCatFood(processAnimalFood);

In type theory: You can use a processor for A where a processor for B is expected if B is a subtype of A (B < A).

// V is in the parameter position (input)
type Contravariant<V> = (v: V) => void;

// Where Animal is the wider type (W), and Cat is the narrower type (N)
function contravariance(
    contraW: Contravariant<Animal>,
    contraN: Contravariant<Cat>,
) {
  contraW = contraN; // Error! A processor for cat food cannot process any food.
  contraN = contraW; // OK! A general food processor can also handle cat food.
}

Invariance

Invariance is simpler. It represents a lack of interchangeability. In nominative type systems, like in C, this is the only kind of variance. A real-world example of this relationship can be found in waste sorting.

There is the general concept of Waste and its specific varieties, such as Paper Waste, Food Waste, etc.
And if your waste is classified and there is a suitable container for it, you must use that container and only that one.

class Waste {
  readonly type = 'non-recyclable';
}
class FoodWaste extends Waste {
  readonly type = 'organic';
}

function unrecycledBin(waste: Waste) {}
function organicBin(waste: FoodWaste) {}

unrecycledBin(new FoodWaste()); // You can't throw food waste into the container for non-recyclables! Do the right thing!
organicBin(new Waste()); // You can't throw unsorted waste into the organic container, are you a criminal???

Formally: You can only use A where A is expected.

// V is in both an input and output position
type Invariant<V> = (v: V) => V;

function invariance(
    inW: Invariant<Animal>,
    inN: Invariant<Cat>,
) {
  inW = inN; // Error! The types are not interchangeable.
  inN = inW; // Error! Same thing.
}

Bivariance

The opposite of invariance. Bivariance is complete interchangeability, where type A can be replaced by B and vice versa.

In TypeScript, bivariance isn't common, but it does exist. For example, as we found out earlier, function parameters are contravariant. But there are exceptions: method parameters are bivariant.

type Bivariant<V> = {
    process(v: V): void;
}

function bivariance(
    biW: Bivariant<Animal>,
    biN: Bivariant<Cat>,
) {
  biW = biN; // OK!
  biN = biW; // OK!
}

This behavior was chosen by the creators of TypeScript for greater flexibility, although it is theoretically less sound. It can be changed using explicit variance annotations.

// The `in` keyword in generics makes the type Contravariant
type ContravariantMethod<in V> = {
    process(v: V): void;
}

function contravariance(
    contraW: ContravariantMethod<Animal>,
    contraN: ContravariantMethod<Cat>,
) {
  contraW = contraN; // Error! This is now strict contravariance.
  contraN = contraW; // OK!
}

Cheat sheet

Variance	Rule	Type	Example
Covariance	`Child -> Parent`	Output	`() => T`
Contravariance	`Parent -> Child`	Input	`(arg: T) => void`
Invariance	`Type -> Type`	Output and Input	`(arg: T) => T`
Bivariance	`Child <-> Parent`	Input (method)	`{ method(arg: T) }`

References:

Introducing REROI: Explicit and Robust Reactivity for Modern JavaScript

Maksim Iakovlev — Sun, 31 Aug 2025 09:39:07 +0000

Motivation

Reactivity is one of the most influential concepts in modern front-end development. Applications are expected to update promptly, propagate changes through complex data relationships, and remain reliable as they evolve.

Most established reactive libraries—such as MobX, Vue's reactivity system, and Svelte—offer developers tremendous convenience and power. I have used them extensively, and the convenience they offer is impressive. For example, MobX can make your values "magically" reactive with minimal boilerplate.

However, while using them for the development of complex systems, I've encountered issues like layers of implicit behavior, syntax restrictions, and a lack of control. Other solutions, like RxJS, offer granular control but come with the steep learning curve of Functional-Reactive Programming, which developers must fully adopt. Improper use can often lead to chaotic, hard-to-debug code.

reroi was created out of a desire to rebalance reactivity in favor of clarity, predictability, and a greater level of control, even if it comes at the cost of some convenience. It aims to reveal the entire path of state change, so that every mutation, every dependency, every notification, and the order of execution are plainly visible and subject to the developer’s intent.

Why would you need this? For real-time applications with large and complex codebases, the "simplicity" of tools like MobX can lead to difficult questions: "What is the full list of dependencies for this computed property?", "What would happen if I make this getter a computed property?", or "How do I ensure the reaction C executes after reaction A but before reaction B?". In such cases, perceived simplicity becomes a bottleneck.

Overview

reroi achieves its goals through a set of core principles:

Every reactive object is a type-constructor(like a Promise).
Everything is explicit.
Everything can be controlled.
Everything is synchronous.
No Proxy is used; only plain objects and functions.
Performance: due to lack of huge computation on side and plain data structures, reroi is very fast and easy on memory.

import { val, deriveAll, listen. write, read } from 'reroi'

const _name_ = val("Alice")
const _surname_ = val("Liddell")
const _fullName_ = deriveAll(
    [_name_, _surname_],
    ([name, surname]) => `${name} ${surname}`
)

// Explicit subscription:
listen(
    _fullName_,
    name => console.log("User's full name:", name)
)

write(_name_, "Jane") // User's full name: Jane Liddell
read(_fullName_) // "Jane Liddell"

The core concepts here will be familiar from other reactive systems:

Reactive Values: val (Read-Write).
Derivations: derive/deriveAll (Read-only).
Listeners: listen/listenAll (Fires an effect on change).
Reading: read (Returns the current state of a reactive object).
Writing: write (Sets a new state for a reactive value).

What Makes reroi Unique

From the example above, one might think reroi is just another syntax for the same concepts. However, it provides unique capabilities:

1. Controlling evaluation order

Priorities API

Typically, synchronous libraries build a dependency tree, detect and resolve circular dependencies, and rebalance the execution order automatically.

Let's imagine the following cart store, which calculates price, shipping fees, and tax to display a total. Code here is written with MobX library:

import { makeObservable, observable, computed } from 'mobx'

class Cart {
  price = 0

  constructor() {
    makeObservable(this, {
      price: observable,
      shipping: computed,
      tax: computed,
      showTotal: computed,
    })
  }

  get shipping() {
    return this.price > 50 ? 0 : 5.00
  }
  get tax() {
    return this.price * 0.08 // 8%
  }

  get showTotal() {
    const total = this.price + this.tax + this.shipping
    return `Final price: $${total.toFixed(2)} (incl. tax: $${this.tax.toFixed(2)}, shipping: $${this.shipping.toFixed(2)})`
  }
}

const cart = new Cart()

cart.price = 20
console.log(cart.showTotal) // Final price: $26.60 (incl. tax: $1.60, shipping: $5.00)

Here, showTotal computed has three dependencies: price, tax, and shipping. shipping and tax depend on the single observable price, and it also understands that showTotal should be re-evaluated only after shipping and tax have been updated. An abstract dependency graph would looks like this:

   _price_
 /    |    \
⌄     |     ⌄
tax   |  shipping
 \    |    /
  ⌄   ⌄   ⌄
  showTotal

Most importantly, after updating price, showTotal should be updated only once! If each dependency triggered its own update, showTotal would re-evaluate multiple times unnecessarily!

Does reroi solve this diamond dependency problem automatically? No, it doesn't! But instead, it gives you a powerful tool to solve it yourself: priorities.

You declare these relationships explicitly:

const _price_ = val(0)

const _tax_ = derive(
  _price_,
  price => price * 0.08, // 8% tax
)
const _shipping_ = derive(
  _price_,
  price => price > 50 ? 0 : 5.00, // free shipping over $50
)

const _totalSummary_ = derive(
  _price_, // We only need to subscribe to the root dependency.
  (price) => {
    // We read the latest values of other derivations inside.
    const tax = read(_tax_)
    const shipping = read(_shipping_)
    const total = price + tax + shipping
    return `Final price: $${total.toFixed(2)} (incl. tax: $${tax.toFixed(2)}, shipping: $${shipping.toFixed(2)})`
  },
  // Set priority: execute this derivation *after* the base level.
  { priority: priorities.after(priorities.base) },
)

write(_price_, 20.00)

console.log(read(_totalSummary_)) // Final price: $26.60 (incl. tax: $1.60, shipping: $5.00)

Resolved graph of dependencies above would build a following timeline of updates:

_price_
 |
 +---> _tax_
 +---> _shipping_
 |
 +---> _totalSummary_

Every derive and listen accepts a priority option. This allows you to declare the order of execution. Here, _totalSummary_ depends on _price_, and its update is scheduled after the base priority pool, where dependencies like _tax_ and _shipping_ are placed by default.

Priority is simply a number. priorities.after(priorities.base) is a readable helper for -1. The execution order looks like this:

HIGHER
 0: [_tax_, _shipping_]
-1: [_totalSummary_]
LOWER

And yeah, it is really just a number, the higher the number, the higher the priority:

const _msg_ = val("")
const log = console.log

listen(_msg_, (msg) => log("3: " + msg), { priority: 3 })
listen(_msg_, (msg) => log("2: " + msg), { priority: 2 })
listen(_msg_, (msg) => log("4: " + msg), { priority: 4 })
listen(_msg_, (msg) => log("1: " + msg), { priority: 1 })

write(_msg_, "Hi?")

// 4: Hi?
// 3: Hi?
// 2: Hi?
// 1: Hi?

2. Transactions

Transactions API

Batching changes is a common feature in reactive systems. In reroi, the approach might look different at first, but it is highly controllable and powerful.

Lazy write

A reroi transaction is essentially a delayed write.

const _name_ = val('Mike')

const transaction = transaction.write(_name_, 'MIKE')
read(_name_) // Mike

transaction.run()
read(_name_) // MIKE

Are there other differences from a standard write? Yes—we can also reject a write, preventing the state from changing.

const _counter_ = val(1)

const inc = () => transaction.write(
    _counter_,
    count => {
        if (count < 3)
            return transaction.success(count + 1)
        else
            return transaction.error() 
    },
)

let result = inc().run()
console.log(read(_counter_), transaction.isSuccess(result)) // 2, true

result = inc().run()
console.log(read(_counter_), transaction.isSuccess(result)) // 3, true

result = inc().run()
console.log(read(_counter_), transaction.isSuccess(result)) // 3, false

This is an incredibly useful concept. You can pass transactions around as objects and operate on them without needing to know what they write to—you only need to deal with the transaction itself!

Here is an example with graphics redrawing on transaction success!

import { val, read, transaction, ReactiveTransaction, ReactiveValue } from 'reroi'

class Graphics {
    // ...
    addObject(object: ReactiveValue<{ x: number; y: number }>): void
    redraw(): void
}
const graphics = new Graphics()

/**
 * Execute transaction and redraw graphics on success
 */
function update(transaction: ReactiveTransaction) {
    const res = transaction.run()
    if (transaction.isSuccess(res)) {
        graphics.redraw();
    }
}

const player = val({ x: 0, y: 0 })
const enemy = val({ x: 10, y: 0 })

// register objects
graphics.addObject(player)
graphics.addObject(enemy)

const movePlayer = transaction.write(_player_, player => {
    player.x += 10;
    return transaction.success(player)
}

// if moving would be successful - scene would be redrawed!
update(movePlayer)

Composing Writes

But the core of transaction is batching changes together! How does a lazy write help here? The answer is: we can compose multiple writes into a single, atomic transaction.

const _name_ = val("Alice")
const _surname_ = val("Liddell")
const _fullName_ = deriveAll(
    [_name_, _surname_],
    ([name, surname]) => `${name} ${surname}`
)

listen(
    _fullName_,
    (full) => console.log(`The full name is: ${full}`),
)

const nameTransaction = transaction.compose(
    transaction.write(_name_, "Mark"),
    transaction.write(_surname_, "Smith"),
)

nameTransaction.run()
// The full name is: Mark Smith

If we would make this writes one by one, the listener would be triggered twice. With a composed transaction - only once!

Canceling Transactions

Another important aspect of transactions is atomicity: all changes are rejected if any single part of the transaction is an error. This prevents the application from entering a broken or inconsistent state. reroi follows this principle with the error() state.

const _name_ = val("Alice")
const _surname_ = val("Liddell")
const _age_ = val(22)
const _userinfo_ = deriveAll(
    [_name_, _surname_, _age_],
    ([name, surname, age]) => `${name} ${surname}, ${age}`
)

listen(
    _userinfo_,
    (info) => console.log(`user info: ${info}`),
)

const update = transaction.compose(
    transaction.write(_name_, "Mark"),
    transaction.write(_surname_, () => transaction.error("NOT FOUND")),
    transaction.write(_age_, 30),
)

update.run() // listener wasn't triggered
read(_userinfo_) // "Alice Liddell, 22" (state remains unchanged)

That's not all about transactions. Important questions might appear: how can I see updated value of previously succeeded transactions in composition list? How can I read updated state of dependended computed?

If you are interested in answers, you can find them in Composing Transactions section in README!

3. No Hidden Memoization

As you've seen, reroi does nothing behind your back. If you call write, it writes the new value and notifies all its listeners, period. This also means you are not forced to use immutable data structures.

const _cart_ = val<Array<number>>([])
const _cartSum_ = derive(
    _cart_,
    cart => cart.reduce((acc, item) => acc + item, 0)
)

// This function mutates the array directly.
const pushToCart = (item: number) => {
    write(_cart_, cart => {
        cart.push(item)
        // We must return the mutated array to signal a change.
        return cart
    })
}

pushToCart(5)
pushToCart(5)
pushToCart(5)

read(_cartSum_) // 15

4. Dynamic Dependencies

Because reactive objects in reroi are first-class citizens, they can be nested inside one another. This powerful feature allows you to create dynamic dependencies, where a derived value can switch its underlying sources based on application state.

Imagine a scenario where a _son_ reactive value reflects different sources based on his _age_. When under 18, his "voice" is derived from his parents (_mommy_ and _daddy_). Once he turns 18, his voice becomes his own, represented by a separate, writable reactive source (_matureSon_).

const _mommy_ = val("Eat your breakfast");
const _daddy_ = val("Go to school");

const _age_ = val(10);

const _matureSon_ = val("...");
const _youngSon_ = derive(
    [_mommy_, _daddy_],
    (mommy, daddy) => `Mommy said: "${mommy}", Daddy said: "${daddy}"`
);

// This derivation returns another reactive object, not a simple value.
const _son_ = derive(
    _age_,
    age => (age >= 18 ? _matureSon_ : _youngSon_)
);

// To get the final value, you must 'unwrap' it twice:
// 1. read(_son_) -> returns either _matureSon_ or _youngSon_
// 2. read( ... ) -> reads the value from that inner object
console.log(read(read(_son_))); // Mommy said: "Eat your breakfast", Daddy said: "Go to school"

write(_age_, 20);

// Now, _son_ points to _matureSon_
console.log(read(read(_son_))); // "..."

// We can now write directly to the new source
const currentSonSource = read(_son_);
write(currentSonSource, "I want to be a musician");

console.log(read(read(_son_))); // "I want to be a musician"

While this example is intentionally simple, this pattern requires careful consideration in real-world applications. When a dependency is switched (e.g., from _youngSon_ to _matureSon_), the old source (_youngSon_) is no longer tracked by _son_, and all subscribes to old source is still active. So, for more complex objects, you should be mindful of memory management and may need to use tools like destroy to properly unsubscribe and clean up unused reactive objects, preventing potential memory leaks.

Summary

If you are looking for a robust, low-overhead, and easy-to-adopt reactive library that isn't tightly coupled to a specific framework like React, reroi might be a great fit for you. It trades implicit convenience for explicit control, giving you the power to build predictable and highly performant state management systems.