Which language has the brightest future in replacement of C between D, Go and Rust? And Why?

So let me dispense with D first

• Poor adoption after many nominal years of existence. Insiders to the D community could qualify this statement (D in its current form is relatively new, adoption does grow, etc). Yet the perception remains, and adoption is driven by perception and becomes fact. So managers and engineers are nervous about adopting a language that's been around unsuccessfully for so long. Furthermore, time works against D unless/until a major uptick in adoption becomes obvious.
• Weak story about D's relationship to garbage collection. GC is a great invention, but the decision to use it for D has instantly alienated a core market - existing C and C++ programmers. For those, the party line has historically been "Don't want GC? No problem! You can use D with RAII or manual management style as well!" Though true, that's next to useless because there's little support in the standard library for alternative memory management styles, which means the putative user would need to start with the language stripped down to the studs and create all the core infrastructure. Also, for those who are okay with using a GC, the quality of its implementation is lackluster. Overall it could be said that D has the downsides of GC but doesn't enjoy its benefits.
• A historical lack of vision. Absent corporate support, D has been community-driven, where engineering acumen is easier to find than long-term vision, charisma, and leadership. For a good while, the stridency of D's attempts at promotion and PR has had negative value. The first vision document (http://wiki.dlang.org/Vision/2015H1) is dated January 1, 2015, and the next iteration (Vision/2015H2 - D Wiki) has been four months late in a six-months cycle, which is at best ironic.

