Actually one of the guiding principles of Go's design is that syntax is anything but superficial. It affects nearly all aspects of your design. Everything from the parser to the compiler to the stdlib. Syntax is the UI/UX of your language. Dismissing syntax as superficial is a mistake.
Imperative languages really aren't massively different in the grand scheme of things. Sure, some are more OO than others, different type systems, and so forth. But you do more or less tackle the same problems with similar kinds of solutions. So a lot of the time, the syntax changes are relatively superficial compared to the complete mindset change you require if you were to tackle the same problem with a LISP, or Prolog, stack-based languages, or even a procedural SQL (albeit to a lesser extent).
I do welcome the breadth of choice we have in programming languages, but sometimes we get too caught up on the finites of one language of a particular sub-genre when compared to another language of the same sub-genre. Particularly when a good programmer should be more interested in coding good logic and thus understand the paradigms enough to swap between the different languages of the same ilk with relative ease.
