Last conversion of the Campfire from my token stash goes to JavaScript/Express. As with the others, I'm sure you can find more to optimize. But this gives you a sense of what order of magnitude these options exist within with agent-led development. https://t.co/UUapL99SJE https://t.co/2H2NXfeZog

— DHH (@dhh) October 5, 2026

I won’t defend him this time. A one-shot conversion, done by an agent, with no fine-tuning at all, doesn’t measure language: it measures how much the model knows each stack’s idioms. It’s rage bait and he knows it. That said, I do the same from time to time, and so do half his critics, so we’re all hypocrites and life goes on.

And the weak spot of his methodology became a topic of its own: several people noticed the Rust version had gone through far more agent iterations than the others, meaning more optimization rounds. @kurtome answered in practice: he took the Elixir version and sped up the main page requests 10x, with obvious optimizations that no first conversion does, like caching and async database connection pooling.

@dhh Here you go https://t.co/gUtK7Z7zG7

got a 10x speed up on the Room page requests, and sped up all the other requests significantly as well. the biggest gains came from some no brainers: implement caching and pool the db connections with proper async https://t.co/mbp94q9N0s

— kurt (.com) (@kurtome) October 5, 2026

His comparison, then, wasn’t “Rust versus Elixir”: it was “Rust after N tuning rounds versus Elixir after one.” And that lays bare the truth the thread pretends to ignore: no real software ships from half a dozen prompts. Coding with AI shines when an experienced engineer steers the agent toward their goal, and that means dozens of iterations, not three.

The good part is that the bait was useful to me. I’ve been doing LLM benchmarks and decision-model benchmarks, but I had never measured, in a reproducible way, the question that thread pretended to answer: does it matter which language you pick when the one writing the code is an LLM? My short answer was already out in two posts of mine:

Pressure under load is not a trivial problem to solve from scratch and I recommend you do not attempt to. It's a solved problem already and all solutions converge to what Elixir already brings out of the box. So yes. I use Rust all the time, but if I had to solve high scalability problems (particularly high volume message queues), I would think of Elixir first.

— Fabio Akita (@AkitaOnRails) October 9, 2026

Language wars are tiresome. And the reality is simpler if you're doing AI assisted coding.

- system level (drivers, fs, daemons, etc): Rust. C++ is you're extending existing legacy
- windows only desktop apps: C#
- iOS/MacOS/iPadOS: Swift
- multi-OS: Rust/Tauri, Qt/C++, Flutter, Electron (pick your poison)
- simple websites: Node/Typescript/Bun/Deno
- highly scalable backend: Elixir, parts in Rust, parts in Go
- CLI tools: Rust

Everything else, by default, Rust. Unless it's an edge case.

— Fabio Akita (@AkitaOnRails) October 9, 2026

There’s no better language, there’s the right tool

That list from the post isn’t a ranking, it’s a terrain map. Every language and every framework was designed for a use case, and none covers them all. That was true when you wrote every line by hand and it stays true with agents. The LLM doesn’t change the physics of the problem: it only changes who’s typing.

And the map goes beyond language. A real system has infrastructure around it: Kubernetes when scale asks for it, SQLite by default because most apps never need more than that, Postgres with pgBouncer when they do, Redis for cache and key-value, RabbitMQ or NATS for queues. Picking “the stack” on day zero and expecting it to last ten years is fantasy. It doesn’t, and that’s fine.

Personal example: new web app, I open Ruby on Rails without thinking twice. It’s the most complete end-to-end solution there is for the web, and with an LLM writing most of the code, the framework’s productivity weighs even more than the language’s. As the system grows, I swap the parts that ask for another tool: a high-volume queue leaves Rails’ side and goes to something from Erlang land, starting with RabbitMQ, which already solves the hard backpressure part for me.

No good software is finished: it grows. Usage dictates what you replace, rewrite and add. The final architecture is never the first commit’s, and whoever tries to get everything right in the first commit only produces dead documents.

The token superstition

DHH’s thread resurrected two beliefs that have been circulating since LLMs became work tools:

• “Script languages are better for AI because the lean syntax spends fewer tokens.”
• “Strongly typed languages are better for AI because the compiler catches the errors, so you need less testing and less repair.”

Both sound reasonable and both are superstition until someone measures. I was betting against both, from experience: a good compiler helps, but it doesn’t do magic, and syntax conciseness was never the bottleneck of an agent that reads and writes files all day.

What really separates a project that moves from a project that spins in circles is test discipline. I’ve written that TDD became a technical obligation, not a philosophy, and this post’s benchmark is one more data point in the same direction. It doesn’t matter whether you do test-first or test-after: what matters is that the suite grows with the code, that every user-reported bug becomes a regression test before the fix, and that you never make the same mistake twice. Software without users is dead software, so release early, release often, break fast and fix even faster. AI closes exactly that gap: the reproduce-test-fix cycle got cheap. QA became the programmer’s most valuable skill, far above “knowing Rust syntax.”

Discipline beats compiler and beats language. That was my hypothesis. Time to measure.

The benchmark

I built a reproducible experiment, public in the vibe-coding-benchmarks repository, with per-attempt results published in JSON and the raw traces kept out of the repo for credential containment. It’s not a language championship, and the design itself says so: it’s a snapshot of one real task, measuring what can be honestly measured.

The task

One task only, on purpose: maintain a multi-tenant ledger engine. The agent receives working v1 code and has to take it to a v2 contract, with per-tenant identities, authorization, serializable snapshots, a unique secondary index with alias swap, a capacity-bounded journal, torn-group recovery, checkpointing, legacy schema migration and durable retry IDs. It’s not FizzBuzz: it’s the kind of system that demands invariants across operations, exactly where LLMs tend to trip.

Correctness is judged by 43 test stories applied after collection, out of the agent’s sight: the 27 public ones from T1 plus 16 hidden ones. Passing is 43 out of 43. The conditions:

• T0: prose contract, input and output examples, a working launcher. No test suite.
• T1: the same, plus 27 public stories and a driver to run them.

Each attempt had a 15-minute budget, with at most two 3-minute continuations. In practice, none of the 112 needed a continuation.

The languages and the models

Seven languages in three strata, with pinned toolchains and Rust in safe mode:

• Typed natives: Rust (safe, pinned), Haskell (pinned GHC).
• Typed VMs: C# (with nullable analysis), Kotlin, TypeScript (strict, noUncheckedIndexedAccess, exactOptionalPropertyTypes).
• Dynamic scripts: Python and Ruby, no checker at all.

Four model configurations, all on subscriptions, no paid fallback: Kimi K3 (high), GLM 5.3 via OpenCode (high), Claude Opus 5.5 (medium) and Codex with gpt-6 Sol (medium). Crossing everything: 7 languages × 4 models × 2 conditions × 2 repetitions = 112 attempts.

What this design doesn’t measure

Before the numbers, the brakes, because they’re part of the result. It’s a single task, with two repetitions per cell: a small sample by construction. Token coverage is partial in some models (missing data is not zero). The harness changed mid-campaign across three instrumentation epochs. And provider delays contaminate wall time: one of the Opus attempts spent half the clock waiting for quota release. All numbers below are descriptive, and I point out where they can’t support a conclusion.

There’s one additional brake, on purpose: the iteration level. My design measures what can be reached in all languages with similar iteration levels, on a short budget, with no human tuning afterwards. It’s a photograph of the floor, not the ceiling. Any of the 112 implementations probably improves with more agent rounds, and the four queue stacks likewise: what I publish is what each language delivers “out of the factory” under the same effort, not the maximum a patient engineer would extract from it.

Mandatory disclaimer before quoting any number from this post around: every result that follows holds for this benchmark, with this task, these models, these prompts and this hardware. Your case may vary violently. If your task doesn’t look like a ledger engine, if your model isn’t one of these four, if your queue isn’t my queue, the numbers don’t transfer. The code, the tasks, the grades and the step-by-step to reproduce are all in the GitHub repository. And if you disagree with some result and that disagreement matters to your company or your project, the only honest attitude is the one I had: stop arguing and run your own benchmark.

Result 1: on correctness, the frontier models tied at the ceiling

Reading: Sol passed all 28 eligible attempts and Opus its 25 (the 3 failures were infrastructure, not code). 53 of 53 eligible attempts correct between the two. The task, made to be hard, was too easy to separate the frontier models, let alone the languages: with everyone passing everything, there’s no correctness ranking to publish.

The difference showed up in the weaker models, and in the direction my hypothesis predicted: provided tests helped. Kimi and GLM, with the public suite in hand (T1), delivered 24 correct artifacts against 16 without it (T0). Kimi, in particular, passed all 14 attempts with provided tests. It’s descriptive, not causal, but it’s the cleanest signal in the whole benchmark: what changed the outcome wasn’t the language, it was the presence of tests.

Per language, within each model, correctness scattered between 1/4 and 4/4 with no pattern that repeats across models. The three semantic failures I audited in depth are instructive: a GLM C# and a Kimi Python lost the same story by violating the same cross-operation invariant, and a Kimi Haskell missed a checkpoint path. None of the failures was a type error.

Where the model erred, it erred on domain invariants: the kind of error no compiler catches, in typed or dynamic languages. The myth that strong typing spares you the work of understanding the problem dies right there.

Result 2: concise language saved no tokens

Here’s the table that kills the first superstition. Medians per language on Sol, four valid attempts per cell:

Ruby, the most concise in lines (a bit over half of Rust’s), cost practically the same tokens as Rust on Sol, and on Opus it was the most expensive of all, about 205 thousand median tokens against C#’s 94 thousand. The cheapest were TypeScript and Python on Sol, C#, Haskell and Kotlin on Opus. If “fewer source code lines = fewer LLM tokens” were a law, Ruby should have led by a wide margin. It finished last.

And the second superstition? I audited the traces looking for the compiler-guided repair cycles that strong typing supposedly avoids. Result: zero compilation-error repair cycles in the audited Opus attempts, across Ruby, Rust and Haskell. Rust needed no compiler-driven fix at all; Haskell had one warning cleanup; Ruby spent its extra tokens on voluntary performance tuning. The frontier model almost always writes code that compiles on the first try, and the real effort goes to verification, not to appeasing the compiler.

One counterpoint that closes the coffin on the “cheap is good” thesis: GLM’s lowest token-consumption cells were the failures. TypeScript T0 at 50 thousand tokens looks efficient until you see it’s two unmodified starters because the model blew the output limit. Low tokens can mean early surrender.

Result 3: under load, everyone tied at the queue

Now for DHH’s question: Rust “beats” Elixir and Ruby when the subject is throughput. I built the separate track for that: four queue workers against a real RabbitMQ, written with agent help, each in its natural idiom:

• Elixir with OTP and Broadway
• Rust with Tokio and Lapin
• Rails with Bunny
• Plain Ruby with Bunny (control)

A generator published 10 thousand 4 KB messages to RabbitMQ, at 200 per second, and each worker consumed as fast as it could, hitting the effects on an HTTP/SQLite collector with a nominal 50 ms delay, limited to 2 CPUs and 1 GB of RAM. Two concurrency profiles:

On the 8-handler profile, the four stacks delivered the same throughput, 93 to 95 effects per second, and drained the whole queue. The apparent bottleneck was the shared collector (a Python lock, a single SQLite writer), not the languages. On the 64-handler profile, all of them left a backlog and blew the client timeout en masse, so I marked those cells as not qualified: the strong protocol, with a group-commit collector and a 50 to 800 msg/s ramp, is designed but not executed.

The only difference left standing in the numbers was memory: Rust held the peak at 16 MiB where the BEAM spent 135. It’s a real Rust advantage in density, with the caveat that a cgroup peak is not a language footprint. On throughput, which was the thread’s claim, a technical tie.

And the tie deserves an honest reading: it may only mean my pressure was too little. With the shared collector holding everything around 95 effects per second, any stack capable of more than that shows up as “equal.” What this test shows is where the bottleneck was, not where each stack breaks. To find each one’s ceiling I’d need the strong protocol, with a group-commit collector and a load ramp, which is designed but not executed. Until then, “all stacks perform the same” is the wrong conclusion; “all of them stayed above what my test could measure” is the right one.

And the question that interested me most, “does the agent work less to deliver a reliable queue consumer in Elixir than in Rust?”, was deliberately left unanswered: these four implementations were written to validate the environment, not as a controlled coding attempt. Comparing AI effort between Elixir and Rust would require the same ledger matrix running on the queue task. It’s on the list.

So, does the language matter?

With the data on the table, the thread’s three questions can be answered:

Is there a better language for programming with LLMs? None showed up. In the frontier models, correctness and effort varied less between languages than between models. Where there was a correctness difference, it followed the presence of provided tests, not syntax. “No general language ranking is established” is the report’s official sentence, and it’s the correct one.

Do the token-economy theses hold? Neither one. Conciseness didn’t save: Ruby cost as much as Rust, or more. Strong typing spared no repair: there was no type repair to spare. The models’ effort went to verification and understanding the contract, and that has no language.

Was DHH right? In what he measured, he measured what an agent delivers for free on each stack, without tuning, and called that a verdict on language. In my test, with real load and honest measurement, the four stacks tied on throughput in the stable regime, and only memory differentiated Rust. If his thread proves anything, it proves that agent conversion measures the model, not the language.

My bets from the introduction came out standing: testing and discipline are the lever, the compiler is a supporting actor, and the right tool depends on the problem. New web app is still Rails in my hand, heavy queue is still Erlang territory, low-level system is still Rust, and the LLM writes any of them with the same competence. Whoever spent the week fighting for their favorite language on X fought over nothing.

And my daily practice tells the same story. I have a personal bias toward Rust and even so I’ve published more than 30 open source projects in all kinds of stacks: ai-memory is Rust, FrankMD is Ruby on Rails, ai-memory-web and ai-jail-web are Node.js. In none of them did I feel any relevant difference that came from the stack: the wins were similar, the errors too, and the errors were always understandable. Every error became an invariant, a rule, a skill improvement. It never became a language switch.

So forget “token savings” and “typing superstition.” Do real software engineering: pick the right tool for your specific problem, apply proper engineering technique, and any reasonable agent will perform more or less the same. And stop wasting time arguing over language-war rage bait on the internet. Be a real software engineer and do real engineering. That’s it.

The per-attempt data, the full methodology and the evidence limits are in the repository. If you run the matrix with another task and find a ranking I didn’t, show me.

A language that promises to run near C speed, parallelize itself across CPU and GPU, and still formally verify that the code the AI wrote does what you asked. That’s a lot of promises stacked together. I had never touched Bend 1, so this is new territory for me too: on launch day, I pointed my agents at two of my Rust projects and told them to port them to Bend 2. The result of that test is the most interesting part of this article.

Before we start, the disclaimer: this is a review written on the second day of the language’s life, based on a one-day experiment. I may be wrong about several of my assumptions, and that’s fine. The comments are down below; feel free to correct and add to it.

Who Victor Taelin is

First things first, the author deserves an introduction. Victor Taelin is a Brazilian functional programming researcher who spent more than a decade obsessed with one specific problem: optimal reduction of the lambda calculus, Lamping’s 1990 algorithm, and then Lafont’s interaction nets.

His own autobiography tells the story: he worked at the Ethereum Foundation, created the Formality proof language, retired early on the ETH he stacked from salary, went back to the problem on his own dime, created HVM (the Higher-Order Virtual Machine), and founded the Higher Order Company, which raised a $4 million seed to turn the research into a product.

And here’s a point that matters a lot to me: I love seeing a Brazilian doing serious programming language design work. We barely have real cutting-edge research in this country, let alone in computing fundamentals. For that alone, Taelin already has my respect and my congratulations for what he’s built so far.

So let it be on record: every criticism in this article is constructive, from someone rooting for Bend to go further. Nothing against him or the project.

Where Bend comes from

The first version of Bend showed up in May 2024, with Python-like syntax running on top of HVM2, and the promise of automatic parallelism: write sequential code, the runtime spreads it across every core and even the GPU, no threads, no locks, no mutexes.

