What's happening to MATLAB?
Or, "The slow demise of the engineering toolbox everyone loved to hate at University."
Twenty years ago, if you were brave enough to launch a new hardware startup in the automotive or aerospace domain, your toolchain was pretty simple: MATLAB for your engineers to do basic trade-off analysis, and Simulink so they could model, simulate, and optimize how your vehicle would behave in the real world.
And while your CAD engineers and manufacturers started assembling a prototype, Simulink did something else pretty helpful: It automatically generated embedded C code that could run on your hardware control unit, and guarantee your product behaved exactly the way you designed it. This was a lot more efficient than translating MATLAB pseudocode to C by hand. Pretty soon you were doing flight tests with your prototype, iterating on the design completely within the MATLAB ecosystem, and shipping product.
More recently, this paradigm has changed quite a bit. Fewer and fewer recent grads and new startups are embracing the old toolchain. So what the heck happened? How did "MATLAB" become such a dirty word in startup engineering?
The port to Python
The most obvious trend from about 2005-2015 was the slow but steady migration of powerful, proprietary MATLAB functions into open-source, free Python equivalents: Numpy, SciPy, and Pandas to name a few. Somewhere around 2015, there was virtually no good reason to pay for MATLAB anymore, when you could do all that rigorous analysis in Python for free.
Then, the emerging fields of computer vision and machine learning really accelerated the switchover. Rather than porting from MATLAB, all the newest algorithms started emerging in Python from day one. Suddenly, it was MATLAB who was playing catch-up. And it takes at least a year for a trendy new algorithm to make it onto MathWork's radar as a potential revenue stream, plus 6-12 months to re-implement it in their proprietary language to ship with the next semi-annual release. So if you were a computer vision researcher trying to work in MATLAB, you were at least 18-24 months behind the curve... an eternity in cutting edge research.
Don't believe me? Go search for ML job descriptions containing "PyTorch" or "Tensorflow". And now compare that to the search results for "Machine Learning MATLAB". Virtually no one is building new ML or computer vision in MATLAB.
"Software is eating the world"
The second nail in the coffin is related to the expanded role and influence of software teams over product design. In our original story, the typical aerospace or automotive product of yesteryear was a closed system; rarely did it communicate with the internet, and 90% of its code was simply the control system to steer the vehicle.
Today, the situation has completely flipped: All new products are software-defined vehicles with significant fleet and/or internet connectivity, and significantly more involved software systems than ever before. Software leads, trying to wrangle a large and complex stack, will tolerate Simulink code if they must, but everyone absolutely despises it.
That's because Simulink generated code is an unreadable, unmaintainable mess that doesn't play well with anything outside the MATLAB world. The proprietary ecosystem generating it is a nightmare for revision control, collaboration, code comparisons, and integration with other tools (CI, requirements, etc). Not to mention it's hugely expensive.
But MathWorks is still "growing"!
Before going any further, let me preface this by saying what an absolute admirer I am personally of the MathWorks empire. They've been growing by ~20% year over year for decades, have built an incredibly powerful technical product that operates most aerospace and automotive systems you've ever encountered, plus hundreds in space and on Mars. And by all accounts, it seems like a really great place to work. This isn't a hater tirade, it's a sober market analysis from a long-time fan.
Mathwork's revenue does continue to grow, but in very large part because it completely captured big aerospace and automotive companies. About a hundred
major companies shell out $10-50M annually on MathWorks licenses, and since a good portion of those costs are directly passed along to the US government by aerospace contractors, "license creep" is real.
Part of the dangerous cliff ahead for these companies involves future engineers: For decades, MathWorks has given away MATLAB for free (or cheap) to universities, which absent compelling alternatives to teach engineers with, had led to legions of loyal(ish) new MATLAB engineers entering the work force every summer.
But ask anyone running an internship program at NASA, Lockheed Martin, or Tesla today, and they'll tell you the same thing: The new batch of students is Python proficient, and increasingly MATLAB clueless. Universities are making the switch.
This doesn't bode well for an expensive, proprietary tool chain, or for the enormous industries passing its license costs through to the government.
The writing on the wall
If you could step through a time portal to the year 1990, and walk into any major aerospace or automotive software integration lab to profess "In the future, no one will build new hardware products on top of FORTRAN", you would have undoubtedly been met with a cacophony of laughter, condescension, jeering, and/or tomatoes.
"FORTRAN has decades of proven track record, billions of miles driven and flown!" they'd confidently tell you. "We have millions of lines of FORTRAN code to maintain!" they'd insist. "FORTRAN is the only thing that gets certified!" they'd shout.
Yet here we are, a few decades later, with billions of lines of C code, and an order of magnitude more mileage under that newer, more powerful language's belt.
...And yet, we're once more gripped by the same graybeard insistence things will never change (again).
The entire Simulink empire was built on riding the industry transition from FORTRAN to C in the 80s and 90s. MathWorks still supports C code deployed to the field 25 years ago, nearly 50 versions old. And new Simulink C code deployed by Boeing today will be in service through 2060.
This is one big boat that will absolutely struggle to adjust course if the industry evolves away from C, purely from a legacy support perspective. This also creates enormous tension between sales and their ability to innovate with the future.
Aerospace software doesn't lead, it follows
We so often associate cutting edge aerospace and automotive achievements with the tip of the spear of engineering progress, that we forget sometimes the software running on these vehicles is painfully behind the times.
This is often a function of regulation, where certifying new computers and software in safety-critical fields takes years or decades. People at NASA will tell you they'd kill to have the compute of a modern, $50 Raspberry Pi on their cube sat. They just can't. They have a $20,000, radiation hardened, space-approved embedded board from 10 years ago, with 5% the computational resources.
The same is true with software. When these industries made the switch from FORTRAN to C in the late 80s/early 90s, they were already a decade behind Silicon Valley, which had largely adopted C and then C++. The truth is, consumer software is where new tools and languages are validated, and the automotive and aerospace sectors catch up about a decade after something new has taken off in Silicon Valley.
Today, that shift is the rapid deprecation of C and C++, for memory safe, high performing Rust. The Rust language has been consistently voted the most admired by developers for 8 years in a row – meanwhile, MATLAB has plummeted to the least desired language:
The Linux kernel itself is now being developed in Rust. Every major player, from Meta, to Google, to Amazon are porting their C and C++ code as fast as humanly possible to Rust.
Without going into it too much, the basic reason is because Rust is safe by default, where C and C++ are permissive by default.[1][2][3] That permissiveness was originally very appealing - it lets you do whatever you want with low-level memory access and hardware interactions. But "with great power comes great responsibility", and it turns out that letting engineers do whatever idiot thing they want with memory is a really, really bad idea at scale.
Rust can be seen as the natural evolution from the last 3 decades of C/C++ learnings. Developed at Mozilla, it is incredibly safe by design, nearly impossible to introduce race conditions, and fantastic for concurrency. Moreover, Rust achieves these benefits with minimal runtime overhead through zero-cost abstractions, which is critical for embedded systems. While modern C++ also aims for zero-cost abstractions, Rust's stricter compiler essentially guarantees it.
Most people serious about systems software see this turnover as inevitable and good. And it's going to have a profound effect on the software tooling ecosystem in these large automotive and aerospace industries, not to mention the robotics, biomedical, and industrial manufacturing sectors.
Where we go from here
Shameless plug time: We built Pictorus specifically to address this sea change in tooling. We're swapping out proprietary, desktop-centric MATLAB for browser-based, open source Python. We're swapping out C for Rust. And we're going to make the entire embedded development workflow more like something the software team would draw up - Github centric, collaborative, forkable, and human maintainable.
We know that, pretty soon here, MathWorks is going to start showing the signs of collapse, either due to flight from expensive MATLAB to free Python, the lack of new grads interested in the language, or a transition away from C to Rust that they are not well-positioned to weather let alone lead.
Most likely, a combination of all three at once.
When that happens, these large engineering teams will either have to completely burn it all down, hire thousands of new software engineers to build up their own internal tools (a very bad and expensive idea) before their existing engineers retire, or a new tooling ecosystem will need to emerge to help them through this transition and into a brighter future with better, modern languages. We're betting it's the latter.