Why Go and Not Rust? (2019)
&gt; This makes Go easy to learn and, even more importantly, it ensures that Go projects remain understandable even when growing in size.<p>Do people actually find this to be true? Honest question.<p>In my personal experience, as Go programs grow in size, they become increasingly unmaintainable. Avoiding abstraction and keeping everything explicit sounds great in theory, but what <i>actually</i> happens in a larger project is that they just become a mess. Functions start taking on seemingly-unrelated extra parameters just to shove a tiny bit of extra necessary information four layers down. Details related to one coherent idea are strewn about everywhere because it was easier to add the logic in situ to a dozen places rather than have one part of the code responsible for it. Internal idioms are copy-pasted across dozens of files, many of them missing improvements made to later copies.<p>I&#x27;ve seen this happen in every large go project I&#x27;ve jumped into, and it (subjectively to me) seems to be significantly worse than in other languages. Maybe it&#x27;s because—on average—gophers tend to trend more junior in their careers and there haven&#x27;t been enough senior mentors keeping things well-factored. But at this point it makes me instinctively dread any time I have to switch to a new project that&#x27;s written in the language.<p>The whole &quot;complexity is bad, explicit is good&quot; mindset vaguely reminds me in some way of the hype around &quot;schemaless&quot; databases. No database is schemaless. All this means is that you still have a schema, it&#x27;s just implicit, inconsistent, and now you lack tools to understand and&#x2F;or manipulate it. The complexity in your go program still exists, it&#x27;s just scattered absolutely everywhere and you lack good tools to wrangle the worst parts of it.