The launch went viral. Almost a thousand points on Hacker News, over 20 thousand GitHub stars, a Fireship video. And then reality hit: the HN thread was merciless. 24-bit numbers, no FFI, a simple sum taking 42 minutes on a user’s machine, single-core C++ beating the demo’s RTX 4090. Taelin himself admitted back then that the codegen was bad, and admitted now, in the Bend 2 thread, that the 2024 hype didn’t convert into usage: “there is also my own failure into making the language actually be used, rather than just a viral moment”.

Bend 2 is the answer to that. And pay attention: it’s a different language. The README is explicit that Bend 1 programs don’t load. Interaction-graph evaluation (HVM) is out; native compilation to a single C file is in, with clang for CPU and Metal or CUDA for GPU. Numbers are now real Nat, U32, and F32, and the memory limit jumped from 2 GB to 8 TB, according to gihyo’s Japanese announcement. Interaction nets stay in the architecture, but in his words, “inets live in it architecturally, but they don’t exist at runtime”.

What Bend 2 promises

The new pitch now revolves around AI. The project page sells a “post-AGI” vision: humans will stop writing and reading code, so we need an ambiguity-free way to tell the AIs what we want. Bend’s solution is splitting the program into two files:

• LAWS.bend: the system’s invariants, written by the human.
• PROOF.bend: the proofs of those laws, written by the AI.

Bend’s type checker is a proof checker, in the lineage of Lean and Rocq, so bend PROOF.bend becomes a commit gate: if the proof doesn’t close, the code doesn’t ship. The site’s demo is a little game with the law “winning is impossible” and a direct invitation: “Skeptical? Try breaking the game”. The positioning is explicit: LAWS.bend is an AGENTS.md with mathematical backing.

And what does it look like? The syntax feels like Python with dependent types. A complete program with effects:

import Base

# Performs effects on the CPU.
def main() -> IO(Unit):
  do IO<Unit>:
    name : String <- IO.try(String, IO.get_env("USER"))
    IO.print("Hello, " ++ name)

Parallelism is divide-and-conquer: you split the work in two and the runtime spreads it over whatever cores it finds. And the ! operator dispatches the function to the GPU:

# Computes 2^d in parallel: a tree of d levels, one leaf per unit.
def pow2(+d: Nat) -> U32:
  match d:
    case 0n:
      1
    case 1n+p:
      a b = pow2(p) pow2(p)
      (a + b : U32)

# Runs pow2 on the GPU, via `!`.
def main() -> IO(Unit):
  result = pow2!(20n)
  IO.print(U32.show(result))

Notice the differences from mainstream languages: there’s no if (every branch is a match on True/False), natural numbers pattern-match on the successor pattern (1n+p), and the +d marks the parameter as affine, which is what lets the language live without a garbage collector.

And proofs are ordinary defs. The law declares what holds; the proof is induction with explicit rewrites:

# CLAIM: for every nat x, x + 0 equals x.
law add_zero:
  for x: Nat
  {Nat.add(x, 0n) == x : Nat}

# PROOF: induction on `x`, one rewrite (`%`) per step.
def add_zero(x):
  match x:
    case 0n:
      {==}
    case 1n+xp:
      %add_zero(xp) : {1n+Nat.add(xp, 0n) == 1n+_ : Nat}
      {==}

No tactics, no inference, everything annotated by hand. It’s verbose on purpose: that’s the price of the 0.1s checker.

The other promises, all with benchmarks on the page:

• Runs fast: Game of Life on an M4 Max in 7.8s on one core, against C’s 6.78s. On the GPU, 0.06s, or 124x.
• Checks fast: 3,200 generic instantiations checked in 0.38s, against Lean’s 19.2s and Rocq’s 6.04s. The idea is that the agent can verify after every edit.
• Parallelizes by itself: the ! operator sends the function to the GPU, no threads, no locks, no hand-written kernels.
• No garbage collector: affine types, each closure can be called at most once, so memory resolves statically.

Two honest details I liked seeing published: the site itself warns “Bend is still evolving. Expect bugs”, and Taelin stated that the compiler is 99% AI-written, with only the checking kernel audited by humans. Consistent with his thesis, at least.

And there’s already a business plan: the Bender, a paid, proprietary “proving agent”, a harness on top of Anthropic and OpenAI models today, with a dedicated model and its own symbolic prover on the roadmap.

Not everyone swallowed the benchmarks

The technical reception had strong caveats, and they matter. Nezk’s gist, “Why the benchmarks of Bend’s 2 typechecker are misleading (and possible problems with its type system)”, points out that Bend skips elaboration, unification, and implicit arguments, which is exactly where Lean and Rocq spend their time. Comparing times like that would be comparing an apple to a rocket.

Heavier: Liam Powell’s post, “Bend 2 and the Vibe-Coding Trap”, notes that the expression “formal verification” appears nowhere on Bend’s site or code, redoes the game demo in SPARK/Ada proving the same two properties automatically with GNATprove (“all checks proved (12 checks)”), without the 442 lines of manual proof, and concludes that Bend is “decades behind the state of the art”.

These are criticisms from people who know the subject, and they deserve an answer. That said, Bend 2’s main HN thread sits at over 600 points, so attention the project has.

What I tested

A tagline doesn’t compile a program, so I went and tested. I have a bend-tests repository where I pointed my agents at porting real projects of mine, written in Rust, to Bend 2 (v2.0.16, pinned via mise; to get a sense of the maturity, the language had nine releases in ten hours on GitHub the day after launch). The documentation for the whole experiment lives in docs/ in there, and that’s where the next sections come from.

The three candidates

I picked three of my projects with different profiles. Fair warning: none of the three is a worthy Bend example, and I know it. I just grabbed small, simple projects I had lying around, somewhat at random, to see where the language breaks when you rub ordinary day-to-day code against it.

ghpending is my CLI that lists open issues and PRs across my repositories via GraphQL. The port covers the main command, the filters, the sorting, and the config.toml, with output verified byte-for-byte identical to the Rust binary in the cases tested against the real GitHub API (on my loaded config, the only difference is the fork view the port left out).

tclock is my fork of clock-tui, a terminal clock with timer and stopwatch. The port covers clock, timer, and stopwatch, without the widget system (which alone is 2,075 lines of the Rust), verified by driving the binary through a pty.

ai-jail, my sandbox for AI agents (bubblewrap, Landlock, seccomp), never even became code: the paper evaluation killed it. A port would be a C program with a Bend main, which defeats the purpose. And it had the most interesting part to prove: the policy logic, like “path resolution never escapes the root”. But there’s no way to embed that in the Rust binary, so it stays for a next round.

The numbers

I measured Rust and Bend side by side on both ports:

Read that table carefully, because it lies. The runs are network-bound. The 43-repo gap is Rust doing more work (fork lookups, sequential viewer query). Bend’s tclock redraws whole frames, 26 KB/s against ratatui’s 2 KB/s of diffs. And the lower line count is partly because the port does less. No number here shows Bend faster than Rust on the same work.

The proofs in practice

Here’s the part Rust can’t imitate, so it’s worth the detail. The design that worked was proving an isolated guard, leaving the algorithm outside the proof. ghpending’s --limit allocator ended up in two stages: the first is the original algorithm in U32, unproven; the second is a Nat guard that takes the first stage’s proposal and cuts any excess. The laws say the budget is conserved and that no repo gets more items than it has.

This is the real guard, from the port’s alloc.bend:

# the lesser of b and w
def take(b: Nat, w: Nat) -> Nat:
  match b w:
    case 0n w0:
      0n
    case 1n+bp 0n:
      0n
    case 1n+bp 1n+wp:
      1n+take(bp, wp)

# what is left of b once w is taken from it
def rest(b: Nat, w: Nat) -> Nat:
  match b w:
    case 0n w0:
      0n
    case 1n+bp 0n:
      1n+bp
    case 1n+bp 1n+wp:
      rest(bp, wp)

The law holds even if the unproven stage proposes garbage. The guard doesn’t trust arithmetic it can’t see. That’s the pattern that makes proofs work in real code.

The mutation test is the honest measure of the thing. I injected an off-by-one into the guard that leaks budget: the three sample outputs came out identical, so a test suite of that size would have passed it. The proof gate rejected it, with the exact term that stopped matching. That’s Bend working as promised, down to the detail.

Now the price: 93 lines of laws and proofs to guarantee two simple facts about a guard of some 30 lines, starting from zero, because Base ships no Nat lemmas (the only arithmetic lemmas are U32.add_comm and Word.add_comm, which don’t help in a Nat proof; we had to prove addition associativity by hand, and Taelin acknowledged in the thread: “We need a mathlib!”).

And what stayed outside the proof: the algorithm’s exactness (it would need division lemmas, days of work), everything U32 (underneath it’s a 32-bit vector; proving arithmetic on it without a lemma library is impractical), and literally everything else in the program: JSON, sorting, rendering, IO. The provable surface of a program like ghpending is a few percent of the code.

The checker, on the other hand, is the best part of the tool: 0.1s per round, errors pointing at one exact line. It took some 30 check rounds on ghpending. For an agent iterating in a loop, it’s exactly the feedback format it needs.

The price of escaping to C

Everything Base lacks becomes a foreign effect: a Bend def whose body is a C function (for the native binary) and a JS twin (for the dev runner). The two ports needed eight hand-written effects:

• Http.post: because there’s no TLS, HTTP, or DNS (the official HTTP demo hard-codes an IP).
• Clock.unix and Clock.local: because IO.now is milliseconds since boot, with no wall clock and no timezone.
• Tty.width, Tty.raw, Tty.key, Tty.size: because there’s no stdin, no raw mode, no terminal query. None of that exists.
• Clock.millis: convenience.

And the official guide is clear about the trade: there’s no ABI promise. The names are runtime internals and any release can rename them, so “rebuild your effects with every update”. In a language with nine releases in ten hours, good luck with that. Details that complete the picture: there’s no flag to link an extra library (ghpending uses a $CC wrapper that injects -lcurl), custom handle types are WONTFIX, and including a C header mid-file worked by luck, because the runtime defines short names like lock and u32.

Here’s where the conceptual point lands: the moment you cross the FFI boundary, the proof stays behind. The checker guarantees what’s inside its model; the C code on the other side is an act of faith. Rust has exactly the same problem with unsafe, where the borrow checker’s guarantees hold up to the edge of the block and inside it the proof is on you. If you want strong end-to-end guarantees, the C boundary has to be minimal or nonexistent, and in Bend today it’s enormous for any real program.

Where Bend fits

Crossing the three projects with what the language offers, the winning shape is a small pure core, with a sharp spec that tests cover poorly, inside a thin shell of effects:

• allocators, schedulers, rate limiters, quota logic
• deterministic game or simulation rules, especially with rollback netcode (the only domain where Base already has what’s needed: UDP, windowing, audio)
• consensus state machines, ledgers, matching engines
• parsers and codecs with a round-trip law
• CRDT merge functions (commutative, associative, idempotent)
• access policy evaluators (like ai-jail’s)

And the design center the authors declare: the AI writes the code and the proofs, the human writes only the LAWS.bend, and the checker arbitrates. The shortest honest description I found: a proof-carrying language for AI-written kernels. Compared with Lean or Coq, which prove well and deliver applications poorly, Bend is far more executable.

One thing that surprised me in my own numbers: at first I’d assume the natural niche was academic math research. It’s the opposite. For mathematics it loses badly to Lean 4, Coq, and Isabelle: no tactics, almost no inference, nothing at mathlib’s scale, no reals, and a foundation (Type : Type, no positivity check) that would make a mathematician’s hair stand on end. What it does is software verification, closer to Dafny, F*, or Liquid Haskell than to a proof assistant.

Two limitations weigh even in that niche: Bend emits a whole program instead of a library, so the proven core can’t be linked into a Rust application today; and the cost of proving without a lemma library is high.

What would change the verdict

Recorded in use-cases.md, the list of what would make me reevaluate:

• library output with a C ABI, so a proven core can live inside a Rust or C program
• U64/I64 and F64
• a lemma library for Nat, lists, and ordering
• stdin, subprocesses, TLS, and JSON in Base, or a package hub that has them
• incremental or faster native builds (62s for 1,000 lines today)
• an effects ABI that survives a release

The unvarnished reality

Now my reading, and you already know I don’t sugarcoat.

It’s a newborn language. It launched two days ago. Outside the language’s own repo, a GitHub search today finds only a few dozen 48-hour spikes, almost all with zero stars, nothing that looks like a real project. The repo’s 21 thousand stars are almost all inherited from Bend 1; the repo was renamed. The site’s demos are all toys: a little game, Game of Life, pow2. They’re demonstrations of possibility, with no real usage yet.

The stdlib needs to grow by an order of magnitude. A language’s strength lives in its standard library and ecosystem. The only historical exception to that rule was JavaScript, and that’s a can of worms that doesn’t fit in this article.

The killer app is missing. Every language that made it had one. My tests point to the niche (proven pure cores, written by AI), but someone needs to turn that into an app the world wants to use. And here’s a concrete suggestion, free of charge: Taelin could pick popular open source software he thinks would be better in Bend and rewrite it. Taelin is the exact opposite of the stubborn maintainer who turns his nose up at AI: he designed the whole language around AI. So put that to work: grab a ripgrep, a jq, a sqlite, rewrite it with AI in Bend, and publish the side-by-side comparison. Performance, lines of code, and above all what the proofs guarantee that the original doesn’t. A real-world before/after like that is worth more than a thousand little game demos. And as a bonus, every one of those rewrites hands back the most valuable feedback there is: which stdlib holes actually hurt in a real project. Nothing reprioritizes what to implement in the next version better than real code hitting what’s missing.

Don’t expect webapps, mobile, or anything day-to-day anytime soon. Maybe that’s not even the goal, and that’s fine too. But the “C speed” promise cuts the other way: if the differentiator is performance, it’s easier to go straight to C, especially now, with an LLM writing the code for you.

And here’s my concrete situation. I use Rust a ton. I hate the syntax, and I find the ergonomics miserable. But since the LLM writes the code and I don’t have to deal with it by hand, I tolerate it, and in exchange I get performance, good-enough guarantees, and a gigantic ecosystem of crates and frameworks. Ecosystem. That’s what decides it.

I don’t pick a language by the elegance of the paper. I pick it by the size of the ecosystem I don’t have to write by hand.

The proof-and-GPU focus, and the doubt that remains

One thing nagged me the whole time: Taelin clearly concentrates everything on two pillars, proofs and GPU, and I wasn’t sure what that meant for the language’s scope. I went and read what he himself said in the pre-launch thread and on HN, and the story is more interesting than I assumed.

The GPU pillar is research inheritance. Ten years of interaction nets and optimal reduction, from HVM to here. But there’s a nuance that surprised me: Bend 2 consciously betrays his academic idealism. In his own words: “Bend2 is designed to be practical, not idealistic”, closer to C than to Haskell, because he couldn’t make interaction nets beat the lower-order variants on common hardware. The GPU stayed as the practical application of the obsession, without becoming a fetish.

The proof pillar is older than the LLM era: it goes back to the Ethereum Foundation days, immutable contracts holding millions with a bug, which produced Formality. The LLM era just gave the old obsession a market outfit: “the same capabilities that proved Navier-Stokes will now be writing real proofs that your own apps are correct”.

And here comes my hypothesis that didn’t survive the research. I was ready to write that the minimal stdlib was maybe on purpose, that the idea was never general-purpose programming, and that my criticism of the library desert was aiming at the wrong target. Wrong me. His words are general ambition, period: “the potential to become the most sensible choice for any vibe-coded project”, “Bend is made for the general public”, and the team “working hard to […] make this language competitive with the mature alternatives in the market”. The only deliberate leanness is the checker’s, no inference, verbose on purpose. The small Base is day two of life, so much so that he himself asks for a mathlib.

That makes my stdlib criticism bite even harder: if the declared goal is to be the choice for any vibe-coded project, the comparison with mature ecosystems is the game he chose to play.

And there’s the business angle, which he admits with rare frankness: “we ship without a product”. The language is the free substrate; the sellable thing is the Bender and the proving infrastructure behind it. Worth keeping an eye on that space.

