{"id":45687576,"title":"Show HN: I built Kumi – a typed, array-oriented dataflow compiler in Ruby","points":4,"user":"goldenCeasar","time":1761255596,"time_ago":"2 days ago","type":"link","content":"

Hi HN,

I'm the author of Kumi, a project I've been working on and would love to get your feedback on.

The Original Problem:

The original idea for Kumi came from a complex IAM problem I faced at a previous job. Provisioning a single employee meant applying dozens of interdependent rules (based on role, location, etc.) for every target system. The problem was deeper: even the data abstractions were rule-based. For instance, 'roles' for one system might just be a specific interpretation of Active Directory groups.

This logic was also highly volatile; writing the rules down became a discovery process, and admins needed to change them live. This was all on top of the underlying challenge of synchronizing data between systems. My solution back then was to handle some of this logic in a component called "Blueprints" that interpreted declarative rules and exposed this logic to other workflows.

The Evolution:

That "Blueprints" component stuck in my mind. About a year later, I decided to tackle the problem more fundamentally with Kumi. My first attempts were brittle—first runtime lambdas, then a series of interpreters. I knew what an AST was, but had to discover concepts like compilers, IRs, and formal type/shape representation. Each iteration revealed deeper problems.

The core issue was my AST representation wasn't expressive enough, forcing me into unverifiable 'runtime magic'. I realized the solution was to iteratively build a more expressive intermediate representation (IR). This wasn't a single step: I spent two months building and throwing away ~5 different IRs, tens of thousands of lines of code. That painful process forced me to learn what it truly meant to compile, represent complex shapes, normalize the dataflow, and verify logic. This journey is what led to static type-checking as a necessary outcome, not just an initial goal.

This was coupled with the core challenge: business logic is often about complex, nested, and ragged data (arrays, order items, etc.). If the DSL couldn't natively handle loops over this data, it was pointless. This required an IR expressive enough for optimizations like inlining and loop fusion, which are notoriously hard to reason about with vectorized data.

You can try a web-based demo here: https://kumi-play-web.fly.dev/

And the repo is here: https://github.com/amuta/kumi","url":"https://kumi-play-web.fly.dev/","domain":"kumi-play-web.fly.dev","comments":[],"comments_count":0}