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.
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:
* https://github.com/tav/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!