> Error handling is a big one for me. This could be generalized to lack of expressivity; this has been shown over and over to be incorrect. go programs are wit

> Error handling is a big one for me. This could be generalized to lack of expressivity; this has been shown over and over to be incorrect. go programs are within the ballpark of other languages in terms of LOC. usually the examples given are niche use cases that impact an extremely small amount of code. golang is looking for ways to make it more ergonomic just hasnt found a decent path forward yet. interestingly your sum types complaint might allow for it eventually. > Go really likes forcing you to either write a ton of tests or discover your errors in production this is just not true compared to most languages. evidence please. given the prevalence of dynamic languages in the wild today its most likely the opposite. i know my golang tests tend to be less in number than java or any dynamic language. >Farther down the list is escape analysis. Rather than just giving me control over whether allocation happens inline or indirect also not true, golang absolutely gives you the ability to control this. but its guarded by rules. rules that prevent you from screwing up and causing memory issues. this is a good thing.