

Ask HN: Is Go to C as Rust is to C++? - bsg75

From http:&#x2F;&#x2F;www.drdobbs.com&#x2F;open-source&#x2F;why-not-go&#x2F;240005062<p>While the article is about Go, it makes this comparison:<p>&quot;While many languages—notably D, Rust, and Vala—aim to simplify C++ and add specific features, they all feel to me like “C++ with better features.”&quot;<p>Given that Go and Rust are often compared, is there a distinction that Golang more comparable to C and Rust to C++ ?
======
catnaroek
To a certain extent, the analogy is fair:

Go's design is much simpler (in the sense of "bare bones") than Rust's, just
like C's design is much simpler than C++'s. But this comes at the price of
leaving many common, repetitive development tasks as "exercises to the
[reader] programmer", such as resource management. Now, I am aware that
memory, being plentiful these days, can be managed using a garbage collector.
But, for any resource not called memory, you are on your own. Also, Go's
shared memory model, while flexible by default, is also quite messy by
default. Managing the mess is, again, left as an exercise to the programmer.

Rust's design is much closer to the C++ philosophy that the language must do
as much as possible for the programmer. But what sets Rust apart from all the
other wannabe C++ replacements is that Rust also incorporates the idea (taken
from the Haskell/ML world) that one of the most useful things a language can
do for the programmer is provide tools for ruling out huge classes of bugs.
Thus you get a strong type system that provides support for parametric
polymorphism (generics), ad-hoc polymorphism (traits), guaranteed-correct
resource management (the pointer system) and mutability control.

Finally, I would like to improve on your analogy: Go is to C/Python as Rust is
to C++/Haskell. Go is for the hacker type who wants to write his program as a
sequence of instructions and call it a day. Rust is for a more refined type of
programmer, the kind that is aware that his brain alone is not powerful enough
to reason about the correctness of a big program, and thus prefers to use
tools to automate reasoning about the boring repetitive parts, freeing his
brain for reasoning about the actually hard parts of his program.

