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

Inspired by Andrei Alexandrescu’s answer, I started writing a long comment…then decided to recapitulate and answer the question.

I admit I’m not a pusher or an expert in C, D, Go, or Rust. I use C/C++ frequently in coding when I want “bare-metal” speed, or when I want modules to run as services on the back end. Since that’s a stylistic approach, not exactly fundamental- let me qualify to say I do “Integrations” or at least performant interfaces between disparate systems, and I solve some really interesting problems, and face some challenges which are not unique but significant in themselves.

My main contribution here is to question the premise of the question! I don’t mean to nuke it entirely. I think it’s a relevant question, but speaking of replacing C… that reminds me of turning to the pet store when you have just put your dog down at the vet.

So is there a better question to reach for the result looming at the end of this current question?

Integrations seem to be the immediate future (10x years from now lol). Rather than looking to more middleware there is a trend of revolution. In my wildest tech fantasy I’d like to see optical systems and holographic character recognition in place within 5 years. I mean, why not? MIR (Micro Impulse Radar, LLNL) has a clock cycle of 33.3Ghz and could work in an optical system, particularly if that were all it were doing. So speaking of speed and next-gen architecture, regardless of how or when it comes down, the current model of hardware needs to change, because it is causing layers of complexity that are work-arounds rather than solutions. Now that we’ve effectively put mainframes and servers inside desktops, yay team, we actually need to rethink computing.

But you aren’t going to get that response from an industry which is tooled from tip to toe using the existing systems.

And yet one can’t quash evolution. There are evolutions and revolutions present in the aggregate world of languages, and we are more likely to find some small and completely obscure language which effectively solves a real-world problem such as a virtualized system model that represents the quantum leap in computing. In that case, the language that goes forward will not be carefully positioned, elected democratically, or even branded into existence. It will simply be.

2 examples hopefully illustrating a larger point:

1. JavaScript has become more declarative and compositional- which is a gradual process as all languages slide towards Functional paradigms with time- yet with Node.js it is doing things once only dreamed of. Case in point the Back-end and Front-end meet, and suddenly the old adage “…and ne’er the twain shall meet” really does become archaic just like the language it is built on.
2. Similarly, there are many lower-level languages (I can speak with authority about Lua) doing the job that once only High Level languages would ever be called on to do. Lua interfaces directly with C/C++, and it is fully supported and particularly powerful working in tandem with the Apache killer, Nginx.

These are not the only examples in an era which is progressing to the edge beyond behavioral programming. Event based architecture allowed the evolution of the Reactive paradigm, which is the industry’s word for what I call “behavioral programming” or the precursor to self-aware systems and something that more closely resembles true AI.). To be clear, we are still 2 orders of magnitude away from producing hardware and software that can render any type of true AI. However, we are also pushing on the first of those stages. That push was allowed through Event Based architecture.

What will be next will either require new systems (hardware) or will move forward based on a really poorly performant virtual systems. However, this seems to be more likely the case… and in that case there will be language to serve self-aware objects and the constructs of dynamic functions. All AI will use dynamic functions and programming idioms that neither C, C++, D, Go, or Rust use. One of the chief bottlenecks will be hardware processing of code and language itself, therefore optical systems, laser, and/or radars will be desired- and as I have just said it is likely that a prototype will appear before an entire industry re-tools itself on speculation…

Somewhere between the certainty of a future which is going to happen and what is being discussed here today I really appreciate the efforts to be proactive and replace C. However, I’m not even sure it’s broken, and I would sum it up like Einstein said- you don’t solve the problems of today by following the same logic that got you here to begin with.

Having said that, I like D. And I will learn Go sometime in my career, perhaps some weekend when I’m not doing anything else.

I am not a language guru' but I am a student of the development of social  institutions (and language is one of the oldest human institutions) and an approach that is useful for understanding change in the domain of economics may prove of at least some small value when thinking about the role played by different computer languages and the relationship between them.

Peter Thiel is right: competition is for losers!
http://www.wsj.com/articles/pete...

And these languages are not truly competing with each other.  I really can't imagine (in part for the reasons that Andrei mentions) that in the typical domain of Go there are many users who have an epiphany and think "well, really, this was all a big mistake and we should have written it all in Rust".  And the opposite is also true.  Go, as Rob Pike has said, serves a particular purpose, and that's not the purpose of Rust.  It really wouldn't make sense for Google to have put those developers not long out of school to work writing in a language whose basic design serves very different needs, and is far from simple, or quick to pick up to a level where you can be writing useful code.  Similarly, I doubt anyone at Mozilla had the inclination to write their browser in a language like Go.
D is s little different, because it is more general in purpose.  The language itself is quite suitable for writing for embedded systems and some kinds of system programming (the runtime needs some work for some of these cases because that hasn't been the focus to date, but that's a distinct issue).  But it's also a pretty good replacement for a language like Python in certain cases, and indeed even at a shop like Adroll,  known for its heavy use of Python, D is used by the data scientists because it is productive yet efficient (fast).
In my own domain, which is a particular part of financial markets, I really don't see a real competitor to D for much of what I am doing.  That doesn't mean that I won't also use Python for some things, Lua for others, and in time Go might also make sense.
In his speech that is better known today for the pithy saying that "premature optimisation is the root of all evil", Knuth also welcomed the future proliferation of languages, because language is the expression of thought, and different people naturally think differently, and that's also dependent on the problem domain.  It's fun for a bit to pit languages against each other, but it's a mistake, in my view, to think that this captures the essential nature of this question, because it doesn't.  I think these languages all have a bright future, but that mostly people will use them for different purposes.  C will be around for a long time yet.

Probably none of them could replace C because C is intended for low level interface to hardware and data where you don't know things like data types ahead of time.  So Go! is out because it is a logic based language that does not have the necessary procedural aspects.  D is out because it does not have the low level stuff like bitwise operations, etc.  And Rust is too restrictive, in that it does not let you do things that might seem unsafe to the compiler.  But Rust has the best chance would guess.  All they have to do is add a variety of unsafe labels for circumstances that may be necessary for low level operating systems programming.

The reality is that there is never a reason to come up with a "new" language.

C or C++ are perfectly adequate.

Those who think the memory management is too hard in C or C++ don't have very much imagination.  First of all it is not at all hard to simply do your own house keeping.  A good programmer sets up variables at the beginning of a function, and cleans them up at the end.  Things that have been created are not that hard to delete.  But you don't really have to in C or C++ either.  You can use memory management libraries if you want.  I recall using Lattice C++ with calls like Alloc_Remember() way back in the 1980s.  It is not at all hard to add memory management tools or anything else you might want, to C or C++.

The idea we need a new language is more from people who want to make a name for themselves.

And remember that any web language is out by default.  Web scripting and design has nothing to do with real programming in the general world.  It is very specific and quirky due to the lack of maturity of web browsers.

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.