I have written a command-line log processor in Rust, an XML processor in Go, and some small microservices in both. My experience in working with both languages is that Rust has a steeper learning curve than Go, and it took me longer to feel proficient in Rust. However, once I felt proficient in both I felt much more productive in Rust.
It's my impression that you may need to have worked with functional languages and have an understanding of type systems before you can be efficiently productive in Rust, but for those who reach that I think they can be much more productive in Rust than Go,based on only my personal experience. One of Rust's biggest and best features, and its biggest barrier to grokability, is the Rust Borrow Checker.
I think Go is a very good language, has awesome concurrency designs (I love Go channels), and is more accessible to more developers, but it also doesn't seem as flexible. I think the OP hit the nail on the head with the idea that Go is designed for Enterprise, where a sea or journeyman engineers are working under a small number of senior eningeers. I think Rust OTOH is designed for senior engineers, but is usable by less experienced engineers if they are mentored properly, i.e. 1:1 or at most 1:3.
Also, I like the tooling better in Rust than Go. Rust tools are easier for me to install, and the cargo build tool is not part of the language, but there is a standard build tool, so I get to have my cake and eat it too. Meaning I can customized the build tool to my needs, and have different customizations for different projects. That can get out of hand, which is why so many hated Gradle. OTOH, the level of customization is why many shops with senior engineers loved Gradle (e.g., Netflix).
Examples of build tool install:
* Go: $GO111MODULE=on go get golang.org/x/tools/cmd/stress
* Rust: $cargo install cargo-stress
One thing I think both languages will need to watch out for is the P3 problem (Package Proliferation Pachyderm), where there becomes an ocean of packages, some too trivial to really be an effective package (e.g., a package with a single functor to add two numbers). I've seen this with Node.js, though the community has noticed it and is working to rectify the situation. This, like so many problems with language adoption and evolution, is a policy/community problem and not a technical problem. Both Go and Rust have great communities, so hopefully we can avoid P3 in the future.
I have zero field experience regarding go, but it seems to me that it's made to remove friction for teams.
Lean toolchain, lean build times, lean formatting (can you imagine the amount of time wasted on IDE config, commit syntax, and formatting style debates ?) so that large groups can just go to work.
ps: I'd love to work in rust. As you said, it seems very potent at making very expressive yet very efficient code.
I was trying to do some CLI formatting this weekend and discovered that an equivalent to leftpad exists in the Node API.
I was up to my elbows in troubleshooting (when you don't know how to solve the problem, describe it more clearly), so I didn't have time to dig into the history, but I got a chuckle out of that.
It's my impression that you may need to have worked with functional languages and have an understanding of type systems before you can be efficiently productive in Rust, but for those who reach that I think they can be much more productive in Rust than Go,based on only my personal experience. One of Rust's biggest and best features, and its biggest barrier to grokability, is the Rust Borrow Checker.
I think Go is a very good language, has awesome concurrency designs (I love Go channels), and is more accessible to more developers, but it also doesn't seem as flexible. I think the OP hit the nail on the head with the idea that Go is designed for Enterprise, where a sea or journeyman engineers are working under a small number of senior eningeers. I think Rust OTOH is designed for senior engineers, but is usable by less experienced engineers if they are mentored properly, i.e. 1:1 or at most 1:3.
Also, I like the tooling better in Rust than Go. Rust tools are easier for me to install, and the cargo build tool is not part of the language, but there is a standard build tool, so I get to have my cake and eat it too. Meaning I can customized the build tool to my needs, and have different customizations for different projects. That can get out of hand, which is why so many hated Gradle. OTOH, the level of customization is why many shops with senior engineers loved Gradle (e.g., Netflix).
Examples of build tool install:
* Go: $GO111MODULE=on go get golang.org/x/tools/cmd/stress
* Rust: $cargo install cargo-stress
One thing I think both languages will need to watch out for is the P3 problem (Package Proliferation Pachyderm), where there becomes an ocean of packages, some too trivial to really be an effective package (e.g., a package with a single functor to add two numbers). I've seen this with Node.js, though the community has noticed it and is working to rectify the situation. This, like so many problems with language adoption and evolution, is a policy/community problem and not a technical problem. Both Go and Rust have great communities, so hopefully we can avoid P3 in the future.