The doubt that remains, and this one I register with no answer: the generalist ambition is his north star, but the reality I measured pushes Bend toward the niche of AI-written verified cores. Which of the two wins, only time will tell.

The final word

If I could give Taelin one piece of advice, it would be this: the hard part, the research, he’s already done. Now comes the less glamorous part, the one that decides whether a language lives or dies: marketing and ecosystem building. Adoption, teaching material, killer app, stdlib, mathlib. Going way beyond toys and demos.

The example that comes to mind is Zig. Years on the road and still fighting for adoption, even with immediate practical use: zig cc alone is a trivial drop-in for compiling C, without using any of the language. Real apps use it; Mitchell Hashimoto’s Ghostty is the famous case. But Andrew Kelley, the author, is a notoriously difficult figure, from the crowd that turns its nose up at AI, and he clearly doesn’t understand ecosystem building, and that holds Zig back. Technical perfectionism doesn’t mix with marketing and adoption.

Bend 2 has real potential. Instant checker, proofs catching bugs that tests don’t catch, parallelism without ceremony. But potential alone means nothing if adoption doesn’t come. I’m rooting for it to come, and rooting double because a Brazilian is leading.

And one final provocation, this time for you who read this far. Thin stdlib, zero frameworks, zero third-party libraries, no killer app: all of that stops being a problem when you look from another angle and becomes an opportunity map. Everything missing in Bend is something someone will have to write, and whoever gets there first etches their name into the project’s history. If you always wanted to contribute to impactful open source but never found room in the mature projects, where everything already exists, here’s an empty lot waiting.

Those are my two cents. Don’t take it too seriously.

What I liked most about Jarred’s post was the level of detail. He did not sell the idiotic fantasy of writing a prompt like “rewrite Bun in Rust” and waiting for a miracle. Quite the opposite. What he described was procedure: PORTING.md, lifetime analysis, LIFETIMES.tsv, a trial run with three files, dynamic workflows, adversarial reviewers, process correction when the agents started doing stupid things with git stash, then compiler errors becoming a work queue, then smoke tests, then the whole suite, then multi-platform CI. No irresponsible vibe coding. Engineering using AI as a multiplier.

That’s why I was disappointed by Andrew Kelley’s response, “My Thoughts on the Bun Rust Rewrite”. Andrew is Zig’s creator. I wanted to read the best possible technical argument defending Zig. I wanted to see him explain where Bun confused a language problem with an architecture problem. I wanted to see which Zig APIs could have helped, which invariants should have been hardened, where comptime, allocators, arenas, errdefer, DebugAllocator, and Zig’s new I/O design could change the analysis.

Instead, a large part of the text becomes an attempt at character assassination. Comments about personality, management, VC, startup culture, backstage gossip. There may even be real resentment there. I don’t care. It does not help technically.

So I decided to do the exercise I expected to have read: put Claude Fable 5 and GPT 5.6 Sol as technical arbiters and ask them for the answer Andrew should have written. Not the polite answer. Not the fan-club answer. The technical answer.

Before handing over the microphone, one off-topic note. If you, like me, stared at those beautiful GitHub animations in Bun’s post and thought “I want that in my projects”, I went there and built it. github-visualize is a self-hosted dashboard that tracks your repositories and replays commit evolution, the hourly heatmap, and the CI race until everything turns green. It’s all open on GitHub.

But now let’s separate support from proof. One thing is to say “I would have done something similar”. Another is to say “it was technically impossible to continue in Zig”. To answer that, we need to look at causes: which bugs were really language bugs, which were architecture problems, which were ecosystem costs, and which could have been reduced with different discipline inside Zig itself.

That’s where the analysis starts.

First, minimum vocabulary. Use-after-free is using memory after freeing it. Double-free is freeing the same memory twice. Leak is forgetting to free. Ownership is who is responsible for destroying a resource. Lifetime is how long a reference remains valid. FFI is the boundary where Rust or Zig call C/C++ and lose part of the language guarantees. GC root is a way to tell the garbage collector: “do not collect this object yet”. Pinning is holding a buffer in place so it cannot be moved, detached, or invalidated while someone still has a pointer to it. Reentrancy is when a call enters the runtime again before the previous call has finished.

What Rust actually buys

The strongest thesis in Bun’s post is simple: a large percentage of the listed bugs were use-after-free, double-free, or forgotten resources in error paths. In safe Rust, a good portion of that becomes compiler error or automatic cleanup through Drop, as long as the resource is modeled as an owning value. Rust does not prove the general absence of leaks: Rc cycles, mem::forget, Box::leak, and abort still exist. But it makes accidental leaking in error paths much harder.

That is correct. And it is a strong argument.

Rust’s strong point here is not magic. It is that Rust forces certain ownership and lifetime relationships to appear in the type, instead of being scattered around as convention. When a value has an owner, when it is moved, when it leaves scope, when a destructor runs, that stops being just an agreement between programmers. The compiler participates.

In Bun’s current code, you can see the pattern in miniature. A MySQL byte wrapper stores a pinned JavaScriptCore value, and Drop undoes the pin when the object dies:

impl Drop for Bytes {
    fn drop(&mut self) {
        if !self.pinned.is_empty() {
            // `pinned` is rooted by the caller's MarkedArgumentBuffer for the
            // lifetime of this Value (see struct doc); the FFI itself is `safe fn`.
            JSC__JSValue__unpinArrayBuffer(self.pinned);
        }
        // self.slice dropped automatically
    }
}

Source: src/sql_jsc/mysql/MySQLValue.rs. The important detail is not the FFI call itself. It is that cleanup follows the value’s owner.

This is the round Rust wins cleanly. In a small project, discipline is enough. In half a million lines, with reentrant callbacks, threadpool, libuv, sockets, TLS, JavaScriptCore, parser, bundler, package manager, and Node API, discipline becomes recurring cost.

Rust probably reduced the invalid state space the team needed to keep in their heads. Real win.

But a real win does not mean total victory.

Zig was not defenseless

The weakest argument you can make against Zig is pretending it is C with new syntax. It is not. Zig has explicit mechanisms to address exactly part of these problems.

The most obvious one is errdefer, the idiomatic mechanism for cleanup on error paths:

fn readThing(alloc: std.mem.Allocator, fail: bool) ![]u8 {
    const buf = try alloc.alloc(u8, 16);
    errdefer alloc.free(buf);

    if (fail) return error.Boom;
    return buf;
}

test "leak em caminho de erro" {
    const alloc = std.testing.allocator;
    try std.testing.expectError(error.Boom, readThing(alloc, true));
}

std.testing.allocator reports leaks in tests. DebugAllocator helps find double-free, leaks, and many invalid memory uses, including making bugs noisier by not immediately reusing addresses. This is not the same thing as a static proof of the absence of use-after-free. It is not a borrow checker. It does not cover allocation done inside C++, JavaScriptCore, BoringSSL, or any other external allocator. It only catches what goes through it and only on the paths exercised by tests.

The allocator’s own comment is precise about what it provides:

//! * Captures stack traces on allocation, free, and optionally resize.
//! * Double free detection, which prints all three traces (first alloc, first
//!   free, second free).
//! * Leak detection, with stack traces.
//! * Never reuses memory addresses, making it easier for Zig to detect branch
//!   on undefined values in case of dangling pointers.

Source: debug_allocator.zig. It is a good testing and debugging tool. It is not a theorem.

Even so, it is wrong to say Zig had no tools. It did.

The difference is feedback timing. In Rust, a lot appears at compile time. In Zig, a lot appears in tests, fuzzing, instrumented allocators, ASAN, review, and architectural style. In critical code, that matters. Early feedback is better.

But it also matters to say the whole sentence: if the problem was lack of clear invariants in the Zig code, the answer could have been a rewrite in Rust. It could also have been an aggressive restructuring of the Zig.

We do not know which would have been cheaper. We only know which one Bun chose.

Drop is not just sugar, but it is not a miracle either

Bun’s post is right to contrast defer with Drop.

In Zig, you write:

var resource = try Resource.init(allocator);
defer resource.deinit();

This is explicit. It is in your face. There is no hidden control flow. That is Zig’s philosophy: if something happens, you should be able to point to where it happens.

In Rust, if the type implements Drop, cleanup follows the owner:

impl Drop for Resource {
    fn drop(&mut self) {
        self.deinit();
    }
}

This is not just syntactic sugar. Rust’s destruction rules connect Drop to ownership, move semantics, field destruction order, and panic unwind. Ordinary safe code cannot use a value after it has been moved, nor double-drop the object as if it still owned it. It is a language guarantee.

But the guarantee ends where semantics the compiler does not understand begin.

If drop calls an FFI function to unprotect a JavaScriptCore value, Rust guarantees the destructor will run on normal scope and drop paths, not on abort, mem::forget, intentional leaks, or Rc cycles. It does not prove that the JSC pointer is still valid. It does not prove the GC has no special rule. It does not prove an asynchronous C callback will not call back after you destroyed the wrapper.

The comment in the same Bun wrapper shows the size of the contract that still remains outside the compiler:

/// JS could `transfer()`/detach an earlier ArrayBuffer, or drop the last
/// JS reference to it and force GC, while we still hold a borrowed slice
/// into it. Pinning the backing `ArrayBuffer` makes it non-detachable for
/// the duration, and the caller's stack-scoped `MarkedArgumentBuffer`
/// roots the wrapper so GC can't sweep the cell. `Drop` unpins.
pub struct Bytes {
    pub slice: ZigStringSlice,

Source: MySQLValue.rs. Notice the size of the contract. It did not disappear because this is Rust. It became documented and encapsulated.

That is the real boundary: Rust improves the Rust side of the contract. It does not perform magic inside the JavaScriptCore heap.

The FFI boundary is still hell

Bun is not a simple CLI. Bun is a JavaScript runtime. It talks to JavaScriptCore, uWebSockets, usockets, BoringSSL, SQLite, compression libraries, system APIs, asynchronous handles, buffers that JavaScript can detach in the middle of a coercion, reentrant callbacks, and a conservative GC.

That is where the debate gets interesting.

Inside an unsafe block, Rust requires discipline. The Rustonomicon on FFI itself treats foreign calls and raw pointers as programmer obligations. If the binding is lying, if the real ownership does not match the type, if the foreign callback outlives the Rust object, the compiler does not save you.

Bun’s binding documents the preconditions in the declaration itself:

unsafe extern "C" {
    /// By-value `JSValue`; C++ side null-checks and reads its own heap state.
    /// No caller-side preconditions → `safe fn`.
    safe fn JSC__JSValue__unpinArrayBuffer(v: JSValue);
    /// 0 = detached/null, 1 = FastTypedArray (GC-movable — caller should dupe;
    /// no unpin needed), 2 = pinned ArrayBuffer (caller must unpin).
}

Source: MySQLValue.rs. The language lets you declare a foreign call safe. The obligation to prove that safety remains ours.

But there is an important difference: Rust lets you encapsulate that unsafe behind safe APIs. You can create handle types, NonNull, PhantomData, Pin, lifetimes marking the relationship between wrapper and runtime, wrappers that do not implement Send or Sync, RAII for GC roots, and a smaller surface for audit. The goal is not to eliminate danger. It is to shrink the place where danger lives.

The most didactic example in Bun’s post is the uv_close bug. The first version compiled, but handed a Box to libuv to close asynchronously and let the Box fall at the end of the scope. Use-after-free followed by double-free. The fixed version in the current code makes the transfer explicit:

spawn::WindowsStdioResult::Buffer(pipe) => {
    // `uv_close` is async — libuv keeps the raw handle pointer until the
    // next loop tick. Leak the Box so it outlives this scope; dropping it
    // here would be a use-after-free + double-free when the callback fires.
    Box::leak(pipe).close(Subprocess::on_pipe_close)
}

Source: js_bun_spawn_bindings.rs. It compiled in Rust and was still wrong at the C/async boundary. The review process caught it.

Here leak does not mean “leak forever”. It means removing the Box from Rust’s lexical control and transferring ownership to libuv’s asynchronous protocol, whose callback later reconstructs and frees the allocation.

Zig also lets you write good wrappers. The difference is that it does not have the safe/unsafe boundary as part of the language. In Zig, everything is explicit and reviewable. In Rust, a larger part of the contract can become type.

For a large team, that matters. It matters even more when part of the code is being generated by agents.

Arenas: yes, Bun already used them

Here the pro-Zig argument needs to be honest. Arenas are idiomatic and excellent for certain problems: parser, AST, request lifecycle, data that dies together.

But Bun’s post does not ignore arenas. It explicitly says the existing approach was already a mix of lifetimes by arena, reference counting, and “pay really close attention”. It even cites parser state and AST nodes as good cases for an arena.

The excerpt from the post is this:

Our current approach is a mix of:

- arena lifetimes, where the scope of when it's accessible is clear
  (parser state doesn't escape the calling function and so AST nodes
  are a good choice there)
- reference-counting
- pay really close attention

Source: Bun’s official post. The good counter-argument is not “use arena”. They already did. The good counter-argument is asking whether the remaining boundaries could have been hardened in Zig.

So the correct response is not “you forgot arenas”. They did not forget.

The correct response is: arena solves the case where lifetime is clear. It does not, by itself, solve a socket handle that closes asynchronously, a callback that runs later, an SSL session that needs a specific free, a GC root, a pointer that may be invalidated by reentrancy, or an object that crosses several API layers with implicit ownership.

Arena is a good tool. It is not a religion.

If Bun had hardened the boundaries more in Zig, maybe part of the rewrite’s benefit could have come from that: more restricted APIs, fewer raw pointers crossing subsystems, handles with explicit ownership, allocators instrumented by default in tests, fuzzing aimed at reentrancy, wrappers that force deinit, less “pay attention”.

But that would also be a rewrite. Just inside Zig.

The borrow checker helps, but not where the internet thinks

A lot of people talk about the borrow checker as if it were a universal bug detector. It is not. The borrow checker is the part of the Rust compiler that prevents certain invalid borrows: two mutable owners at the same time, a live reference after the owner dies, use after move. That is a lot. It is not everything.

It does not understand the JavaScriptCore heap. It does not understand every GC rule. It does not automatically understand that a C callback can trigger JS, that JS can detach an ArrayBuffer, that it can reenter the runtime, that it can invalidate a pointer captured earlier. These invariants need to be modeled.

But when they are modeled, Rust charges you.

A small example in Bun: a uSockets wrapper that turns a C pointer into a Rust borrow tied to &mut self:

impl PacketBuffer {
    pub fn get_peer(&mut self, index: c_int) -> &mut sockaddr_storage {
        // SAFETY: uSockets guarantees a non-null, properly-aligned peer pointer for
        // indices < packet count. The returned storage lives inside the C-owned packet
        // buffer, which is exclusively loaned to the data callback for its duration; no
        // other Rust or C path holds a reference to it. The reborrow of `&mut self`
        // ties the returned lifetime to this handle, so the borrow checker prevents
        // obtaining a second overlapping `&mut` via `get_peer`/`get_payload`.
        unsafe { &mut *us_udp_packet_buffer_peer(self, index) }
    }
}

Source: src/uws_sys/udp.rs. The unsafe still exists. But after the wrapper creates the reference, the borrow checker can prevent certain abuses on the Rust side.

And Bun is not only JavaScript heap. It is parser, bundler, module resolver, package manager, file watcher, HTTP protocol, buffers, caches, tables, queues, process state, glue code. In these parts, local ownership matters a lot. Vec, String, slices, maps, wrappers, enums, finite states: all of that becomes easier to refactor with the compiler slapping your hand.

The honest argument is not “the borrow checker solves Bun”. It is: the borrow checker reduces many classes of error on Bun’s Rust side, and that frees human attention for the part that remains hard.

That is strong enough. No need to exaggerate.

comptime: here Zig has a real advantage

The best technical counterexample in Bun’s own post is Output.pretty.

In Zig, the format string could be a comptime parameter. Bun’s own post puts the difference like this:

// Zig:
pub inline fn pretty(comptime fmt: string, args: anytype) void;
Output.pretty("<r>{f}<r>", .{hyperlink});

// Primeira API Rust:
pub fn pretty(payload: impl PrettyFmtInput);
Output::pretty(format_args!("<r>{}<r>", hyperlink));

This allowed processing color and formatting markers in the literal known at compile time, before mixing runtime arguments. When porting to Rust, the first version became a function. Result: the tag parser touched bytes that came from the arguments. Issue #30693 shows the regression in port/canary involving an OSC 8 hyperlink escape and <r>, not a failure released in stable.

The bug was exactly the contamination between template and runtime argument:

TerminalHyperlink::Display emits an OSC 8 hyperlink:

\x1b]8;;URL\x1b\ai\x1b]8;;\x1b\

