I have watched some developers giving advice about using C for general software development, i noticed that a not insignificant amount of them are strictly using C89, vaguely gesturing that more recent versions of C are less dependable, or more broken.
I would appreciate if anyone here can explain the specifics, as me not being a C developer (yet) and looking over the source code of some libraries which do heavily use modern C features, for example to have a defer-like macro (using attributes, or the 2 for statement trick), or generic data structures (using manual name mangling).
I understand these examples are strictly not how C is usually used, and are common in other more modern languages, which may turn some developers away from using these, my main question is “why exactly?”.
I don’t mind being given further reading about this, so if you have an article in mind, it too would be greatly appreciated.
note: in the title i referred to C23, but it could be anything post C89/C99 depending on the subject matter.
At least since C99, I’ve seen a trend where ISO tends to bring in unnecessary C++ features in. In fact, the current boss of WG14 quite explicitly calls for bridging gaps, modernising capabilities, and bringing select features (like
constexprobject definitions and ergonomics) closer to what developers enjoy in C++, while “balancing C’s unique philosophy and design constraints”. I don’t suppose it sat well with most C developers who feel C++ has evolved into a language of its own and that we shouldn’t try to bridge gaps that don’t exist. And consequently, the very fear of “dead on arrival” features have already crept in. Off the top of my mind, VLA is one such example. Appeared in C99 and is now a deprecated feature.That said, C89 is, for most parts enough to express that largest chunk of your codebase. But sure, you might need a little bit of size guaranteed integers, so you could borrow that from C99. What’re you left with? The convenience of declaring variables midway? That’s about as far as it goes. In very rare circumstances you might want to statically assert macros is global variables. Sure, pick C11 just for that task.
If I really need some awesome syntax sugars, I’d rather use one of those modern languages like Zig, Rust and what nots…
I can see this. Im not a dev but when scripting I often would mention I like to make something simple shell script if I did not need anything more because it would run fine on pretty much any system. I only went to a higher level shells when I need capabilities that simple shell did not have.
I can see that, personally i dislike using C++, as it has so many different ways to solve the same problem, confining a project to use a specific subset of C++ is very difficult.
Though mostly what i would like to be closer to other languages, is what is mostly standard across everything, like tuples, so i wouldn’t have to do:
Err fallible(Arg argument, Out* output) { ... }But at least attributes allow me to warn if the error in this case is unused.
Thing is, C can compile to anything, so i wonder if Zig/Rust can really be a drop in replacement in most use cases.
It works. You have hammers and nails. Then, someday, a dude come with the new Hammer23, with better ergonomical grip, colored high density 3 sided head, and so on. Yeah, cool, but I still have the same nails to nail, and my current hammer do the job perfectly. And I drilled a hole in my workbench ten year ago that have the perfect size for my current hammer.
Later versions than C99 have no real added value proposition for the real use-cases where C is actually desired as an implementation language.
Later versions than C99 continue to introduce C++isms among other shit, from committee members some of whom probably never coded anything serious in C. This actually sometimes trickles down to compiler implementations even when you’re sticking with an older version. So they manage to anger you even when you’re keeping a distance.
Despite street myths and stereotypes, most people who choose C for some projects are not grey-hairs stuck in the past and incapable of learning new tools. Many of them in fact do use newer languages like Rust where they see fit. So there is no pressure to pick the one or two features from newer C versions that are maybe possibly can be useful.
Still, for some big projects that are kind of half-stuck with millions of lines of C, while at the same time having immense pressure to deliver maximum reliability AND security, these newer versions could proof useful at times. But the only project that comes to mind that fits this mold is the Linux kernel really. And there, non-standard language extensions are getting used anyway, so it’s kind of an exceptional situation, that is also not very portable, but that’s not a concern by the very nature of where a kernel sets in the stack.
That’s very fair for the linux kernel, I’m aware that they use more modern features of C, though i have no idea to what extent.
It was part of the inspiration for asking this question to begin with.
They haven’t bothered to update their knowledge about it. And why should they? They got gud with C89 and can write software that works with it. So since they don’t know how to, when they use the modern stuff they break things; they haven’t learnt the footguns yet. The same way a n00b would write broken software with any version of C. That feels bad so they reject it. It’s like how everyone thinks the music from when they were a teenager is the best music. Starting learning from nothing it’s probably better to learn the new stuff too, but if you’re maintaining software written with one version it’s probably not worth updating it and so you’ll need to just work with what there is.
Although if you really need generics and other more advanced language features and you’re starting a new project from scratch it might be better to go with something like rust at this point.
I don’t know if I’d assume the same about them, as the way the argument was worded made it seem the new features aren’t a positive, or are broken in some way, or at least gave the appearance of the actual reason being technical and not skill.
I was originally thinking of the use case for C is when you need to have something in a closed ecosystem, as in no dependencies, so generics made sense as an example, and while I’m aware one can use rust, it usually enables (and in a sense encourages) pulling in many dependencies, which is not always desirable.
The main reason I stick to it is that I target platforms that normally don’t have anything else. Also the rules are easier to understand.
If you’re willing to share, are you talking about embedded?
