[javajosh]

Excellent comment. This is true, and I think golang embodies the idea (or attempts to). Enterprise wants consistency over anything else.

That said, there is a type of cleverness that can be brought to bear on Enterprise systems that, for example, take a simple, unidirectional data flow into account - something that is rather abstract, but which can and will thwart lots of complexity down the line.

[IceNotNice]

Can you elaborate a bit on the golang part? As someone who dabbled with Go but never found it too alluring when comparing to other options (if I wanted ease-of-use I'd go with Python, if I wanted performance I'd go lower level - C++/Rust), I'm interested what you mean by it. Go did find a footing in the industry and a lot of cloud infrastructure relies on it, I do think it's the most interesting option out of compiled garbage-collecting languages.

[Aeolun]

Go finds a really good position in between. The language itself restricts your ability to get too crazy (with for example types).

I hate it, but I can totally see how it would work really well for keeping your architecture simple.

[ctvo]

Go removes non-value added decisions as teams scale:

- formatting built in. There’s one way. No preferences needed

- language constructs are dead simple. There’s one way to use them, and they’re verbose. No cleverness encouraged

- patterns are straight forward Read the standard library code if stuck

Every Go project resembles every Go project. It’s great.

[pjmlp]

Plenty of languages have traveled that path, COBOL, RPG, xBase, Visual Basic, Delphi, 4GLs, Java, and now Go.

The problem is then you get some enterprise architects that go crazy with the design space.