I spent five years writing mainly in Go, then in the last few months have started writing in Rust. In both cases, the language choice was made by the company I work/ed for, not me, so it's not a question of personal preference. I also have Node.js/Typescript and C# to compare to. Because my Rust proficiency is between beginner and intermediate (I haven't, for instance, written any serious macros yet), I cannot really legitimately compare productivity yet, but I do have some subjective impressions. I try not fall into fanboyism for any language or framework, so I hope this is a reasonably fair-minded and unbiased perspective.
I can believe that with time, I may be able to approximate my Go-level productivity using Rust, but that is still a long way off. A few factors contribute to this. Firstly, the in-editor experience has not been great for me with Rust. Partly because macros make it much harder for the language server to do things like "go to definition". Also because, for example, a single C library dependency that I can't compile on my Mac means I have no intellisense at all for the project. That would not happen in Go. Secondly, borrow-checking and lifetime checking are painful for a programmer newish to the language because they represent a new class of compile-time errors - not syntax errors or type errors, which will be pointed out immediately in your editor, but usage errors that relate to how and where variables are used in relation to one another and which only get detected when you do cargo build. Thirdly, the zero-cost abstractions do have a cost, just paid by the programmer rather than the computer. The async abstractions in particular are awkward to use. Try joining futures with return types that look the same but actually have different underlying concrete types, for example. Oh, says my Rust mentor, you need to whack a .boxed_local() on the end of that... Say what?
Productivity in Go is hampered by all those horrible if err!=nil clauses and lack of generics causing you to use a code generator or simply cut and paste functions... but hell, they got concurrency right!
Anyway, I understand how the philosophical starting point of Rust leads to all this, and it's fine. It's a fantastic language in many ways, and I'd choose it over Go for anything high performance or with low-level C interop requirements. But there's no denying these things have and do affect my productivity using it. Compare it with Node + Typescript and the productivity gap is even larger. That said, it also true that the Rust code I write does seem to have fewer bugs than other languages - the no data race guarantee is particularly nice; I've wasted weeks chasing data races in Go.
There's evidence for the case that getting a major project up in Rust is slower than other languages, at least if the developers are having to learn the language - I remember reading about parallel teams developing the same project in Rust, Go and a number of other languages, and the Rust project (all developers were starting as language beginners) was much slower than the others. I wish I could find the reference...
Like I say, none of this is to knock Rust. I'm really looking forward to the day when I can churn out Rust code the way I can churn out Go, because it will be tighter, faster code. But there's no denying the productivity cost of getting there.