For me, as a golang programmer, it's almost the same like you mentioned. Additional mental overhead in golang is that you also need to implement everything in a

For me, as a golang programmer, it's almost the same like you mentioned. Additional mental overhead in golang is that you also need to implement everything in as-flat-dependencies as possible due to the compiler not having support to resolve single methods or recursive dependencies (and -injections). Usually I find myself rewriting the codebase at least 3 times until I have a modular enough architecture that does not have any unresolvable recursive dependencies. Usually it ends up in a folder structure with a top level structs, utils, actions, cmds, schemas, parsers, protocols etc. While it also embraces strong knowledge about the architecture, it also is a much higher threshold until you have a program working. Add to this the always occurring defined but not used errors and you can demotivate kids real fast, even though the language syntax and grammar could be very easy to learn (apart from what pointers, slices and reflections or memory allocations and callstacks are).