finbarr1987

I'm on the team behind RunMat, we launched the first version of the runtime last August, and for 0.5 moved away from a direct AST-to-bytecode path toward:

source -> AST -> semantic HIR -> MIR -> MIR analysis -> VM layout + bytecode -> runtime/providers

The blog is mostly about the annoying parts of making that work: figuring out whether something is indexing, a function call, a constructor, an object access, etc., and making sure the interpreter, LSP, JIT, and GPU planner all agree.

Happy to answer questions! source -> AST -> semantic HIR -> MIR -> MIR analysis -> VM layout + bytecode -> runtime/providers

Happy to answer questions!

Fair question, and agreed we should make this clearer on the site.

We like Octave a lot, but the reason we started fresh is architectural: RunMat is a new runtime written in Rust with a design centered on aggressive fusion and CPU/GPU execution. That’s not a small feature you bolt onto an older interpreter; it changes the core execution model, dataflow, and how you represent/optimize array programs.

Could you add a JIT to Octave? Maybe in theory, but in practice you’d still be fighting the existing stack and end up with a very long, risky rewrite inside a mature codebase. Starting clean let us move fast (first release in August, Fusion landed last month, ~250 built-ins already) and build toward things that depend on the new engine.

This isn’t a knock on Octave, it’s just a different goal: Octave prioritizes broad compatibility and maturity; we’re prioritizing a modern, high-performance runtime for math workloads.

We don’t have a finalized business model yet, right now the focus is getting the open-source runtime solid, useful and very fast. If we add paid stuff later, it’ll be around optional services (not taking features away from the core runtime), and we’ll be clear about it up front.

Yeah, this is a pretty common pattern: use a domain-specific tool where it fits (Octave for the math), and a general language for the product glue (Python). Same idea as infra work — lots of teams would rather express intent in Terraform than build it in Rust, because a DSL can be a cleaner fit for the job.

That's precisely the point(s), the runtime's issues (closed source, cost, etc) are what is helping with the declining popularity of the language when really the language can be handy to people who work in math-heavy industries.

thankfully there are fast open source alternatives out there now, hint hint runmat ;)