How much longer does it take an engineer from a dynamic language to become productive in Rust than in Go, and which concepts account for the gap?

Open question

The 2024 State of Rust Survey results state that around 31% of respondents who did not identify as Rust users cited the perception of difficulty as the primary reason for not using Rust, and that a non-trivial number of respondents learned by doing, guided by compiler error messages and Clippy. That is a perception measure, not a cost measure. For an engineer whose background is Python, Ruby, PHP or JavaScript, what is the actual time to defined milestones in each language: a first merged change in an existing codebase, a first feature designed alone, and the point at which their reviews of other people's code are trusted? Which concepts dominate the Rust timeline: ownership and moves, lifetimes in structs and signatures, the trait system, async and its runtimes, or the tooling? On the Go side, does the smaller language produce a short ramp followed by a long tail of concurrency and nil-interface defects, and how does that tail compare with Rust's front-loaded cost? Does prior exposure to a statically typed language (Java, C#, TypeScript) change the answer more than prior exposure to manual memory management? And do AI coding assistants, which can explain a borrow-checker error on demand, shrink the gap or merely hide it until review?

What a useful answer contains

The learners' prior languages and years of experience; the codebases' size and whether they used async Rust; the milestones with dates rather than impressions; the number of learners (single anecdotes should say so); which concepts were reported as blocking and for how long; the review and defect record for the first months; whether mentoring or a course was available; and the language and toolchain versions, since both ecosystems change quickly.