The closing string terminator ST is the final two bytes `\x1b\`.

This is then wrapped via `Output::pretty(format_args!("<r>{}<r>", hyperlink))`.
The rendered string tail is `...\x1b\<r>`.

Source: issue #30693.

Then they fixed it using a macro.

The current code makes the difference explicit:

/// Write to stdout with `<tag>` color expansion.
/// Function form: performs the `<tag>` → ANSI rewrite at runtime on the rendered
/// payload (using stdout's colour state). Prefer the `pretty!` macro for literal
/// templates so the rewrite happens at compile time.
#[inline(always)]
pub fn pretty(payload: impl PrettyFmtInput) {
    let buf = payload.into_pretty_buf(enable_ansi_colors_stdout());
    write_bytes(Destination::Stdout, &buf);
}

And right below:

/// Compile-time `<tag>` → ANSI escape rewriter.
///
/// This must be a proc-macro because it consumes a string literal and emits
/// a new string literal usable as a `format_args!` template.
///
/// `pretty_fmt!("<red>{s}<r>", true)`  → `"\x1b[31m{}\x1b[0m"`
/// `pretty_fmt!("<red>{s}<r>", false)` → `"{}"`
pub use bun_core_macros::pretty_fmt;

Source: src/bun_core/output.rs.

This demonstrates a legitimate strength of Zig: comptime is the language itself running at compile time. You do not switch to a parallel system. In Rust, macros are powerful and mature, but they are another mechanism. For some kinds of API, Zig is simply more direct.

But let’s not turn a porting bug into universal proof against Rust. The problem there was not “Rust is fragile”. It was the wrong translation of a comptime API into a runtime function. Bun’s own post recognizes that and fixes it with a macro.

The correct reading is simpler: Zig had a structural guarantee there. The first Rust version lost that guarantee. That cost a regression in port/canary.

Point for Zig.

Binary size and performance: careful with cheap causality

Bun’s post shows good numbers: smaller binary, some faster benchmarks, better startup in certain scenarios.

The numbers from the post:

Bun v1.4.0 (canary) — Windows — 76 MB
Bun v1.3.14          — Windows — 94 MB
Bun v1.4.0 (canary) — Linux   — 70 MB
Bun v1.3.14          — Linux   — 88 MB

Bun.serve  — 169.6k → 177.7k — +4.8%
node:http  — 103.8k → 108.5k — +4.5%
fastify    —  91.5k →  95.9k — +4.8%

Source: Bun’s official post.

I believe the numbers. I do not believe in simple attribution.

A rewrite changes many things at the same time. It changes code layout, removes debt, changes toolchain, touches LTO, changes how generics/comptime are instantiated, changes linker, changes dead code, changes ICU, changes internal organization. When all of that happens together, you cannot look at the graph and say: “it was Rust”.

You also cannot say: “it was only the rewrite”.

The post itself talks about a combination: Rust, ICU changes, Identical Code Folding, LTO, codegen, accumulated cleanup. LTO is optimization at the final link stage, when the compiler sees more of the program before generating the binary. Identical Code Folding is the linker merging identical functions into one. Andrew is right to point out that Zig also supports LTO and that some of these gains could have been pursued before. But that does not prove the result would be the same. It only proves causality is mixed.

Bun’s Cargo.toml shows there is explicit build engineering in this story:

# Cargo's defaults (lto=false, codegen-units=16) leave us at ~105 crates × 16
# CGUs ≈ 1680 separately-optimized units with NO cross-crate inlining beyond
# `#[inline]`-annotated leaf fns. `lto = "fat"` + `codegen-units = 1` collapses
# the whole Rust crate graph into one LLVM module, matching Zig's shape.
[profile.release]
lto = "fat"
codegen-units = 1
debug = "line-tables-only"
strip = "none"
panic = "abort"

Source: Cargo.toml.

And there is LTO configuration crossing Rust and C++:

/**
 * Cross-language LTO: rustc emits LLVM bitcode (`-Clinker-plugin-lto`) into
 * `libbun_rust.a` so the final lld `-flto=thin` link sees through Rust↔C++
 * call edges. When false but `lto` is true, both halves still LTO
 * independently (C++ via `-flto=thin`, Rust via `[profile.release] lto =
 * "fat"`); only the cross-language inlining is lost.
 */
crossLangLto: boolean;

Source: scripts/build/config.ts. It is not “Rust won”. It is language, toolchain, linker, configuration, and code working together.

Same thing for stack usage and parser depth. The post attributes improvement to Rust emitting better llvm.lifetime.start/end and allowing stack slot reuse. Codegen detail? Yes. But a codegen detail delivered by today’s toolchain counts. Zig itself still has an open issue about stack allocations that do not disappear at the end of scope. For the user, it matters little whether the advantage comes from the pure language, the compiler, or backend maturity. What matters is that it works today.

The mechanism described by Bun is this:

Rust's LLVM IR codegen emits LLVM's llvm.lifetime.start and
llvm.lifetime.end intrinsics for stack variables when they are no longer
in use, which lets LLVM reuse stack space slots.

And the Zig ticket says, bluntly, that this case is still not solved:

Block stack allocations do not disappear at end of block scope #23475

There is also the architectural solution: iterative parser with an explicit stack on the heap. Works in Zig and Rust. But it is more work.

Honest reading: the numbers favor Bun’s Rust version in that experiment. They do not prove general language superiority.

Miri, crates, and the real world

There are Rust advantages that have no direct equivalent in Zig today.

Crates is the obvious one. The Rust ecosystem is large, mature, and practical. For a project the size of Bun, a good off-the-shelf library is real engineering value. Zig is still maturing on this point.

Miri is also a real advantage. It detects classes of undefined behavior in executed Rust code: out-of-bounds, use-after-free, uninitialized data, alignment problems, data races in certain cases. The project itself documents the limits: it is not a formal proof, it evaluates the executions you provide, and it has restricted support for FFI and platform APIs. It does not replace testing. But to validate isolated unsafe abstractions, it is a tool Zig does not have in the same way.

Bun does not merely cite Miri in the abstract. It is in the toolchain:

[toolchain]
channel = "nightly-2026-05-06"
components = ["rust-src", "rustfmt", "clippy", "miri", "llvm-tools"]

Source: rust-toolchain.toml.

And there is an internal test explaining exactly the use:

// Run under Miri (`bun run rust:miri -p bun_ptr`): every path here walks raw
// pointers through `Box::into_raw` / `heap::take`, so Tree Borrows is what
// proves the ref/deref/destructor handoff does not alias or use-after-free.

Source: src/ptr/ref_count.rs. It does not prove the whole program. It exercises a dangerous abstraction under a model made to detect undefined behavior on those executed paths.

There is also hiring, tooling, documentation, IDE, review culture, CI, examples, people in the market. This is not a political detail. It is engineering. A language exists inside an ecosystem.

If Bun were a smaller project, with a smaller team, less pressure, and less Node-compatible surface area, maybe I would weigh this differently. But Bun became a runtime used by millions of monthly downloads. The margin for “let’s maintain perfect discipline” shrinks.

Async: Zig may have a better answer, but it is not Bun’s present yet

Zig removed the old async/await and is redesigning I/O around std.Io, passed by the caller in a way similar to Allocator. The idea is good: avoid classic function coloring, make the function less coupled to blocking, threaded, or event-driven execution, and treat I/O as an explicit capability.

The proposed format is like this:

const std = @import("std");
const Io = std.Io;

fn saveData(io: Io, data: []const u8) !void {
    const file = try Io.Dir.cwd().createFile(io, "save.txt", .{});
    defer file.close(io);

    try file.writeAll(io, data);

    const out: Io.File = .stdout();
    try out.writeAll(io, "save complete");
}

Source: Kristoff on Zig’s new async I/O. io is a capability passed explicitly, like Allocator.

I like this direction a lot.

But it is still in transition. The tracking issue remains open: there is a prototype, roadmap, discussion, parts landing gradually. It is not a stable foundation Bun could bet on today without cost.

So the argument here cannot be “Zig already solved it”. The correct formulation is: Zig is moving toward an async/I/O design that may be cleaner in some aspects than the traditional colored model. But Bun needed to make a decision with what exists now, not with what promises to exist later.

That is always cruel to young languages. But it is real.

The rewrite process matters more than the language

The best part of Jarred’s post is not Rust. It is method.

The mental loop of the post is literally this:

// Pseudocode, not real code:
let task;
while ((task = todoList.pop())) {
  const result = task();
  const feedback = await Promise.all([review(result), review(result)]);
  await apply(feedback, result);
}

Then compiler errors became a queue:

~16,000 compiler errors left

error: deref *mut EventLoop before field access
error[E0034]: multiple applicable items in scope
error: event_loop/EventLoopTimer.rs: port Timespec::ns from bun.zig

And the per-crate cycle was explicit:

- For each crate, run cargo check, group the output by file and save the errors to a file
- Fix all the compiler errors within that crate
- 2 adversarial reviewers for the crate's changes
- 1 fixer applies the fixes

Source: Bun’s official post.

He did not tell Claude to rewrite an entire runtime and go to sleep. He built loops. Separated implementer from reviewer. Used different context for adversarial review. Did a trial run. Fixed the workflow when agents started tripping over each other. Banned dangerous commands. Split worktrees. Turned compiler errors into a queue. Ran the same TypeScript suite because the suite did not depend on the runtime language. Used multi-platform CI as judge.

That is the part everyone should study.

The model did not replace engineering. The model executed work inside an engineering process. When the process was bad, the result was bad. When the process improved, the result improved.

It is the detail the tribal discussion ignores. The story is not “Claude rewrote Bun”. The story is “an engineer turned a giant migration into several verifiable loops and used Claude to accelerate each loop”.

Much more interesting.

So did Zig fail?

No.

Zig did not fail because Bun chose Rust. Rust also did not become the universal answer because Bun chose Rust.

What the public evidence shows is more boring: that code, at that moment, was too expensive to evolve with the level of confidence the team wanted. Rust bought predictability. Bought compiler feedback. Bought ecosystem. Bought an explicit safe/unsafe boundary. Bought tooling. Bought an environment where AI agents can bang against compiler errors and move forward mechanically.

That is enough to justify the decision.

But it is not enough to prove Zig was technically unviable for Bun. Many cited problems also look like boundary problems: implicit ownership, overly permissive APIs, allocation without a visible contract, resources crossing layers without a type carrying the owner, tests that maybe did not capture difficult invariants, and the human cost of reviewing all of that.

Those things could have been attacked in Zig. Maybe an aggressive Zig restructuring would have solved a lot. Maybe not. Maybe it would cost more than the port. Maybe it would cost less, but deliver less confidence. We do not have the counterfactual.

And that is exactly why the conclusion needs to be calibrated.

I support Jarred’s decision as a product and engineering decision. His post is one of the most useful reports I have ever seen about a large AI-assisted rewrite. But liking the decision does not force me to pretend it was the only possible technical conclusion.

And there is one important disclaimer. Anthropic acquired Bun in December 2025, and Jarred opens the post by saying that he and the Bun team now work there. Anthropic sells Claude Code. Jarred had every institutional incentive to use as much Claude as possible and turn this rewrite into a public demonstration of his new employer’s product. That does not prove bad faith, nor does it invalidate a technical result. But it adds bias to the decision and to the way the case is presented. Ignoring that conflict of incentives would be as naive as ignoring Andrew’s resentment over Bun leaving Zig.

The best reading is less dramatic: Bun chose to pay a large cost now to reduce recurring maintenance costs later. Rust was a defensible choice, maybe a great one for that team at that moment. Zig remained an excellent language, but would have required another kind of reengineering: more explicit invariants, less informal ownership, more tools enabled by default, harder boundaries.

Andrew could have written that. He could have defended Zig on technical ground. He could have said: “Rust bought some real guarantees, but a large part of the problem was architecture and process; here is how Zig could have attacked the same causes.” That would have been a useful post.

We do not need to declare a winner. Language does not replace architecture. It only changes which errors become cheap to detect and which still depend on human discipline.

Bun chose to trade part of that discipline for compiler. I think it is a good bet.

I do not think it buries Zig.

The problem: subtitles

Anyone who maintains a movie and TV collection knows the pain. You download the MKV, but the embedded subtitle is out of sync. Or worse: there’s no subtitle at all in the language you want. So you go to OpenSubtitles, download a subtitle, and it’s 3 seconds ahead because it was made for a different release. The manual flow is:

1. Extract subtitle tracks from the MKV with mkvextract
2. Go to OpenSubtitles, look for a subtitle for the movie
3. Download, test, see it’s out of sync
4. Run some sync tool (ffsubsync, alass)
5. Rename the file, move it to the right place
6. Repeat for every language, for every movie

For someone with 10 movies, it’s tolerable. For someone with hundreds, it’s insanity. It’s exactly the kind of thing that should be automated.

Subservient: the Python solution

Looking at what already existed, I found Subservient. It’s a Python project that automates exactly this flow: it extracts subtitles from MKVs, downloads them from OpenSubtitles via REST API, syncs them with ffsubsync, and cleans ads out of SRT files.

The project is complete. It has movie mode and series mode, smart sync (tests every candidate in parallel and picks the best one) and first-match (stops at the first one that works). It uses the OpenSubtitles hash for exact matching and cleans watermarks and ads with more than 30 regex patterns.

But it has the typical Python distribution problems:

• 7 pip dependencies: colorama, requests, langdetect, ffsubsync, platformdirs, pycountry, tqdm
• ffsubsync as the sync engine: which in turn depends on numpy, auditok, and a bunch more Python packages
• Interactive menu UI: good for manual use, terrible for scriptability
• Config in INI format: not the end of the world, but YAML is more ergonomic
• 10,220 lines across 6 Python files: 2,700-line files with hundreds-of-lines functions each

The point isn’t that Python is bad for this. Subservient works. But installing and maintaining it in production is another story. If you want to run it on a headless server, you need Python 3.8+, pip, virtualenv (or you’re going to pollute the system), and pray no dependency breaks with the next OS update.

The experiment: porting it to Crystal with Claude

Here’s where it gets interesting. I wanted to test a hypothesis: can Claude take a large open source project, understand the architecture, and do a complete port to another language?

I’m not talking about translating it file by file. I’m talking about understanding what the project does, redesigning the architecture where it makes sense, and generating idiomatic code in Crystal.

What I did:

1. Asked Claude to clone and analyze the Subservient repo
2. Explained the design decisions: use alass (a Rust binary, no Python dependencies) instead of ffsubsync, CLI subcommands instead of interactive menus, YAML instead of INI
3. Asked for a feature-parity port, with tests

alass is an important detail. ffsubsync works fine, but it’s a Python package that pulls in numpy and does audio analysis. alass does the same thing (subtitle synchronization through timing analysis), but it’s a standalone Rust binary. Swapping one for the other eliminates the biggest Python dependency in the stack.

The result: easy-subtitle

Five commits. Less than 40 minutes from the first to the last.

The first commit already delivers a working project: 8 CLI commands, OpenSubtitles client with rate limiting, 76 passing tests, GitHub Actions with CI and release for Linux and macOS.

Numbers

The LOC difference is loud: 10,220 vs 2,516. But that’s not all Crystal’s doing. The original Python has monolithic files of thousands of lines, with a lot of duplication and UI logic mixed with business logic. The port separates the responsibilities into small, focused modules.

Architecture of the port

