In the end, Go is indeed effective at making engineers avoid arcane and difficult code, but doing the "difficult" stuff that's not available in Go is definitely not how the most productive engineers are productive.
IMO, someone making code that abuses special features to the point it is difficult for other members (including future members) of the team to read is the definition of a negative-X programmer. Unless they're working solo, of course.
Also, like wavesbelow mentioned in his great comment, the "10x" doesn't come from coding prowess alone: it starts long before that, with the process and planning.
Comments
In the end, Go is indeed effective at making engineers avoid arcane and difficult code, but doing the "difficult" stuff that's not available in Go is definitely not how the most productive engineers are productive.
IMO, someone making code that abuses special features to the point it is difficult for other members (including future members) of the team to read is the definition of a negative-X programmer. Unless they're working solo, of course.
Also, like wavesbelow mentioned in his great comment, the "10x" doesn't come from coding prowess alone: it starts long before that, with the process and planning.