Switching from MATLAB to Julia

The hard part of moving MATLAB code to Julia is proving the new result still means the same thing.

MATLAB vs Julia: key differences

Julia cannot run MATLAB code directly. It has its own grammar and semantics, and MATLAB compatibility is not a Julia language goal. Julia’s migration guide describes Julia as distinct from MATLAB and documents differences in assignment, array growth, returns, shapes, scoping, broadcasting, and concatenation.

Similar syntax, different semantics

Matrix indexing uses parentheses in MATLAB and brackets in Julia:

% MATLAB
y = A(i,j) + sin(x);

# Julia
y = A[i, j] + sin(x)

Array assignment behaves differently. MATLAB’s copy-on-write behavior lets A and B behave like separate arrays after one is modified:

A = [1 2 3];
B = A;
B(1) = 0;
% A is still [1 2 3]

In Julia, both names refer to the same mutable array unless the code copies it:

A = [1, 2, 3]
B = A
B[1] = 0
# A is now [0, 2, 3]

Broadcasting applies an operation across the elements of an array. MATLAB and Julia express it differently:

% MATLAB
y = sin(x) + x.^2;

# Julia
y = sin.(x) .+ x.^2

Julia’s dots are part of the language’s broadcasting system. A chain of dotted operations can be fused rather than materializing an array after every operation. Removing or adding a dot may change both meaning and performance.

Other differences affect common ports:

• Julia does not grow an array by assigning beyond its bounds; code uses push!, append!, or preallocation.
• rand(N) creates a one-dimensional vector rather than an N x 1 matrix.
• Multiple returns use tuples instead of MATLAB’s nargout control flow.
• Module and loop scoping differ between the languages.

Julia also loads functionality from packages explicitly. For example, MATLAB makes fft available directly:

% MATLAB
y = fft(x);

Julia loads the package that provides it:

# Julia
using FFTW
y = fft(x)

Julia projects use using or import to load packages from an active environment. MATLAB concentrates more functionality in the language and installed toolboxes; Julia makes package dependencies visible in the project. The difference affects setup and reproducibility as well as syntax.

A translator can replace punctuation and known function names. It cannot determine mutation semantics, select packages with matching numerical defaults, or redesign functions around Julia types and dispatch. Julia users discussing nontrivial MATLAB ports recommend translating tested pieces, checking correctness, then making the working code idiomatic.

Where Julia’s performance comes from

Julia specializes compiled methods for the concrete argument types passed to functions. When those types remain predictable, the compiler can generate efficient machine code for ordinary loops and custom numerical algorithms. Type instability and unexpected heap allocations can produce slower code, so Julia’s performance guide emphasizes functions, stable types, allocation control, and preallocation.

The first call to a method may include compilation, so one-off timings can measure startup work rather than steady-state execution. Julia developers commonly warm up a function and use BenchmarkTools with @btime to inspect repeated execution and allocations. Julia’s dot syntax can fuse broadcast expressions, while multiple dispatch lets packages provide specialized methods for numeric types, sparse matrices, GPU arrays, automatic-differentiation types, and domain-specific structures.

Julia’s founders were power MATLAB, Python, R, Lisp, and C users. They wanted mathematical notation, general-purpose programming, an open license, multiple dispatch, and compiled performance in one language. Their two-language argument starts with a model written in MATLAB, Python, or R whose hot path is later rewritten in C, C++, Fortran, CUDA, or another specialized implementation. Julia lets a team continue that optimization work in Julia.

MATLAB reaches performance from another direction. Its numerical built-ins and toolboxes package optimized implementations behind stable interfaces. That is effective when the workload fits those interfaces. Custom kernels, new numeric types, or algorithms that cross toolbox boundaries give Julia more room to expose and optimize the implementation.

RunMat has a third execution model. For supported MATLAB-syntax array operations, its fusion engine can combine elementwise work and reductions, select CPU or GPU execution, and keep reusable values on the device. Julia and RunMat can each win different workloads. Warmup, implementation quality, array scale, and hardware can change the result, so neither is universally faster.

