// HACKER NEWS — CYBERSECURITY
Show HN: Rex, a parallel functional language for scientific workflows
Rex (short for Rush Expressions) is a statically typed,
pure functional workflow language. It is designed for
scientific computing and data processing: work in Rex is expressed as pure
transformations over immutable values, while typed tool modules delegate
work to external programs for compute-intensive tasks.
The workflow runtime connects four ideas that are particularly useful when
processing scientific data:
Together these properties make workflow definitions concise, inspectable, and
amenable to parallel execution. They also create a clean boundary between the
logic of an analysis and the operating-system processes that carry it out.
Rex is also useful as a target for LLM-generated workflows: static types give
fast, high-signal feedback, pure code is easier to inspect, and the closed tool
boundary sharply limits what generated programs can ask the host to execute.
See LLM guidance for syntax and validation advice.
Project status: the main branch contains the work in progress toward
Rex v4 and is currently versioned as 3.9.x. rex-workflow is new and under
active development. The older production release of the core Rex language
is available at talo/rex.
Many workflow systems begin with a directed acyclic graph and gradually grow
their own expression syntax, templates, conditionals, loops, and plugin model.
Rex starts with a small general-purpose language instead. It provides
Hindley–Milner type inference, algebraic data types, records, pattern matching,
parametric polymorphism, type classes, higher-order functions, recursion, and
modules.
That matters for scientific and data-processing work because real pipelines
rarely remain a static sequence of commands. They need to map an analysis over
a cohort, group observations, branch on metadata, preserve domain-specific
failure information, combine several tools, and package reusable methods.
Those operations are natural in a functional program:
Rex uses strict evaluation, but expressions and functions are pure: their
meaning does not depend on hidden mutable state in the language. This gives
the evaluator freedom to run independent asynchronous calls concurrently
without making users manage threads, futures, locks, async/await syntax,
or callback graphs. Sequential dependencies are expressed by passing one
result into the next; independent work remains independent in the source.
Purity also improves reviewability. A function's arguments describe the data
it can use, its result type describes what it can produce, and an algebraic
data type can enumerate every expected outcome. Tool modules preserve this
model by returning ordinary typed values such as:
Expected invalid requests and tool-process failures can therefore be matched
and handled inside the workflow. Storage failures, executor failures, and
other infrastructure problems remain evaluation errors, keeping domain
failures distinct from failures of the runtime itself.