[junkscience2017]

I feel like go-kit is quite antithetical to the Go mindset...it presents a lossy abstraction as a means of future-proofing against eventualities that will almost certainly never be encountered

to be honest it strikes me as the sort of library that excites intermediate developers who tend to over-architect

[sagichmal]

Your "almost certainly never" is another organization's "certainly inevitable" or "already happened". Go kit's scope and applicability is pretty clearly enumerated in the documentation. And there's nothing lossy about its abstractions.

[alpeb]

I fully agree, unlike many others that are voting down this and other criticisms. The amount of boiler plate that go-kit adds is crazy.

[lima]

I vouched for this comment - why would it deserve to be flagged?

[grzm]

This comment in particular wasn't flagged: 'junkscience2017 is banned. Note it was marked [dead], not [flagged].

[lima]

Thanks for the explanation!

[natethinks]

> the sort of library that excites intermediate developers

I find this true about nearly all microservices in Go. Microservices are much more useful in something like Node that can only take advantage of 1 OS thread per instance. Without containerization and load balancing in Node you wouldn't be able to scale.

Go on the other hand can efficiently utilize a nearly unlimited amount of threads as necessary with its scheduler. You're much more likely to over-architect if you don't keep this capacity in mind.

[sagichmal]

Opting-in to microservices has almost nothing to do with CPU efficiency.