I couldn't disagree with this any harder. I'm a Java BE Engineer who joined a Go shop, so I have a direct comparison. Both are microservice environments for products of similar complexity. It is insane to me how much less productive Go is for your average microservice enterprise environment. I'm sure it's great for systems programming or tool development. I like the simplicity. But the ecosystem is borderline useless for larger scale enterprise-y service landscapes. GRPC and Protobuf are overengineered and underdocumented, a lot of things are seemingly optimized for Google's specific needs.

We are more people, we are more experienced and have a decent engineering culture. Yet we're definitely less productive than the last average, traditional Java Spring Enterprise team I've been in. "Circumventing" a framework restriction (which rarely happens if you stick to good practices) is MUCH less effort than building things yourself from scratch.

This 100%. I think the people largely arguing for no frameworks have no idea what real productivity looks like at large scale engineering orgs. This mostly means you are not handcrafting libraries. There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Product teams may contribute to that but they will mostly be consumers. I always equate this to car manufacturing. I am not buying a kit car, I am not buying a hobby car, I'm buying a well engineered product from a large scale manufacturer. Frameworks and platforms fall into this category, especially for enterprises.

I think it's fine for small teams not to use frameworks, and maybe 200 person engineering orgs are made up of many small teams who just want to agree on a protocol rather than shared framework/platform but once the scale starts to increase you really need to start tightening up and implementing some better standards.

People constantly talk about not being Google, well let me tell you the people scale is all the same, the amount of legacy infra is all the same. If you haven't peaked into the depths of the messy multi-decade enterprise you have no clue. Your 4 year old company that you joined 6 months ago is no comparison to something with a legacy of 3 decades with 2k+ engineeers scattered across a disparate org trying to modernise in the cloud or whatever comes next.

Full disclosure: I work on https://micro.dev - a framework for Go

micro.dev is different from an actual go framework go-micro.dev ?? (https://github.com/go-micro/go-micro)

Yup, I was the author of go-micro. It was very much a standalone Go framework aka common interfaces grouped together for distributed systems development. By using interfaces they effectively became pluggable abstractions for infrastructure. Unfortunately I don't think a Go library alone solves the problems I was trying to solve so it got merged into Micro which is platform that includes a CLI, API, Runtime, etc. It powers https://m3o.com

What if any is the relationship between https://m3o.com/ and https://micro.dev/ ?

We used Micro to build and offer Micro services on M3O. Every API to you see there is powered by the open source equivalent Micro service here https://github.com/micro/services