C is still a great language. Here we examine some viable successors.
The C programming language was the 3rd programming language I’ve learned—-and that was over 4 decades ago. The first two languages I have essentially forgotten and will never use again: BASIC and Pascal. To be honest, after learning C in university I actually forgot it since I was steeped in a quite different language for my day job for nearly a decade.
As luck would have it, I not only relearned C but also learned C++. I mostly learned C++; I learned just enough to get done whatever was needed; it is a beastly language.
In fact like most programmers, I largely used C++ as a better C. Then C got better.
After more than another decade and I no longer needed to write programs in C++, I very happily
I will not re-acquire it, no matter how many gyrations the C++ committee puts it through.
With each gyration they attempt to make it a more something language—-more streamlined, more
expressive, more I don’t know what.
They do improve some things but then introduce other
kludges features—-just too
much syntactical strychnine.
There is now so much baggage that C++ is beginning to approach COBOL or Ada.
COBOL evolved where you could do nearly anything and everything with it…
in thousands of lines of stultifying code.
Ada was designed to be absolutely everything for every possible usage and therefore could
do nothing well or fast.
Yet, we keep hearing the incessant bleats, “C is too hard! Pointers! Waaa!”
Then I learned Objective-C. It is C with a few simple syntax additions. Suddenly you have objects and methods. It was influenced directly by Smalltalk where the focus is upon messages, and not all of that other OOP gobbledygook in other OOP languages. The Smalltalk environment has great limitions. Objective-C has a different set of limitations; one is you will only find a viable programming environment for it on macOS. Forget about iOS and the other inhabitants of Apple’s walled garden; they want you to use Swift and only Swift. Swift was billed as a systems programming language but nearly 10 years later very little of any core OS is written with it. Oh, and they just introduced macros in Swift. <sigh>
Aside: The C preprocessor is the one facility of C that I truly despise.
Back to C
Well, mostly. FreeBSD, OpenBSD, Linux (on just about every device), Raspberry Pi, and even Arduino still require C skills. So these things are keeping C alive after 50 (!) years.
The thing I like the most about the C Standards Committee is that for each version they follow
a charter. The charter has evolved—-grown, not changed—-from the original to meet current needs.
You can read the charter for C23 (née c2x). Note that at the time of this writing, most
compilers currently only recognize the
-std=c2x option and do not yet recognize
even though many features of C23 are supported in current versions.
This charter thing is significant because it means C will continue to operate as C and not some new, improved, now with fizzle-gig gyration of C. There are myriad examples of languages that have gone off this cliff; consider the whole ongoing Python 2.x versus 3.x debacle.
If you accept the proposition that C++ has failed as the next iteration of C, and I deeply believe it has, what are current the reasonable options?
I will simply state without going into details that I have a strong bias against Apple’s Swift and Microsoft’s C#. Both of these are vendor-driven technologies from vendors who have a proven track record of abandoning developers for the next new shiny thing. And beyond their walled gardens, they promise broader platform scope, but how long has this ever lasted from both of these companies. It’s just not in their charters.
Let’s consider each of these.
Rust has been around since 2015. It is not C. It is not necessarily easy to learn.
Additionally, it is now officially supported in the Linux 6.1 kernel. That is a rather notable vote of confidence for this language. Furthermore, Rust is not only supported as an extension to an OS (Linux) it is also used to write new, experimental OSes. There’s also a tutorial to build a simple one. There are lots of similar systems projects when you start looking for them.
The Rust community is vibrant. It provides a great deal of resources for learning Rust and support for creating apps in Rust.
In a recent chat with Mark Dalyrmple of CocoaHeads fame and author of Advanced Mac OS X Programming, among other works, he mentioned Zig as a C-like evolution of C. He’s always good for that kind of thing, as in, “Hey, lookee at that thingee over there…”
The syntax looks simple and clean. It has objects. It already runs a bunch of places.
Okay, that’s enough to get me interested.
The main problem with Objective-C today is that it only, or largely only, runs on Apple platforms. Then, this article surfaced via OSNews. ObjFW promises to give new life to Objective-C on more than just Apple platforms.
I am rather excited by this development because I really like Objective-C. I wrote a desktop clock application with it and very much enjoyed the experience. That was about the time Swift was announced.
Sadly, I’ve let that app languish. But now with ObjFW I can see a way to not only escape from the clutches of Apple but also port this app to other non-Apple platforms. Writing/porting my Objective-C app to Linux/Wayland is now a real possibility. I don’t know when that will happen but it is back on my list.
Will these languages replace C? I think not.
Or, at least, not anytime soon. The market is fickle. Programmers are even more fickle. What is the new, shiny today may no longer hold any interest tomorrow. To be clear, these languages will have to get well beyond the new, shiny phase to displace C. That day is coming… but nobody knows when that will be; that day seems to be too far off over the horizon.
I do think these languages will provide vibrant and stable development environments for picking up where C is weak or falls down. I am looking forward to deeply learning each of these languages to see if, in fact, they will fullfil their promise as the next iteration of C.