Why we built RevelCode: a new programming language for the physical world

By Scott Morton, Founder + CEO of Revel

Introduction

When I was a mechanical engineering undergraduate working in a robotics lab, software was my biggest bottleneck. I could design the robot. I could machine the parts. I could build it. But I couldn’t write the code to make it work.

That frustration led me to get a master’s in computer science. Soon, bringing a system to life through code became one of my favorite parts of the building process. But I shouldn’t have needed a second degree to take a robot from concept to functional prototype.

This problem only gets more severe as the stakes rise. Software that controls physical systems doesn’t just process data. It opens valves, fires igniters, and moves control rods. And when it fails, the consequences show up in the physical world. Yet most hardware teams still program these systems with tools that are decades old, or with in-house software efforts built on general-purpose languages that were never designed for the job.

Learnings from SpaceX

When I joined SpaceX, I witnessed the same problem from the robotics lab, now with a rocket on the line. The engineers who knew the system best relied on software teams to write their control logic, or were reliant on commercial test and control platforms on the market that hadn’t fundamentally changed since the 1980s and 90s.

SpaceX’s answer was to build its own. When the opportunity emerged to rethink control software internally, I jumped at the chance to join the effort. Working alongside that team taught me a tremendous amount about what control software should feel like to the engineers using it, and what it takes to trust it on hardware where failure isn’t an option.

But there was a limit to how far we could take it. At SpaceX, our primary focus was on making rockets fly, not building the best possible control software infrastructure. That was the right call for SpaceX, but it meant there were improvements we envisioned and ideas we wanted to pursue that we couldn’t justify allocating resources to. The end goal for our tools was to further SpaceX’s business outcomes. Making those tools the best that they could be was an entirely different mission, one I took on when I started Revel.

Why we started with a language

Every control system has a language at its core, whether it’s ladder logic on a PLC, a graphical programming environment, or a framework a team has built in-house on top of C++. It’s how engineers tell the hardware what to do, and it shapes everything built around it: how control logic gets written, tested, reviewed, and ultimately run by operators.

But a language does more than express an engineer’s thinking. A well-designed language can fundamentally shape how engineers think about the systems they build. We wanted to embed as many hard-earned lessons as possible into RevelCode, making good engineering practices the natural way to write control logic. In doing so, we could pass those lessons on to the next generation of engineers, helping them build better, safer, and more reliable systems from the start.

That’s why, when we set out to build Revel’s platform, the language was where we started.

We weren’t the first to recognize how much control software matters. Some of the most ambitious hardware teams have invested heavily in building their own, usually as frameworks and tooling layered on top of general-purpose languages. The best of those efforts showed how much better things could be. But the fact that so many teams felt compelled to build their own solutions pointed to a larger problem: there was no commercially available platform compelling enough to make building internally clearly unnecessary.

Consider CAD software. Virtually no engineering company today would consider building its own CAD system. The commercial tools are so sophisticated, mature, and capable that replicating them internally would be an enormous distraction from the company's actual mission. We believed control software should be the same. Engineers should have access to tools so far beyond what they could reasonably build themselves that developing an internal platform simply doesn't make sense.

But achieving that required going deeper than the existing approaches. Building on a general-purpose language means inheriting its tradeoffs. We wanted to design the language itself as a product any hardware team could use, and as the foundation everything else in the Revel platform builds on.

That language had to work for the mechanical engineer who understands the machine, the software engineer building sophisticated algorithms, and the team that reviews and operates the system. And it couldn’t just be easy to get started with; it also had to remain useful as the system became more complex.

What Python got right, and where it falls short

Python is one of the most successful programming languages in history. In my view, accessibility is at the heart of that success. Its readable syntax and approachable development experience make it useful to people whose primary expertise isn't software engineering. That’s an enormous strength, and a lesson we carried into RevelCode.

But Python has serious drawbacks and limitations when used to control physical systems. Its interpreted execution model is substantially slower than compiled languages like C++ and Rust. It’s dynamically typed, so many programming errors aren't discovered until execution. And controlling hardware requires code that executes deterministically, without the possibility of runtime exceptions, which Python's garbage collection and scheduling model make difficult without additional infrastructure.

Foundational to RevelCode’s development was taking what made Python so successful and eliminating the tradeoffs that engineers face when using it. What if we could build a language with Python's accessibility, the performance of C++ or Rust, and runtime safety guarantees built in, all at once?

