I've always like the description of C as just being "raw memory, but with syntactic sugar."<p>I think C is still so pervasive for 2 simple reasons (I might be wrong):<p>1) It's a small language. Compared to many newer languages (Swift, modern C++, old C++, Objective-C, Java), it's quite tiny. The language itself can be learned in short time. (Which is deceptive, because properly using what you have learned takes longer than a short time).<p>2) It's fast. It's just direct memory access, direct and explicit hardware manipulation. And whether justified or not, there is a very large portion of the developer community that remains obsessed with speed. I see it all the time, even when speed isn't not going to matter enough to justify C. I often see people going way out of their way, making their work much more time-consuming, because of their everlasting pursuit of writing the fastest damn program they possibly can.
<i>Add to this the disastrously central role that C has played in our ongoing computer security nightmare</i><p>One sees plenty of news on the downsides, but on the other hand the lack of security has also enabled console homebrew, iOS jailbreaking, Android rooting, and a bunch of other creatively liberating activities which involve doing something not officially sanctioned. It's worth pondering whether we would be better off, had everyone switched to something much "safer" (maybe even with formal verification) a long time ago. I think it's debatable.
> <i>We rely on Python which is written in C89, a standard older than many of our developers.</i><p>Python ≥ 3.6 requires (some features of) C99.<p>> <i>Perhaps the reluctance to move to a more ‘modern’ C is that even C99 can’t legally buy a drink</i><p>Perhaps it's because MSVC didn't fully support anything newer.<p>Source: <a href="https://www.python.org/dev/peps/pep-0007/#c-dialect" rel="nofollow">https://www.python.org/dev/peps/pep-0007/#c-dialect</a>
"C is the desert island language". see <a href="http://crypto.stanford.edu/~blynn/c/intro.html" rel="nofollow">http://crypto.stanford.edu/~blynn/c/intro.html</a><p>For me, Linux is a huge development environment dedicated to C programming. Chapter 2 and 3 of manual pages gives C api. C gives the most direct access to kernel. IMHO we should try to find a replacement for C and the first target for this language should be linux kernel. If you can conceive a language that Linus Torvalds accepts, the rest of the planet will follow ;-)
In my mind, C very closely resembles what's going on in my mind's model of the computer. I "think" in C when I'm thinking about an algorithm. It's almost exactly the same as the fake language people sometimes use for explaining an algorithm. I think this property contributes towards the popularity. No "artificial" abstractions like classes, templates, modules, imports etc. Just think of the first step you would do to solve a problem, and write it. Then think of the next step, and write that. And you get fast, portable code that produces tiny binaries! What more do you need?
I think that during the nineties the focus switched from compiled, small runtime, unmanaged language to higher level, garbage collected, "big runtime" languages like Java or the scripting languages. One notable exception being C++ but its complexity and the difficulty to interface it with other languages meant that it couldn't completely replace C.<p>So for a long time if you wanted to do low level, fast, small, reasonably portable code you simply didn't have much of a choice.<p>Rust is the first language in a long time that I think could end up replacing C in all of its use cases but there's still some way to go. The main difficulty I can foresee is that like C++ it's significantly more complex than C and harder to interface with other programing languages (you end up making an unsafe C interface).<p>I think C is here to stay. The billions of lines of C code out there won't be rewritten in a fortnight.
C works everywhere, and everyone knows C, or can learn it in a couple of weeks and get coding. This is a hard combination to wholesale replace, but then not even Rust aims to do that. Instead it aims to chip away gradually, and I don't see why it can't do <i>that</i> .
My 2 cents, from the perspective of someone who built a career on writing software in C for small devices.<p>C has longevity b/c its compact and provides a straightforward model of memory on the machine. I understand the desire to use safe, garbage collected, memory safe language when you're serving HTTP requests, but sometimes you need to access the hardware: twiddle a GPIO or read from a DMA device. This is where I've yet to see a good replacement for C, and by extension, C++ (b/c its fundamentally still just C). Maybe rust is there, but I don't have experience there to judge.<p>[edited for clarity]
C was originally a language for modest size programs on machines with 64K address spaces. C isn't a bad language for a thousand line program. It's a terrible language for a million line program. Just to get memory safety, there's too much that has to be manually coordinated across compilation unit boundaries.<p>The three big questions in C are "how big is it?", "who owns it?", and "who locks it?" The language gives zero help with all of those issues. Most later languages deal with some or all of those issues.
I'm quite bored by the obsession of some for replacing C.<p>Yes, it does exactly what you tell it to do and that's dangerous. It was a high level language 25 years ago, but today the metaphor should be assembly. Nobody would criticize assembly for letting you shoot yourself in the foot, C is much the same.<p>The biggest threat to the tech sector is Linus dying and being replaced by some charlatan who insists on replacing C and using Jira.<p></offtopic>
As maddening as it may be, my gut tells me it has more to do with the precompiler than anything else. When it comes to wrestling with cross-platform differences, I don't know of a corresponding feature in Rust or Go that is equally powerful (or equally ugly!).<p>As long as computing remains a battleground where rich assholes put vastly different wrappers around the exact same shit so they can wring more money out of us, I will probably be writing in that abominable assembly language w/ turing-complete string-paster for many years to come.
>Perhaps now it is time for a new generation to make their mark, will their efforts last 40 years? Rust anyone?<p>I'd think it's quite difficult for a new language to replace a language whose main attractive points are it's longevity, stability (not the code and programs coming out of it, but the syntax and tools etc), and broad support.<p>There are many fields where C is easy to beat. But I don't think the next 40 year lasting language will be a C replacement.
> In 1987 this code took around half an hour to run, today 0.03 seconds. Progress eh?<p>The thing I take away when reading this is that in 1987 there were superior languages to C which — while usable — were just a <i>bit</i> too sluggish, and hence lost out. I'm thinking specifically of Smalltalk & Lisp, but I'm sure that there are others (maybe ML was around that far back?).<p>Well, if a program which once ran in half an hour can now run in 300 milliseconds, I think that maybe we should reconsider using just a little of that extra performance to run a better language environment.<p>Imagine if we had OSes written in safe languages which catch errors rather than allowing programs to misbehave. Honestly, it's hard for me to do because I've become so accustomed to crashes. Recently I've been doing some X programming with Lisp, and it's amazing — even when I make a mistake, things keep on running properly. I just see an error and that's that.<p>Well, most of the time, anyway. Nothing's perfect. Still, the experience is <i>orders</i> of magnitude better than writing C. I mean that literally, not figuratively.<p>(Also, as an aside: when I switched tabs to the article, it displayed for just a second, then disappeared. Reader mode didn't even work. I had to enable JavaScript just to view some text. What gives‽)
> Add to this the disastrously central role that C has played in our ongoing computer security nightmare<p>Hindsight is 20/20.<p>C was simply the pervasive language when the internet happened. C was designed when the world was a friendlier place, where buffer overflows did not exist. It was embraced by everyone because of its speed and simplicity.<p>No C programmer was raised/educated to have security in the front of his mind. Hell, many programmers of any language still don't.<p>Stop bashing C and start using Oauth instead of inventing your own authentication schemes.
C was the first language I learned in the mid-90s and I still go back to it once and a while when I want raw speed and direct memory access. I know other languages, sure, but I have yet to find a suitable replacement that lets me do what I want to do on a machine level without getting in the way.<p>Lately I've been doing some of the stuff I would normally do in C in GoLang instead. But it still can't match C in performance. (beats the hell out of Node.js though which is where I do most of my middle-tier / front-end code)<p>It also makes an excellent foot gun for the same reason.
If something is to replace C (or C++), I hope it's not Rust, because Rust is even more complicated than C++.<p>People should not have to bend their mind to satisfy some tool like the borrow checker, the tool should do the right thing and allow them to express their ideas in code with as little effort as possible.
I wonder if the danger of C is something people like, deep down. I spent some time talking to people who do dangerous jobs, thinking about automating their jobs with robots. Most of them <i>liked</i> the danger. They enjoyed having mastered the art of not getting killed by falling tree branches, or live wires, or runaway trucks, or whatever the job involved. They felt satisfaction at doing a job where, if someone else tried to do it, they'd probably get hurt on their first day. You can imagine various ways this could have evolved in hunter-gatherer societies.<p>Most new languages are far safer than C. For some that's the main selling point, for others it's just a side-effect of having GC. I wonder if you could get a lot of traction with a language as expressive as Ruby, but with footguns galore. I'm not sure that space has been adequately explored.
It shouldn't be such a surprise, unless one is ignorant of a stable, decades old, computing maxim:<p>Old computers (and by definition, old computer software) never dies. <i>The users do</i>.
Even in relatively new fields like machine learning, nearly every software that we use at work is written in C or is a wrapper around a C library, or in some cases in Fortran (a 60 years old programming language) : we use extensively PyTorch, torch, numpy, LAPACK, Scipy, etc.
The "AHL" name brings me fond memories of Creative Computing magazine and their editor, David H. Ahl.<p>Sadly these AHL's are unrelated.
Binary compatibility is as much a reason as the language itself.<p>For C++ I remember spending years trying to carefully track compiler versions, precise build setup, etc. or your library would probably fail to link. I have never had a binary compatibility problem with a plain C library.
C exposes you to low level programming environment, memory management and system internals. Its a great base to build upon for programmers. Even after more than a decade, I still have fond memories for K&R C - a must read for programmers.
"We use git for source control. hg, largely written in Python, was started within a few days with the same goals. Who won?"<p>I somehow doubt git's popularity has a whole lot to do with it having been written in C.
it's time we admitted bad code isn't because of the tools we use but a function of how we write code. You can write bad code even in "safe" languages. Leak memory with languages that come with a GC, etc etc.