Forem: lmilz

Dr. Strangelove or How I Learned to Stop Worrying and Love Testing

lmilz — Wed, 13 May 2026 19:51:24 +0000

When I was still programming at university, my “testing” looked roughly like this:

std::cout << "Value: " << value << std::endl;

along with some classic debugging: setting breakpoints, inspecting variables, stepping through the code. Looking back, this was clearly not an effective approach. I don’t even want to know how many bugs went unnoticed back then. Over several professional roles, I gradually improved my testing skills. In my first job, I initially continued exactly as I had done at university. Later, I had the chance to dive deeper into testing. At that time, my workflow looked like this: implement changes, document them, integrate, deploy, and only then start testing. This naturally led to discovering bugs late, being unable to fix them right away, and shipping bugfixes only with the next release.

This became increasingly frustrating for me. At the same time, I noticed that many developers “automate” their manual debugging process by reproducing the implementation inside their tests. This is a classic anti-pattern: you end up testing the implementation instead of the behavior. If you simply reproduce the production code in your tests, you're effectively writing the same code twice and that adds no value.

I started with small steps: whenever I worked on a new feature, I wrote tests immediately. In parallel, I began adding tests to our legacy codebase to gain experience building a meaningful and maintainable test suite.

Early on, I fell into the usual traps myself: I recreated the implementation in the test or wrote tests that were so granular that the suite became hard to maintain.

Along the way, I realized that testing is not just testing. In particular, we distinguish between:

Verification: Are we building the product right?
Validation: Are we building the right product?

Consider a simple example: a football field has exact specifications. If those are implemented correctly, verification is satisfied. But whether you can play well on that field is a matter of validation. A field can meet all technical requirements and still be unplayable if the ground is uneven or sloped.

Eventually, I had a kind of Eureka moment: proper testing is a learning process. In a way, it felt like my own little Dr. Strangelove moment. I stopped worrying about breaking things and started to love testing. Because once your tests define the expected behavior, fear turns into confidence.
Tests help me understand how the code is meant to behave and provide immediate feedback. The only problem was that my feedback always came too late. So I looked for ways to move it earlier in the process.

After many iterations, I finally found the answer to my problem: I must not test the implementation, I must test the behavior. The method that enforces exactly this is called Test-Driven Development (TDD).

TDD is often misunderstood. It’s not a testing technique but a design method. Tests are the tool we use to shape the design. TDD can be used for both verification and validation.

To demonstrate my approach, I’ll use the calculation of the inverse square root. This function is used to normalize vectors. From this, we can derive verifiable mathematical properties as well as validation tests based on intended behavior. These properties must hold regardless of the internal implementation of inverse_sqrt. Below is an example of the tests (with the input data inputs and vectors omitted for readability):

// ------------------------------------------------------------
// 1. Positivity Test
//    f(x) > 0 for all x > 0
// ------------------------------------------------------------
#[test]
fn always_positive() {
    for &x in &inputs {
        assert!(inverse_sqrt(x) > 0.0);
    }
}

// ------------------------------------------------------------
// 2. Monotonicity Test
//    f(x) decreases as x increases
// ------------------------------------------------------------
#[test]
fn monotony() {
    for i in 0..inputs.len() - 1 {
        assert!(inverse_sqrt(inputs[i]) > inverse_sqrt(inputs[i + 1]));
    }
}

// ------------------------------------------------------------
// 3. Product Rule Test
//    f(a·b) ≈ f(a)·f(b)
// ------------------------------------------------------------
#[test]
fn product_rule() {
    for i in 0..inputs.len() - 1 {
        let a = inputs[i];
        let b = inputs[i + 1];
        let x1 = inverse_sqrt(a * b);
        let x2 = inverse_sqrt(a) * inverse_sqrt(b);
        assert!((x1 - x2).abs() < 0.25);
    }
}

// ------------------------------------------------------------
// 4. Division Rule Test
//    f(a/b) ≈ f(a)/f(b)
// ------------------------------------------------------------
#[test]
fn division_rule() {
    for i in 0..inputs.len() - 1 {
        let a = inputs[i];
        let b = inputs[i + 1];
        let x1 = inverse_sqrt(a / b);
        let x2 = inverse_sqrt(a) / inverse_sqrt(b);
        assert!((x1 - x2).abs() < 2.5);
    }
}

