We largely had similar experiences, but formed different conclusions. Like you, with Go I was up and running rather quickly. I didn't have to think very hard.

We largely had similar experiences, but formed different conclusions. Like you, with Go I was up and running rather quickly. I didn't have to think very hard. It was easy because I didn't have to pick up new concepts, only new syntax. With Rust I had to learn some new concepts and internalize them, new concepts I generally find much harder than new syntax, but I believe I became a much better programmer (including when writing Go) as a consequence. Now the journey is majority complete in both languages, and my conclusion isn't that Rust or Go made a pile of bad design choices, rather that the languages made different trade offs that appeal to different people in different circumstances. Go pushes a lot of expectations of behavior during runtime onto the author while writing (don't share mutable state between threads without appropriate care, always remember to manually free your (not memory) resources, don't deref a null pointer, don't use a returned value if err != nil, etc). Rust pushes a lot of expectations of knowledge onto the author while writing just to get the project to compile (ownership, lifetimes, sum types, address all the above mentioned Go expectations). It's been years since I started using both languages, and I've spent months dealing with bugs in Go. I believe a lot of those bugs could have happened in any language, but also a lot wouldn't have made it past rustc. Which is the winner for specific type of situation? I don't think we can know for a long time, studying such things is very difficult and takes a lot of time. In the mean time, we gravitate towards our personal preferences, believing them to be superior for $reasons.