The “developer speed above all else” mindset is driven by economics rather than technic. There are no reasons why one should not produce a good design in a any language. In the end it's a "people problem" most of the time.
> Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion
I'd add another dimension: reading go is slower than reading Rust, but it's easy. Rust may be faster to read, but you can hit some very rough patch and serious head scratchers.
> it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields
Some refactorings in Rust has brought back memories of refactoring struggles with highly coupled code bases, where one seemingly small change ends up requiring touching many many areas of the code.
The omniscient need to define ownership across a code base seems to make it easy to introduce high coupling, which is unavoidable unless you start using shared_ptr/RC all over the place.
Rust complexity is not encapsulated in libraries that parses JSON or YAML, or others.
Rust complexity is embedded in the following: in order to get something to work, you effectively need to solve a puzzle.
Solving the puzzle is fun and feels very good once completed, and the prize is definitely worth it when performance and safety are critical.
I highly doubt that "solving the puzzle" makes sense in the context of ad-hoc automation or boring sysadmin/devops stuff. Last time I checked, creating a static binary (a-la go) was not easy. It may sound stupid... but at the end of the day go is the king of pragmatism.
I think exactly the opposite though about systems languages: Rust should take over C and C++.