easy-subtitle/
  src/easy_subtitle/
    cli/           # Router + 9 commands (init, extract, download, sync, run, clean, scan, hash, doctor)
    core/          # Language map, SRT parser/writer/cleaner, video scanner
    acquisition/   # OpenSubtitles API client, auth, search, download, movie hash
    extraction/    # MKV track parsing, extraction, remuxing
    synchronization/  # alass runner, offset computation, smart/first-match strategies
    models/        # VideoFile, SubtitleCandidate, CoverageEntry

Every module has a clear responsibility. The biggest file is 144 lines (config). In the original Python, acquisition.py alone has 2,726 lines.

What each command does

# Generate the default config
easy-subtitle init

# Extract subtitles from inside MKVs
easy-subtitle extract /path/to/movies

# Download subtitles from OpenSubtitles
easy-subtitle download -l en,pt /path/to/movies

# Sync downloaded subtitles with the video
easy-subtitle sync /path/to/movies

# Full pipeline: extract → download → sync
easy-subtitle run /path/to/movies

# Clean ads/watermarks from SRTs
easy-subtitle clean /path/to/subtitles

# See subtitle coverage by language
easy-subtitle scan --json /path/to/movies

# Compute the OpenSubtitles hash (debug)
easy-subtitle hash /path/to/movie.mkv

# Validate the setup: config, credentials, dependencies
easy-subtitle doctor

doctor is a command I added later. It checks whether the config exists, whether the API key is configured, tests login against the API, and checks whether mkvmerge, mkvextract and alass are on the PATH. It shows OS-specific install instructions when something is missing.

Smart sync with fibers

Smart sync is the part I most enjoyed seeing in the port. In the original Python, it uses ThreadPoolExecutor to run multiple candidates in parallel. In Crystal, the same logic is more natural with fibers and channels:

def execute(candidates : Array(Path), video : VideoFile) : SyncResult?
  channel = Channel(SyncResult).new(candidates.size)

  candidates.each do |candidate|
    spawn do
      result = sync_one(candidate, video)
      channel.send(result)
    end
  end

  results = Array(SyncResult).new(candidates.size)
  candidates.size.times do
    results << channel.receive
  end

  accepted = results.select(&.accepted?)
  accepted.min_by(&.offset)
end

Each subtitle candidate gets synced in a separate fiber (via spawn). The results come back through the Channel. At the end, it picks the accepted one with the smallest offset. No ThreadPoolExecutor, no futures, no callbacks.

API rate limiting

OpenSubtitles requires throttling of 500ms between requests. The Crystal client implements that with a Mutex:

RATE_LIMIT_MS = 500

private def throttle! : Nil
  @mutex.synchronize do
    elapsed = Time.utc - @last_request_at
    remaining = RATE_LIMIT_MS - elapsed.total_milliseconds
    sleep(remaining.milliseconds) if remaining > 0
    @last_request_at = Time.utc
  end
end

Simple, thread-safe, no external library.

Installation

The static binary comes out of GitHub Actions and can be installed three ways:

# Homebrew (macOS / Linux)
brew install akitaonrails/tap/easy-subtitle

# Install script
curl -fsSL https://raw.githubusercontent.com/akitaonrails/easy-subtitle/master/install.sh | bash

# Or grab the binary directly from Releases

One binary. No Python, no pip, nothing.

On porting things “just because”

I’ve always argued that porting software from one language to another just for the language fetish is a waste of time. How many projects have been rewritten in Rust “just because”? How much effort spent on rewrites that delivered no new value?

But I have to admit this experiment made me reconsider.

When the cost of porting drops from weeks/months to less than 40 minutes, the equation changes. Porting Subservient to Crystal with Claude wasn’t an exercise in linguistic vanity. I wanted a static binary I could drop on a server and forget. No managing a Python runtime, no pip install breaking on the next system update.

And the result isn’t a mechanical port. It’s 2,516 lines across 42 files, against 10,220 in 6 monolithic ones. The port came with 76 tests the original didn’t have, CI with automatic release for Linux and macOS, a Homebrew formula and an install script with checksum verification.

The point isn’t that Python is bad. It’s that the bar for “is it worth porting?” got ridiculously low. Feature-parity port with tests in less than an hour. Hard to argue against that.

The repository is here. GPL-3.0, like the original.

Language Design takes into account creating reasonably optimized, safe code, etc., but balances that with being easy for a human to read, understand, and edit later. Usually these two things tend to conflict: the more “friendly” for a human, the less efficient it is for a compiler/machine. Examples of that include dynamic languages like Python, Ruby, PHP, and Javascript.

In my head, I imagine the “best” (always in quotes) for a machine are exactly the ones we humans consider to have the worst ergonomics: functional, strongly typed, highly bureaucratic or “verbose” languages, for example, Rust, OCaml, Lean, etc.

Coincidentally (again, ask it yourself), Claude and GPT reached more or less this same conclusion. That doesn’t mean it’s “correct”. It’s what the model can deduce from its probabilities, with the information it has. It’s a massive exercise in “guesswork”. But I think the arguments make a lot of sense.

I asked it to show me what a snippet of code in this “AI-friendly” language would look like, which resembles the AST of a Lisp, but with more features, like annotations, metadata, typing, etc. I think the closest thing to an AST — with proper tooling to give feedback — would be, more or less, what an LLM would prefer for editing.

See what you think:

Update: Pact-Lang

In the section below, you’ll find Claude/GPT’s reasoning and arguments about the ideal language. I liked the idea and decided to ask Claude to generate a prototype compiler that actually works, using what it itself described as the requirements.

It chose to do it in Rust, a language called PACT (it picked the name itself), and this initial version compiles .pct files and generates .rs files. I haven’t even tested it yet, just let it do the project and threw it on GitHub.

• Pact-Lang Repository

On X, I commented that I wasn’t impressed when Anthropic hyped that Claude managed to make a C compiler (using GCC as a comparison). Making a compiler isn’t hard — it’s one of the first subjects in a decent computer science degree; everyone who studied there has already done one.

And, to reinforce this point, Claude managed to make a compiler for a language that doesn’t exist, which — according to it — is ideal for LLMs, but not for humans.

I don’t know why nobody has discussed this angle yet. Leaving it as a curiosity.

I don’t think — at least in the short term — this is something that will actually happen, but it seems inevitable to me: why spend so much trying to make the LLM adapt to a language made for humans, if the goal is to prevent humans from directly touching the code anymore?

The most obvious answer is going back to the beginning: getting humans to write very detailed software specifications. Until now this was super unproductive; we’ve tried it several times over the years. But it was impractical to write specifications that another human would then need to convert into code: it was smarter to create a language that was easier to write and that, more or less, resembled a good specification (and so we invented strong types, annotations, unit tests, etc.).

But if “generating code” becomes a trivial task with the LLM, it’s worth dedicating more time to the specification, the famous “blueprint”. I don’t know how practical this would be, but it’s a line of reasoning that, today, with LLMs, makes sense to at least explore.

So let’s get to the reasoning Claude gave:

Designing a Programming Language for AI Agents

A thought experiment on what a programming language would look like if it were conceived for LLM-based coding agents rather than human programmers.

Summary

• The Problem
• What Human-Oriented Design Gets Wrong for LLMs
  • Safeguards That Become Redundant
  • What Would Actually Help an LLM
  • The Counterintuitive Insight
  • The Real Question
• A Prototype: What It Would Look Like
  • Layer 0: The Human Specification
  • Layer 1: The AI-Native Format
  • Layer 2: The Human Projection
  • Layer 3: How an LLM Would Edit This
  • Design Decisions Rationale
  • Main Takeaway
• Existing Languages: How Close Are We?
  • Tier 1: Closest to the Vision
  • Tier 2: Get Several Things Right
  • Tier 3: Get One or Two Things Right
  • The Uncomfortable Pattern

The Problem

We design programming languages to be fast, safe, and mostly human-friendly — modularity, scope isolation, easy syntax, etc. But when the main “user” of a language is an LLM-based coding agent, the constraints change drastically. Humans have limited working memory, read linearly, and interpret visually. LLMs don’t share those constraints — but they have others that current languages ignore.

What Human-Oriented Design Gets Wrong for LLMs

Safeguards That Become Redundant

• Syntactic sugar — An LLM doesn’t need for x in list to be prettier than loop(list, fn(x) -> ...). Both are equally easy to parse. The idea of “readable syntax” is a human concern. Lisp S-expressions or even raw AST notation would be enough.

• Naming conventions — camelCase vs snake_case, short vs descriptive names — they exist to help humans scan and remember. An LLM could work with UUIDs as identifiers if the semantic graph is available.

• Indentation/formatting — Entirely visual. Explicit block delimiters (or just an AST) are unambiguous. Python’s significant whitespace is actually harder for LLMs because whitespace is hostile to tokenization.

• Boilerplate reduction — DRY exists because humans hate repetition and lose track of duplicated logic. An LLM doesn’t get tired and doesn’t get lost. Explicit repetition with guaranteed consistency checks can be better than implicit magic (think Rails conventions that hide behavior).

• Progressive disclosure of complexity — Languages hide things (default parameters, implicit conversions, operator overloading) so as not to overwhelm humans. That gets in the way of LLMs — hidden behavior means the model has to simulate what the runtime actually does versus what the code appears to do.

What Would Actually Help an LLM

1. Rich, inline semantic metadata — Not comments (natural language is ambiguous), but machine-readable annotations of intent. “This function is pure.” “This block must execute in < 10ms.” “This invariant must hold: x > 0 at exit.” Current type systems are a weak version of this. The ideal is contracts, effects, and provenance as first-class citizens, not bolted on afterward.

2. Bidirectional traceability — Every line of code should know why it exists. Link to the requirement, the test, the commit rationale. When editing a function, the language should say “this exists because of requirement R-1234, it’s tested by test T-56, and it’s depended on by modules A, B, C”. Current languages don’t support this — it lives in external tools (Jira, git blame, grep).

3. Formal, queryable dependency graphs as a language primitive — Not imports to chase. The ability to ask the runtime: “what is the total transitive impact of changing this type?” and get a precise answer. LSP is a makeshift approximation.

4. Deterministic, total effect tracking — Every function should declare everything it can do: I/O, mutation, allocation, panic, non-termination. Haskell’s IO monad is going in the right direction, but it’s too coarse. The ideal: “this function reads from the network, writes to this specific database table, and can throw these 3 types of error”. That lets an LLM reason about changes without running the code.

5. Native diff/patch semantics — Current languages represent state (the current source). LLMs work in deltas (edits). A language designed for LLMs could represent programs as a history of transformations with semantic meaning, not plain text files. Think: a program is a chain of refactorings, not a bunch of characters.

6. Constraint-based specifications alongside implementation — Instead of just writing code and hoping tests catch bugs, every function would carry a formal specification. LLMs are much better at checking “does this implementation satisfy this formal constraint?” than “does this code do what that vague comment says?”.

7. Elimination of ambiguous overloading — Every operation should have exactly one meaning in context. The fact that + means integer addition, float addition, string concatenation, and list concatenation depending on the types is a human convenience that creates inference load for LLMs.

The Counterintuitive Insight

The language an LLM would actually like looks less like Python and more like a typed, total, effect-tracked AST format with embedded formal specs and full provenance metadata — basically a rich IR with the semantic density of something like Lean 4 or Idris, but without any concern for on-screen appearance.

The irony: this already exists in parts. LLVM IR, WebAssembly, Typed Racket, Dafny, F*. Nobody uses it directly because it’s hostile to humans. An LLM-native language would essentially be a very rich IR that no human would want to write, paired with a human-facing projection (like a “view layer”) for when people need to read.

The Real Question

The deeper question isn’t “what language should LLMs use” — it’s should LLMs use textual languages at all? Text is a serialization format for human cognition. The ideal programming interface for LLMs may be direct manipulation of a semantic graph with formal verification at every step, where “source code” as plain text simply doesn’t exist.

A Prototype: What It Would Look Like

The same concept — a simple HTTP user service — shown in four layers: the human intent specification, the AI-native format, a human projection, and the semantic editing interface.

Layer 0: The Human Specification

If humans no longer write code — neither the native format (Layer 1) nor the readable projection (Layer 2) — what exactly do they write? The answer: a declarative specification of intent. It isn’t code. It isn’t pseudocode. It’s a structured declaration of what the system must do, which constraints it must respect, and which guarantees it must offer. The human describes the what and the why. The AI decides the how.

This isn’t free-form natural language (too ambiguous) nor a programming language (too detailed). It’s something in between: a specification DSL where the vocabulary is restricted, the structure is formal, but the cognition required is product design, not software engineering.

For the same user service:

spec: SPEC-2024-0042
title: "Serviço de usuários"
owner: time-plataforma
status: rascunho

domain:
  User:
    campos:
      - nome: obrigatório, texto, 1–200 caracteres
      - email: obrigatório, formato email, único no sistema
      - id: gerado automaticamente, imutável

endpoints:
  buscar-usuário:
    descrição: "Retorna um usuário pelo ID"
    entrada: id do usuário (da URL)
    saídas:
      - sucesso: o usuário encontrado (200)
      - não encontrado: quando o ID não existe (404)
      - ID inválido: quando o formato do ID é incorreto (400)
    restrições:
      - tempo máximo de resposta: 50ms
      - somente leitura no banco

  criar-usuário:
    descrição: "Cria um novo usuário"
    entrada: nome e email (do corpo da requisição, JSON)
    saídas:
      - sucesso: o usuário criado (201)
      - email duplicado: quando o email já existe (409)
      - validação falhou: lista de erros de validação (422)
    restrições:
      - tempo máximo de resposta: 200ms
      - idempotente por email (mesma requisição não duplica)
      - escrita no banco

qualidade:
  - toda função deve ser total (sem crashes, sem loops infinitos)
  - todo campo deve ter validação explícita
  - todo erro deve ser tipado e enumerado (sem exceções genéricas)

rastreabilidade:
  - testes requeridos: cobertura de todos os caminhos de saída
  - dependências conhecidas: api-router, admin-panel

What this specification does not contain:

• No implementation decisions (which database, which framework, which validation pattern)
• No programming syntax (no types, no functions, no imports)
• No serialization details (the JSON format is a constraint, not an instruction on how to serialize)
• No concern for file structure, modules, or code organization

What the LLM does with this:

1. Interprets the specification and generates Layer 1 (the native AST format with all the metadata, effects, invariants, and provenance)
2. Automatically derives tests from the declared outputs
3. Computes the dependency graph from the known dependencies
4. Fills in provenance by linking each function back to the section of the spec that originated it
5. Generates the schema migration if the type is new

The fundamental inversion: in traditional programming, humans write the implementation and hope it matches the intent. Here, humans write the intent and the system guarantees that the implementation matches it — because the specification is formal enough to be verifiable, but high-level enough to be thought about in product terms, not in code.

The specification DSL isn’t YAML. The example above uses YAML as a familiar format, but the real representation could be anything structured — a form, a visual graph, a conversational interface with the agent. What matters is that the vocabulary is restricted to the domain (not the implementation), the constraints are explicit (not implicit), and the output is machine-verifiable against the generated implementation.

This changes the human’s role from code author to constraint author. The programmer becomes a specifier — someone who thinks in terms of domain, invariants, and guarantees, not syntax, patterns, and boilerplate.

Layer 1: The AI-Native Format

This is what the LLM actually works with:

