Ask HN: Will the C programming language really die?

Read this - http://blog.biicode.com/cpp-will-never-die/. And I think C will never die! But it's very interesting to known Linus Torvalds's opinion about Rust and the future of system programming languages.

It does feel that there has been a recent boom in new compiled languages (languages that compile to native code, I mean, instead of whatever virtual machine people currently think is hot). One or more of these might well wind up displacing C in the future. C is an elegant language but it suffers from not being able to learn from the lessons of the last 40 years.

Fortran is still in use after ~60 years, but it isn't really being used for new applications, which seesm to be what you're asking. It seems safe to assume that someday C will follow suit.

Well, it's an interesting question!

I started learning C almost 30 years ago and while I have learned a lot of other languages: C++, Java, Scheme, Dylan, NewtonScript, Visual BASIC, some Haskell, a little Forth, various assembly languages... recently I received training in LabView.

I keep winding up using C again. I spent today writing C code that runs on an embedded board. Simple code, really, running on an embedded processor with very little RAM. There's still a need for this. I have most of modern C++ available on this platform. It is technically C++, but I'm not using any classes or templates, so it looks for the most part very much like C99.

As someone who is well-acquainted with C's weaknesses as well as strengths, I would honestly like it if I could migrate all my work to something else. I really like functional languages and I really like strict type safety. I am looking forward to using Haskell on embedded systems and think it will have a niche there. I'm looking forward to expressing embedded state machines in FRP (functional-reactive). However, these things are still relatively limited and experimental. As for Rust and Go, etc., it's still a chicken-and-egg thing, I think. And I'm not sure they are really suited for _small_ chips -- what's the minimal runtime? Can you get rid of all garbage collection at runtime? And remember that practical issues of tooling are _huge_. They tend to swamp theoretical elegance and even sometimes efficiency by a large margin.

So, I guess the answer is "I don't know." C still has a niche. At some point it may truly be unnecessary. As to whether it is worth studying or investing your time understanding, I would say the answer is almost certainly yes. The C runtime model is still the dominant one; C is still the language used to build most of the tools that other languages are built on. If you need to understand what is going on at the low level, just above assembly language, and programmers still do, they still need to understand C.

Not in a hundred years, everything we use today is built on top of thousands of C code lines.

C is still absolutely standard and huge in both the fields you mentioned. Despite all the new system languages or whatever doesn't change the fact that C dominates and will continue to dominate embedded development among other fields.

Anyone who claims C is dead likely is working in the Silicon Valley startup bubble. Sure, C isn't going to get your far at mostly web based companies but every computing device you own most likely has C and assembly running the hardware bits and the underlying system.

There's a Japanese proverb: If you believe everything you read on hacker news, don't read hacker news.

Let's say rust fares better than go, c#, D, java, limbo, modula (-2, -3), oberon, pascal, etc. Programmers around the world race to convert all legacy C code to rust. C, C++ and Objective C are banned under international treaty and everyone suspected of leaking memory is rounded up and sent to coder bootcamps for re-education. Learning C is the second best (behind assembly) programming language to understand how your computer actually works.

There's still nothing that can actually replace C. I think that's because of a combination of:

1) Being reasonably high level

2) Having asm() be usable at all. You can't drop into asm with Go, as far as I'm aware. You can with Rust and C++, but the next point...

3) The ABI as commonly implemented is dead simple. I know how to call C from asm, and vice versa, without screwing everything up, having bizarre initialization and destruction to worry about, etc. C++ can't claim that. I don't think Rust can either.

C will live on until there's an actually usable replacement. Right now, there isn't.