1) The struct's fields will have the default value for their respective type. I understand you might want to force specific values, but if this is the case, maybe you could only export an interface to the struct? And said interface would have the "constructor" methods.

2) You can always encapsulate errors. Your code will still have a type assertion or switch, but you don't need to use string parsing (although I have seen string parsing used in libraries such as mgo - the MongoDB client library).

3) Because maps are references, just like slices. You can still call len() on a nil map and therefore treat it as an empty map? If you mean the assignment to nil maps: https://groups.google.com/forum/#!topic/golang-nuts/RkYIF8Sq...

4) This is subjective I think, but I disagree. I like just being able to type "return" instead of for instance typing in 6 different places "return something, err".

5) Do you mean un-exported structs (and therefore lowercase)? I haven't come across this, but I can see where it could be an issue. I usually just use VSCode and mouse over to quickly see a name's definition.

I agree with you that it's not perfect, but as I saw someone else say on the internet, it's the least bad language (in my opinion). And I don't envy you for working with dependency injection in Go :)