IMHO there are better things to pick on Go for. The choice of using capitalization for public/private is probably the largest imho. When you want to change a fi

IMHO there are better things to pick on Go for. The choice of using capitalization for public/private is probably the largest imho. When you want to change a field you have to change all references to it too. You could argue an IDE makes that easy, but what about when patching with Git or other external tools, now your simple patch is context specific. The second biggest is then probably the module system. To this day I'm still confused when a local project has an import from a github URL. Is that using my local github.com/user/myfolderlocally or is that legit pulling the old version I have on github, gets more confusing with cross repo modules. Then the whole /internal paths for modules is also annoying, I sometimes want to use an 'internal' thing from another repo, but I can't because Go artificially limits me and the previous author thought 'nope no touchy' and I'm just left with forking for a tiny little import - gah. Finally is probably the ethos of the community itself - never change anything and keep it all dog simple or get chastised for suggesting anything outside of what is currently the norm. The power is often handed to the authors of packages and the language itself, over the users of packages - and there's essentially no escape hatches anywhere - "do it this way or your design is wrong".