Based upon the increasing number of languages showing up that combine high performance with higher levels of abstraction than C, and the increasing number of serious languages gunning for C specifically, like Rust.
C has ridden for a long time on the fact that we didn't know how to combine high performance and systems functionality with high abstraction languages, so you had your choice of C or C-like and fast, or high abstraction and slow, like Python or Perl or Ruby. This gap is closing, fairly quickly now, and once it does C will start experiencing a rapid decline into a niche language, rather than the lingua franca of computing. It has advantages that have kept it going for a long time, but it has terrible disadvantages too, and once the two are separable, people are going to want to so separate.
Already a great deal of what was once automatically C or C++ has gone to some sort of bytecode (Java or .Net), even on things you would used to simply automatically assume to be "embedded", like your cell phone. The decline has already started.
Of course it won't die. Computer languages never really die. You can still get a job doing COBOL, and in fact get paid quite well. But 10 years from now, I think on the systems considered "modern" at the time, it will not be the "default" language anymore.
Rust is the sole _potential_ C competitor I've come across but the language isn't even finalized last I checked so it hardly constitute a challenge to C as of yet. A new language showing up doesn't mean it will gain any traction.
As for the higher level languages closing the gap, that is certainly not my experience and I've seen no benchmarks to this effect. And I'm not talking about Python or Ruby and the likes which are in an entirely different category, I'm talking about C#, Java, etc. They are still alot slower on cpu intensive code, also they certainly doesn't fulfill other important properties of C like small memory footprint.
The notion that there was some 'magic piece of the puzzle' missing which has been solved in making high level languages perform like low level languages like C comes across as nonsense to me. Higher level languages sacrifice speed for convenience and safety, depending on your demands that can often be a very wise sacrifice, in the areas where C excels it's likely often not.
Also cell-phones (which are really the upper-end of 'embedded') run a kernel and system-level code written in C doing the heavy lifting system-wise, also performance demanding applications (higher-end games) are often still written in native code on these phones.
There's certainly room for a more 'modern' C, maybe something else has replaced C in 10 years, but I don't see it being any of the languages we are discussing today, not even Rust. As it stands, I think C will remain dominant in the aforementioned domains.
Guess we are going to have to disagree, history will prove one of us right I suppose :)
I don't know, Rust has Mozilla behind it, and lots of active development and (for a new programming language) a pretty decent community.
ATS is hosted on SourceForge, and looks to be someone's research project. That's totally fine, and it may actually be _better_, but the real world often doesn't care about better.
If I was a betting man, I'd be putting chips down on Rust. (and I sort of am...)
That said, the more programming languages the merrier!
Rust may be more successful but at this time ATS is a better C replacement. Mainly because Rust is currently tied to a runtime and garbage collector. But also because ATS has better features for describing the API boundaries when calling into C and back (ie. FFI).
Rust will grow into these areas I'm sure because Mozilla will need them for Servo and safer programming.
It's high-level assembly language. Thus, it allows you to write code with a very small barrier between you and the machine instructions, but with enough of a barrier that you can reuse and organize your code logically. At the same time, it gives you most of the speed and raw bit manipulation of machine code.
The negatives about C:
You're almost as likely to introduce completely silent catastrophic memory corruption with every operation than you are to actually accomplish the task you're trying to do. Most of the things which would normally be bugs are also now major security breaches. C's structure also makes it extremely difficult to do static analysis, making it difficult to find bugs, security vulnerabilities, and make performance optimizations.
How ATS helps:
ATS addresses a lot of these issues by emitting efficient C code. However, at a higher level ATS combines C with an extremely strong type system (dependent typing) which allows you to do things like verify statically that there are no out-of-bound memory accesses through typing. It can do even stronger things like prove your code correct.
ATS provides all the low level hackery that C can do but allows more information to be encoded in types to ensure that is safe. It also provides high level features from functional programming languages like higher order functions, pattern matching, etc.
Any new language will have a maturity gap to make up for that will be hard to bridge.
Java has to some extent displaced C++ (and the .net framework has done some more of that), but I haven't seen any language that displaced C in an arena where C is strong.
For rust to make this happen they'll have to finalize the language spec, gain a decade+ experience in what the quirks are (these things only come out over time it seems), sway a generation of programmers to adopt it rather than the incumbent.
Go is shooting for the same space and it already lost the plot in several aspects (for instance: newer Go versions break older code).
Pre-version 1, there were no promises that your code would not be broken. In fact, quite the opposite is true. It is hard for me to classify this as a failing of Go when it was exactly according to plan. Now, if future versions break version 1 code...
Acknowledged, however I also think that Cs inertia will keep it going for a long time. Because System X was written in C, the next iteration will be written in C, goto 10. Also, for scientists (and others, I'm sure), it is hard to convince them to learn a new language when they are comfortable with their current language and are not convinced of the benefits of switching.
C has ridden for a long time on the fact that we didn't know how to combine high performance and systems functionality with high abstraction languages, so you had your choice of C or C-like and fast, or high abstraction and slow, like Python or Perl or Ruby. This gap is closing, fairly quickly now, and once it does C will start experiencing a rapid decline into a niche language, rather than the lingua franca of computing. It has advantages that have kept it going for a long time, but it has terrible disadvantages too, and once the two are separable, people are going to want to so separate.
Already a great deal of what was once automatically C or C++ has gone to some sort of bytecode (Java or .Net), even on things you would used to simply automatically assume to be "embedded", like your cell phone. The decline has already started.
Of course it won't die. Computer languages never really die. You can still get a job doing COBOL, and in fact get paid quite well. But 10 years from now, I think on the systems considered "modern" at the time, it will not be the "default" language anymore.