At least for me: the major difference between the two [implementation wise] is currently the core and standard libraries.
Go may not have the most efficient stdlib, but it covers _such a wide breadth_ of features, and the code is all very readable, well documented, and idiomatic. This is my current pain point in Rust, however I'm confident it will get better with time, and the language itself is _really_ exciting to me.
The two can certainly coexist, they're not exactly sharing the same space IMO. Most importantly, Rust seems to have a much more complex type system, in addition to some very interesting concepts on memory management. Go on the other hand is pretty tightly coupled to its garbage collector, and while it is slowly improving, the current collector leaves a lot to be desired.
Go is great for writing "programs in the large", things like highly scalable servers; it also has a huge focus on concurrency with goroutines [functions multiplexed onto threads by the runtime for concurrent execution] and channels [ability to share data amongst routines in a typesafe way]. In a lot of ways its like a statically typed, compiled Python, rather than a C/C++/"systems" language. The language feels very "light" and it's a very readable language.
Rust seems to be a much more modern, more orthogonal, more comprehensible "C/C++"/systems programming alternative.
While there is definitely some overlap, I don't think the two languages are really targeting the same niche, and there is certainly room for both of them to continue evolving.
Rust and Go may be superficially similar, but they are night and day semantically. They're also aimed at different niches and have wildly different goals. So though it may be tempting to compare the two, it's not an especially productive exercise. :) This town is more than big enough for the two of them.
It seems to me that any answer that stated specifically what those different niches and wildly different goals actually were would be a more productive exercise.
If there's room for more than one of them in this town, in which part of town would each reside?
[Disclaimer: I've written only a tiny amount of Rust code, and no real Go code. I work for Mozilla but not on the Rust team.]
From what I've seen Go is designed with emphasis on ease of programming, performance, and concurrency; Rust is designed with emphasis on safety, performance, and concurrency. (Of course these are broad generalizations, and neither language is limited to only these concerns.)
Go is a simpler language in various ways. Rust provides more control over things like memory management but at the cost of some added complexity (e.g. multiple pointer types). Rust provides some abstraction/expressivity features that Go lacks (like parametric/generic types, macros, and algebraic datatypes), again at the cost of some added complexity. Rust makes more static safety guarantees (for example, no null or "nil" pointers). While the compiler provides many of these guarantees without creating extra work for the programmer, sometimes you do have to structure or annotate your code in a particular way so the compiler can prove its safety.
Of course the two languages are also similar in many ways. For example their syntaxes are in the C family; they compile to native code; they provide CSP-style concurrency; they have some amount of local type inference; and they do not use inheritance as the main style of composition.
Rust's safety features should make it ideal for writing security- or stability-critical code. Go's simplicity probably makes it faster to learn and better for rapid development, especially for programmers used to dynamic languages like Python or JavaScript. Rust's expressive power might provide more options for abstracting common patterns out of large codebases, or to provide libraries that extend the language in different ways (e.g. using macros). Go is more mature than Rust at the moment and has more libraries and a larger community. Rust has first-class support for code that does not use garbage collection, which can make it more suitable for certain types of systems programming.
I love both. If you are writing a production app today, I would strongly recommend Go. However, if you want to write an app that you want to take over the world with in a year or so, I would strongly recommend coding it in Rust.
Go is a beautifully minimal language and very easy to learn. Rust isn't quite as productive, but it won't be too foreign for most coders either — unlike the Erlangs and Haskells of this world. And whilst I've never missed generics in Go, I've already found them useful in Rust.
Rust's memory model takes a bit of time to understand, but it provides a lot more power and flexibility than Go is ever likely to. To get the same kind of fine-grained memory management in Go, you have to manually allocate and manage []byte slices. Not only does this get tedious, but you end up losing most of the benefits of static typing as well.
Rust is also exciting due to the lower-level nature of tasks (the unit of concurrency in Rust). Goroutines are awesome, but you are at the mercy of Go's runtime/scheduler. In Rust, the potential is there to even do interesting things like dynamically load new tasks at runtime — opening up possibilities like Erlang's hot swapping so that code can be changed without ever stopping the system.
However, despite the awesomeness of the language, Rust suffers from a terrible standard library at the moment. Even when Go was first released in 2009, it had a really impressive standard library. And, today, thanks to having superstar hackers like agl and bradfitz on its team, Go has some of the highest quality libraries around — especially in crypto, networking, http, etc. In comparison, Rust's standard library is rather poor with little attention having been paid to API design.
Rust also suffers in comparison to Go with regards tooling support. The 'go' command-line tool is awesome. I've not had a single dispute over style guides due to 'go fmt' and 'go doc'. The 'go fix' command really helped in auto-updating my Go code as the language evolved. The 'go build' tool saves me from having to write build scripts and Makefiles. And Go's (non-existent) package management system is absolutely brilliant — just 'go get github.com/user/repo'!
But, neither problems — quality of the standard library or tooling — are intractable in Rust. In fact, now that the language is starting to stabilise, I am highly confident that a lot of love and attention will be given to both of those issues. This is also an area where we, the community, can also help out a lot. Myself, I've slowly started working on a port of the 'go' tool called rusty:
And, having found the Rust developer community to be extremely friendly on #rust on irc.mozilla.org, I'm pretty sure they would be happy to have other interesting hackers join in too!
Thanks, that's very helpful, and good comments about the standard library. Tons of library support is what accounts for the "stickiness" of Java in the enterprise domain.
great summary :) You're absolutely right about the stdlibs, Go has a great library, which you quickly start missing when you're using Rust which otherwise is a great language. I'm looking forward to what I think is the next stage for Rust, the stdlibs.