(module user-service
  :provenance {req: "SPEC-2024-0042", author: "agent:claude-v4", created: "2026-02-09T14:00:00Z"}
  :version 7
  :parent-version 6
  :delta (added-fn get-user-by-id "support single-user lookup endpoint")

  (type User
    :invariants [(> (strlen name) 0) (matches email #/.+@.+\..+/)]
    (field id   UUID   :immutable :generated)
    (field name String :min-len 1 :max-len 200)
    (field email String :format :email :unique-within user-store))

  (effect-set db-read    [:reads  user-store])
  (effect-set db-write   [:writes user-store :reads user-store])
  (effect-set http-respond [:sends http-response])

  (fn get-user-by-id
    :provenance {req: "SPEC-2024-0042#section-3", test: ["T-101" "T-102" "T-103"]}
    :effects    [db-read http-respond]
    :total      true
    :latency-budget 50ms
    :called-by  [api-router/handle-request admin-panel/user-detail]

    (param id UUID
      :source http-path-param
      :validated-at boundary)

    (returns (union
      (ok   User   :http 200 :serialize :json)
      (err  :not-found {:id id} :http 404)
      (err  :invalid-id {:id id} :http 400)))

    ;; the logic itself — note how small it is compared to the metadata
    (let [validated-id (validate-uuid id)]
      (match validated-id
        (err _)    (err :invalid-id {:id id})
        (ok  uuid) (match (query user-store {:id uuid})
                     (none)   (err :not-found {:id uuid})
                     (some u) (ok u)))))

  (fn create-user
    :provenance {req: "SPEC-2024-0041", test: ["T-090" "T-091"]}
    :effects    [db-write http-respond]
    :total      true
    :idempotency-key (hash (. input email))
    :latency-budget 200ms

    (param input {:name String :email String}
      :source http-body
      :content-type :json
      :validated-at boundary)

    (returns (union
      (ok   User   :http 201 :serialize :json)
      (err  :duplicate-email {:email (. input email)} :http 409)
      (err  :validation-failed (list ValidationError) :http 422)))

    (let [errors (validate-against User input)]
      (if (non-empty? errors)
        (err :validation-failed errors)
        (match (insert! user-store (build User input))
          (err :unique-violation) (err :duplicate-email {:email (. input email)})
          (ok user)               (ok user))))))

Layer 2: The Human Projection

This is auto-generated. It isn’t source code — it’s a read-only rendering, like a database’s storage format and a query’s output. No human writes this; it’s projected from Layer 1 whenever someone needs to review.

# --- Auto-projetado a partir de user-service v7 ---
# Spec: SPEC-2024-0042 | Tests: T-101, T-102, T-103

@effects(reads="user_store")
@budget(latency="50ms")
@total
def get_user_by_id(id: UUID) -> User | NotFound | InvalidId:
    match validate_uuid(id):
        case Err(_):
            return InvalidId(id=id)          # → 400
        case Ok(uuid):
            match user_store.get(id=uuid):
                case None:
                    return NotFound(id=uuid) # → 404
                case user:
                    return user              # → 200

Layer 3: How an LLM Would Edit This

An LLM wouldn’t send a text diff. It would send a semantic operation:

(edit user-service
  :operation add-field
  :target-type User
  :field (field role (enum :admin :member :guest) :default :member)
  :reason "SPEC-2024-0055: role-based access control"

  :cascading-impacts
    ;; the language itself computes these impacts and asks for confirmation:
    ;; - create-user needs to accept optional 'role' parameter
    ;; - get-user-by-id now returns 'role'
    ;; - 3 tests need to be updated: T-090, T-091, T-101
    ;; - user-store schema migration required
    ;; - admin-panel/user-detail consumes User — check compatibility

  :confirm true)

The system responds with:

(edit-result
  :version 8
  :parent 7
  :changes-applied 4
  :changes-pending-review 2
  :migration-generated "M-0008-add-role-to-user"
  :tests-invalidated ["T-090" "T-091" "T-101"]
  :tests-auto-updated ["T-101"]    ;; trivial: return format changed
  :tests-need-manual  ["T-090" "T-091"]  ;; behavioral: creation changed
  :downstream-verified ["admin-panel/user-detail: compatible"]
  :downstream-warning  ["api-router: new field not yet exposed in list endpoint"])

Design Decisions Rationale

Main Takeaway

The ratio of metadata to logic is something like 3:1. In human languages, it’s the reverse. That’s the fundamental shift — an AI-native language is mostly specification, provenance, and constraints with a thin layer of computation. Logic is the easy part. Knowing why, what else is affected, and which guarantees must hold is where LLMs spend their reasoning budget.

This isn’t a language for writing code. It’s a language for maintaining systems. And with Layer 0, the loop closes: humans specify intent, AI generates and maintains the implementation, and formal verification guarantees that both agree. Code becomes an intermediate artifact — important for the machine, invisible for the human.

Existing Languages: How Close Are We?

An honest ranking of existing popular languages, based on how much each one already delivers natively of the ideal.

Tier 1: Closest to the Vision

Lean 4

The closest thing that exists today. Dependent types mean that specifications are the code — a function’s type can literally say “returns a sorted list whose length equals that of the input list”. Proof obligations force total, verified logic. The macro system operates directly on the AST, which gets close to the “semantic editing” concept. The metaprogramming framework (Lean’s Elab monad) lets you query and manipulate the proof environment programmatically.

Missing pieces: no effect tracking, no provenance, no built-in dependency graph queries.

F* (F-Star)

A Microsoft Research language. It has exactly the effect system described above — you declare ST for state, IO for I/O, Pure for pure computation, and the compiler enforces it. Refined types let you encode invariants like :min-len 1 directly into the type. It can extract verified code to OCaml, F#, or C. It’s the closest thing to “lots of specification with little logic”.

Almost nobody uses it outside research, which says a lot about the human-friendliness trade-off.

Idris 2

Similar to Lean, but with first-class quantitative type theory — the type system tracks how many times a value is used. That’s a primitive form of resource/effect tracking. Elaborator reflection lets programs inspect and modify the type-checking process itself, which speaks to the idea of semantic editing.

Tier 2: Get Several Things Right

Rust

Not for the reasons people usually cite. The borrow checker is essentially a compiler-verified effect system for memory — it tracks aliasing, mutation, and lifetime at the type level. The trait system with Send, Sync, Unpin is effect tracking by another name. The Result<T, E> convention with exhaustive match gives explicit returns. cargo provides a real dependency graph you can query.

What’s missing: formal specifications, provenance, totality checking, and the syntax is complex enough that LLMs burn tokens on lifetime gymnastics.

Haskell

The classic of several of these ideas. Purity by default means effects are always explicit (IO monad). The type system is powerful enough to encode many invariants. hlint and typed holes give structured feedback.

What’s missing: the effects story is coarse (just IO vs pure — no granularity about what kind of I/O), no provenance, no built-in specification language, and the lazy evaluation model makes reasoning about performance genuinely hard even for LLMs.

Dafny

A Microsoft language focused on verification. It has requires, ensures, invariant as first-class syntax — exactly the :invariants annotations described above. The verifier checks these at compile time. Loop termination is verified (decreases = totality). It’s basically “specification-heavy programming”.

Weakness: small ecosystem, no effect system, and it’s oriented toward verifying algorithms more than building systems.

Tier 3: Get One or Two Things Right

Elixir/Erlang (BEAM)

A surprising pick, but: OTP’s supervision trees are essentially a declarative dependency and failure graph. The process model gives natural effect isolation — each process is a boundary. Pattern matching with tagged tuples ({:ok, result} / {:error, reason}) is explicit union return. @spec and @doc are inline metadata. Hot code reloading is a primitive “semantic patch”.

What’s missing: formal verification, compile-time type enforcement (Dialyzer is optional and incomplete), no provenance.

Scala 3

The work on the effect system (Caprese/capture checking) is going in the right direction. Union types, match types, and opaque types give expressive return specifications. Inline metaprogramming via scala.quoted operates on typed ASTs. But it carries a huge JVM complexity bundle.

Ada/SPARK

The SPARK subset is formally verifiable with contracts (Pre, Post, Contract_Cases). Used in aerospace and defense, where “proving it can’t break” is a real requirement. Very close to the concept of :total + :invariants. But the language is verbose, the ecosystem is small, and there’s no effect tracking beyond what contracts can express.

The Uncomfortable Pattern

Every feature exists somewhere. The reason no language combines them all is that each one adds cognitive load for humans. The history of mainstream language design is about removing the things LLMs find most useful, because humans experience them as friction.

That’s the central tension: the ideal language for AI is the one humans keep rejecting.

Addendum: Additional Thoughts

Extra primitives that seem especially useful for LLMs

• Canonical, lossless AST serialization — A single, stable, deterministic, diffable, and hashable representation. That removes formatter drift and makes semantic caching trivial.
• Proof-carrying artifacts — The compiler emits machine-verifiable certificates tied to specs and effects, allowing incremental trust without rerunning the world.
• Capability-scoped effects — Effects should require explicit capability grants at the module boundary (not just declared in signatures). That gives the language a built-in permissions model.
• Spec/test duality — Specs should be executable and tests should be derivable from specs. The boundary between the two should be thin and programmatic.

Modularization for LLMs

LLMs handle monoliths better than humans, but modules still matter as semantic boundaries:

• Effect scope: capabilities are granted at module boundaries.
• Ownership and invariants: modules define which data invariants they own and enforce.
• Dependency graphs: the language can cache and re-verify smaller units.
• Partial recompilation: the impact of a change is smaller when units are isolated.

In an AI-native language, modularization should be constraint- and capability-driven, not file-driven. You can keep everything in a single file, but the units should still be explicit.

Runtime observability as a language primitive

A language for LLMs should treat structured tracing as a first-class thing:

• Every effect produces machine-readable trace events with causal links.
• Edits can be validated against behavioral deltas, not just type diffs.
• Provenance can extend into the runtime, letting you attach “why” to “what happened”.

Alternative framing

Instead of a “language”, think: native graph IR + semantic edit protocol + human projection DSL. Text becomes a view, not the source. The primary interface is a semantic graph with checked constraints, safe capabilities, and proof-carrying metadata.

The nature of the original Manga Downloader is no different from a web crawler: it fetches HTML pages, parses them in order to find collections of links and keeps fetching until a set of images is downloaded. Then I organize them in volumes, optimize them to fit the Kindle screen resolution, and compile them down into PDF files. This makes this project an interesting exercise in trying to make concurrent HTTP requests and process the results.

A year later I was learning Elixir. The Manga Downloadr was a nice candidate for me to figure out how to implement the same thing in a different language. You can follow my learning process in this series of posts.

Finally, I’ve been learning more about Crystal, a Ruby-inspired platform that can compile Ruby-like source code into LLVM-optimized native binaries. And as a bonus it features Go-like CSP channels and fibers to allow for concurrent code.

So I adapted my Elixir version to Crystal and the result is this code you can find over Github as akitaonrails/cr_manga_downloadr.

It works very well and performs really fast, limited mainly by how many requests MangaReader can respond to concurrently and the speed/reliability of the Internet connection. So, as my original Ruby version was terrible code, it was a good time to rewrite it. And as Crystal is surprisingly close to Ruby I decided to port it over.

The port was almost too trivial

It was mostly copying and pasting the Crystal code without the Type annotations. And I had to replace the lightweight Fibers and Channel implementation for concurrency with traditional Ruby Threads.

The new version 2.0 for the Ruby version of the tool can be found in this Github repository: akitaonrails/manga-downloadr.

Ruby, Ruby everywhere!

Moving between Ruby and Crystal is not so difficult. The Crystal team did a fantastic job implementing a very solid Standard Library (stdlib) that very closely resembles MRI Ruby’s.

For example, let’s compare a snippet from my Crystal version first:

def fetch(page_link : String)
  get page_link do |html|
    images = html.xpath("//img[contains(@id, 'img')]").as(XML::NodeSet)
    image_alt = images[0]["alt"]
    image_src = images[0]["src"]
    if image_alt && image_src
      extension      = image_src.split(".").last
      list           = image_alt.split(" ").reverse
      title_name     = list[4..-1].join(" ")
      chapter_number = list[3].rjust(5, '0')
      page_number    = list[0].rjust(5, '0')
      uri = URI.parse(image_src)
      CrMangaDownloadr::Image.new(uri.host as String, uri.path as String, "#{title_name}-Chap-#{chapter_number}-Pg-#{page_number}.#{extension}")
    else
      raise Exception.new("Couldn't find proper metadata alt in the image tag")
    end
  end
end

Now let’s check the ported Ruby version:

def fetch(page_link)
  get page_link do |html|
    images = html.css('#img')

    image_alt = images[0]["alt"]
    image_src = images[0]["src"]

    if image_alt && image_src
      extension      = image_src.split(".").last
      list           = image_alt.split(" ").reverse
      title_name     = list[4..-1].join(" ")
      chapter_number = list[3].rjust(5, '0')
      page_number    = list[0].rjust(5, '0')

      uri = URI.parse(image_src)
      Image.new(uri.host, uri.path, "#{title_name}-Chap-#{chapter_number}-Pg-#{page_number}.#{extension}")
    else
      raise Exception.new("Couldn't find proper metadata alt in the image tag")
    end
  end
end

It’s uncanny how similar they are, down to stdlib calls such as URI.parse or Array methods such as split.

Once you remove the Type annotations from the Crystal version, it’s 99% Ruby.

Ruby doesn’t care if you’re trying to call a method on a Nil object - at source code compiling time. Crystal does compile-time checks and if it feels like the method call will be over Nil, it won’t even compile. So this is one big win to avoid subtle bugs.

In Rails we are used to the #try method. Ruby 2.3 introduced the safe navigation operator.

So, in Ruby 2.3 with Rails, both of the following lines are valid:

obj.try(:something).try(:something2)
obj&.something&.something2

In Crystal we can do the following:

obj.try(&.something).try(&.something2)

So, it’s close. Use with care.

As I mentioned before, Crystal is close to Ruby but it’s not meant to be compatible, so we can’t just load Rubygems without porting. In this example I don’t have Nokogiri to parse the HTML. But this is where the stdlib shines: Crystal comes with good enough XML/HTML and JSON parsers. So we can parse HTML as XML and use plain XPath instead.

Instead of Ruby’s Net::HTTP we have HTTP::Client (but their methods and semantics are surprisingly similar).

There are other differences, for example, this is the main file that requires all the others in Ruby:

...
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), "lib")

require "manga-downloadr/records.rb"
require "manga-downloadr/downloadr_client.rb"
require "manga-downloadr/concurrency.rb"
require "manga-downloadr/chapters.rb"
require "manga-downloadr/pages.rb"
require "manga-downloadr/page_image.rb"
require "manga-downloadr/image_downloader.rb"
require "manga-downloadr/workflow.rb"

And this is the Crystal version of the same manifest:

require "./cr_manga_downloadr/*"
...

On the other hand, we need to be a bit more explicit in each Crystal source code file, and declare the specific dependencies where needed. For example, in the pages.cr file it starts like this:

require "./downloadr_client"
require "xml"

module CrMangaDownloadr
  class Pages < DownloadrClient(Array(String))
  ...

Crystal has less room for “magic” but it’s able to maintain a high level of abstraction anyway.

A Word about Types

We can spend the next decade masturbating over all there is about Types, and it will be extremely boring.

The only thing you must understand: the compiler must know the method signature of classes before you can use them. There is no Runtime component that can introspect objects on the fly, like in Ruby and other dynamic languages (even Objective-C/Swift can do more dynamic stuff than Crystal).

Most of the time the Crystal compiler will be smart enough to infer the types for you, so you don’t need to be absolutely explicit. You should follow the compiler’s lead to know when to use Type Annotations.

What may really scare you at first is the need for Type Annotations, to understand Generics and so forth. The compiler will print out every scary error dump that you will need to get used to. Most scary errors will usually be a Type Annotation missing or you trying to call a method on a possibly Nil object.

For example, if I change the following line in the page_image_spec.cr test file:

# line 8:
image = CrMangaDownloadr::PageImage.new("www.mangareader.net").fetch("/naruto/662/2")

# line 10:
# image.try(&.host).should eq("i8.mangareader.net")
image.host.should eq("i8.mangareader.net")

The commented out line recognizes that the image instance might come as Nil, so we add an explicit #try call in the spec.

If we try to compile without this recognition, this is the error the compiler will dump on you:

