In brief, all three of Go, Rust and D are designed to replace C++.
Go is built around concurrency, so applications you write are almost instantly parallelisable. It uses a simple garbage collector, to make it easier to program. It was developed at Google, with none other than Rob Pike being involved. http://golang.org/doc/faq.
Rust is designed to help prevent memory leaks, while still enabling manual memory management. https://github.com/mozilla/rust/wiki/Doc-language-FAQ. It was written by mozilla, because using C++ for a web browser leaves quite a few memory leaks. Mozilla are also building a prototype browser engine in Rust, called Servo, http://www.mozilla.org/en-US/research/projects/#servo. Although its future is still quite uncertain at this point.
I haven't had too much contact with D, but from what I understand, it's designed to be C++ done right, while keeping compatibility with many parts of C. http://dlang.org/overview.html
> Rust is designed to help prevent memory leaks, while still enabling manual memory management. https://github.com/mozilla/rust/wiki/Doc-language-FAQ. It was written by mozilla, because using C++ for a web browser leaves quite a few memory leaks.
Nit: It's not just memory leaks, it's memory safety in general. Leaks are actually somewhat less of a problem than issues like use-after-free, because leaks are usually not exploitable, but use-after-free can easily lead to exploitable security vulnerabilities (for example, the one that brought down Chrome a couple of days ago).
In general, only Rust is designed to allow totally memory-safe usage without a garbage collector.
Google has been steadily moving away from "Go is a C++ replacement" (because it's not) and toward "Go is a Python/Ruby replacement." (which fits it _much_ better)
Also, you're descriptions of Go and D are great, but I'd say that Rust is more "Concurrency of Erlang, speed of C++, type safety of ML/Haskell".
> Google has been steadily moving away from "Go is a C++ replacement" (because it's not) and toward "Go is a Python/Ruby replacement." (which fits it _much_ better)
I don't see that Go is particularly good general replacement for C++ or Python/Ruby, it seems more of a good tool for the place where Python or Ruby's performance characteristics and less well developed support for concurrency/parallelism make them unattractive, but at the same time the relative heaviness and complexity of C++ makes it unattractive, and so neither seems to be the right choice.
I think we're in violent agreement. I think people have been building stuff in Python/Ruby, and are seeing some of the drawbacks, and realize they're bigger than they thought.
Dart has a broadly similar server side role to Go (the approach is very different) in that it falls between C++ and currently popular dynamic languages, plus it has a client-side role where it aims to be a better JS.
Obviously on the server side it overlaps with Go, but Google has the resources to do multiple efforts in parallel in areas they think are important to find what works best with real world experience.
Its a replacement for Java. C++ is still suited for situations where GC is impossible, Python/Ruby are still suitable for quick scripting. I think Go aims for everything in between.
I quite agree with that. Java & Go have a close typing system (static but not very elaborate, and java < 5 was lacking generics just like go), share a close philosophy (a simple language with no tricky corner, safer memory management, designed for programming in the large), have built-in concurrency mechanisms, and are even quite close when it comes to raw performance.
The history of many of the languages has been the same in regards to generics. C++ didn't have them, then templates where added. C# 1 didn't have them, but were quickly added (correctly) in 2. D didn't have them, later they were added. It is very common for a new language to avoid generics in the beginning, but it seems most come to agree, it was a mistake.
For some use cases that would matter, but for a lot of C++ use-cases, no GC isn't really fundamental. Large codebases increasingly use the "C++ GC", aka RAII with std::shared_ptr, as the de-facto-standard way of managing memory. For those kinds of applications, how D's GC compares then just becomes a matter of performance tradeoffs between different GC implementations, not a matter of GC vs. no-GC.
Absolutely. GCs have been improving a lot over recent years, and there's lots of software that's written in C++ that doesn't have to be.
You can write D without any GC at all, though: you lose a lot of the standard library at present, but I've done it. It's not possible, in my understanding, to turn the GC off in Go.
> Large codebases increasingly use the "C++ GC", aka RAII with std::shared_ptr, as the de-facto-standard way of managing memory.
Which large codebases? This is definitely not true for any of the browser engines (Gecko being the smallest at 6M LOC, and going up from there) for example.
WebKit makes relatively heavy use of reference counted objects, though a custom reference counting implementation is used rather than std::shared_ptr. That said, there has been an increasing emphasis on preferring unique ownership to shared ownership of objects where possible.
I'm a little confused by your throwaway comment about Gecko being the smallest browser engine though. WebKit weighs in at less than 3 million lines of code, much smaller than the size you quote for Gecko.
Yeah, I was thinking Chromium when I wrote that and should have been more specific. 6M is all of Firefox.
And Gecko uses reference counting a lot too, of course... but most objects are stack allocated or uniquely owned. It's a very different situation from a language in which all objects are reference counted.
From what I've read, google is using Go to replace many of their C++ systems. While it may have been developed independently, I still consider this enough rationale to be a "C++ replacement". Of course, C++ currently occupies so many different roles, that the term "C++ replacement" is not very specific. I appreciate your point though, it has many more properties in common with python/ruby.
Absolutely: there are many programs which _were_ being written in C++ which didn't necessarily have to, and Go does have a place there. What I mean is that where C++ is a _requirement_, not a preference, Go won't make inroads.
If rust is that, and I suspect you may be right, I'll be putting some serious time into it. pcwalton, could you comment on whether or not you also feel this accurately describes rust?
