I always thought it was because both languages were (at least at some point) referred to and advertised as 'systems languages', which naturally invited comparisons. However, 'systems' meant different things for each language.
For Go, 'systems' as in the sense of software running on servers providing services to user applications.
For Rust, 'systems' as in the sense of (http://en.wikipedia.org/wiki/System_programming_language) - software such as OSes, device drivers, etc.
Just for fun, Swift is advertised as a systems language as well. In its defense, it does have facilities for bypassing the preferred way of managing memory (ARC) and working with memory directly.
This has indeed encouraged much comparison: there is simply a large overlap in the communities that may be inclined to use either. There was a discussion between the authors of C++, Rust, D, and Go in which the topic of what a "systems programming language" even is is brought into question. Rob Pike, speaking on Go's behalf, mentioned that while "systems programming" was originally advertised as a goal of Go, it has since been dropped from the list, due to the expectations that others have when they read that compared to the intent of the drivers of the language. Here's a video of that talk, if you're curious:
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...
Funny, according to Alexandrescu's definition it is a "systems programming language", after all. Go's memory allocator, garbage collector and runtime are written in Go itself.
Re:Thoughts on replacement languages
by FeeTinesAMady on Saturday January 10, 2015 @07:45PM
(#8868580)
I think that if Python can be considered a "systems" language according to somebody's definition, that definition is pretty flawed.
The point is that what constitutes a "system" is not well defined and/or there are multiple conflicting definitions. I was sad to see rust billing itself as a systems language so prominently, given that it doesn't really mean anything.
It's a simple term that, in Rust's case, encompasses all of "bare metal; zero-cost abstractions; no runtime; all language primitives map to simple hardware instructions". I don't see any better word for it. Do you?
That sounds like most of what people mean when they say a low level language, though I admit that the term comes with its own baggage about the simplicity of the language (which doesn't apply to rust).
I guess I think the sentence you wrote above is just a lot more clear than calling it a systems language and hoping people know what you mean.
The two are most compared in communities with a lot webdevs because the last couple of years is when webdevs have started rebounding from the statically typed == bureaucratic enterprise factory bean meme, and will suddenly entertain static types. Then, newly released languages are attractive for the get-in-on-the-ground-floor factor.
They are compared by pretty much anyone that has found both to be significant or interesting. People often compare it to C++ because of the theoretical performance capabilities being similar. People often compare it to Go because Go is a simple, popular reference that many people understand, and hence can be compared against in a way that is meaningful to a lot of people. There are a lot of similarities, as well as a lot of differences, making for lively conversations filled with tangents on various preferences and experiences. In short, you can have a good conversation when making such comparisons. You can compare it against tomatoes, too, but the shared ground isn't huge, and analogies must be far more complex to derive meaning, and the participants need far deeper mental stacks to make ANY progress that relates to the original intent when the tangents veer far from the domain of programming language implementation or usage.
They are compared because as humans, we are much better at learning new things when contrasted to other things that we are aware of. A concept that has absolutely no parallels with a previously encountered one is much more difficult to understand. From this perspective, it is actually quite useful to compare these two things.
The Go runtime provides GC, its own scheduler, time abstractions -- basically everything a JVM is required to do (plus the scheduler)[1]. It's an AOT-compiled Java. Because of its high-abstraction runtime, interoperation with native libraries is hard to nearly impossible (depending on the direction). It is to be used to write server-side applications. It's Java without the JVM, for better or worse (native binary, short startup, but no dynamic code swapping, no multiple languages support, no instrumentation, no JIT, and no deep monitoring)
Rust, on the other hand, is a modern C/C++ replacement. It is meant to be used anywhere C or C++ are used. It can be used to write applications, device drivers, operating systems, or fully native libraries (that can be called from Java, Go, Python or Fortran).
Neither approach is better than the other, but the two are so different that they can't even be compared directly. One is Java minus the JVM, and the other is a C/C++ replacement.
[1]: GC (or rather the illusion of infinite memory), abstracting OS time plus some other OS abstractions -- all provided by Go but but not Rust), are the only things required from a JVM. Runtime bytecode interpretation or JIT -- what most people usually associate with JVMs -- are actually not required; some JVMs, particularly those for hard realtime and safety critical code, perform AOT compilation.