// ------------------------------------------------------------
// 5. Validation: Normalization Length
//    A vector normalized with this function should have length ≈ 1
// ------------------------------------------------------------
#[test]
fn normalization_length_is_one() {
    for &(x, y, z) in &vectors {
        let n = normalize(x, y, z);
        let len = (n.0 * n.0 + n.1 * n.1 + n.2 * n.2).sqrt();
        assert!((len - 1.0).abs() < 1e-6);
    }
}

Now it gets practical: you write the implementation and the tests immediately verify whether it behaves as expected. This instant feedback is one of the greatest strengths of TDD. The test run produces results like these:

running 5 tests
test tests::monotony ... ok
test tests::division_rule ... ok
test tests::always_positive ... ok
test tests::normalization_length_is_one ... ok
test tests::product_rule ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

This illustrates the essence of TDD: define the behavior first, then write the implementation that fulfills it.

Another essential benefit: once tests clearly define the expected behavior, you can refactor the implementation without fear. The tests act as a safety net. They ensure that the visible behavior remains unchanged, even if the internals change dramatically.

To make this even more concrete, here’s a small example that shows the real power of testing for behavior: you can completely change the implementation, yet the tests and therefore the behavior remain unchanged.

Consider a simple function that filters out negative numbers. The tests describe what the function must do, not how it must do it:

#[test] 
fn filters_out_negative_numbers() {     
    let input = vec![3, -1, 0, -5, 9];     
    let result = filter_positive(&input);     
    assert_eq!(result, vec![3, 0, 9]); 
}  

#[test] 
fn keeps_order() {     
    let input = vec![5, 2, 8];     
    let result = filter_positive(&input);     
    assert_eq!(result, input); 
}

These tests specify two behaviors:

Negative numbers must be removed.
The order of the remaining elements must be preserved.

Now here is the first, simple implementation, fully correct but not particularly elegant:

fn filter_positive(values: &[i32]) -> Vec<i32> {     
    let mut result = Vec::new();     
    for v in values {         
        if *v >= 0 {             
            result.push(*v);         
        }     
    }     
    result 
}

Later, you might want to refactor it into a more idiomatic and functional style:

fn filter_positive(values: &[i32]) -> Vec<i32> {    
    values.iter().copied().filter(|v| *v >= 0).collect() 
}

The internal implementation is now completely different, yet the behavior remains exactly the same.

And that's the crucial point: the tests still pass without changing a single line of them. They don't care how the behavior is achieved. They only care that it is achieved. This is exactly the kind of freedom and safety TDD provides: the ability to evolve and improve internal code confidently, without risking regressions.

This is how software is created that not only works but also remains maintainable and evolvable over time, a core principle of good software design.

Looking back, I don’t write tests today because I’m “supposed to”. I write them because they make me faster, calmer, and better at my craft.

When 'Close to the Hardware' Isn't Close Enough

lmilz — Tue, 12 May 2026 07:04:58 +0000

I recently bought myself an STM32 Nucleo microcontroller board to play around with. What fascinated me was how much more flexible things are at this level, how much more you can do yourself. With an ESP32 that's not really the case, you're always tied to ESP-IDF or some other framework.

I started with a first simple example, the kind everyone knows and has done before: the famous Hello World. It's simple, and that's exactly why it's useful. You don't learn a language's syntax with it, it's too small for that. You learn how to actually use the language. What file format, how to compile, how to link, how to run the result.

That's why I always reach for Hello World first whenever I pick up a new language or a new environment. It forces me to run the whole build system once before I do anything else. Two things I learned this way that weren't obvious to me at the start. First: you can learn a surprising amount from a simple example if you take it seriously. Second: simple is almost never really simple. Most things that look easy are easy because someone else hid the complexity for you.

The embedded world has a Hello World too: the blinking LED. Most microcontroller boards have an onboard LED that you turn on and off at some frequency. Sounds trivial. And it is, if you use a Hardware Abstraction Layer (HAL) and some ready-made project template.

