Go was originally designed as C++ replacement to be used at Google but its lack important C++ features lead to little interest from C++ programmers. Pike found much more interest from Ruby/Python programmers.
And Rust is different, since it does incorporate the features that current C++ programmers need (such as GC-free memory management and generics). So I don't see how that refutes the comment you replied to.
I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this.
While apple and oranges is an appropriate metaphor for the approach that the two languages take, Go and Rust are vastly different, their goal of being systems programming languages is not.
The point of objecting to the comparison is that there are lots of important aspects of Rust's design that Go's design doesn't account for, and many C++ developers (for example, me) depend on those. (In my case, those are memory safety in parallel mode, GC freedom, data race freedom, fast interop with C code, and zero-overhead generics.) The languages have wildly different designs. So saying "Go is going to beat Rust" like the OP did is pointless cheerleading, and the "apples to oranges" comment is correct to point that out.
A useful thought experiment is: If Rust completely failed to garner any mindshare, could I switch to Go for the project I work on (Servo)? The answer is no: Go's design goals are totally incompatible with the project. C++ would be more appropriate than Go (though it would mean sacrificing many of Rust's advantages, of course). That's why I, and the Rust community as a whole, tend to dislike the comparison. Go is a fantastic language that works really well for lots of use cases, but a C++ replacement for all niches needs a lot of things that Go doesn't have. And this isn't a knock against Go: as I said, Go is a great language for lots of things that could also be written in C++.
> I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this.
I was following Go from the start, and I am aware of this fact. What I was pointing out is that they backed out of this claim eventually (event regretting using the term "systems programming language").
Let me amend that: Go was a replacement for C++ in a context where C++ was considered unfit and unsafe. Therein - I believe - lies the source of the misconception: Go was made to fill a gap that people tried to fill with various languages they had at hand due to lack of a fitting language. It just so happens that C++ was the one used by Google in that case.
IOW, Rust aims to be a C++ replacement while Go aims to be something that didn't really exist previously (at least not at this scale or in its entirety).
That is an excellent comment. I wish I could give you a prize, but all I have right now is a banana. Every time somebody mentions the "C++ replacement" aspect, people freak out because you can't use Go to write Unreal Engine 6 in it.
There was a talk/video somewhere where Pike/Griesemer explained how it all started. They were waiting for some gigantic C++ project to compile on their compile farm and every compile took hours. So during one of these down times, they started shooting ideas back and forth of how to speed up compilation. Then they figured out it's easier to start a new language with simple parsing rules than to fix the mess that is C++ grammar.
That's really it - it started with a pain point about C++ compilation speed, not C++ performance.
I have mixed feelings about this. In one sense, it's actually pretty true that no new language has really been developed with compilation speed as its primary focus for ages. So in that sense I applaud Go for its dedication to that purpose. On the other hand, a language devoted largely to compile speed (and that's really the one unifying principle I've seen in Go's feature set, since I view "simplicity" as essentially arbitrary in a formal sense) might be a cool research language, but I wish Go did make a few concessions for the sake of productivity. There are some really fast ahead-of-time compiling variants of ML, like Poly/ML, and in the spirit of pragmatism I think Go could have settled for "fast enough" compilation instead and used well-known techniques like type erasure to basically get 'interface{} but with static checking' generics.
I would agree with the statement that Go was intended to be used in situations where C++ was not necessary but I think Java or C# would have easily sufficed for these problems.
The problem is that both Java and C# are controlled by Google's competitors (Oracle and Microsoft) which is why Go probably got the green light from management.
http://commandcenter.blogspot.it/2012/06/less-is-exponential...