I feel I got a lot of inspiration from my time automating working with Excel as a Financial Analyst.

Demo to try it out: https://kumi-play-web.fly.dev/

GitHub: https://github.com/amuta/kumi

The linked demo covers finance scenarios, tax calculators, Conway's Game of Life (array ops), and a quick Monte Carlo walkthrough so you can see the zero-runtime codegen in practice. (The GOL rendering lives in the supporting React app; Kumi handles the grid math.)

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 and are mapped to another system by some function over its attributes.

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 is what 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/?example=monte-carlo-simulatio...

And the repo is here: https://github.com/amuta/kumi

Comments URL: https://news.ycombinator.com/item?id=45826745

Points: 4

# Comments: 0

  Location: Sao Paulo / Brazil
  Remote: Only
  Willing to relocate: No
  Technologies: Ruby / Rails / JS / Linux / DevOps / IAM
  Résumé/CV: https://drive.google.com/file/d/1eFJt5gpK7C-nNJWar75jmskSTIrh0rCv
  Email:andremuta+hn@gmail.com

Also here is my GitHub, you will see some recent contributions to CRuby itself and my OS library Kumi. https://github.com/amuta

If you are working on a challenging problem with a lot of unknowns or need a very skilled debug guy, I'd be very interested to hear about it. Please send me an email, and let's have a conversation.

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

Comments URL: https://news.ycombinator.com/item?id=45687576

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45620078

Points: 1

# Comments: 0

  Location: Sao Paulo / Brazil
  Remote: Only
  Willing to relocate: No
  Technologies: Ruby / Rails (PostgreSQL, Redis, Github...) Linux / DevOps / IAM
  Résumé/CV: https://drive.google.com/file/d/1eFJt5gpK7C-nNJWar75jmskSTIrh0rCv
  Email:andremuta+hn@gmail.com

One of these kind of problems is related to what I am currently building, vector (domain specific) language implemented in Ruby that lowers and then codegens to Ruby and JS: https://github.com/amuta/kumi

I am very confident on my skills as a developer but at the same time I find it to be inversely correlated with short performatic technical interviews. If you evaluate me with scoped work or a debugging session with real logs and tracing, we’ll both get a truer signal.

If you are working on a challenging problem with a lot of unknowns that requires deep technical understanding, I'd be very interested to hear about it. Please send me an email, and let's have a conversation.

https://github.com/amuta/kumi/tree/codegen-v5 (see ./golden for more context on the compilation/codegen. I barely knew what a compiler was before doing this so I might have just created some nonsense )

This is from a Ruby DSL I'm working on (Kumi). Probably the broadcasting semantics are very different from traditional rank operators in q/APL?

Edit: I realized that I missed the input structure:

  Region 0: Office 0 has 2 employees, Office 1 has 1 employee
  Region 1: Office 0 has 1 employee

  schema do
    input do
      array :regions do
        float :tax_rate
        array :offices do
          float :col_adjustment
          array :employees do
            float :salary
            float :rating
          end
        end
      end
    end

    trait :high_performer, input.regions.offices.employees.rating > 4.5
    
    value :bonus do
      on high_performer, input.regions.offices.employees.salary * 0.25
      base input.regions.offices.employees.salary * 0.10
    end
    
    value :final_pay,
      (input.regions.offices.employees.salary + bonus * input.regions.offices.col_adjustment) *
      (1 - input.regions.tax_rate)
  end

  result = schema.from(nested_data)[:final_pay]
  # => [[[91_000, 63_700], [58_500]], [[71_225]]]

Remote: Yes

Willing to relocate: Yes

Technologies: Ruby on Rails, Python, JavaScript/TypeScript, PostgreSQL, Redis, Sidekiq, Docker, Kubernetes, AWS, ECS

Résumé/CV: https://drive.google.com/file/d/1eFJt5gpK7C-nNJWar75jmskSTIr...

Email: andremuta+hnhire@gmail.com

---

Hi! I am André, a Senior Software Engineer with 8 years of experience. I've worked extensively on large, sometimes legacy, Rails monoliths, and have designed and built Rails applications at scale.

I offer expertise in: - Refactor legacy and greenfield Rails apps, increase test coverage

- Perform deep debugging to identify and resolve root causes

- Optimize performance with caching strategies, database tuning, and auto-scaling

- Implement authentication and identity and access management: OAuth2, OIDC, SAML, user provisioning, and audit logging

- Build CI/CD pipelines and container deployments using Docker and Kubernetes/ECS

- Integrate third-party APIs (CRMs, DocuSign, Active Directory, Google Cloud)

Hi! I am a Senior Software Engineer with 8 years of experience. I've worked extensively on large, sometimes legacy, Rails monoliths, and have designed and built Rails applications at scale.

I offer expertise in:

- Refactor legacy and greenfield Rails apps, increase test coverage

- Perform deep debugging to identify and resolve root causes

- Optimize performance with caching strategies, database tuning, and auto-scaling

- Implement authentication and identity and access management: OAuth2, OIDC, SAML, user provisioning, and audit logging

- Build CI/CD pipelines and container deployments using Docker and Kubernetes/ECS

- Integrate third-party APIs (CRMs, DocuSign, Active Directory, Google Cloud)

*Tech Stack* Ruby, Ruby on Rails, Python, JavaScript/TypeScript, PostgreSQL, Redis, Sidekiq, Docker, Kubernetes, AWS, ECS

CV: https://drive.google.com/file/d/1eFJt5gpK7C-nNJWar75jmskSTIr...

LinkedIn: https://linkedin.com/in/andremuta

Email: andremuta+hnhire@gmail.com