I've been working in automotive software for years, and before that on physics simulations at university. In my head I'd always been "close to the hardware", I write embedded software after all, not frontend. A while back I wrote about the roles of C, C++, and Rust in automotive and quietly took for granted that "embedded equals close to the hardware". At some point it hit me that this was a delusion. MCAL, AUTOSAR OS, RTE: there are more layers between me and the silicon than between a web app and the kernel. I wanted to actually get down to the bottom for once. No HAL, no framework, no vendor black box. Just the reference manual and the compiler.

A Blinky in Rust

In the Rust ecosystem the example quickly ends up looking like this:

#![no_std]
#![no_main]

use cortex_m_rt::entry;
use panic_halt as _;
use stm32f4xx_hal::{pac, prelude::*};

#[entry]
fn main() -> ! {
    let dp = pac::Peripherals::take().unwrap();
    let rcc = dp.RCC.constrain();
    let clocks = rcc.cfgr.sysclk(48.MHz()).freeze();

    let gpiob = dp.GPIOB.split();
    let mut led1 = gpiob.pb0.into_push_pull_output();
    let mut led2 = gpiob.pb7.into_push_pull_output();
    let mut delay = dp.TIM1.delay_ms(&clocks);

    loop {
        led1.toggle();
        delay.delay_ms(400u32);
        led2.toggle();
        delay.delay_ms(100u32);
    }
}

It's short, type-safe, and it works. The compiler keeps me from toggling an input pin. The clock config goes through a builder pattern. Pin types carry their configuration in the type system, so toggle() on an input pin is a compile error. The delay is timed off SYSCLK. And everything you don't see, the vector table, the reset handler, the copy loop for .data, the zeroing of .bss, all of that comes from the cortex-m-rt crate. The linker just gets a small memory.x that tells it where flash and RAM are.

That's exactly the problem I wanted to dig into. Not in the "the HAL is bad" sense (I actually came away appreciating it more), but: I wanted to see what the HAL does for me. So the same thing again, but in C, no HAL, no CMSIS, just register addresses straight out of the reference manual.

Hello World, embedded

The board I picked was the Nucleo-F446ZE, and I started reading the docs (Reference Manual RM0390, chapter 6 for RCC and chapter 8 for GPIO).

The blinky itself is quickly explained. Enable the GPIOB clock, configure PB0 as an output, in a loop toggle the output register. In C, with no abstraction, it looks like this. First the registers as macros, then main():

#include <stdbool.h>
#include <stdint.h>

#define RCC_BASE   0x40023800UL
#define GPIOB_BASE 0x40020400UL

#define RCC_AHB1ENR  (*(volatile uint32_t*)(RCC_BASE  + 0x30UL))
#define GPIOB_MODER  (*(volatile uint32_t*)(GPIOB_BASE + 0x00UL))
#define GPIOB_ODR    (*(volatile uint32_t*)(GPIOB_BASE + 0x14UL))

#define RCC_AHB1ENR_GPIOBEN (1UL << 1)
#define LED_PIN             0U

static void delay(volatile uint32_t n) {
    while (n--) {
        __asm__("nop");
    }
}

int main(void) {
    RCC_AHB1ENR |= RCC_AHB1ENR_GPIOBEN;

    GPIOB_MODER &= ~(3UL << (LED_PIN * 2));
    GPIOB_MODER |=  (1UL << (LED_PIN * 2));

    while (true) {
        GPIOB_ODR ^= (1UL << LED_PIN);
        delay(500000);
    }
}

Three things about this code need explaining.

First: *(volatile uint32_t*)(...). That's memory-mapped I/O in its purest form. The hardware exposes certain addresses that don't point to ordinary RAM cells, but to registers of the peripherals. Writing to RCC_AHB1ENR doesn't mean "write into a memory cell", it means "tell the RCC block which clocks to enable". The volatile cast isn't a style choice, it's mandatory. Without volatile, the compiler wouldn't care how often you write, it would optimize the accesses away as dead stores, and the blinky would silently do nothing. volatile is the contract with the compiler: "hands off, every access has a side effect you can't see."

