6 ms·
Thanks for your comment @pphysch! So for authoring an app, I tend to agree with you. Languages like Ruby/Python/Typescript are probably faster to get something
by matthewmueller 4y ago
Thanks for your comment @pphysch!
So for authoring an app, I tend to agree with you. Languages like Ruby/Python/Typescript are probably faster to get something working.
I try to consider productivity holistically though. With Go, there's a lot less fussing with the tooling. I've also found Go saves a lot of time when onboarding new teammates. This is because of Go's intentional decision to be conservative with syntax. After all, most developer time is spent reading, not writing.
I respectfully disagree with your preference to split your backend up over gRPC or HTTPS. I prefer the approach Shopify takes to break up it's monolith: https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity https://shopify.engineering/deconstructing-monolith-designin...
Bud will support something like this in the future.
- pphysch 4y ago> I try to consider productivity holistically though. With Go, there's a lot less fussing with the tooling. I've also found Go saves a lot of time when onboarding new teammates. This is because of Go's intentional decision to be conservative with syntax. After all, most developer time is spent reading, not writing. Ultimately you will be teaching the framework, not the language, when it comes to large frameworks like this. Both Go and Python are easy to learn, but frameworks always add a lot of complexity. > I respectfully disagree with your preference to split your backend up over gRPC or HTTPS. I prefer the approach Shopify takes to break up it's monolith: I'm not arguing for this or that architecture cargo cult. I prefer monoliths too, but sometimes you really need distributed microservices and Go+gRPC is one of the most maintainable ways to do that.
- matthewmueller 4y agoAgree with you on both accounts!