$ crystal spec                                                        [
Error in ./spec/cr_manga_downloadr/page_image_spec.cr:10: undefined method 'host' for Nil (compile-time type is CrMangaDownloadr::Image?)

    image.host.should eq("i8.mangareader.net")
          ^~~~

=============================================================================

Nil trace:

  ./spec/cr_manga_downloadr/page_image_spec.cr:8

        image = CrMangaDownloadr::PageImage.new("www.mangareader.net").fetch("/naruto/662/2")
...

There is a large stack trace dump after that snippet above, but you only need to pay attention to the first few lines that already say what’s wrong: “undefined method ‘host’ for Nil (compile-time type is CrMangaDownloadr::Image?)”. If you know how to read, you shouldn’t have any problems most of the time.

Now, the Chapters, Pages, PageImage (all subclasses of DownloadrClient) are basically the same thing: they do HTTP::Client requests.

This is how the Pages class is implemented:

...
module CrMangaDownloadr
  class Pages < DownloadrClient(Array(String))
    def fetch(chapter_link : String)
      get chapter_link do |html|
        nodes = html.xpath_nodes("//div[@id='selectpage']//select[@id='pageMenu']//option")
        nodes.map { |node| [chapter_link, node.text as String].join("/") }
      end
    end
  end
end

#get is a method from the DownloadrClient superclass that receives a String chapter_link and a block. The block receives a parsed html collection of nodes and we can play with it, returning an Array of Strings.

That’s why we have the (Array(String)) when inheriting from DownloadrClient. Let’s see how the DownloadrClient superclass is implemented.

module CrMangaDownloadr
  class DownloadrClient(T)
    ...
    def get(uri : String, &block : XML::Node -> T)
      response = @http_client.get(uri)
      case response.status_code
      when 301
        get response.headers["Location"], &block
      when 200
        parsed = XML.parse_html(response.body)
        block.call(parsed)
      end
      ...
    end
  end
end

You can see that this class receives a Generic Type and it uses it as the return type for the yielded block in the #get method. The XML::Node -> T is the declaration of the signature for the block, sending XML::Node and receiving whatever the type T is. At compile time, imagine this T being replaced by Array(String). That’s how you can create classes that can deal with any number of different Types without having to overload for polymorphism.

If you come from Java, C#, Go or any other modern statically typed language, you probably already know what a Generic is.

You can go very far with Generics, check out how our Concurrency.cr begins:

class Concurrency(A, B, C)
  ...
  def fetch(collection : Array(A)?, &block : A, C? -> Array(B)?) : Array(B)?
    results = [] of B
    collection.try &.each_slice(@config.download_batch_size) do |batch|
      engine  = if @turn_on_engine
                  C.new(@config.domain)
                end
      channel = Channel(Array(B)?).new
      batch.each do |item|
      ...

And this is how we use it in the workflow.cr:

private def fetch_pages(chapters : Array(String)?)
  puts "Fetching pages from all chapters ..."
  reactor = Concurrency(String, String, Pages).new(@config)
  reactor.fetch(chapters) do |link, engine|
    engine.try( &.fetch(link) )
  end
end

In this example, imagine A being replaced by String, B also being replaced by String and C being replaced by Pages in the Concurrency class.

This is the “first-version-that-worked” so it’s probably not very idiomatic. Either this could be solved with less Generics exercising or maybe I could simplify it with the use of Macros. But it’s working quite ok as it is.

The pure Ruby version ends up just like this:

class Concurrency
  def initialize(engine_klass = nil, config = Config.new, turn_on_engine = true)
    ...
  end
  def fetch(collection, &block)
    results = []
    collection&.each_slice(@config.download_batch_size) do |batch|
      mutex   = Mutex.new
      threads = batch.map do |item|
      ...

This version is much “simpler” in terms of source code density. But on the other hand we would have to test this Ruby version a lot more because it has many different permutations (we even inject classes through engine_klass) that we must make sure respond correctly. In practice we should add tests for all combinations of the initializer’s arguments.

In the Crystal version, because all types have been checked at compile-time, it was more demanding in terms of annotations; but we can be pretty sure that if it compiles, it will run as expected.

I’m not saying that Crystal doesn’t need any specs.

Compilers can only go so far. But how much is “so far”? Whenever you’re “forced” to add Type Annotations, I will state that those parts are either trying to be too smart or they are intrinsically complex. Those are parts that would require extra levels of tests in Ruby and, if we can add the annotations properly, we can have fewer tests (we don’t need to cover most permutations) in the Crystal version (exponential complexity of permutations could go down to a linear complexity, I think).

A Word about Ruby Threads

The main concepts you must understand about concurrency in Ruby are these:

• MRI Ruby has a GIL, a Global Interpreter Lock, that forbids code from running concurrently.
• MRI Ruby does have access and exposes native Threads since version 1.9. But even if you fire up multiple Threads, they will run sequentially because only one thread can hold the Lock at a time.
• I/O operations are the exception: they do release the Lock for other threads to run while the operation is waiting to complete. The OS will signal the program through OS-level poll.

This means that if your app is I/O intensive (HTTP requests, File reads or writes, socket operations, etc), you will have some concurrency. A web server, such as Puma for example, can take some advantage of Threads because a big part of the operations involves receiving HTTP requests and sending HTTP responses over the wire, which would make the Ruby process idle while waiting.

If your app is CPU intensive (heavy algorithms, data crunching, stuff that really makes the CPU hot) then you can’t take advantage of native Threads, only one will run at a time. If you have multiple cores in your CPU, you can Fork your process to the number of cores available.

You should check out grosser/parallel to make it easy.

This is why Puma also has a “worker” mode. “Worker” is the name we usually give to forked children of processes.

In the case of this downloader process, it will perform thousands of HTTP requests to scrape the needed metadata from the MangaReader pages. So it’s definitely much more I/O intensive than CPU intensive (the CPU intensive parts are the HTML parsing and later the image resizing and PDF compiling).

A sequential version of what has to be done, in Ruby, looks like this:

def fetch_sequential(collection, &block)
  results = []
  engine  = @turn_on_engine ? @engine_klass.new(@config.domain) : nil
  collection&.each_slice(@config.download_batch_size) do |batch|
    batch.each do |item|
      batch_results = block.call(item, engine)&.flatten
      results += ( batch_results || [])
    end
  end
  results
end

If we have 10,000 links in the collection, we first slice it to what @config.download_batch_size defines and we iterate over those smaller slices, calling some block and accumulating the results. This is a naive algorithm, as you will find out in the next section, but bear with me.

In Elixir you can fire up micro-processes to make the HTTP requests in parallel. In Crystal you can fire up Fibers and wait for the HTTP requests to complete and signal the results through Channels.

Both are lightweight ways and you can have hundreds or even thousands running in parallel. Manga Reader will probably complain if you try that many at once, so the limit is not in the code, but in the external service.

To transform the sequential version into a concurrent one, this is what we can do in Crystal:

def fetch(collection : Array(A)?, &block : A, C? -> Array(B)?) : Array(B)?
  results = [] of B
  collection.try &.each_slice(@config.download_batch_size) do |batch|
    channel = Channel(Array(B)?).new
    batch.each do |item|
      spawn {
        engine  = if @turn_on_engine
                    C.new(@config.domain)
                  end
        reply = block.call(item, engine)
        channel.send(reply)
        engine.try &.close
      }
    end
    batch.size.times do
      reply = channel.receive
      if reply
        results.concat(reply.flatten)
      end
    end
    channel.close
    puts "Processed so far: #{results.try &.size}"
  end
  results
end

Fetching a huge collection and slicing it in smaller ‘batches’ is easy. Now we have a smaller batch collection. For each item (usually a URI) we spawn a Fiber and call a block that will request and process the results. Once it’s finished processing it sends the results over a channel.

Once we finish iterating over the batch and spawning that many Fibers we can “wait” for them by doing channel.receive, which will start receiving results as soon as the Fibers finish requesting/processing each URI.

We accumulate the results and go over the next batch of the collection until finished. The amount of concurrency is determined by the size of the batch (it’s like what I did with ‘poolboy’ over Elixir where we start a fixed number of processes to run in parallel and avoid doing a Denial of Service to Manga Reader).

By the way, this Crystal implementation is similar to what you would do if you were in Go, using Channels.

In the Ruby version you can fire up native Threads - which has a lot of overhead to spawn! - and assume the HTTP requests will run almost all in parallel. Because it’s I/O intensive, you can have them all in parallel. This is what it looks like:

def fetch(collection, &block)
  results = []
  collection&.each_slice(@config.download_batch_size) do |batch|
    mutex   = Mutex.new
    threads = batch.map do |item|
      Thread.new {
        engine  = @turn_on_engine ? @engine_klass.new(@config.domain) : nil
        Thread.current["results"] = block.call(item, engine)&.flatten
        mutex.synchronize do
          results += ( Thread.current["results"] || [] )
        end
      }
    end
    threads.each(&:join)
    puts "Processed so far: #{results&.size}"
  end
  results
end

Threads are all initialized in a “paused” state. Once we instantiate those many Threads, we can #join on each of them and wait for them all to finish.

Once each Thread finishes the same URI request/process, the results must be accumulated in a global storage, in this case a simple array called results. But because we might have the chance of 2 or more threads trying to update the same array, we might as well synchronize the access (I’m not sure if Ruby’s Array access is already synchronized, but I guess not). To synchronize access we use a Mutex, which is a fine-grained lock, to make sure only 1 thread can modify the global array at once.

To prove that Ruby can support concurrent I/O operations, I have added 2 methods to the Concurrent class, the first is just #fetch and it’s the Thread implementation above. The second is called #fetch_sequential and it is the sequential version also shown at the beginning of this section. And I added the following spec:

it "should check that the fetch implementation runs in less time than the sequential version" do
  reactor = MangaDownloadr::Concurrency.new(MangaDownloadr::Pages, config, true)
  collection = ["/onepunch-man/96"] * 10
  WebMock.allow_net_connect!
  begin
    concurrent_measurement = Benchmark.measure {
      results = reactor.fetch(collection) { |link, engine| engine&.fetch(link) }
    }
    sequential_measurement = Benchmark.measure {
      results = reactor.send(:fetch_sequential, collection) { |link, engine| engine&.fetch(link) }
    }
    /\((.*?)\)$/.match(concurrent_measurement.to_s) do |cm|
      /\((.*?)\)/.match(sequential_measurement.to_s) do |sm|
        # expected for the concurrent version to be close to 10 times faster than sequential
        expect(sm[1].to_f).to be > ( cm[1].to_f * 9 )
      end
    end
  ensure
    WebMock.disable_net_connect!
  end
end

Because it uses WebMock, I first disable it during this spec. I create a fake collection of 10 real links to MangaReader. And then I benchmark the Thread-based concurrent version and the plain sequential version. Because we have 10 links and they are all the same you can assume that the sequential version will be almost 10 times slower than the Thread-based version. And this is exactly what this spec compares and proves (the spec fails if the concurrent version is not at least 9x faster).

To compare all versions of the Manga Downloadrs I let it download and compile an entire manga collection, in this case “One-Punch Man”, which has almost 1,900 pages/images. I am just measuring the fetching and scraping processes and skipping the actual image downloading, image resizing and PDF generation as they take the majority of the time and the resizing and PDF part are all done by ImageMagick’s mogrify and convert tools.

This is how long this new Ruby version takes to fetch and scrape almost 1,900 pages (using MRI Ruby 2.3.1):

12,42s user 1,33s system 23% cpu 57,675 total

This is how long the Crystal version takes:

4,03s user 0,40s system 7% cpu 59,207 total

Just for fun I tried to run the Ruby version under JRuby 9.1.1.0. To run with JRuby just add the following line in the Gemfile:

ruby "2.3.0", :engine => 'jruby', :engine_version => '9.1.1.0'

Bundle install, run normally, and this is the result:

47,80s user 1,99s system 108% cpu 45,967 total

And this is how long the Elixir version takes:

11,38s user 1,04s system 85% cpu 14,590 total

Reality Check!

If you just look at the times above you might come to the wrong conclusions.

First of all, it’s an unfair comparison. The Elixir version uses a very different algorithm than the Ruby and Crystal versions.

In Elixir I boot up a pool of processes, around 50 of them. Then I start 50 HTTP requests at once. Once each process finishes, it releases itself back to the pool and I can fire up another HTTP request from the queue of links. So it’s a constant stream of at most 50 HTTP requests, constantly.

The Crystal and Ruby/JRuby versions slice the 1,900 links into batches of 40 links and then I fire up 40 requests at once. This implementation waits for all 40 to finish and they fire up another 40. So it’s never a constant stream, it’s bursts of 40 requests. So each batch is slowed down by the slowest request in the batch, not giving a chance for other requests to go through.

It’s a difference in architecture. Elixir makes it much easier to do streams and Crystal, with its CSP style, makes it easier to do bursts. A better approach would be to queue up the 1,900 links and use something like Sidekiq.cr to go over one link at a time (spawning 40 fibers to serve as a “pool”, for example).

The Elixir version has a more efficient architecture, which is why it takes no more than 15 seconds to fetch all the image links while the Crystal version takes almost a full minute to finish (the accumulation of the slowest requests in each batch).

Now, you will be surprised that the Crystal version is actually a bit slower than the Ruby version! And you won’t be too surprised to see JRuby being faster at 45 seconds!

This is more evidence that you should not dismiss Ruby (and that you should try JRuby more often). As I explained before, it does support concurrency in I/O operations and the applications I tested are all I/O heavy.

The difference is probably in the maturity of Ruby’s Net::HTTP library against Crystal’s HTTP::Client. I tried many tweaks in the Crystal version but I couldn’t get much faster. I tried to do larger batches, but for some reason the application just hangs, pauses, and never releases. I have to Ctrl-C out of it and retry until it finally goes through. If someone knows what I am doing wrong, please don’t forget to write in the comments section below.

Some of this is probably due to MangaReader’s unreliable servers, they probably have some kind of DoS protection, throttling connections or something like this.

Anyway, when they go through, because the Ruby and Crystal algorithms are essentially the same, they take roughly the same time to complete. So what’s missing is for me to evolve this algorithm to either use something like Sidekiq or implement an internal queue/pool of workers scheme.

Conclusion

The goal of this experiment was to learn more of Crystal’s ability and how easy it would be to go back and forth with Ruby.

As you can see, there are many differences, but it’s not so difficult. I may be missing something, but I stumbled upon some difficulties when pushing HTTP::Client + Fibers too hard, as I explained above. If you know what I am doing wrong, please let me know.

The difference between the Elixir vs Ruby/Crystal algorithms shows not just language performance differences, but also the importance of architecture and algorithms in the overall performance. This test was not conclusive, just a hint that my naive Fibers implementation needs some more work, and that Elixir’s natural handling of parallel processes makes it easier to achieve higher levels of parallelism.

This serves as a taste of what Crystal can do, and also that Ruby is still in the game. But also that Elixir surely is something to look at closely.

I’ll say that Erlang OTP and its internals intrigue me more than just the novelty of the language syntax. I believe that if you want to build highly distributed and also highly reliable systems you will either use Erlang (through Elixir) or you will end up replicating most of what Erlang already has with OTP.

This is true if you see that there are many Java/Scala-based distributed systems such as Hadoop, Spark, Cassandra, and they all could have benefitted from Erlang’s OTP architecture. On the other hand, if you follow Cassandra you will see that even Java still has a hard time competing with C++ if you compare the clone called ScyllaDB.

I believe Elixir (perhaps with HiPE) can compete in the same league as Java for distributed systems, avoiding people leaving the Erlang platform for C or Java as happened with CouchDB back in 2012 because of lack of interest and exotic syntax. And because Java already has a big ecosystem, Clojure is in the game primarily because it can interface directly with it.

I think Go is also a Java contender but for other use cases, particularly in the systems tools space where you have lots of C/C++ and also glue code in Perl and Python. An obvious example being Docker orchestration. Yes, you can do microservices, crawlers and other stuff but I am not so keen to build big “applications” in it, although there is nothing preventing it. Again, it’s just a personal opinion.

Rust is a big contender to low-level systems development. I think it can replace C in many use cases and be used to implement libraries and components to be used by other languages, with the added benefits of a modern language that tries to avoid security hazards such as the recent Heartbleed debacle. But because of its “Borrow system” I find it extremely bureaucratic, especially if you’re coming from highly dynamic languages such as Ruby, Python or even Swift or Elixir. I’m not saying it’s a bad thing, just something that takes way more time to become comfortable with than I expected.

Crystal is something between Rust and Go. LLVM is something you must have on your radar, because of Apple’s support towards Swift it’s better than ever. Crystal is similar to RubyMotion in terms of both being similar to Ruby but not fully compatible and both being front-end parsers to LLVM. RubyMotion, on the other hand, is closer to Ruby and can even use some Ruby libraries almost without changes.

You do have to take your hats off to Ary Borenszweig and his contributors. It’s very impressive how far they got in such a short period of time and without having deep pockets from Mozilla, Apple or Google.

Limitations

Crystal borrows heavily from Ruby but it’s not a goal to reach any level of compatibility. It’s a strong, statically typed language with Type Inference. It does not have any runtime component such as RubyMotion or Swift, so it has no notion of introspection or reflection over objects.

Mainly, you have neither “#eval” nor “#send”. The lack of runtime evaluation is not so bad as you do have compilation-time AST manipulation through a good enough system of Macros (more on that later).

But the lack of “#send” does hurt a bit. It’s the one thing that makes Crystal further away from Ruby’s dynamic object flexibility. But it’s also understandable why it’s not a priority to have it.

As of version 0.17.0, Crystal has one huge limitation: it’s using a Boehm-Demers-Weiser conservative garbage collector.

@asterite @headius I assumed as much... the Boehm GC, although handy for starting a new language, will only get you so far

— Jason Frey (@Fryguy9) May 29, 2016

The language is currently implemented as a single-threaded process. This means that you probably can’t max out all CPUs of your machine with just a single process. Although I may be wrong here, it’s just my first impressions.

Charles Nutter (from JRuby fame) gives a warning about this:

@fryguy9 From their site: https://t.co/uOjIT0c8ji It does say something about "when" parallelism happens. Risky to start single-threaded.

— Charles Nutter (@headius) May 29, 2016

It’s a double-edged sword. Using a “generic” plug-and-play GC such as Boehm - which is not a bad thing in itself, but it’s possibly not nearly as powerful as the JVM’s own set of high performance GC such as the brand new G1GC.

Making the language single-threaded by default also means that the entire standard library and the whole ecosystem are built assuming there is no parallelism. So there are no race-conditions and hence, no usage of proper synchronization anywhere. If one day they decide to add multi-threading, all existing code will not be thread-safe. This is probably the meaning of Charles’ warning.

I don’t think it’s a pressing problem though. You probably won’t have a highly parallel system built with Crystal but maybe it’s not the use case. In that case you should be using Elixir + OTP, Scala + Akka, for example.

Concurrency

Not having access to native Threads doesn’t mean that you can’t have Concurrency. Concurrency is not Parallelism. Since version 0.7.0 they have added support for non-blocking I/O and also Fibers and Channels.

In a nutshell, a Fiber is a special kind of coroutine. It’s a “piece of execution” that can “pause” itself and yield control of the execution back to its caller. It can pause itself but it can’t be paused from the outside like Erlang’s Scheduler can pause its running processes, for example.

In this case we can have a “Fiber Scheduler” of sorts, that can “resume” other Fibers. It is currently single-threaded, of course. And it works as an Event Loop. Whenever you have a non-blocking I/O operation waiting for file reading, network packet sending and stuff like that, it can yield control back to other fibers to resume work.

This makes it work more or less like Node.js. Javascript is also a single-threaded language and Node.js is basically an implementation of an event loop. Functions declare other anonymous functions as callbacks and it works based on the I/O triggers to callback those functions on every tick of the reactor.

On top of that you can add “Channels” as popularized by Google’s Go language. You can start as many channels as you like. Then you can spawn Fibers in the Scheduler. Fibers can execute and keep sending messages through the Channels. Execution control is yielded to whoever is expecting to receive from the same Channels. Once one of them receives and executes, control is sent back to the Scheduler to allow other spawned Fibers to execute, and they can keep “pinging” and “ponging” like this.

Speaking of ping-pong, you have this snippet in the “Go by Example” site:

package main
import "fmt"
func ping(pings chan<- string, msg string) {
    pings <- msg
}
func pong(pings <-chan string, pongs chan<- string) {
    msg := <-pings
    pongs <- msg
}
func main() {
    pings := make(chan string, 1)
    pongs := make(chan string, 1)
    ping(pings, "passed message")
    pong(pings, pongs)
    fmt.Println(<-pongs)
}

And this is mostly the same thing but implemented in Crystal:

def ping(pings, message)
  pings.send message
end

def pong(pings, pongs)
  message = pings.receive
  pongs.send message
end

pings = Channel(String).new
pongs = Channel(String).new
spawn ping pings, "passed message"
spawn pong pings, pongs
puts pongs.receive
# => "passed message"

Same thing, but more pleasant to my eyes, again a personal opinion - which is expected if you’re also a Rubyist.

So Crystal has Node.js/Javascript-like Event Loop in the form of a Fiber Scheduler and a Go-like Channel/CSP mechanism to coordinate concurrent processing. It’s a “cooperative multitasking” mechanism. It’s not good if you have CPU intensive processing, such as heavy number crunching, data processing. It works best for I/O intensive processing.

If you have a Fiber doing super heavy processing, it will block the Scheduler, as is also true for Node.js. The current implementation of the Scheduler is bound to a single native thread so it can’t use other available native threads of the system for now.

Because the Channel implementation is quite new, it’s not used throughout the standard library. But the standard implementation for HTTP::Server uses Fibers. And because it is compiled down to a native binary it’s way faster than Javascript, as this “fast-http-server” shows:

• fast-http-server (Crystal) 18348.47rpm at 8.67ms avg. response time
• http-server (Node.js) 2105.55rpm at 47.92ms avg. response time
• SimpleHTTPServer (Python) 785.14rpm at 1.91ms avg. response time

We’re talking about an order of magnitude of 8 times faster than Node.js and more than 20 times faster than Python.

As usual, you shouldn’t blindly trust synthetic benchmarks but depending on which kind of processing you decide to compare against, you will see Crystal being pretty on par with Rust, Go, Swift, D.

Type Inference

Crystal is a statically typed language. But it won’t require you to declare every single type beforehand. It’s quite smart in its Type Inference so if you just type:

a = 1
b = "HELO"

It will know that “a” is an “Int32” and that “b” is a “String”. By the way, contrary to Ruby, all Strings must be double-quoted. But it becomes particularly more complicated when you’re dealing with complicated data structures such as JSON.

In Ruby I can just parse a JSON String and immediately explore its structure like this:

parsed_json = JSON.parse(response.body)["files"].first["id"]

I can’t do this in Crystal, instead the recommended approach is to declare a schema-like structure like this:

class FilesResponse
  JSON.mapping({
    ok: {type: Bool},
    files: {type: Array(FilesItemResponse)}
  })
end
class FilesItemResponse
  JSON.mapping({
    id: {type: String},
    name: {type: String},
    filetype: {type: String},
    created: {type: Time, converter: Time::EpochConverter}
    timestamp: {type: Time, converter: Time::EpochConverter}
    permalink: {type: String}
  })
end
...
# parsed_json = JSON.parse(response.body)["files"].first["id"]
parsed_json = FilesResponse.from_json(@body).files.first.id

I am very used to Ruby’s duck typing and the ability to query objects in runtime. It’s just not the same in Crystal and it can be quite tedious to change your mindset to think about types beforehand. The compiler will scream a hell of a lot during your development cycle until you become acquainted with this concept.

I did an experiment with JSON parsing and the result is a project I called “cr_slack_cleanup” which showcases both this idea of JSON Schemas as well as Fibers and Channels as I explained in the previous section.

Update: after I posted this article @LuisLavena stepped in to correct me: you can do it like Ruby, without schemas:

@AkitaOnRails @CrystalLanguage re: JSON, you can parse it kinda-like Ruby, see JSON::Any: https://t.co/MD7PYy5AVH

— Luis Lavena (@luislavena) June 1, 2016

And it will be like this:

require "json"

data = <<-JSON
  {
    "files": [
        {
          "id": 1,
          "name": "photo.jpg"
        },
        {
          "id": 99,
          "name": "another.jpg"
        }
    ]
  }
  JSON

obj = JSON.parse(data)

obj["files"].each do |item|
  puts item["id"].as_i
end

So yeah, JSON parsing can be almost identical to what you would do with Ruby, although he also recommends Schemas as it’s a bit faster anyway.

Macros

The last important feature worth mentioning is the presence of Macros. As you don’t have control over your code in runtime, you don’t have “eval”, you don’t have “send”, then you would not have any way to do proper metaprogramming.

Macros bring back some of Ruby’s metaprogramming. For example, in Ruby, when you include a Module to a Class, there is the “included?” hook in the Module where you can add some metaprogramming such as “class_eval” stuff.

In Crystal, a Module does have an “included” hook but now it’s a Macro. You can do something like this:

module Foo
  macro included
    {% if @type.name == "Bar" %}
    def self.hello
      puts "Bar"
    end
    {% else %}
    def self.hello
      puts "HELLO"
    end
    {% end %}
  end
end

module Bar
  include Foo
end

module Something
  include Foo
end

Bar.hello # => "Bar"
Something.hello # => "HELLO"

It feels like having “ERB” templates but for code. A macro is code building code in compile time. In the resulting AST it’s as if you wrote the boring repetitive code yourself. The compiled native binary doesn’t care. If you’re from C it’s like pre-processing but having control of an AST tree of Nodes instead of just manipulating the source code. You can even have something akin to the venerable “#method_missing”.

class Foo
  macro method_missing(name, args, block)
    {{pp name}}
  end
end

Foo.new.hello_world
# => name = "hello_world"
Foo.new.bla_bla("bla")
# => name = "bla_bla"

Any macro function can receive an AST as the argument and you can manipulate this AST in any way as you see fit. For example:

module Foo
  macro teste(ast)
    puts {{ast.stringify}}
  end
end

Foo.teste "Hello World".split(" ").join(" - ")
# => ("Hello World".split(" ")).join(" - ")

In this example you just get a normalized version of the code you passed as argument. And the code won’t be “executed” at that location.

So, you can define new methods and call different versions of methods depending on the combination of elements that you get from the AST. One example of what is possible is this experiment from developer Oleksii that I bundled in this small project I called “cr_chainable_methods” and we can build code that is very different from either Crystal or Ruby:

result = pipe "Hello World"
  .>> Foo.split_words
  .>> Foo.append_message("Bar")
  .>> Bar.add_something
  .>> Foo.join
  .>> unwrap

(Yes, a subset of what a real Elixir Pipe can do.)

Crystal Shards

Finally, one aspect I like about Crystal is that it has task management and dependency management already figured out. No pointless discussions on which implementation of packages and dependencies we “should” be using.

You can just write a simple script into a file such as “test.cr” and run this file like this:

crystal test.cr

Or, you can build and compile to a native binary before executing like this:

crystal build test.cr --release
./test

And you can also start in a proper project structure and development lifecycle like this:

crystal init app test
cd test
crystal build src/test.cr --release
./test
git add .
git commit -m "initial commit"
git push -u origin master

It sets up a proper project directory structure, a Git repository is pre-initialized for you (why would you be programming without Git!?) with proper “.gitignore” file.

You will also find a “shard.yml” file where you can declare your application or library name, version, author, and also its dependencies like this:

name: kemal
version: 0.12.0

dependencies:
  radix:
    github: luislavena/radix
    version: 0.3.0
  kilt:
    github: jeromegn/kilt
    version: 0.3.3
author:
  - Serdar Dogruyol <dogruyolserdar@gmail.com>

This example is from the Kemal web framework by Serdar. It depends on the Radix and Kilt libraries. You must run crystal deps and it will fetch from Github before you can compile.

More than that: every project receives a proper “spec” directory where you can write Rspec-like tests and you can run them using crystal spec. And the spec runner results will look like this:

$ crystal spec
........................................................

Finished in 8.28 milliseconds
56 examples, 0 failures, 0 errors, 0 pending

All built-in, no external libraries needed.

And 8 milliseconds to run the entire test suite of a micro web framework? Not too shabby. If you add up start up time for the executable, it still is around 1 second of total running time. Pretty impressive.

Conclusion

Crystal is not meant to be a Ruby replacement like JRuby. So it will never run existing and complicated Ruby projects such as Ruby on Rails or even Sinatra for that matter.

To me Crystal fills a gap in some use cases where I would use Rust or Go. It has the raw performance of an LLVM-optimized native binary, a reasonably fast Go-like concurrency system (and much faster and less resource intensive than Node.js), and the added benefit of a much more enjoyable Ruby-like syntax set.

You can even start experimenting with Crystal to build Ruby native extensions without the need of FFI and without having to write C. There is an attempted port of ActiveSupport as a native extension to MRI Ruby, written as a proof of concept in Crystal.

If you’re a Rubyist you will find yourself pretty much at home with most of the standard library. You will miss a thing or two but most of the time it will feel like Ruby. The official Guide is good enough to get started and there is a comprehensive API documentation just to check if that favorite Ruby API is there or not, and if not what the replacements are. Most of the time you will think “hmm, in Ruby I would use Enumerator#each … and yes, sure enough, there is Enumerator#each as expected.” The API documentation could use some more love, so if you want to contribute this is a good place to start.

If you want to check out a curated list of Crystal libraries and applications, go straight to “Awesome Crystal”. You can also see the more dynamic “Trending Projects in Github”.

For the most part, your proficiency in Ruby will pay off to build small systems where raw performance and concurrency are really necessary. This is exactly the use case for Mike Perham’s port of Sidekiq.cr. Say you have gigabytes of files to crunch. Or you have thousands of external websites to crawl, parse and organize. Or you have petabytes of data in your database waiting to be number crunched. Those are tasks that MRI Ruby won’t help with but Crystal may well be the quick answer.

You can even get one of the many micro web frameworks such as Kemal and deploy your HTTP API providers directly to Heroku now. This will give you Go-levels of performance, and this is very compelling for me as I really also dislike Go’s archaic smelling syntax.

So, Rust, Go, Javascript, all very fast, but with very questionable syntaxes and not so enjoyable. They are way more mature, and their ecosystems are much larger. But unless I really need to, I’d rather choose Crystal for the use cases I described above, and I think you will find some good use for it too.

Update: after I posted, the creator of Crystal, @Asterite had a few things to add as well:

@AkitaOnRails @waj so it's likely that we'll have something similar. We aren't there yet because we are not Google, Mozilla nor Apple

— Ary Borenszweig (@asterite) May 31, 2016

If you don’t know what the “Pipe Operator” is in Elixir, take the following code:

Enum.sum(Enum.filter(Enum.map(1..100_000, &(&1 * 3)), odd?))

It’s ugly, we all know that. In an Object Oriented language like Ruby we would do something like this:

(1..100_000).
  map { |i| i * 3 }.
  select(&:odd?).
  reduce(&:+)

But Elixir does not have objects, only functions, so how can we code more elegantly? The solution came up in the form of the so called “Pipe Operator” which takes the last returning value and passes it through as the first argument of the next function call, like this:

1..100_000
  |> Stream.map(&(&1 * 3))
  |> Stream.filter(odd?)
  |> Enum.sum

So Ruby and Elixir “feel” the same when we are able to “chain” methods. In the Ruby world we don’t have the “need” for an operator like that. But it would be nice to have a mechanism that we could use to make our code more expressive, or more testable, or more readable. For example, what if we could write something like this:

(1..100_000).
  multiple_each_element_by_three.
  filter_out_odd_elements.
  give_the_sum_of_all_elements

Of course, this is a very constrained example with really bad method naming. But if we look at Mo Lawson’s article I linked above, it becomes more interesting:

keywords
  .map { |kw| kw.gsub(/(^[^[:alpha:]]+|[^[:alpha:]]+$)/, '') }
  .map { |kw| LegacySpanishCorrector.new.correct(kw) }
  .map { |kw| kw.gsub(/[^[:alpha:]\d'_\-\/]/, '') }
  .reject { |kw| STOP_WORDS.include?(kw) }

Ruby allows us to chain Enumerable methods one after the other, transforming the initial keywords list into “something” that is very difficult to infer just by looking at this code.

What about this other version?

class KeywordNormalizer
  def call(keywords)
    Collection.new(keywords)
      .strip_outer_punctuation
      .fix_spanish
      .clean_inner_punctuation
      .remove_stop_words
      .to_a
  end

  # ...
end