Second: initializing GPIOB_MODER. I clear the two mode bits for PB0 first, then set them to 01 (General Purpose Output). Read-modify-write with &= and |=, so that other pins in the same register stay untouched. On Cortex-M, by the way, this is not atomic, that's three instructions (LDR, ORR/BIC, STR), and an ISR could fire in between. It works here because no interrupts are active during init. If you actually need atomicity, you use the bit-band region (where available, it's gone on the Cortex-M7) or LDREX/STREX. For pure set-or-clear on GPIO output pins there's also the BSRR register, which is specifically designed to let you set or reset individual bits atomically in one write, no read-modify-write required.

Third: delay(). The combination of volatile on the parameter and the explicit nop isn't decoration. Without volatile, and depending on the optimization level, the compiler may simply skip decrementing the counter, because nobody reads the value. Without the nop, it's free to collapse the loop body. Together they force the loop to actually run. The comment "500 ms at 16 MHz" is wishful thinking, since the real duration depends on the optimizer, flash wait states, and the pipeline. For a blinky that's fine, in production you'd use SysTick.

So much for the functionality. The really interesting question isn't what's in main(), it's: how does main() ever get called in the first place? On a PC the operating system does that. On a microcontroller there is no operating system, no loader, no process, nothing that reads in code, allocates memory, or prepares a runtime. Someone has to do all of this by hand. That's where it got interesting for me.

The hardware doesn't know about `main()`

When the ARM Cortex-M4 in the STM32 powers on, it does something very concrete. It reads 4 bytes from address 0x08000000 and loads them as the initial stack pointer. Then it reads the next 4 bytes from 0x08000004, interprets them as an address, and jumps there. That's not a software instruction, that's circuit logic, set in silicon. Everything that happens after that is software.

One detail that can cost you hours if you don't know it: bit 0 of the reset vector address has to be set. The Cortex-M4 only knows the Thumb instruction set, and the CPU uses bit 0 of the jump address as a mode bit. If it's zero, you get a HardFault right after reset. The linker usually takes care of this for you, but anyone who builds the vector table by hand and has to cast a function pointer symbol themselves will learn this one the hard way.

Which gives us a clear requirement: at address 0x08000000 exactly the right thing has to be sitting there. This structure is called the vector table, and it's really just an array of function pointers. First entry is the stack pointer (cast as a function pointer, the hardware doesn't care about the type, it just reads 4 bytes). Second entry is the address of the reset handler. After that come NMI, HardFault, and the other handlers. On an interrupt, the hardware looks into this table, reads the address, jumps there. It's a hardware jump table, not a software dispatch.

In code, heavily shortened, it looks like this. The full table also has MemManage, BusFault, UsageFault, SVCall, PendSV, SysTick, and then the roughly 80 STM32-specific IRQs:

__attribute__((section(".isr_vector")))
void (*const vector_table[])(void) = {
    (void (*)(void))(&_estack),
    Reset_Handler,
    Default_Handler, /* NMI */
    Default_Handler, /* HardFault */
};

The section(".isr_vector") attribute matters. It tells the compiler: this data belongs in a specially named section. Where that section ends up in memory, though, isn't decided here. That was the first moment I realized the compiler and the hardware don't talk to each other directly. Something's missing in between.

Since the Cortex-M4 is a licensed ARM core, none of this is STM-specific. It works the same way on boards from NXP, Microchip, or TI. Once you've understood it once, you can dive right in on a different board.

Sections floating in nothing

The STM32 has two memory regions. Flash, non-volatile, starting at 0x08000000. RAM, volatile, starting at 0x20000000. Both on the same 32-bit address bus. From the CPU's point of view both regions are equally addressable; which addresses point to flash and which to RAM is decided by how the chip is wired.

The C compiler knows none of this. It takes main.c, produces machine code, puts it into a section called .text. Constants go into .rodata, initialized variables into .data, uninitialized variables into .bss. These are all just names. The compiler has no idea that .text is supposed to end up in flash later and .bss in RAM. It doesn't even know that flash and RAM exist. The sections have no absolute addresses. They're just floating in nothing.

So someone has to decide which section ends up at which physical address. That's the job of the linker script.

