The Cycle Gap

 

 

 

The figure above shows the progress of the speed of computer processors and human brains during the last 40 years. It is reasonable to say that computers have become 10,000 times faster during this period. And human brains have remained the same.

 

We can say that a processor cycle is 10,000 times cheaper then in 1980 while a "brain cycle" costs the same. Because of this, most software code today is not optimized to save processor cycles, but rather to save brain cycles of the developers. The development cost of software is typically much higher than the cost of running the software (energy, hardware). So, in general, we do not optimize code for computers anymore, but for the human authors of it.

With the increasing cycle gap, programming languages have evolved to save brain-cycles, at the expense of computer cycles. However, when it comes to embedded programming for resource-constrained devices, the C language is still the king of the hill. It was developed in the 1970s! Very successful, but hardly the most productive language to program in. Perhaps now it is finally time for a change. I have been reading up on Rust and how it works. It certainly sounds good. It is popular. And I really like the memory model.

Will it have a chance to compete with C for embedded? Well, well. Rust is in many ways technically superior. However, C has such robust support, so many compatible tools and a vast amount of available code that can be reused. C is clearly defined (has a spec) and has multiple implementations and is very stable. A clear advantage of C is that APIs and example code for embedded processors are typically written in C, not Rust or anything else.

If vendors of embedded processors would ship with example code and APIs in Rust, instead of C, then Rust would win! However, as the situation is now, I don't dare to predict the future. Being technically superior is not enough. However, I would love to see a more modern language that will really compete with C. Also in the embedded world.