{"slug": "show-hn-riot-a-modern-multicore-actor-based-ecosystem-for-ocaml", "title": "Show HN: Riot, a modern multicore actor-based ecosystem for OCaml", "summary": "A new open-source ecosystem called Riot launched for the OCaml programming language, providing a complete stack with a multi-core actor-model runtime, package registry, and standard library. The project ships with an agent-facing skill system that instructs AI agents how to build, test, fuzz, and maintain projects, including structured JSON output for machine readability. Riot aims to simplify OCaml development by offering a single command-line tool for building, formatting, linting, testing, and fuzzing, with opinionated defaults and no configuration options for formatting.", "body_md": "Riot is a tech-demo of a stack and tooling for building applications in OCaml.\nIt is heavily opinionated, and designed from the ground up to get\nout of your way and help you ship great software with agents.\n\nIt comes with a single tool for all your needs, a modern package\nregistry, a multi-core ready actor-model runtime, a whole new\nstandard library, and first-class support for agentic work.\n\nRiot is also a tool: riot — and it's the only tool\nyou need in this stack.\n\nRiot ships with agent-facing instructions, not just human\ndocs. The riot-ml skill tells agents how to use\nthe stack, which commands to prefer, where workflows live, and\nhow to keep package discovery grounded in pkgs.ml.\n\nEvery new Riot project created with riot init includes an .agents folder with the Riot skill already there. Start the project, then use your agent.\n\nThe local skill explains how to build, test, benchmark, run, format, fix, fuzz, and maintain Riot projects.\n\nRiot commands prefer structured output with --json, so agents can inspect build results, diagnostics, test runs, package metadata, and registry flows without scraping prose.\n\nThe skill links deeper workflow references for testing, fuzzing, benchmarking, snapshots, and package lookup, so agents can run the right loop instead of guessing.\n\n/llms.txt is the public discovery map for agents that find Riot from the web; inside a Riot workspace, the local skill is the starting point.\n\nriot build\n\nEasy, fast builds\n\nRiot builds packages. A package is the unit of the build, and\neach package is defined by a plain riot.toml file.\n\nRiot implements a new package-aware build system, so package boundaries, dependencies, targets, and generated artifacts all belong to the same model.\n\nriot.toml is ordinary TOML: no S-expressions, no separate configuration language, and no hidden build folklore.\n\nBuild one package, the whole workspace, debug builds, release builds, and cross targets from the same command.\n\nTarget selection supports exact triples and broad patterns like linux.\n\nriot fmt\n\nOne house style\n\nriot fmt is a fast zero-config formatter optimized\nfor readability and minimizing diffs.\n\nThere is one house style, and no options. Done.\n\nFormatting is part of the stack, not a project-by-project bikeshed.\n\nOutput should be readable first and stable enough that reviews show the actual change.\n\nriot fix\n\nLinting and codemods\n\nriot fix is an extensible linter with automated\nfixes, codemods, and package-provided rules.\n\nRiot fix should not just tell you something is wrong. When Riot knows the fix, it shows the edit and can apply it.\n\nPackages can register lint rules and fixes, then workspaces or packages can enable those rules in riot.toml.\n\nThis is what makes upgrades smoother: the package that changed can ship the rule that helps your code move with it.\n\nriot test\n\nTesting\n\nUnit tests, property tests, snapshot tests, and fuzz cases live\nunder one test runner.\n\nUse unit tests for exact behavior, property tests for broad invariants, and snapshots for generated output that needs review.\n\nFuzz cases declared with the test API replay under riot test, so weird inputs found later become part of the ordinary regression loop.\n\nPackage and suite filters keep the local loop tight when you only need one slice of the workspace.\n\nriot fuzz\n\nCoverage-guided fuzzing\n\nriot fuzz runs coverage-guided fuzzing campaigns\nagainst narrow boundaries such as parsers, codecs, protocol\nhandlers, and CLI parsers.\n\nA fuzz case is an ordinary Std.Test case declared with Test.fuzz, with seeds, corpus files, and mutator hints.\n\nGenerated coverage-increasing inputs are stored under .riot/fuzzing/<package>/<suite>/<case>/corpus/ as local state.\n\nCrashes are saved under crashes/, with captured stdout, stderr, and status in crash-artifacts/ for triage.\n\nA real finding should become a small durable regression: an inline seed, a curated fixture, or a minimized tracked crash input.\n\nriot snapshots\n\nSnapshot review\n\nSnapshot testing checks generated output by comparing it\nagainst a saved expected file. When the output changes, the\ntest writes a new candidate so you can inspect the diff and\ndecide whether the change is correct.\n\nriot snapshots is the review loop for those\ncandidates: approve the new expected output, reject it, or\nleave it pending until you understand what changed.\n\nUse snapshots for output where the full shape matters: formatter output, diagnostics, generated docs, parser fixtures, and text reports.\n\nSnapshot candidates are written as pending files, so generated changes do not silently replace the expected behavior.\n\nInteractive review lets you approve, reject, ignore, or quit without manually hunting through fixture paths.\n\nThe goal is not to bless every diff. The goal is to make expected-output changes visible, reviewable, and boring to manage.\n\nriot bench\n\nBenchmarking\n\nriot bench runs small and large benchmarks, then\nrecords and compares runs from the same toolchain.\n\nBenchmark suites run through Riot, so they use the same package, profile, and toolchain model as the rest of the workspace.\n\n--record persists a run under .riot/bench when you want history, and --compare brings previous comparable runs into the current report.\n\nUse release profile benchmarks when the performance question is about optimized code.\n\npkgs.ml is the Riot package registry: package\nindex, publish flow, search surface, generated docs, and\npublic usage stats.\n\nThe registry is powered by GitHub and Cloudflare, but the workflow stays in Riot: add, remove, update, publish, yank, search, login, and logout.\n\nPublishing a package can generate documentation and make it available under docs.pkgs.ml.\n\nThe registry tracks useful public statistics, like downloads and version usage, so maintainers can see what still needs support.\n\nPackage operations stay scriptable for local workflows and agents with --json where automation needs it.\n\nriot initriot new\n\nGolden-path scaffolding\n\nriot init and riot new create\nworkspaces and packages from the blessed path instead of\nassembling boilerplate by hand.\n\nriot init starts a workspace with the files Riot expects, including package manifests and the OCaml toolchain config.\n\nriot new adds a package inside an existing workspace without making you remember the directory shape.\n\nThe first generated project should already feel like Riot: a package, a manifest, a test loop, and a clear next command.\n\nriot toolchain\n\nOCaml toolchains\n\nRiot ships vendored, precompiled OCaml toolchains and\ncompilers for supported architectures.\n\nA workspace declares the OCaml version and target set in ocaml-toolchain.toml.\n\nRiot provisions and validates the toolchain under ~/.riot/toolchains, including cross-toolchain components when targets need them.\n\nBuilds, docs, tests, benches, fuzzing, and package commands use the same toolchain decision.\n\nriot doc\n\nDocumentation\n\nriot doc generates package documentation locally\nfor your packages and dependencies.\n\nDocumentation is written in Markdown in source comments and package docs, then generated into static pages.\n\nGenerated docs follow Riot's Jolly Roger, so package docs, API reference pages, and registry docs share one readable style.\n\nPublishing to pkgs.ml can publish docs under docs.pkgs.ml as part of the package flow.\n\nriot run\n\nRun executables\n\nriot run runs Riot executables from your\nworkspace, GitHub repos, and URLs.\n\nRun local workspace binaries without manually finding the build output path.\n\nDisambiguate by package when a workspace has more than one runnable target.\n\nRun remote sources for project generators, scaffolding helpers, and one-off tools.\n\nForward runtime arguments after -- so the command remains scriptable.\n\nriot <pkg>:<cmd>\n\nPackage provider commands\n\nPackages can register first-class Riot commands, so\ndependencies can extend your workflow without becoming\nseparate global tools.\n\nA package can declare commands in riot.toml; Riot discovers them from the workspace and runs them as riot package:command.\n\nRiot builds the package before executing the command, so provider commands stay in sync with the package version you depend on.\n\nThat makes package-specific workflows feel native: migrations, code generation, asset compilation, schema checks, and project upgrades can all live behind Riot.\n\nWhat’s possible in Riot?\n\nRiot is for building OCaml software as one piece: tools, services,\ndatabases, packages, experiments, and systems that need to stay\nunderstandable while they grow.\n\nMulti-core applications\n\nBuild actor-oriented systems on top of the runtime in\nstd/runtime and the actor interface exposed through\nstd/actor. Spawn work, supervise it, and let Riot use\nthe cores you have.\n\nCommand line interfaces\n\nBuild fast CLIs with structured output, clear errors, and the kind\nof terminal behavior agents and humans can both drive.\n\nCloud and networked services\n\nUse actors, supervision, message passing, and a practical standard\nlibrary to build services that do real IO. The std/IO\nsurface includes ioSlice for zero-copy operations\nwhen bytes need to move without extra copying.\n\nDeveloper tooling\n\nWrite formatters, linters, code generators, release tools,\nmigration scripts, and project automation with the same toolchain\nthey plug into.\n\nTUI applications\n\nBuild terminal interfaces with Riot packages like\nminttea and gooey: structured state,\nkeyboard-driven UI, and native terminal ergonomics.\n\nWeb applications\n\nBuild web surfaces with suri, including LiveView\nsupport in suri/liveview, typed domain logic, and\nagent-friendly APIs without giving up the ergonomics of OCaml.\n\nDatabase-backed systems\n\nBuild typed database flows with sqlx, connect to\nPostgreSQL through postgres, and use\nsqlite when the right database is a local file.\n\nAgentic workflows\n\nCreate workflows that can be run, inspected, repaired, and\nrepeated by agents: JSON output, stable diagnostics, clear command\nboundaries, and recoverable failure modes.", "url": "https://wpnews.pro/news/show-hn-riot-a-modern-multicore-actor-based-ecosystem-for-ocaml", "canonical_source": "https://riot.ml", "published_at": "2026-05-26 06:47:08+00:00", "updated_at": "2026-05-26 07:09:04.096152+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "ai-infrastructure"], "entities": ["Riot", "OCaml", "pkgs.ml"], "alternates": {"html": "https://wpnews.pro/news/show-hn-riot-a-modern-multicore-actor-based-ecosystem-for-ocaml", "markdown": "https://wpnews.pro/news/show-hn-riot-a-modern-multicore-actor-based-ecosystem-for-ocaml.md", "text": "https://wpnews.pro/news/show-hn-riot-a-modern-multicore-actor-based-ecosystem-for-ocaml.txt", "jsonld": "https://wpnews.pro/news/show-hn-riot-a-modern-multicore-actor-based-ecosystem-for-ocaml.jsonld"}}