The linker script is the floor plan

A linker script is a text file with a .ld extension. It describes two things: which memory regions exist, and which section goes where.

The line

ENTRY(Reset_Handler)

tells the linker where the entry point is.

The MEMORY block lists the physical regions. The numbers come straight from the chip's datasheet:

MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
    RAM   (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}

In the SECTIONS block every section gets assigned to a region. .isr_vector goes at the beginning of flash, because that's where the hardware reads its first 4 bytes. The KEEP(*(.isr_vector)) keeps the linker from throwing the vector table away, since nothing in the C code explicitly references the vector_table symbol.

.text and .rodata go into flash, because they're supposed to be non-volatile. .bss goes into RAM, because it gets filled with zeros at runtime.

My favorite part is .data. These are variables with an initial value: int baud_rate = 9600;. At runtime they need to live in RAM, otherwise they aren't writable. But the initial value has to be stored somewhere before the board ever gets power. So the initial value has to live in flash and get copied into RAM at startup.

The linker script solves this by giving .data two addresses. A virtual address (VMA) in RAM, that's the address the code expects the variable at. And a load address (LMA) in flash, that's where the initial values physically sit. Who actually does the copying, the linker script doesn't say. It only emits boundary markers as symbols: _sidata (start of the initial values in flash), _sdata and _edata (start and end in RAM), _sbss and _ebss for the .bss section.

These symbols aren't variables in the usual sense. They don't occupy any memory. They're just numbers that the linker stamps in at the end. In C you access them by declaring them extern and then taking their address:

extern uint32_t _sidata;
extern uint32_t _sdata;
extern uint32_t _edata;

That confused me for a minute, because they look like variables but aren't. You never read the value of _sdata, you always use &_sdata. The "variable" is its own address.

The startup code is a mini OS

The linker script sets the boundaries. Filling everything in is the job of the startup code. Traditionally a file called startup.s in assembly, nowadays often startup.c or inline in the same file. I kept mine inline in the blinky, for maximum transparency.

The startup code is the reset handler. It does three things. It copies .data from flash to RAM so that initialized variables have their initial values. It fills .bss with zeros so the C standard for uninitialized variables is upheld. Then it calls main(). With C++ there's a fourth step: calling global constructors, which runs through a section called __init_array. In an AUTOSAR project this exact work lives inside the supplier's startup code and runs before EcuM_Init ever sees a register.

In the blinky it looks like this:

void Reset_Handler(void) {
    uint32_t* src = &_sidata;
    uint32_t* dst = &_sdata;
    while (dst < &_edata) {
        *dst++ = *src++;
    }

    dst = &_sbss;
    while (dst < &_ebss) {
        *dst++ = 0;
    }

    main();

    while (true) { }
}

Two things stood out to me when I wrote this for the first time.

First: the startup code uses the linker symbols directly as loop bounds. That's the contract between the two files. The linker script promises that the symbols are there and point to the right addresses. The startup code just trusts it blindly. If you rename the symbols in the linker script, the startup code breaks silently. Nothing warns you. As an aside: the copy loop runs over uint32_t*, not uint8_t*. That's faster, one word per bus transaction instead of four bytes, and it works because the linker aligns the sections to 4 bytes. Unaligned 32-bit accesses can trigger a fault on Cortex-M depending on the configuration.

Second: the while (true) {} after main(). On a PC, main() returns to the operating system. Here there is no operating system. If main() accidentally returns, the processor has to go somewhere. The infinite loop is insurance against it running wild through memory.

The only reason the startup code can run at all, before the C environment is set up, is that it uses only stack-local variables. And the stack already works because the hardware loaded the stack pointer from the vector table at reset. The whole sequence is a domino chain. Each step has exactly the one precondition the previous step just created.

From `.c` to bytes in flash

What happens between source and a blinking LED is also not one step, but several. The preprocessor resolves includes and macros. The compiler translates each .c file individually into assembly, architecture-specific via -mcpu=cortex-m4 -mthumb. The assembler produces object files in ELF format, with relative addresses and unresolved symbols. The linker collects all sections of the same name from all object files, assigns them absolute addresses via the linker script, and resolves the symbols. What used to say "jump to delay" now carries the concrete flash address of delay.

