Why MATLAB Isn't Disappearing Anytime Soon

MATLAB persists because .m files became the working format for a lot of engineering math, and for decades the practical answer was simple: if the work was written in MATLAB, you ran it in MATLAB.

Many of those files are working artifacts: control models, signal-processing scripts, calibration plots, regression tests, or reports whose numbers already passed review. For many teams, MATLAB is where an equation first becomes a plot or a number someone can argue about.

The recurring forum question, "does anyone still use MATLAB?", usually gets answered with work examples rather than language advocacy: flight simulation, RF models, signal-processing scripts, controls projects, internal toolboxes, and old files that still produce the expected curve.

When we chat with users, we hear the same split. There are MATLAB diehards, teams with Python-heavy coworkers who want a shared language, and Julia-curious engineers who want mathematical notation without giving up performance. Most still need the old .m workflow to keep running while the rest of the stack changes around it.

In calls, the pressure comes from several places: validation, collaboration, publishing, deployment, and old-workflow continuity. MATLAB code usually sits next to work people already depend on.

MATLAB stuck because the workflow fit the math

MATLAB has had something close to a monopoly in many labs, departments, and engineering teams. In universities, it is still a de facto lingua franca for numerical coursework in engineering, controls, signals, optimization, and applied math. Student and campus licenses make the proprietary runtime feel normal early. For many engineers, MATLAB is one of the first languages they use for serious technical work, so later company code feels familiar instead of strange.

MATLAB also earns its place in work that is already shaped like arrays, transforms, state-space models, transfer functions, and plots. Engineers point to that fit in discussions about MATLAB's role in industry and controls/system simulation. A controls engineer tuning a model looks at poles, step response, overshoot, and a plot that either matches physical intuition or does not. A signal-processing engineer may load a waveform, filter it, inspect the spectrum, change a cutoff, and plot again.

For a least-squares estimate, the correspondence can be almost literal:

beta = X \ y;
resid = y - X * beta;
plot(resid)

The model matrix, estimate, residuals, and diagnostic plot stay close together. The person checking the model can stay inside the mathematical shape of the problem.

MATLAB's environment reinforces that loop. Arrays are the first-class object, plots are nearby, the workspace is visible, and the numerical routines live in the same environment as the script. Toolboxes package serious engineering workflows. Simulink anchors model-based design in controls, dynamics, automotive, aerospace, and adjacent fields. A company can call MathWorks when a supported workflow breaks.

For teams, the lock-in and the utility arrive together.

Paid runtimes make useful code harder to share

Python and Julia changed what technical users expect from code: open tooling, easier sharing, and fewer assumptions about who has a paid license. Python has obvious pull when work touches data infrastructure, ML libraries, web services, or general automation. It is also easier to publish something in Python and assume a reader can run it without buying anything.

Publishing changes the constraint. A researcher can publish a repo without assuming every reader has a MATLAB license. A professor can write a book or course and know the examples have a free execution path. A package maintainer can avoid locking every downstream user into a paid runtime forever. A mixed MATLAB/Python team can share more of the same codebase.

Plenty of people raising this point still like MATLAB. They think MATLAB syntax is the right way to express the work. They just do not want the ability to run that work tied forever to a paid MATLAB installation.

In practice, this is the runtime side of MATLAB's monopoly. If the code is MATLAB code, the default assumption has been that MATLAB is where it runs. Open alternatives exist, and Python, Julia, and Octave are reasonable answers in many cases. But for a lot of organizations, MATLAB remains the authoritative runtime for MATLAB work.

Rewrites have to reproduce trusted behavior

An existing MATLAB estate includes more than source files. It may include internal helper libraries, saved plots, lab procedures, test fixtures, toolbox behavior, file paths, workspace state, and undocumented expectations about numerical output.

Migration turns into a behavior comparison. The new version has to match tolerances, edge cases, reference outputs, reports, and plots that downstream teams already use. A rewrite can look straightforward in a language debate and expensive in an engineering review.

Scientific computing also has a handoff problem. Teams often prototype an algorithm in MATLAB or Python, then move performance-sensitive or deployment-sensitive pieces into C, C++, or Rust. Julia was created partly as an answer to that pressure: mathematical notation, interactive work, and high performance in one open language.

Julia may remove the handoff for some new projects. Existing MATLAB estates face a second question: what happens to the scripts, tests, plots, and review habits that already define correct behavior? The original MATLAB script often becomes the reference implementation. The team may agree that the final system belongs somewhere else, while the script still says what the math is supposed to do.

One quant team we spoke with had the concrete version of this problem. Their systematic trading stack had been built around MATLAB for years, with a large internal cluster, Slurm scheduling, regression tests for upgrades, and more than a million lines of production MATLAB code. They wanted a runtime path that could keep the code on their infrastructure, remove license-server friction, and let their existing tests tell them what changed.

Their tests, scheduling setup, and reference outputs were part of what made the code usable.

Scratchpad analysis can become a workflow

A lot of engineering computation never becomes a software project. It lives in spreadsheets, one-off scripts, copied folders, CSV joins, shared plots, and reports that get emailed around.

A manufacturing or quality team may need to join serial numbers across files, check reliability conditions, and produce a result someone else can review. A researcher may need a model to run again when a plot looks wrong. A course or book may need readers to run examples without assuming the same campus license.

MATLAB's calculator feel becomes infrastructure when that local reasoning turns into a script, the script feeds a review, and the reviewed output becomes part of the workflow. By the time someone asks whether the code should be rewritten, the output may already be trusted.

RunMat gives MATLAB-syntax code another place to run

RunMat is an open-source, GPU-accelerated runtime for MATLAB-syntax code. Engineers can test existing .m files without a license server and learn what works before committing to a rewrite.

RunMat has a narrower job than the MATLAB environment around it. It does not replace Simulink, MathWorks support, or production C++ and Rust systems. It gives MATLAB-syntax numerical workflows another runtime path when the code is useful and the infrastructure around it is getting in the way.

RunMat is aimed at a smaller job: give MATLAB-syntax code more than one runtime path. Existing numerical scripts need somewhere else to execute, and real code should expose the gaps.

For teams with MATLAB-syntax scripts, the first useful move is often practical: keep the math readable, remove one license-server dependency, and learn which parts can run today before deciding what deserves a deeper rewrite. Real projects will still expose gaps, including unsupported built-ins, toolbox assumptions, and MATLAB behaviors that users expect without thinking about them.

Open the browser sandbox and test a .m file. No install required.