Which language has the brightest future for replacing C: D, Go, Rust?

Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs. To a lesser extent it may compete with Java JVM. (However at this point in time, the JVM GC technology is still far ahead of Go's GC.) If one is writing a networkish service such as REST API endpoint, Golang's combination of language featurs & quality libraries (http) is positioned very well for that. Go isn't suited for system drivers or tight loops that depend on controlling exact memory layouts. I've heard several times to think of Golang as a "DSL for networking apps" and I think it's the best succinct soundbite for that language.

That leaves D-minus-the-gc and Rust which Andrei Alexandrescu provided very reasonable analysis. I don't think either will replace C. In 1995, many predicted that Java would supplant C++ and that never happened. For the performance domains that C++ was good at (e.g. AAA games, commercial software like AutoCAD and MS Office), it became even more entrenched. In terms of being forced to make bets, I'd say Rust has a better chance than D because Rust has the momentum behind it that D never had.

Yes, C++ is old, but it has really stayed with the times in an impressive way. The so-called "Modern C++" that started with C++11 is a significantly different way of writing C++. All the things that made C++ infamously challenging and allowed inexperienced developers to leak memory and cause crashes, are, for the most part, no longer in the normal C++ workflow.

And all the rage about functional programming, passing around functions as values, writing closures that capture and encapsulate their surrounding values, using map, filter, reduce algorithms, relying on type inference, forgetting about pointer deletion and manual memory management and avoiding the access out of bounds memory on iterations -- that is all normal C++ now.

If anything has or will successfully replace C++, it is going to be C++ itself. The standards committee and community are doing an extraordinary job of keeping the language current while maintaining its great reputation for speed.

I disagree with Alexanders (regular) narrative that Rust puts a lot of estate into safe memory handling. Rusts memory management features may seem daunting at first, but they make advanced things (like type-system assisted data sharing) a breeze. So, while the whole "let's talk about data"-aspect of the language _does_ take a lot of estate, it goes far beyond "let's talk about memory".

I agree though that this is a property that comes rather late in learning the language and we still struggle to communicate that easily.

Long live C!

With C and even Objective-C, I have to plan everything out, and finely craft the code. It's meant to be closely examined and optimized and perfected. That's what makes it rock-solid in my experience.

I don't have type-related or buffer or memory related issues since its part of developing in the language. Things like Heartbleed are interesting, because obviously the guy was overworked and didn't spend enough time with the code before checking it in.

I view those types of issues as 'check-in irresponsibility' and it can occur with any language, not just C. My answer would be 'None of the above'.

But the biggest question is not replacement but interoperability. Can I call Rust code from Go? Can I call Go from Rust?

I mean most simple things are easy to read. But once in a while you stumble around code that nobody will understand if not every single character is well documented.

Still somehow I love it.

D is what C++ should have been. It had some traction in mid-2000s but the Tango vs. Phobos debacle killed it.

Go is the most serious of the three languages mentioned. It has the momentum, solid community, solid tooling, and corporate backing. It's well suited for networked services, but it is not replacement for C.

I'm not so sure about Rust. Unlike D and Go, Rust can replace C (in theory), but I don't think that will happen. Rust has a feel of a hobbyist language in perpetual alpha.

Go and Rust in particular have been designed with very specific clients in mind (replacing Google's use of Python for server-side work and safety-paranoid multi-threading for Mozilla's Servo, respectively).

Rust is the only new language mentioned that resembles C in its capabilities but then again: C++ resembles C in (theoretical) capabilities but never de-throned C (mostly because when you use C++ like C, you might as well use C).

That could not have been more graphically enlightening.

However C is often used for writing libraries that can be used for many languages. Think about OpenSSL e.g. I doubt C was chosen due to its credentials as a secure language. Rather this is a liability for C/C++ in many areas.

I think Rust will replace this. Actually I think Swift will be fighting with Rust over some of the the same territory. They both got the same advantage of not requiring a garbage collector and thus can be used to write libraries to be used by any language through a C-API.

While Rust might have an edge language wise, Swift might be just good enough. That matters because we are using C/C++ not so much due to the quality of those languages but due to a combination of their feature set and existing momentum.

Swift is more or less guaranteed to get big as it is replacing Objective-C for iOS development rapidly. That will create a large user base for it quickly. This will only accelerate when Swift goes open source and can be used on more platforms.

Both D and Rust have a bit of a chicken and egg problem. People aren't going to use those languages if people don't believe they have a future. They wont have a future if people don't believe they have a future. Rust is novel and cool enough in a geek perspective that I think it will gain enough momentum to get some presence. D has been around for a long time without that happening so there is no reason to believe it will happen now.

Swift has the chicken and egg problem solved. For writing something like OpenSSL it would take away many potential problems. No accidentally not executed code due to not using curly braces for if statements. No exploitable buffer or integer overflows. No accidentally uninitialized variables. No accidental switch-case fall through. No unintentional type conversions. A whole host of memory bugs gone.

By using source-to-source compilers, C is a good target language.

From this standpoint, we can treat C as a "cross-architecture assembly platform".

Simplicity is beautiful!

1) What is the ecosystem now? If it is not good, does it look like it will improve in next X time or so?

   1.1) What are the production ready libraries right now?
   1.2) Who are the maintainers? Who is backing them?
   1.3) How approachable is the community? 
   1.4) Are the current pain points are being worked at and at appropriate speed?
   1.5) How is the tooling scene?

3) How hard/easy it is to wrap C/C++ code/libs if we ever need? Will there be any performance impact?

4) Does it look like more CPU bound code will be added looking at the product roadmap?

We are a python shop. As long as it was network IO centric we were ok. However due addition of features, the CPU bound code has increased and we clearly see the limitations of Python. This has led to find the replacement language. Since we are reviewing now the 'X time' in #1 is '1 year'. For others the tolerance may vary.

As for #2: Code review has an additional overhead due to Python's dynamic nature. Also we need to write additional unit testcases. A language which "prevents" basic issues (not going into 'how') has less overhead on the team.

#3: From what I know, go does not do well here in terms of performance. We deal with lot of 3rd party APIs e.g using VMware APIs which are in C and are called in the main loop. Also evaluation of this point helps us to see if any shortcoming in the current libraries can be augmented by wrapping existing C/C++ libs. Rust & D are better I suppose.

refactorability: GC'ed languages inherently has an advantage (for large codebases). Counter examples welcome.

learnability: Rust suffers here most. This is a point which makes it hard for Rust to get introduced and even though I may have patience to stick with it others may not and drives down the adoption. On most occasions, other teams also need to be convinced for any meaningful transition.

Testability (i.e. unit tests): Python is really good at this. This is not a point for the testing tools but more for language features. I find dependency injection in Rust really hardest right now (or may be I might have missed something)

#4 is true in our case.

#1 (libraries/tools): Go is ahead I think in terms of production ready libs.

#1 (community aspect): Go & Rust are better here than D (right now) even though the founder of D is prolific. Note that when championing a language inside a company is concerned perceptions matter a lot. Here I think D suffers a bit in my case.

Right now I am in wait-and-watch mode but leaning towards Rust.

(edited: formatting issues)

Go kinda is already, but is too sucky on too many levels to really break through.

Rust is still alpha and seems to be going backwards at times, but looks like a strong contender.

Assuming Go fixes its many problems, and Rust is eventually delivered, I think they will both have a strong role to play, Go in the networking/systems space, Rust in the large scale app development space (like making a browser).

But C will still be around.