The final product is an ELF file. It contains the machine code, but also program headers (which bytes go where in memory), the symbol table (function and variable names with their addresses, for the debugger), and optionally debug information (the mapping of machine code to source lines). A .bin file, which you produce via objcopy -O binary, is just the raw bytes without any metadata.

To flash it, you use a tool like probe-rs or OpenOCD. The tool talks over a debug adapter (ST-Link, J-Link, or CMSIS-DAP) to the Cortex-M4's SWD port (Serial Wire Debug). The debug port has direct access to the entire address space of the chip, regardless of whether the CPU is running. The tool reads the ELF file, extracts the program headers, writes the bytes into flash, and triggers a reset. After which the whole cycle starts over. Hardware reads the vector table, jumps to the reset handler, startup initializes, main() runs, LED blinks.

I want to stress again that this is a little learning project of mine, not production code. In production you'd put an abstraction on top, either a vendor HAL (for example ST's) or the Cortex Microcontroller Software Interface Standard (CMSIS), which is vendor-agnostic.

What I took away

Two things stuck with me.

The first: a Hello World is very much not a waste of time if you take it seriously. I could have written the blinky with a HAL in five lines, done. Instead I wrote the vector table myself, the reset handler, read the linker script, understood the boundary markers. And I learned more about the system than I would have in weeks of framework tutorials.

The second: simple is almost never actually simple. The blinky with a HAL isn't any easier than the blinky with registers, it's just further away from what's actually happening. Between make flash and a blinking LED sit the linker script, the startup code, the ELF, the flashing, the hardware reset. All of this is there, even when you don't see it.

For those of us in automotive this is particularly interesting. In a classical AUTOSAR project we never see the vector table, never see the reset handler, never see the linker script. The MCAL, the supplier's startup code, the OS init, BswM scheduling: all of that arrives as a black box, and we write runnables that get called from the RTE. Between power-on and Rte_MainFunction_* there's the exact same chain as here. Hardware reads 4 bytes, jumps to the reset handler, someone initializes .data and .bss, someone calls the OS init, someone starts the tasks. It's just that each of those steps is buried inside an AUTOSAR configuration we normally don't open. Once you've built this foundation yourself, you read an MCAL doc differently. It also sharpens the language question. In the earlier post I argued that C, C++, and Rust each have their layer, but the layer we usually work on in AUTOSAR is several steps above the one where that choice really matters. The reset handler, the .data copy, the linker script, those are all C, regardless of what we write on top. The supplier picks the language down there, we don't.

Not seeing it is comfortable as long as everything works. The moment it doesn't, you have to go a level deeper. And then it's good to have been there before.

From C to Rust - Evolving Programming Languages in Automotive Development

lmilz — Sun, 10 May 2026 19:50:55 +0000

Introduction

In recent years, the automotive software landscape has changed dramatically. What used to be small, specialized electronic control units (ECUs) with narrowly defined functions has evolved into highly networked systems with powerful System-on-Chips (SoCs) and a growing fusion between traditional embedded and high-performance software development.

This evolution brings new challenges, especially when it comes to choosing the right programming language. The language doesn’t just impact performance and resource usage; it also defines maintainability, safety, and ultimately the certifiability of the software.

The Automotive Software Landscape

Low-level microcontrollers still handle classic tasks such as engine control, sensor interfaces, or basic actuators. At the same time, high-performance SoCs power increasingly complex domains like driver assistance, infotainment, and connectivity.

Each layer has its own constraints and challenges. Many ECUs must meet real-time requirements while operating under tight memory and processing limits. Some controllers still run with only a few kilobytes of RAM or Flash, demanding highly efficient and deterministic code. Meanwhile, system complexity continues to grow, with vehicle platforms ranging from dozens of distributed ECUs to centralized zone architectures, each with unique communication and software requirements.

In such environments, many language features are off-limits: dynamic heap allocation, uncontrolled pointers, and large standard libraries are often forbidden. That leaves us with three real contenders for automotive software development: C, C++, and Rust.

C - The Embedded Classic

