If the makers of golang wanted to avoid the complexity of public, protected and private, especially if you consider C++ where you can change those access modifiers depending how you inherit, it is an understandable decision, but then I would have rather just ignored access modifiers all together and kept everything as public regardless, like many languages do. That would avoided the atrocious json hack completely.
I think this goes back to what this critical article about go concluded, that Simple is a lie.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
"when you make something simple, you move complexity elsewhere."
If I were a golanger another thing I would have disliked is definitely the internal folder for packages, having folders to have magic capabilities is something I truly dislike. First you need be aware when reading the source file where it is located, second when creating such folder you have to be sure to create it with the correct name, these things has tendency to be hard to detect during code review.
MVC frameworks likes to do this, put the controller in the correct folder and give it a correct name and name your method with get, hard to debug if you misspell any of it. Or database migrations, put them in a folder in a consecutive order, so to detect if new migrations have slipped in between the one you are working on you need to diff on folder sorting. Just horrible.
