As Patrick said, Go was announced much later in the development lifecycle. Go was developed for quite a while before it was announced. At Mozilla, we do things a little differently. All of our projects are open and public from the very first commit into the repo.
People seem very excited about Rust and want to use it right away, which is great, but things have been changing a lot, as you noticed, and will continue to do so for a while. One of the reasons things are changing is because the Rust developers take into account the opinions of random early adopters of the language. There is no idiomatic way to write Rust yet because Mozilla wants the Rust community to help figure out what idiomatic code should look like. Go, on the other hand, has lots of opinions.
There are obviously tradeoffs to each approach, and one downside of the Mozilla approach is a lot of churn and chaos sometimes. However there are a lot of benefits too, one important benefit being that the community is helping to shape the language in an open way.
I have no problem with the community helping to shape the language. But I think the difficulty in getting started with the language, due primarily to documentation problems and lack of good introductory material, is going to make it harder for people to get involved.
I know when Go was first released I immediately jumped in and started using the language. I was even the first non-google, non-@golang person to get their name in the CONTRIBUTORS list (because I wanted to modify the emacs go-mode, but still). But I feel like I can't even get started with Rust because I have no idea what I'm doing and the documentation isn't helping.
For example, right now I'm trying to whip up a really tiny program to test out the FFI. But the libc module's documentation is completely nonexistent. It's just a series of nested modules, which end up having nothing in them. I'm sure there's actually stuff in the modules, otherwise they wouldn't exist, but the documentation claims that they're empty. So I have no idea what I'm doing.
The problem with libc is twofold: first, reexports don't show up in the docs (bug on file [1]), and secondly, that every module gets a separate page (filed as [2]). You can actually see the signatures for functions if you click through enough, e.g.
Having to click through is annoying, though. It would be better to be able to specify that a module and all its submodules should go on one page in the docs.
Makes sense. Would fix the problem where I have no idea what prelude pulls in too.
Also, part of my confusion with libc is that not all of the leaf modules actually have something in them. The first few I looked at were completely empty, so I thought the entirety of the libc documentation was empty.
People seem very excited about Rust and want to use it right away, which is great, but things have been changing a lot, as you noticed, and will continue to do so for a while. One of the reasons things are changing is because the Rust developers take into account the opinions of random early adopters of the language. There is no idiomatic way to write Rust yet because Mozilla wants the Rust community to help figure out what idiomatic code should look like. Go, on the other hand, has lots of opinions.
There are obviously tradeoffs to each approach, and one downside of the Mozilla approach is a lot of churn and chaos sometimes. However there are a lot of benefits too, one important benefit being that the community is helping to shape the language in an open way.