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!

Pictorus is a simulink alternative https://www.pictor.us/simulink-alternative

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 ;)

Thanks for digging in ;) We just released RunMat in August as an open-source, fast MATLAB runtime. The goal is to make it the fastest way to run math, period.

Coming from Octave, you'll notice significant speedup advantages, you can see some of our benchmarks with it here https://runmat.org/blog/introducing-runmat

Last month, we put out 250+ built-in functions and Accelerate, which fuses operations and routes between CPU/GPU without any extra code/memory management, i.e. no GPUarray.

We're still flushing out the plotting function, but we'll have updates to share around that and a browser version very soon.