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.
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.
Why do you focus exclusively on matlab as your competitor posterchild?
I feel like you should be saying Matlab / Octave wherever possible; especially since your target audience is far more likely to be the one that wants a "faster Octave" rather than a "cheaper Matlab".
PS: Don't trust github language stats; half of that code is octave specific, but still gets labelled as Matlab.
