Go Micro: a standard library for distributed systems development

I've also seen it cause a lot of pain during upgrades since upgrading the service framework is implicitly upgrading so many other components and the framework is probably not being diligent about only improving one component (ex. Auth) per release. Sometimes that leads to basically never upgrading to avoid the risk.

It's true you need to do propagation for tracing but open telemetry has pretty broad support these days. That cost seems worth the stability and control.

Further it turns some straight forward business logic in to some cultish bulshittery of endless packages, classes, annotations and so on. But hey, there is no xml config now, so it all is super modern stuff.

Just yesterday, I had to look into perf issue of Spring based project. It has probably 500 line of core business logic. But it is littered in tens of packages and dozens of java source files.

So it is standardization for sure but it does not seem to be leading to better results. It is however giving a great cover for bad stuff because now code follows all best practices as per Spring framework.

I emphasize the age of Go because I don't think this is a virtue of the language per se (considered as a bag of features), or because the developers were super geniuses who could see what nobody else could. It's just that net/http was able to be spec'd and put into the standard library based on the decades of experiences other languages had. I would expect any other upcoming languages to be able to pull off a similar trick, as long as they try.

I certainly don't sit down with every Go web app I write with literally nothing but the standard library. I do have some non-trivial code written that way, but it isn't something I seek out as a terminal goal. It just isn't necessary to go commit to "Spring" or "Ruby on Rails" or some other framework just to get access to anything at all. I'm already in the Go ecosystem just by using net/http, you're not obligated to commit to a "framework"'s ecosystem just to get access to basic functionality because you're all but already tied in to a framework's ecosystem just by using Go, and there are many options for that basic functionality.

And to be clear, I'm more agreeing with you than disagreeing with you; I'm trying to explain the divergence between your understanding and what the Go ecosystem has because I consider it a worthy question to ask, and there is legitimately an interesting question to consider here based on experience from many other languages.

You can often use package reflect to hack up something approximating a solution to this class of problems, true. But, like package unsafe, package reflect sidesteps a bunch of language assumptions, conventions, idioms, etc. which means any code that uses reflection is going to be subtle, brittle. It's a tool of last resort, really, an escape hatch. Not something that you should consider part of your tool set.

This is all by design, I think. Go tries to ensure that a straight-line reading of the code accurately represents the execution flow. So you can't really implement the inversion of control patterns that frameworks usually rely on without fighting the language.