Three requirements: performance, accessibility, and safety

+ PERFORMANCE

RevelCode had to be in the same class as C++ and Rust to have millisecond-level determinism across hundreds of thousands of hardware inputs and outputs. So we built it as a compiled, strongly-typed language on LLVM, the compiler infrastructure behind Rust, Swift, and Clang. (LLVM’s creator, Chris Lattner, is an advisor to Revel!) That foundation lets RevelCode run control cycles in the kilohertz range without needing specialized hardware.

+ Accessibility

RevelCode is simple enough for hardware engineers to write control logic themselves, yet powerful enough for software engineers to express sophisticated algorithms without compromise.

It is also organized around concepts that reflect how hardware engineers naturally think about physical systems: cycle loops, sequences, and state machines. Cycle loops are inspired by the scan cycle found in traditional PLC programming, where control logic executes at a defined frequency. Sequences are rooted in procedural programming, much like writing a Python script. Engineers can directly describe a series of actions, conditions, and delays in the order they should occur. State machines come from automata theory and allow engineers to define states such as Idle, Starting, Running, and Faulted, along with conditions that trigger transitions.

These concepts, while easily understood by hardware engineers, are real programming constructs that support the sophisticated algorithms and abstractions needed as a system grows. With RevelCode, hardware and software engineers work in the same code, rather than one team handing control logic off to another.

+ SAFETY

RevelCode is designed to be runtime safe. Put simply, if it compiles, it cannot crash.

In general-purpose languages, programmers are responsible for anticipating and handling a wide range of potential runtime failures. We didn’t want a program to fail halfway through an operation because of a software mistake that could’ve been ruled out before execution. So we chose to deliberately constrain what the language permitted and require a compilation step.

Runtime safety doesn’t mean that every program that compiles is safe for hardware. The intended behavior still needs to be reviewed and validated. But whether the engineer has described the correct behavior and whether the program can execute without crashing are different problems. RevelCode takes responsibility for the second so engineers can focus on the first.

What RevelCode makes possible (and how it is used with AI)

From enabling Aalo Atomics to write the program for their Sodium Test Loop in days, to giving Astro Mechanica’s test operators ownership over their own automation, to helping Impulse Space’s Mojave engine test team test 5x more frequently, we’re excited to see RevelCode do exactly what we designed it to.

And we’ve seen some exciting possibilities when RevelCode is used in tandem with AI. RevelCode's constrained syntax and well-defined execution model make it particularly compatible with the process of AI-assisted software development. An engineer can simply describe how a system should behave and have an LLM produce RevelCode. This isn’t “vibe coding” in the traditional sense: rather than generating thousands of lines of general-purpose code with subtle concurrency and runtime risks, the model generates a small program built from primitives specifically designed for controlling hardware. Then, it’s easy to use Revel’s compiler and simulation tools to validate the result.

This workflow is already helping engineers dramatically narrow the gap between knowing how physical equipment should operate and producing working, verifiable code to run it. We think that's incredibly powerful. (You can read Hunter Smith’s blog post on how he uses AI to build faster with Revel here.)

Software for the next generation of industry

The next generation of physical systems deserves an entirely new approach to programming them. Today, RevelCode is used across testing, manufacturing, and operational systems; but our ambitions extend much further. We see it eventually running inside production products and embedded systems, controlling machines wherever they're deployed, not just in stationary industrial facilities.

By combining accessibility with high performance, RevelCode dramatically broadens the range of systems a single platform can support, from simple benchtop test setups to large-scale operational facilities. We've seen companies consolidate more than five different software solutions onto Revel, allowing engineers to move between systems without having to learn an entirely new stack. The benefits of this standardization extend beyond software consolidation: teams can share expertise, reuse control logic, and collaborate across systems that previously required entirely different skill sets.

Perhaps most importantly, RevelCode is a major part of what enables teams to move so much faster. Learning a new programming language might initially sound like a significant undertaking, but across several dozen companies, we've seen engineers become productive remarkably quickly, sometimes in under an hour. The investment in learning the language is small relative to the productivity gains it enables, and those gains compound as more engineers and systems adopt it.

We believe that every hardware engineer and operator can be self-sufficient without compromising on performance or safety. No one should need a second degree to bring their machine to life. RevelCode, a programming language designed specifically for the physical world, is fundamental to realizing that vision.