Go strikes a middle ground between low-level and high-level in some awkward ways. It wouldn't be hard to use e.g. nullable types or option types to outlaw null pointer exceptions without restricting the set of possible programs, and with stronger static guarantees of correctness. On the other hand, Go also has mandatory garbage collection, which emphatically does not reflect the underlying machine and also restricts its usefulness in certain situations.

w/r/t regularity: most of the functional programming languages (e.g. ML, Haskell sans GHC extensions, various Lisps) are incredibly regular, especially in the semantic sense of providing a few semantically simple features and milking them for all they're worth. Go has quite a few special cases (e.g. the make versus new distinction, the iota keyword) and some odd omissions (e.g. simulating union types involves what I perceive as interface trickery; const only allows numbers or strings as values.) Coming from C++, Java, &c, Go seems incredibly regular—the lack of OOP goes a long way towards keeping it simple—but it's not a simple language except in the context of "modern, Algol-derived applications languages." Which it is an improvement on, but it's not regular in the strict sense.