If you work in automotive software, C is unavoidable. Since the early days of electronic control units, it has been the de facto standard and for good reason.

C was designed for system programming, and that’s exactly why it fits so well in the automotive domain: it offers direct hardware access, minimal abstraction, and precise control over timing and resources. When you need to process a signal within microseconds or trigger an actuator at exactly the right time, C is unbeatable.

Why C still rules:

Full hardware control: Direct access to registers, memory, and interrupts, essential for real-time control.
Minimal overhead: No hidden runtime mechanisms, no unnecessary memory use.
Excellent toolchain support: C is universally supported across microcontroller families, including certified compilers, debuggers, and analysis tools.

The downsides:
C lacks type safety and relies entirely on the developer to manage memory and concurrency correctly. Pointer errors or race conditions can lead to unpredictable behavior. Large C codebases, often grown over decades, are notoriously hard to maintain.

Still, C remains the bedrock of embedded software: predictable, efficient, and deeply integrated into automotive safety and toolchain ecosystems.
Modern languages build on its shoulders, but they don’t replace its role in low-level, deterministic control.

C++ - Structured Power for Complex Systems

As ECUs grow more powerful and interconnected, C++ has gained significant traction in the automotive world. It brings structure, modularity, and abstraction, qualities that are becoming essential in modern vehicle software.

Why C++ matters:

Object-oriented design: Enables clear separation of concerns and better code organization in large projects.
Templates and generic programming: Combine type safety and code reuse without runtime cost.
RAII and stronger type checking: Improve memory safety and resource management.
Modern language features: constexpr, auto, and std::array improve readability and reliability at zero runtime cost.

In practice, this means we can design flexible, modular interfaces for instance, a unified abstraction layer for radar, camera, and lidar sensors to enable sensor fusion. In C, that would require far more boilerplate and unsafe pointer tricks.

However, embedded C++ comes with caveats. Many automotive compilers only support subsets of the language, and standard libraries (<iostream>, <string>, <vector>) are often restricted due to dynamic memory usage or exceptions. Templates and inlining can easily bloat the binary size, and long compile times are common.

In short: C++ has become the bridge between low-level efficiency and modern software design. When used with discipline and clear safety guidelines like MISRA, it enables robust and maintainable systems without sacrificing performance.

Rust – The Rising Challenger

When talking about the future of automotive software, one language always comes up: Rust.

Rust brings something that C and C++ have struggled to achieve memory and thread safety at compile time, without sacrificing performance.
In a safety-critical industry, that’s a big deal.

What makes Rust so exciting:

Compile-time memory safety: No null pointers, no use-after-free, no buffer-overflows.
Ownership and borrowing: Clear rules for who owns memory and how it can be accessed.
Zero-cost abstractions: High-level expressiveness without garbage collection or runtime overhead.
Safe concurrency: The type system prevents data races by design.
Growing embedded ecosystem: Frameworks like embedded-hal and no_std make Rust viable on microcontrollers.

Of course, Rust isn’t production-ready everywhere yet. Certified toolchains and ISO 26262 support are still emerging, and the learning curve can be steep. But after that initial hurdle, developers gain an unprecedented level of reliability and maintainability.

To me, Rust feels like the natural evolution of C and C++: the same low-level control and efficiency, but with built-in safety guarantees. Especially in application layers or safety-critical software, Rust has the potential to fundamentally reshape how we build automotive systems.

Outlook: Balancing the Proven and the New

C, C++, and Rust are not competitors, they complement each other.

C remains indispensable for hardware-near programming, where every cycle and byte matters.
C++ provides structure and abstraction for complex, modular systems and middleware.
Rust introduces memory safety, concurrency safety, and modern reliability to the mix.

The future of automotive software will be hybrid. C will stay the foundation for low-level, deterministic code; C++ will handle structured, object-oriented logic; and Rust will take over where safety, reliability, and modern software practices meet.

Over the next few years, we’ll see how quickly Rust gains traction in production automotive environments. But one thing is certain: the future won’t belong to a single language, it will belong to those who choose the right tool for the right layer. Combining efficiency, maintainability, and safety is what will define the next generation of automotive software.