I encourage everyone in this thread to not take things personally. Rust vs. Go conversations are going to cause a lot of angst on both sides. I also encourage people not to assume or read into comments, where someone states that "Rust is not a play thing", they are not implying that Go is.

For some people who've spent the time with it, Rust is a godsend, but that does not mean that by believing so they implicitly hate Go in anyway.

Go clearly has a lot of people who love it as much as people who love Rust, and because they overlap, there will constantly be a conversation of which language to pick for cases where it looks like both could be used. As such, the learning curve for Rust will always be an impediment, to its adoption, which is sad, b/c in all my experience it's the only language that I've used which inherently answers every core issue or fundamental bug that I've encountered in my career. This is why I'm really excited that the Rust core development team has decided to focus on development experience heavily this year.

I did not mean to imply that Go is a toy language. The Go developers are very smart engineers and they made a great language. Sorry if it came across that way. I was more making a point about putting some effort into learning Rust. I did not mention Go anywhere in my comment but I understand why people thought I intended to slight Go. I didn't.

Adding a quick opinion here: I worked for one of these companies (working with libraries written by all of these) and it's just a matter of personal taste. Docker, CoreOS, Hashicorp, etc. are "successful" (which is hard to confirm for now) because they can gather a lot of open source contributions thanks to the easy Go learning curve. I don't think this would be the case if they used Rust instead. Go is definitely not a play toy and you can build scalable and reliable software with it. The problem with Go in my opinion is also its ease of use, it's incredibly easy to write sloppy/buggy code with panics/data races that become increasingly hard to debug. I've had my fair share of frustrating experiences debugging concurrent code with hundreds of goroutines or investigating random data races on complex distributed systems code. I've yet to see that happening with Rust after four months of using it, the compiler does an incredible job at preventing these.

While Go's frustration often comes from debugging sloppy concurrent code, the frustration with Rust is often about having your code to compile. But once it compiles, it runs beautifully. Some prefer the former, I personally prefer the latter. Also, I think the argument of increased productivity with Go should not be the main argument, because the time you save writing a large program, you will probably lose trying to debug a deadlock (which could still happen in Rust but harder to make happen) or a random data race that the race detector couldn't catch (or in a vendored library).

If I had to define the experience with both languages, Go is the instant gratification option, you feel productive quickly, the language is easy to learn with a forgiving syntax sometimes at the expense of correctness. Rust is the delayed gratification option, frustrating at times, very hard to learn and master but offering strong safety guarantees with an elegant syntax (which is a personal opinion).

Also it's a controversial topic in the Go community but the lack of generics...

Rust has its downsides too, for example the slow compile times or the lack of maintained libraries for some core functionalities but overall, programming with Rust is a much more enjoyable experience once you start getting ahead the learning curve.

One last thing: It is hopeless trying to learn Rust in four days without very good resources/books. I recommend "Programming Rust" from OReilly if you really want to dig into the language. It's incomplete at the time of writing but still one of the most useful resource out there (with the free Rust ebook). My knowledge of Rust dramatically increased after reading it and I felt much more confident writing larger programs.

Go is a language that is used to write on top of things. Rust can, maybe, be used to write the things Go are written on top of.

This sentiment (or slight) is the same as always said of C and C++, that they are used to make real things (systems and infrastructure, foundations), and the sentiment (and slight) is there because there's a lot of truth to it.

Which language was used to write our *nixes, windows, the biggest web servers (apache, nginx, IIS), haproxy, mysql, postgresql, oracle db, etc, etc? C/C++, of course. What else?

Docker is just a front end/abstraction layer for the features already in the Linux kernel (written in C). You can write, what's essentially just automation tools, like this in any language.

I don't think what you write in this post is a testament to any strength of Go. If currently there exist a testament to its strength it must just be the fact that it's used; adoption rate/popularity, although I have not seen the numbers.

> Docker is just a front end/abstraction layer for the features already in the Linux kernel (written in C).

That's actually a perfect example of "systems programming", in the true sense of the phrase. And it is done in Go, because it can be done in Go.

Your point is fair about trivializing the other party, even implicitly.

Docker and CoreOS are not really successful companies...it's hard to say if any of the companies in that space will be successful.