The debate about removing the C language has been going on for years now, but replacing C is unrealistic because it is often the only alternative to any other programming language.

Recently, an article titled “Is it Time to Retire C?” was posted here. The article is well versed and its premise is well argued, but I believe the conclusions are misleading. The debate about withdrawing from the C language has been going on for years now. Engineering managers claim that using the C language is too demanding and makes any software project a complex and error-prone process, while software sales managers complain that it takes years to create a software. product for sale. Opponents often argue that it depends on the job at hand – the ubiquitous “find the best tool for the job” stance and legacy support systems (of which there are many) are nearly impossible to maintain without C. My view is slightly different . angle though: is it possible in today’s software industry to retire C? Also, my point of view is largely the design and development of embedded systems.

Half a century has passed since the introduction of C. Before C, the art of programming was indeed “art”. Since the introduction of C, art has quickly become a real profession. Complex projects have been planned and implemented to improve all aspects of life: software now controls everything from a simple electrical outlet to complex spacecraft systems to social networking systems. There’s no doubt that all of these life-changing advancements wouldn’t be possible without a simple tool like C.

There are many alternatives that are successfully and rightly used to support software ecosystems. So how important is C in a modern software development toolset? Perhaps it could be replaced by modern alternatives? Consider these alternatives.

Alternatives to C

Alternatives can be “safe” languages ​​such as Java, C#, and Go. One of the main problems with these languages ​​is that, by design, they suck up system resources like a vacuum cleaner. Security is achieved primarily by using a garbage collection (GC) process that safely manages memory allocations so that allocated objects never use the contents of other objects. In the beginning, GCs had to walk through all object references to make sure the object in question is out of scope. This would “overheat” the memory bus, especially if the number of objects allocated by the application is large. Over the years there have been many improvements to garbage collectors – GC in the background, garbage collectors through multiple parallel threads, generational collectors, etc., etc. As a result, modern garbage collectors in languages ​​like Java aren’t hugely expensive from a performance perspective. Yet in embedded systems, where memory is scarce, garbage collectors must perform the cleanup frequently, and often any attendant overhead is unacceptable.

Another “safe” alternative is Rust. No doubt about it, Rust’s idea is just wonderful: “compiled means runtime”. Yet, in practice, using Rust is so complicated that it too often feels like “programming for the sake of programming.” Development in Rust is turned into a fight with language instead of solving the pressing problems at hand.

Consider for example Rust’s approach to working with pointers, a normal C programming practice. It’s so complicated it’s almost useless. Listing 1 illustrates a simple function that inserts a node into an AVL tree. Compare it to a C implementation in Listing 2. The Rust code looks like gibberish.

use std::mem::{replace, swap};
impl<'a, T: 'a + Ord> AvlNode<T> {
    fn rotate_right(&mut self) -> bool {
        if self.left.is_none() {
            return false;
        }

        // 1. Take nodes A and C
        let left_node = self.left.as_mut().unwrap();
        let left_right_tree = left_node.right.take();
        let left_left_tree = left_node.left.take();

        // 2. Link A node to left node
        let mut new_right_tree = replace(&mut self.left, left_left_tree);
        // 3. Swap B and D node value to avoid moving the root
        swap(&mut self.value, &mut new_right_tree.as_mut().unwrap().value);
        // 4. Take E node
        let right_tree = self.right.take();

        // 5. Link C and E nodes to swapped D node
        let new_right_node = new_right_tree.as_mut().unwrap();
        new_right_node.left = left_right_tree;
        new_right_node.right = right_tree;
        // 6. Link swapped D node to root right node
        self.right = new_right_tree;

        if let Some(node) = self.right.as_mut() {
            node.update_height();
        }

        self.update_height();
        true
    }
}

Listing 1: Rust code for inserting a note into an AVL tree.

node * rotate_right(node *x)
{
    node *y;
    y=x->left;
    x->left=y->right;
    y->right=x;
    x->ht=height(x);
    y->ht=height(y);
    return(y);
}

List 2: C version of List 1.

Then there’s C++ which was supposed to be better, more user-friendly C. In practice, however, C++ has become a large juggernaut, full of compromises and inheriting many problems from the C language. Short of large-scale systems (such as commercial systems), it is difficult to find a place for C++ . Maybe using a subset of C++ would be worth it. Yet, without a doubt, embedded systems projects will almost never be good candidates for C++.

Embedded systems

Back to embedded systems. By a broader definition, these systems are integrated systems intended to perform a single task, and to do so optimally. The task can be extremely simple like turning on a light on the timer, or complex like a module of a steering assistance system or a power grid controller. The underlying hardware resources are always used to the maximum: the light switch should be cheap, so the less CPU and memory used, the better; the aircraft’s on-board computer must limit its energy consumption, and therefore uses a processor that is just powerful enough.

These embedded systems are all around us. Today, each car has several on-board systems. The same goes for stoves, air conditioners, cell phones, refrigerators, headphones, network routers, watches, cash registers, ATMs, and traffic systems. The list is lengthened increasingly. Every industrial facility has hundreds, if not thousands, of systems. Programming these hardware-like systems in “alternative” languages ​​is often impossible; there is no way to access hardware interrupts, peripherals, and other hardware resources in a high-level language other than C. Additionally, the operating system kernels that form the basis of embedded devices and provide programming services (API) are themselves written in C.

Additionally, modern embedded systems include two categories that are often overlooked.

The first category includes systems that require various safety-critical certifications: MISRA, FAA, FRA, ISO 26262 (automotive safety) certifications, etc. Certification processes are rigorous and essentially require inspection and substantiation of every line of a system’s code. . This is not a task that can be accomplished if the systems language is Go or Python – I am not aware of the certification procedures for any language other than C. To complicate matters, the development tools – compilers, etc., are also certified. Low-level development tools are still written in C. So unless we’re willing to sidestep certifications and look into security, developers of these systems are bound to use C for the foreseeable future.

The second often overlooked category is real-time systems – those that are deterministic in nature. Real-time systems can again be simple and harmless, like an inkjet printer that needs to deliver dye in time, or those that carry a lot of weight, like radiation therapy equipment that delivers a metered dose of radiation to a specific place. These systems can never be programmed in any language other than C.

Conclusion

It’s not ideal. That said, whether it’s time to retire the language or even try is a moot point. Replacing C is, in my opinion, unrealistic because it’s often the only alternative to any other programming language.

---

Andrei Gorin, co-founder of McObject, leads the company’s product engineering as CTO. He has held senior management positions in major embedded systems and database software companies, and his experience in providing embedded storage solutions in areas such as industrial control, industrial preventive maintenance, television satellite and cable and telecommunications equipment is highly recognized in the industry. Mr. Gorine has published articles and spoken at numerous conferences on topics such as real-time database systems, high availability and memory management. During his career, he participated in university and industrial research projects in the field of real-time database systems. Mr. Gorin holds a master’s degree in computer science from the Institute of Electronics and Mathematics in Moscow and is a member of the IEEE and the ACM.

---

Related Content:

To learn more about Embedded, subscribe to Embedded’s weekly email newsletter.