Toolboxes, packages, and deployment

JuliaHub positions Julia as a compute layer for technical applications, including deployment, reproducibility, security, and scaling. Production migration therefore extends beyond syntax into interfaces and operations.

Python remains common in machine-learning products and the web or data systems around them. Performance work may cross several library and native-extension boundaries. Julia suits teams that want numerical exploration and custom high-performance implementation in the same language.

Use cases and engineering friction

MATLAB remains well suited to teams organized around Simulink, mature commercial toolboxes, official support, code generation, or previously reviewed results. MathWorks publishes courseware and teaching resources across engineering and science, so many graduates and colleagues already know the environment. Its notation also stays close to the matrices and equations engineers use in reviews, an advantage discussed in our defense of whiteboard-style MATLAB code.

Julia suits new scientific software where the implementation is part of the value: custom solvers, simulation engines, optimization systems, numerical libraries, and research code built around new types or algorithms.

When numerical work sits inside a larger ML, data, or web product, Python’s integration breadth often carries more weight than using one language for every performance layer.

A team developing a solver may need the same algorithm to work with sparse matrices, automatic-differentiation types, and GPU arrays; Julia’s type and dispatch model keeps that specialization in the same language. A controls group maintaining reviewed Simulink models may care more about stable toolbox behavior, code-generation settings, and accepted test fixtures.

Julia has its own engineering friction. Compilation latency, deployment, documentation, and package maturity vary by project. The community’s “1.5-language problem” discussion describes the cultural split that can remain after the technical language boundary shrinks: researchers write exploratory Julia while package engineers maintain types, tests, and releases.

Switching a MATLAB workflow to Julia

Once the language delta is understood, the more expensive question is whether the workflow should be rewritten.

Consider a vibration-analysis pipeline. It loads .mat fixtures and CSV measurements, detrends sensor channels, applies a window, computes an FFT and power spectral density, filters known bands, detects peaks, plots the result, and exports a report. The MATLAB version may have years of accepted outputs and review history.

A Julia rewrite has at least five validation surfaces:

1. Language semantics: indexing, mutation, shapes, array growth, broadcasting, scoping, and returns.
2. Package behavior: replacements for file I/O, filtering, spectral estimation, peak detection, plotting, and export.
3. Numerical equivalence: normalization, padding, default windows, filter edge behavior, tolerances, and random-number behavior.
4. Review outputs: plots, units, warnings, tables, report layouts, and known fixtures.
5. Runtime and deployment: local machines, CI, approved build environments, packaged applications, and GPU hardware.

The team also needs an adoption plan:

• Train contributors on Julia syntax, mutation, types, package environments, and benchmarking.
• Establish Project.toml and Manifest.toml ownership, CI tests, and reproducible build instructions.
• Decide how applications will be packaged, deployed, monitored, and supported.
• Run the MATLAB and Julia versions against the same accepted fixtures and tolerances.
• Assign long-term maintainers and cut over only after both numerical and operational validation pass.

The Julia version may be cleaner and faster. Reviewers still need an explanation when a peak moves, a PSD uses a different normalization, or a plot no longer matches the report used in the last design review.

Language differences describe the scope of a rewrite. A validation inventory shows whether that rewrite creates enough value to justify replacing a trusted engineering artifact.

Where RunMat fits

RunMat implements MATLAB-compatible semantics for supported MATLAB-syntax workflows. For teams taught to work in MATLAB or maintaining an existing .m codebase, it provides a way to evaluate that work before deciding which parts require a rewrite. The .m files, familiar outputs, and review trail may be the assets the team wants to retain; where compatibility allows, the team can change the runtime while preserving them.

The RunMat runtime is open source, runs locally, and supports CLI, browser, and desktop hosts. Its fusion engine and GPU paths accelerate supported operations.

Evaluation starts with the real project: run it, identify unsupported language and toolbox dependencies, and measure representative workloads. That evidence shows which pieces can remain in MATLAB-syntax code and which require rewriting. Simulink-heavy systems remain a separate workflow decision.