It's an accident of history and messaging. They were both publicly announced at the same time, and both described themselves as "systems programming languages."
As it turns out, the two languages have entirely different ideas of what "systems programming" means. And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Still, the initial contrast seems to have stuck.
The only real overlap is that both deign to be C successors. But in such different ways that the head-to-head comparisons make little sense.
There's also the perception that they're the only recently-created languages that have gained any real traction. You don't see nearly the ink spilt on Nim or Zig as you do on Rust or Go. So there's maybe some sibling rivalry there. (In this vein, I occasionally see comparisons of Rust vs Swift.)
> And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain.
Back when Rust was announced, it was much more similar to Go than it is now, even having a similar runtime for concurrency. Go did a better job than Rust of delivering this paradigm, largely because the Go implementors weren't relying on commodity technologies like LLVM and libuv.
As time went on, Rust was given more support by Mozilla, and it evolved into something more suited for browser implementation. It had other major influences at this point:
- The constraints of using LLVM. Many projects have failed trying to make LLVM do something that it's bad at doing. At the end of the day, LLVM is good at compiling C++ and things that look like C++, so if you stick to using LLVM and want an efficient language, your language will end up looking more like C++ over time.
- The swell of momentum around C++11. All of a sudden, programming idioms from the "Modern C++" movement were becoming mainstream.
- The halo of academic research into type-safe systems languages. Very few of the ideas in Rust are new, but some type system features from academia became more palatable for ordinary programmers when combined with the C++11 style.
> Back when Rust was announced, it was much more similar to Go than it is now, even having a similar runtime for concurrency. Go did a better job than Rust of delivering this paradigm, largely because the Go implementors weren't relying on commodity technologies like LLVM and libuv.
Or rather because the community decided to move away from this paradigm and towards a much more C-style view of systems programming.
I've heard this about LLVM a lot in the past; does LLVM recognize its C++-centricity as a problem in delivering on its mission of being a multilingual target platform, or has it tacitly changed its mission to be more-or-less implicitly C++-centric? And specifically, what sway does Rust hold on the LLVM project and its goals?
> does LLVM recognize its C++-centricity as a problem in delivering on its mission of being a multilingual target platform, or has it tacitly changed its mission to be more-or-less implicitly C++-centric?
LLVM is a mostly corporate-sponsored open source project. There isn't really a global LLVM roadmap, and developers usually work on things that help their employers.
There has rarely been explicit opposition to features that help other languages, but at the same time it is very difficult to make a large nontrivial change to LLVM at this point. Someone who is not already an active LLVM developer might be overwhelmed and give up on upstreaming their changes. IMO the most successful use of LLVM for a sufficiently non-C++ language has been Azul's work on last-tier JIT compilation using LLVM:
> both described themselves as "systems programming languages."
IIRC Rob Pike later commented that Go should have been advertised more like a "network services programming language" as it is better suited for writing network services than to write low-level components (os kernels, device drivers, embedded programs).
Learning Go and Rust recently, it feels like Go is aiming to be a better Java(GC, excellent libraries, feature rich std library, fast enough but easier on devs) and Rust is aiming to be a safer C.
Zig has a good safety story -- in fact, I think it might turn out to better than Rust's -- but it is very different. A language that uses sound methods to guarantee certain kinds of safety (as Rust does) is not necessarily the best way, and it certainly isn't the only way, to write safe code. The handwavy way to explain that is that a language that soundness comes at a cost, and getting rid of 100% of a certain class of bugs might overall be less safe than an approach that gets rid of, say, 98% of that class and can also help reduce bugs outside that class by similar unsound means. I.e. system safety and memory safety are very much not the same thing (although the former is a subset of the latter), and since the goal is system safety, it is unclear exactly how much it is worth paying to soundly eliminate all memory safety bugs.
I agree with the premise that there are multiple measurements for ‘safety’ and I absolutely do not believe Rust’s chosen method is superior to all others, but I’ve seen you get blow back in other threads for these statements before, so I thought I’d toss in some support of the overarching ideas before the long meeting of response come flying in.
Its weird people don't compare Go to Kotlin. It has channels and coroutines. I think Kotlin does better with contexts and I think flows are a really cool addition. There does seem to be a lot there but honestly, it reminds me a lot of Go in its pick up and play nature
Having used Kotlin, I’m now actively switching to Go. I find it much more enjoyable to write. But this is also highly personal opinion. I feel seriously lost in Kotlin’s documentation. Go is a joy to me.
While there's a lot of truth in this comment, at the same time, the domains are wide enough that there are a lot of similar usages, and teams that decide to use one, the other, or both.
True, but you could say the same of nearly any pair of general-purpose languages. Even Python and C overlap to some non-trivial extent. Go and Rust certainly have overlap, but I'm not sure I'd agree that they have an unusually high level of overlap.
I think the closest language to Rust in niche is, by far, C++. I'm surprised to see it compared less often to that than to Go.
I think the reason that C++ and Rust are compared less often is because the advantages and disadvantages of each are clearer. Rust has better memory safety and concurrency, is less focused on backwards compatibility and so doesn't bring a lot of cruft along, and so on. Of course, its ecosystem is far less mature and there are situations where backwards compatibility is paramount.
The advantages and disadvantages of the two may be clearer, but Rust is clearly most similar to C++ from a complexity and usage domain view. I don’t see why this is not the only discussion on ‘Rust vs’. The same arguments against C++ being compared to C are almost directly applicable to arguments comparing Rust to C, and the same goes when comparing against higher level languages. I get that Rust has its borrowing/ownership semantics and a ML inspired type system, but Rust and C++ are more readily comparable than almost any other languages in general usage.
I'd say it's in part because Go originated at Google and Rust originated at Mozilla. Two browser vendors announcing new languages at the height of the browser wars caused the languages to attract the same tribalism.
I don't think the tribalism is even really in the language communities themselves as much as it is among onlookers, casual users, or otherwise fans of either language. (Note that there is certainly plenty of enthusiasm for each language in its respective community).
Rust in particular seems to have a large following of people who aspire to use it but haven't really learned it or used it in anger (this especially used to be the case). Basically they (like me) appreciate the ideas of strong static guarantees, strong performance characteristics, and the general aesthetic of Rust code compared to other high-performance languages or other "functional languages".
But those people (and to a lesser extent, many in the Rust community proper) tend to believe that Rust is optimal for those use cases that are conventionally considered to be Go's purview, which is to say they believe Rust is more productive than Go, Python, Ruby, Java, etc for the sorts of applications that those languages are regularly used for (SaaS application backends and other network services). They argue that you just need a little more experience with Rust and you will hit some productivity nirvana; however, each year, I (and many others with experience in this domain) get another year of experience with Rust (as a hobbyist--not full-time development) and still I'm far more productive in Python and Go than I am with Rust.
And I don't think the "just need a little more experience" argument holds water. It's based on the idea that the borrow checker and memory management in general become progressively more natural. Well, I have a decade of C and C++ experience and manual memory management is very natural (almost said "super natural") to me, and the trend is asymptotic--with more experience you do indeed get better with the borrow checker and memory management, but it never quite reaches the point where it's in the same ballpark as a garbage collector (where you truly don't need to think about memory management outside of hot spots).
Of course, GC languages also don't help you deal with race conditions, but 99% of the code we write in these domains isn't subject to race conditions (and if you are writing something that is pervasively subject to race conditions, it might well be worth considering Rust).
Note that there are a handful of very smart, well-respected (and deservedly so) people who also have lots of experience with Rust and who are familiar with the domain in question who disagree with me. I think theirs is the niche opinion, but I think it's worth hearing them out and forming your own opinion.
I agree; however, a point of clarification: If you model the resource as an object then the ownership system precludes concurrent use of that resource within the process (the ownership analog for RAII). However, if you have multiple processes attempting to access the same resource, then no, of course those static guarantees don't help, and (perhaps to your implicit point) this multihost/multiprocess model is the more common case in saas applications.
Rust and Swift though do have a very close relationship IMHO. They have similar design decisions for ergonomics, and often borrow (no pun intended) from each other.
As it turns out, the two languages have entirely different ideas of what "systems programming" means. And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Still, the initial contrast seems to have stuck.
The only real overlap is that both deign to be C successors. But in such different ways that the head-to-head comparisons make little sense.
There's also the perception that they're the only recently-created languages that have gained any real traction. You don't see nearly the ink spilt on Nim or Zig as you do on Rust or Go. So there's maybe some sibling rivalry there. (In this vein, I occasionally see comparisons of Rust vs Swift.)