Productivity comparisons are tricky. As an analogy: Being more than 10 years long Vim user, I am very productive with Vim. I have all my configs polished, I kno

Productivity comparisons are tricky. As an analogy: Being more than 10 years long Vim user, I am very productive with Vim. I have all my configs polished, I know all the tricks, etc. I can work on shell scripts, C, C++, D, Rust, Python, Go, anything... all in one editor, locally or through ssh, on any platform, etc. But if you take a person that has spent a month using Vim, and a person that has spent a month using some popular IDE, the IDE person is going to be more productive. Also, I'm sure long-term Java IDE user is going to be more productive than I am with Vim, when writing Java. Obviously. Similarly with Go and Rust, as I'm following Rust development since like 0.3, I am very productive with Rust, while I find Go noisy, verbose and constantly dragging me down with its limitations. I don't have to be "architect astronaut" to need generics or decent macros. On top of that: how do you measure productivity? Many people seem to measure it by "perceived productivity when writing new code". "I am writing this new service in Go, and I was able to do 500 lines today. I feel very productive!" Never mind that 30% of that lines are verbose error checks and other error-prone boiler-plate, reviewing it might not be pleasant, there are multiple errors that will have to be ironed out when production starts to exhibit them, everything needs refactoring because performance is not good enough under load, and that the next person might not have a such a wonderful time modifying the original code, as the first person writing it, and so on. The project might be in such a bad shape, then it will just get rewritten from scratch, so the next developer will feel "productive" again, ironically. I am NOT addressing Go and Rust particularly here - just overall. It is very hard to measure long-term productivity, while it is easy to lure yourself into believing the perceived short-term productivity matters a lot. Having said all that, Go is easy to understand, so it is easy to find people that are able to use it (huge business reason to prefer it!), has a nice ecosystem, fast compilation, nice scalability with goroutines and many things that are going for it. I find Rust's "quality", trump Go's "productivity", but that's like ... my personal opinion, man. :)