-1.6 C
New York
Thursday, February 2, 2023

Is it time to retire C? – Embedded

The C programming language is undoubtedly one of computer science’s most successful programming languages. First appearing around 1972, C came out of Bell Labs and was created by Dennis Ritchie. Over the last 20 years, C has been ranked as one of the two topmost popular programming languages in the world (see Figure 1) by the TIOBE Programming Index. It is the most popular language for embedded systems developers and is used in nearly 80% of all embedded projects. After almost a half-century of use, is it time for embedded developers to move on to a more modern language? Is it time to retire C?
click for full size image

Figure 1 – The TIOBE Programming Community Index ranking of programming languages over the last 20 years. C has always been one of the top two languages.
For several reasons, the temptation to retire C and move on to a more modern programming language is relatively high. First, entry-level engineers who are often highly sought after by tech companies have little to no experience with C. University programs today focus on teaching modern languages like Python or C++. Getting them up to speed and experienced can require significant monetary and time investments that few companies are interested in.
Next, while very popular, the C programming language is dated. C doesn’t support modern programming concepts like classes and inheritance. If you compare the feature sets of modern languages like C++, Python, and Rust, the C language is starting to look like a dinosaur! The last time the C standard had new features added was 2011! The 2017 standard release only had technical corrections and clarifications, and the upcoming standard release expected in 2023 most likely won’t rock the boat either.
Retiring C continues to look tempting, but there are several problems with just moving away from C. First, C is a great language for low-level procedural applications that run close to the hardware. It’s compact and efficient. Second, senior engineers are entrenched in the language. They are at a point where they have used the language for decades and have little to no interest in learning and transitioning to a more modern language. Finally, so many legacy libraries and code bases use C that we can’t just abandon them. The cost to port the legacy code would just be too much!
It seems that we have a bit of a quandary! As an industry, we should be retiring C to leverage more modern languages and techniques, but the time and costs to change and the amount of legacy code we must maintain often get in the way of retiring C. The need for more modern techniques, while maintaining the benefits we get from C, may drive us away from using a single dominant language and force us to rely on multiple languages to get the job done.
The use of other languages to support C may already be happening. For example, Table 1 below shows the ranking of several languages in the TIOBE Index. In the past, one or two languages dominated computer science. Today, the top four languages all have a rating of about 10%. I believe this points to the end of single dominant languages. Instead, developers will leverage several languages to achieve their end goals.
Table 1 – A listing of programming languages often associated with embedded software development (Source: TIOBE Index). Note: These ratings do not represent embedded software use, just general computer science industry use.  
If you carefully look within the industry, this is already happening. I see companies transitioning to using C++ that still have numerous C libraries. I see companies trying Rust but relying on their tried-and-true C libraries as part of the build and vice versa. Unfortunately, or perhaps, depending on your perspective, fortunately, this means that C will continue to remain a dominant language indefinitely into the future.
Is it time to retire C? It’s a simple but complicated question. I would argue yes, but it depends on what you are doing. You might not want to use C++ or another language with an 8-bit microcontroller. If you are working with cutting edge 32-bit microcontrollers using machine learning or developing connected devices, a language other than C will provide you the additional tools you need to be successful.  The time and cost to switch languages might be too high. My rule of thumb is that if it is a new design, start with a modern language. If it is a legacy design, leverage the legacy code and write new code in a modern language.
What do you think? Is it time to retire C?
Related Contents:
For more Embedded, subscribe to Embedded’s weekly email newsletter.

Please read the article “Object-oriented oblivion”
I can’t offer a more cogent explanation about the madness of object-oriented languages
My special disdain is languages like YAML and Python than have rules regarding whitespace
Retiring C is not a simple matter as there are actually few contenders when it comes to embedded programming – I mean microcontrollers. Most modern languages ensure security by doing stuff behind the curtain and a number of these tricks actually rely on some form of memory management, which C does explicitly. Languages like Java or Python would probably be out of scope for this reason. C++ is a nice candidate if you limit it to a subset of the language. There is also a port of Rust to embedded (I’ve tried it on an Arm Cortex core).
For other languages you will need an OS but then you’re off for standard programming. In this case, you can get a cheap SBC running Linux, with more memory, more components, a more fragile MicroSD… A different project altogether.
Is it time to retire me? I was an embedded designer/programmer from 1981 to 1996, and have spent the past 26 years as a field applications engineer supporting microcontroller design and development for a leading semiconductor supplier. While you might wish to start a new design using a modern language, you won’t find compiler support for that language on my company’s parts. I would estimate that 90% of my customers are still using C with the remainder using C++. Those are the only two compilers we sell, and the only compilers available from our third-party partners like GNU, Keil (GNU), and IAR.
Most C programmers my age cut our teeth on assembly language and did not trust C compilers in the early years. Most of us learned to write our C code in a manner that guided the compiler in the creation of the underlying assembly. For its faults, C has served us well and continues to serve us well. Until modern toolchains are readily available from a variety of microcontroller manufacturers, you’ll be looking at C through the windshield and not the rearview mirror.
It is forty years since I first encountered C, already a decade old, and within a year I worked on a project where I was able to construct macros to allow other programmers direct access to hardware, but hiding the real addresses etc.
OTOH with no classes or scoping there was very little compile time safety offered, so I would strongly recommend shifting to C++ or similar / better for anything requiring more than one module of source code.
Programmers with experience of C and any other high-level language should have no problem getting to grips with C++.
Sometimes too much emphasis is put on the language and not as much on the base knowledge required to program an Embedded System. I had to fix bugs on an ES related to this lack of base knowledge, one related to reentrancy and race conditions (bare metal) and other related to two’s complement math. One bug fixed with protecting the critical section of the code (two lines of C) with interrupt disabling/enabling and the other with one liner to replace a complex (and wrong) logic. I suspect this kind of knowledge is becoming a lost art, I wonder what others have to say about it.
FWIW, I missed C++ on the project above (even though I am not as fluent in C++): there were some parts where templates and class inheritance would save a lot of coding.
I am currently developing a test setup (PC running Linux); I decided to use Python because the setup had to control some relays and I could not nor wanted to waste much time with it. I decided to use a USB-Serial converter, and RTS and DTR outputs to control the relays (the TX as spare, using break, if a need a third output). Even though I never programmed in Python, the test of concept was made in literally three minutes, with the help of some search in the Internet. Try doing that in C. Using Python is allowing me to focus more on the test itself (despite the somewhat steep learning curve) than writing code.
So, we must be able to have more than a hammer in our toolbox to avoid making all problems a nail and use the right tool for the job.
You must or to post a comment.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Your account has been deactivated.
Sorry, we could not verify that email address.
Your account has been reactivated.
You must verify your email address before signing in. Check your email for your verification email, or enter your email address in the form below to resend the email.
Please confirm the information below before signing in. Already have an account? Sign In.
We have sent a confirmation email to {* emailAddressData *}. Please check your email and click on the link to verify your email address.
We’ve sent an email with instructions to create a new password. Your existing password has not been changed.
{| foundExistingAccountText |} {| current_emailAddress |}.
Sorry, we could not verify that email address. Enter your email below, and we’ll send you another email.
Check your email for a link to verify your email address.
Thank you for verifiying your email address.

Your password has been successfully updated.
We didn’t recognize that password reset code. Enter your email below, and we’ll send you another email.
We’ve sent you an email with instructions to create a new password. Your existing password has not been changed.


Related Articles


Please enter your comment!
Please enter your name here

Latest Articles