I think this article is a great illustration of the things a Java developer will struggle with while they are learning Go. I no longer write Java, and I now view many of these as strengths.
1. Capitalization rules vary by language, I remember struggling with camel cased naming in Java in some scenarios. I also thing the example given is bad, User.user is a poor name in any language.
2. Structs w/ implicit interfaces. I like this feature of Go, and it's never bitten me in the way the author describes. I never liked having to declare them in Java. And there is an easy way to ensure your particular type implements an interface in Go.
3. I prefer not having exceptions, and linters will tell you when you are not checking returned errs. I do wish Go would offer tools to reduce the amount of if err != nil {} blocks, particularly in IO heavy code.
4. Go's build system is very easy to understand compared to something like Makefiles or Maven. I don't consider a few conventions "magic." I have mixed feelings about init(), but I think it's much better than trying to come up with thread-safe alternatives to compile regexp, etc.
5. Naming. Writing unit tests from an outside perspective (package xyz_test) will help you pick better names, and you will run into less conflicts. In Java you see hideous combinations of Abstract, Singleton, Factory, etc. I much prefer Go's concise/pragmatic naming style.
6. I don't do much code generation, can't comment.
7. I do miss ternary sometimes, but I have seen it abused with very long statements in other languages. I would note that "else" has become a code smell in Go, it's more normal to assign a value and then change it.
8. Sorting. I like that not everything needs to be an object in Go. Having to add a few extra lines of code the rare occasion I need to make something sortable is much better than a project full of Java class/getter/setter boiler plate for what should have been a struct.
9. Yes, dependency management is a mess. No argument. Looking forward to dep becoming official.
10. I do sometimes miss generics, but I started writing Java before it had generics so I can live without them :P. I think they can lead to readability problems when overused.
11. append is a bit confusing, but hiding how it works should be considered "magic." linters will help you here.