Debugging in MATLAB: A Barrier to Engineer Ambition

#MATLAB users debug their code by modifying it. When a simulation diverges, engineers add print statements to observe what the math is doing, read thousands of lines of raw output, and delete those statements once the code goes back into production. The tool forces you to modify the work to see the work. The typical fix is to rewrite everything in #Python. But that pulls hardware engineers away from their actual job. They end up managing package environments and writing boilerplate code instead of doing engineering. We are building #RunMat for a world where the math an engineer runs is limited by their ambition, not by their tooling. Modern debugging, #GPU acceleration, and a #runtime built for #engineers. The obstacles between the idea and the simulation are coming down. Read the full breakdown on what print-debugging actually costs.

  • diagram

Great point. The underlying issue is a JIT one: since R2015b MATLAB uses LXE on top of LLVM — the same backend clang uses for C++ — but it's a black box. It doesn't expose hooks to inspect state inside a vectorized expression, which is exactly why we end up dropping disp/fprintf calls like it's the 80s. A V8-inspired JIT (tiered compilation + deoptimization) changes the equation: set a breakpoint, the runtime locally deoptimizes, you inspect, execution resumes optimized. That's modern debugging. Combined with WGPU instead of CUDA, it also breaks the dependency on the Parallel Computing Toolbox. Over at Hekatan Structure we've been working on an adjacent problem: a MATLAB-style calc-editor embedded in the browser (TypeScript/Vite + Eigen/WASM solver) for structural engineering. Same conclusion you're landing on — the real bottleneck isn't raw speed, it's runtime observability. Are you planning to expose an introspection API so third parties can build debuggers on top of the runtime?

Like
Reply
See more comments

To view or add a comment, sign in

Explore content categories