Comment by pphysch | Hacker News Reader

Comment by pphysch | Hacker News Reader

Parent Full thread

Cool project but I think building a full stack web framework in a language without features like operator overloading is a fool's errand.

Yes, Go has nice standard templating and HTTP serving libraries, and nice dependency management. These are all important features for a web framework.

No, it will never be productive as its competitors in the web framework space, because you simply cannot write expressions like `order.customer.region` that intelligently hit the database, because you can't override the dot operator. Instead you have to write unreadable crap like `regionController.Show(userController.Show(order.customer).region)` which is infinitely less "productive" than the former, for obvious reasons. Oh, you can `go generate` the *.Show definitions from a simple struct definition (or with 1.18 generics)? Too bad the final product is still unusable!

Use Go where it excels and connect it to your Ruby/Python/Typescript web backend over gRPC or HTTPS.

I see where you're coming from, but tbh the more I work on web backend code the more I disagree with this. I really think database interactions should be made explicit, even early on, rather than hidden by ORMs (or overriding a dot operator).

That's fine, but you are making a trade off with productivity here.

You have to be careful because sometimes productivity is just an illusion caused by accruing technical debt that you have to then pay for in time later. With database abstractions you often pay back this debt once the app reaches even slight complexity and you need to spend a lot of time understanding, debugging and refactoring query flows.

Writing backend with raw SQL: $10

Writing backend with a rigid, verbose, mostly type-safe ORM: $5

Writing backend with a terse, expressive ORM: $2.50

Adding type annotations to the previous code: $1

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-designin...

Bud will support something like this in the future.

> 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.

Agree with you on both accounts!

Reply on news.ycombinator.com