> First, please don't compare Go and Rust. They are completely different languages with completely different target use cases.
Then why does everyone insist on comparing Rust and C++? Objectively Rust is much closer to Go than to C++.
That's just dumb. Rust and Go were, in fact, contemporarily designed to similar constraints and with similar goals. That they made significantly different design choices is an interesting point that should be discussed and not swept under the rug just to win internet points.
At the language level, Rust is substantially more similar to C++ than it is to Go. C++ and Rust both have many properties (lack of GC, pervasive stack allocation [even for closures], move semantics, overhead-free C FFI compatibility) that many other languages lack, and the Rust developers actively work to match C++ on features. None of this is true for Go; Rust's similarities with Go are shared by many other languages as well, many of which are much more widely used than either (hence would probably represent a more informative comparison; e.g. I think posts contrasting Rust and Java would be quite useful, but I have seen very few of them). As such, Go and Rust comparisons tend not to be very illuminating.
>
At the language level, Rust is substantially more similar to C++ than it is to Go. C++ and Rust both have many properties (lack of GC, pervasive stack allocation [even for closures], move semantics, overhead-free C FFI compatibility) that many other languages lack, and the Rust developers actively work to match C++ on features.
I think this is absolutely true, for what it's worth.
The Rust on Rosetta code is exceedingly old. There's a community project to update the examples, but they're waiting until 1.0 to move upstream, so as not to cause them too much churn.
Rust is very similar to modern C++, just without backwards compatibility considerations, and with the (fantastic, IMO) additions of compiler-enforced ownership rules and generics instead of templates, which makes certain type checking work better.
What objective criteria are you using by which Rust is much closer to Go? Go being garbage collected and Rust/C++ not being seems like a much larger gap than anything between Rust and C++.
A managed heap; emphasis on the use of functional constructs; rejection of lots of previously-thought-to-be-essential OOP features; built-in concurrency based on a rejection of the traditional primitives; general de-emphasis of metaprogramming constructs like templates and macros; broad design emphasis on preventing common programming mistakes.
You're saying, I think, that the Go implementation and runtime looks more similar to Java and that C and Rust are clearly in the same family (in the sense of being only losely coupled to a runtime environment). That's the way a language implementer might look at the question, I guess. It's certainly not the only one.
I'm not sure what you mean by this, but when I hear "managed heap" I think of heap memory managed by a garbage collector. This is not a feature of Rust.
> emphasis on the use of functional constructs
Rob Pike wrote (unavoidably, because of the lack of generics) crippled versions of map and reduce for Go and declared that the almightly for loop was superior. I don't think an emphasis on the use of functional constructs follows from this.
> rejection of lots of previously-thought-to-be-essential OOP features
Yep, this is an important similarity between Go and Rust. Rust brings traits, which are (extremely) similar to Haskell's typeclasses, into the mix as well.
> built-in concurrency based on a rejection of the traditional primitives
Sure, but the differences between the languages is crucial here: Go builds safe(ish) concurrency primitives into the language; Rust does not, but provides language features powerful enough to build memory-safe concurrency primitives in the standard library. And, perhaps surprisingly, mutexen and the like are actually encouraged precisely because Rust can make them safer.
> general de-emphasis of metaprogramming constructs like templates and macros
I don't agree that Rust de-emphasizes these. Generic programming is strongly encouraged, and indeed Rust's generics are implemented very similarly to C++ templates. Rust also strongly encourages the use of macros for cleaning up repetitive blocks of code, both inside of and outside of function bodies. And very powerful metaprogramming is on the way (already available in nightlies) in the form of compiler plugins, which allow arbitrary code execution at compile time.
> broad design emphasis on preventing common programming mistakes.
I think this is a feature, or at least an intended one, of every higher-level programming language :-)
On the rejection-of-OOP thing; I agree that seems like the biggest similarity between Go and Rust, but even then, the major replacements for those features are completely different – Rust's traits are more like typeclasses and C++ templates (to some extent) than they are to Go's interfaces (though "trait objects" are like interfaces, but used less often). It also seems like Rust will eventually add some form of more traditional OOP features like inheritance, because the servo project would like such things to implement the DOM (and I think others are also interested for different reasons), which I doubt Go will ever do.
> It also seems like Rust will eventually add some form of more traditional OOP features like inheritance, because the servo project would like such things to implement the DOM
There's been a great community and core team effort to design small, orthogonal language features (or extensions to existing features) that can be used to regain the performance + code reuse benefits one gets from using inheritance, without all the associated warts. The DOM/Servo problem is a tough one and it's going to be very interesting to see if Rust can solve it without resorting to the blunt instrument of inheritance.
Yeah I've followed the evolution of that discussion with interest (or I did until a few months ago, so I'm likely out of date), and came to the, perhaps incorrect, conclusions that it is likely there will be some solution added at some point, and it is likely to share some trade-offs with inheritance.
Then why does everyone insist on comparing Rust and C++? Objectively Rust is much closer to Go than to C++.
That's just dumb. Rust and Go were, in fact, contemporarily designed to similar constraints and with similar goals. That they made significantly different design choices is an interesting point that should be discussed and not swept under the rug just to win internet points.