• 10x faster to compile than C++ for comparable produced code. This gap is essentially impossible to bridge for C++ and prohibitively difficult for any other language. (Go compiles a tad faster than D, but produces slower code.) The experience of using a system language that builds this fast code this fast is transformative and far-reaching. Combined with D's abstraction power, it essentially makes D a good choice for writing highly optimized code for the simple reason that experimentation has a low cost.
• 10x faster than scripting languages for comparable convenience. A good use of D is as a convenient scripting language for a variety of casual tasks. The build/run cycle is just as quick, and the gain in speed is enormous. Also, there's no "hitting the wall" effect - if a script grows large, D has always more power and modular mechanisms to offer. Of course, this must be taken with a grain of salt because e.g. Python has much more libraries available. But the 10x gap is fundamental: systems languages would have difficulty getting to D's level of conviviality, whereas scripting languages would have difficulty closing the speed gap.
• 10x easier to interface with C and C++ than any other language. D uses the same memory layout as C and C++; all it does is build structure on top of it, but the lower layers are readily accessible at no cost. The entire C standard library is readily accessible at no syntactic or speed cost,  there is work to allow the same for the C++ standard library, and many C libraries are easy to interface with (https://github.com/D-Programming...). It could be claimed that literally no other language can reach that level of integration.
  
• 10x better than any other system language at generic and generative programming. D's static introspection, compile-time evaluation, and mixin-driven code generation combine to a powerful cocktail that is very difficult to mix right in other languages, be they new or extant; at this game, Go is so out of depth it doesn't even get the point; C++17 is hopelessly lost in the woods; and Rust is just trying to dabble.

On to Go

• Fundamental slowdown due to indirect calls and garbage collection. Virtually no meaningful Go can be written without resorting to indirect function calls and garbage collection, which are central to its core features. These are major impediments to achieving in-core performance. The response of the Go team has been tactical, e.g. work on a better garbage collector. However, it's unlikely that the challenge of replacing C can be won tactically.
• Politics. Go's party line has been disproportionately strong and rigid on a number of issues, small and large. Among the larger issues, the approach on generics has been heavy-handed and demeaning enough to make generics the N word of Go; the whole topic has become enough of a stigma to discourage any attempts at meaningful dialog. I think politicizing of technical matters is an extremely damaging pattern in the long run, and I hope Go finds a way to repair this.
• Simple-cum-simplistic. Go is famously simple - there are anecdotes of people picking it up quickly. However, that becomes problematic as time goes by; Go code is hopelessly pedestrian - Go coders find themselves writing again and again the same things from an ant's vantage point because Go cannot abstract even the simplest notions or algorithms. Domains that are not already served by easy to glue libraries are difficult to get into. There is backlash from coders who have used Go for one project and wouldn't want to ever use it again. It would be great if Go made life better for repeat customers.

• 10x better strategy. After a brief period in which Go claimed to be a systems programming language, it has fully committed to the niche of networking services. This has been a brilliant marketing move, which capitalized on the strengths of the Go team (some of the best engineers in the world at networking services). That market is hot, and Go was a fresh breath of air in a world dominated by Java EE bureaucracy and slow scripting languages. Now Go is a major player in that area, and it would be difficult to displace it.
• 10x engineering. Go has a solid engineering team behind it, and that's a major influencer of the quality of the language and in particular the networking library and the tooling. Until now, good engineering has compensated very well for the lack of power in the language.
• 10x branding. Many of us are ready to admit that a main motivator of Go is its connection to Google. That gives it a clout of professionalism, quality, and stability. Of course, brand is not everything, but what it means is all Go has to do is be a decent language; it doesn't have to be a fantastic language. The brand works out the rest.
  

Last but not least, Rust

• A disharmonic personality. Reading any amount of Rust code evokes the joke "friends don't let friends skip leg day" and the comic imagery (https://www.google.com/search?q=...) of men with hulky torsos resting on skinny legs. Rust puts safe, precise memory management front and center of everything. Unfortunately, that's seldom the problem domain, which means a large fraction of the thinking and coding are dedicated to essentially a clerical job (which GC languages actually automate out of sight). Safe, deterministic memory reclamation is a hard problem, but is not the only problem or even the most important problem in a program. Therefore Rust ends up expending a disproportionately large language design real estate on this one matter. It will be interesting to see how Rust starts bulking up other aspects of the language; the only solution is to grow the language, but then the question remains whether abstraction can help the pesky necessity to deal with resources at all levels.
  
• Foreign syntax. Rust's syntax is different, and there's no apparent advantage to the difference. This is irritating for folks coming from Algol-style languages, who need to deal with a gratuitously different syntax in addition to getting the resource bookkeeping right.

• 10x better theorists. Of the three, Rust is the only language with world-class PL theorists on roster. This can be seen in the precise definition of the language and the depth of its technical approach.
• 10x better safety than other systems programming languages. Of course that had to be here, we just discussed the cost of that.
• 10x better PR. There has been a long period pre-1.0 when Rust was a community darling and could do no wrong: whatever problem there was, either Rust had a solution to it, or will have had by 1.0. The realities of 1.0 ended that honeymoon and marked (by my measurements and estimates) a stark decrease in general interest, but these effects have a way to linger. Plus, after all, Rust is a decent language with real things going for it, and it's well positioned to convert this lingering hype into solid marketing.

In brief

D.

It's a long shot – D is unlikely to replace C, but I think it has a better chance long-term than Rust or Go. D might not look like a big contender right now, but things change and the tortoise can win the race in the end.

---------------------

Edit on April 23, 2016: I'm not as confident in D after seeing how the maintainers have rejected improvements to the language. D doesn't have a large installed base out in the world, so their reluctance to make breaking changes seems misplaced – D's only real long-term play is adoption from new users, so focusing on not perturbing incumbent users is strange.

---------------------

1. Go is out of contention. It cannot replace C, given that it's garbage-collected and somewhat constrained.

Go's strength is that it’s explicitly designed with an awareness of the social context of software development (and the organizational context.) This is underexposed. Go was developed by Google for Google. It was developed with an awareness of the needs of integrating code from a bunch of different developers. That's why it's so opinionated and restricted – it's an entropy-reducing language.

In any case, it can't do what C does, and it doesn't contemplate the needs of non-Google-esque users, like embedded systems, OS development, etc.

2. Rust could conceivably replace C, but it’s very complex and seems harder for newbies to learn.

Here it's worth pausing to note that whatever replaces C will be adopted by young programmers – people who are young now – not old ones. Like Kuhn noted in describing scientific paradigm shifts, the old guard eventually retires or dies. So it doesn't necessarily matter what veteran programmers think about Rust, Go, or D. However, it does matter whether a language is easy to learn.

D is easier to learn. And I'm just very impressed with Andrei Alexandrescu. If he's working on D full-time now, I wouldn't rule D out just yet. They do need better branding and more sponsors. D has always had a pocket protector vibe, in contrast to Rust's youthful, futuristic image. (See edit above – I'm not as confident in Andrei after seeing him shoot down others' improvements and consistency fixes to the language. Maybe I’m wrong about this – I probably don't know enough yet.)

All that said, I don't see any of them as likely to replace C – I just think D is most likely of the three. The reason is lack of vision. All three languages waste their opportunity to fundamentally rethink programming language syntax and semantics. None of them are based on usability and learnability research, and rather seem to be based on the preferences of their creators. The culture of software development seems to reinforce and perpetuate insane syntactical conventions.

I think the fundamental insanity of almost all programming languages is a significant factor in the gender and ethnicity gaps in the software industry. People who end up being programmers tend to embrace a programming language as teenagers. They get over the initial craziness of the syntax, but lots of people are deterred by it and leave programming aside. Recent research posits that one of the reasons women are underrepresented in STEM is that smart women have more options than smart men – they have a broader set of skills, including social skills, and thus are free to pursue a broader set of careers. Programming languages look ridiculous to the uninitiated – they're gratuitously unintuitive in ways that don't buy us anything, don't help the compiler, etc. I think smart women are more likely to see it as a waste of their time, and pursue other careers.

The language that has the best shot of replacing C will have sane syntax and draw from research on usability and learnability – it doesn't exist yet. You probably need some fundamental advantages and advances to replace C. Sane syntax would be noteworthy. You also need to think about embedded systems and the broader user base. With Rust, Mozilla is thinking mostly about building a browser, understandably. Multiple dimensions of safety are a must. I think Andrei is fundamentally underestimating the enormity of the security crisis, the price the world is paying for C and POSIX. Computing is fundamentally insecure to such a degree that it might not even be rational to have certain data on computers at all. Software and systems need to work fundamentally differently than they currently do – e.g. code injection is a ludicrous phenomenon that should not be possible, but C does a lot to make it possible.

For some early work on sane, research-based syntax, see the Quorum Language, a project led by Professor Andreas Stefik: Quorum Programming Language I think they rushed to design the language after a couple of tiny survey studies, so I don’t endorse Quorum as a replacement for anything (and it’s a JVM language, not a C replacement). But at least they’re doing some research before designing a language.

None of those languages will replace C.

Fans of D, Go, and Rust can have a good old time fantasizing about this subject - but it’s really a waste of time because it simply isn’t going to happen. Here are a few reasons why:

• C is arguably the most successful programming language of all time. In comparison D, Go, and Rust are wanna-be’s.
• C is the dominant language for embedded systems. Embedded systems are not some tiny percentage of the computing world - over 95% of the world’s processors are in embedded systems, not in “traditional computers”. Embedded systems also tend to need much more custom code than any other area of computing - meaning that less code is reused and more fresh code needs to be continually written. You need a ton of developers to write all that code, and C has been the de-facto standard language of embedded systems since the 1980s (and before that it was assembly language) - good luck trying to displace that entrenched of a language with any other. Decades of success speaks for itself.
• Possibly only Java has a larger eco-system in place than does C. The C eco-system is beyond huge. Just about every processor on the planet has a C compiler for it - can anyone say even close to the same about any other language? Companies that make processors almost universally write their example code, libraries, utilities, etc. in C. Not even C++, but C. Assembly language comes in at second place, and D, Go, and Rust are nowhere to be seen.
• C just works. It does the job it was designed to do better than any other language. Again, many millions of devices run on C code (more than any other single programming language) - and this is no new phenomena - there must be a reason for this (and the reasons are many), but I’ll simply say again, success speaks for itself.
• You can complain all you want about the drawbacks of C, but if you do you’re looking at it from a high-level programmer’s point of view which really does not apply to C. C is, and was designed to be, a “portable assembly language” - it does an excellent job at this and there simply isn’t any other language that can even hope to compete with C in this space.
• Your garbage collection, your classes, your libraries and APIs…. none of these are needed and usually not even wanted by C developers. Please quit comparing apples to oranges. Admit it, C rules in a domain that is for the most part totally foreign to most high-level programmers - the same rules do not apply when you’re working right on top of the hardware, so please stop thinking that they do. If you think you’ve got a replacement for C then you’re obviously not familiar with the domain in which C rules.
• C is not a language for programmers that need to be babysat or have their hands held. If you can’t deal with managing your own arrays manually, or if you suffer from memory leaks, you’re not C programmer material. C is not a language for the average programmer. You need to know what you are doing, down to the bit level. Good C programmers have no problem with this because C’s lack of protection from the programmer is one of it’s greatest strengths - what others consider drawbacks in C a true C programmer knows are actually strengths of the language. C does not hold your hand, it doesn’t protect you from your own programming mistakes, nor should it! Tremendous power always comes at a cost - and I say if you can’t take the heat get out of the kitchen. If you aren’t confident that you understand and have complete control over what every single line of your code is doing, or that you could successfully debug every problem that you could encounter in the code you write, then you aren’t ready to use C professionally. So why the heck are you sitting there debating what could replace C? If you really knew C and could use it properly you would know that it doesn’t need replacing.

So flame-on if you wish, I’ve got my trusty asbestos suit on - the same one that has served me well for many decades now. And as much as you want to argue, the facts about C that I have pointed out are just that - facts. You can debate facts if you want, but it’s still a fools errand to do so.

:)

First: I don't think anything's going to replace C for quite a while -- In a lot of places C is used, it tends to be a language that's hard to beat -- the "enhancements" the other languages introduce tend to be *contrary* to what makes C the right language -- size of run time, portability, closeness to hardware, absolute control of memory, etc. The only other language that seems suitable to replace C in these domains is Rust, but to make Rust work here, you have to give up a lot of what makes Rust a great successor to C/C++. This means there just isn't reason to switch languages.

However, there are times C is used where it's not uniquely suited, and I'll introduce C++ to compare D/Go/Rust to.

The success of languages have rarely relied on what languages are technically better -- it's largely been about politics, branding, money, what sounds good to the bosses (and not the engineers). This is why Java became such a successful language (whether or not the language itself was worthy of its success).

This explains the lackluster adoption of D -- it's a pretty great language, and most coming from C++ seem to have very high opinions of it. But there's just not the sales and marketing teams behind it to sell it to companies. There's really been no killer apps. Just a few guys who go online and say "D is a pretty cool language." And people are stubborn and this doesn't convince them the same way some $$s can. Despite any technical merit D has, despite how good of a language D is, I don't think we'll see D ever enjoy mainstream success unless something spectacular happens.

This is also why I think Go has the best opportunity. It's got Google behind it. It already has a killer app written in it -- Docker. A lot of companies have also already switched a lot of their code to Go. In a word: Go has quite a few $$s behind it.

Now on to Rust: I think Rust is most technically suited to replace C++/C. I think Rust will be adopted by many -- it does have a major name behind it -- Mozilla, and it's being used in the Servo project. And when/if that ends up being successful, it's a great demonstration of the merit of Rust, and will lend to its adoption by others. Even if it doesn't "beat" Go, I think we'll see it as a very successful language. After all, Python might be more used than Ruby, but Ruby certainly has made a name for itself and enjoys a great deal of success.

That said, there's so much code and momentum behind C/C++, we'll probably not see these languages replaced for a long, long time, although Rust and Go might take a bite out of its market share.