3 ms·
Ask HN: Is Go to C as Rust is to C++?
From http://www.drdobbs.com/open-source/why-not-go/240005062
While the article is about Go, it makes this comparison:
"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.”"
Given that Go and Rust are often compared, is there a distinction that Golang more comparable to C and Rust to C++ ?
- catnaroek 13y agoTo 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.