[meddlepal]

As others have noted, this is one of the areas Go really shines at (and I am not a Go fan). The lack of language features really forces most code into a limited form of TOOWTDI and because it has pretty opinionated choices about loops, conditionals, errors etc... you really don't see much Go code that makes you scratch your head.

[Cthulhu_]

Plus - at least so far - it hasn't aged; they are reluctant to make backwards-incompatible changes, and right now they're really humming and harring about whether or not to add generics. The biggest changes you'll see in Go codebases from 10 years ago vs modern will be Go's module system / dependency management and the `context` package sprinkled as an argument to some of the API methods.

Compare that to other languages (from the top of my head, don't pin me down on details or inaccuracies please):

- Java: Added generics, annotations, lambda expressions and streams, new date/time libraries, modules, switch expressions and multiline strings.

- PHP: Added classes, types, null coalescing operator, etc

- Javascript: Classes, ES6 features (arrow functions), imports, and offshoots like Flow, Typescript.

- Obj-C / Swift; ARC, Swift itself (4 versions), I haven't been up to date with this much.

TL;DR, most languages really shift over time, often 'borrowing' features from other languages, but Go resists these changes because it's intended to still be read and compile in ten, twenty years' time.

Personally, I'm working on a management interface for a network application; the existing UI has been around since 2012, I'm trying to build this to last at least as long, probably longer, and I think Go is a great choice for it. The old application was built in PHP 5.2, which is vastly outdated now (and updating is challenging because on the one hand, the versions of RHEL used in production don't supply newer packages, and on the other there's 65K lines of badly written PHP that would likely need to be updated).

Conversely, the new Go back-end is standalone and self-contained, I try and maintain the habit of updating the Go version and all dependencies monthly; so far I've never had to make any code changes or had to rethink my architecture because of Go adding a new (architectural) feature. (I probably have the benefit that it started after `context` and the module system were in place though). I feel a lot more confident in its future proof-ness. And I feel confident that anyone looking at the code can maintain it, although that said I'm cautious about the more magic parts like GORM, which I should probably swap out with lower-level SQL at some point but I don't really want to.