4 ms·

> why not skip that and use libraries that implement the functionality you do need. I was just asking specifically about the ORM part. The subject of "use an o

> why not skip that and use libraries that implement the functionality you do need. I was just asking specifically about the ORM part. The subject of "use an opinionated framework vs. tie specialized libraries together" is a complete different debate. But about this matter: I quite like to assemble libraries when I'm solo on a personal project. But that's definitely not something I want in a team. That's pretty much why we go with Django and not Flask or any of the "lightweight", "micro" framework things that are everywhere. "Just bring whatever ORM you want", "Use whatever template engine you like", etc. But that's a lot of decision making and integration with no added value for us. The fact that Go has such a comprehensive standard library is a good thing, but probably not enough because, like you wrote: > you'd need to add quite a bit of scaffolding (Which obviously contradicts the idea that Django brings just a glorified POST form app to the table) As to why I'm interested in Go: faster execution, less memory, easier deployment... but as a small shop, team productivity still comes first.

tgv 3y ago
I meant: you'd need quite a bit of scaffolding to imitate django's way of importing urls. If you're happy writing them as function calls, and/or manually importing them, it can be quite straight-forward. But Go doesn't have one framework that pretends to do it all. And IMO, django just pretends. Want to turn your GET/POST-based views into JSON/REST-like endpoints? Add a library, and two extra modules per data type. Want to do something slightly more complicated with the database? Be prepared to write a bunch of code, or look for a library that understands tree/graph-structures. Want to integrate Angular or React? Add another library or two. File conversion? Charting? Monitoring? Repeated tasks? Packing static files? Moving images into the right place for deployment? You get the picture. You may have to good reasons to pick django for your team, but it sounds a bit like you're outsourcing the architecture, hoping that django suffices and the community can support you. But if you understand the needs of your (web) service, flask or basic 'requests' or fastapi are not such bad starts. Once you're at that point, Go's web frameworks can look quite similar, so I'd recommend that if you ever take that step.

tgv 3y ago

I meant: you'd need quite a bit of scaffolding to imitate django's way of importing urls. If you're happy writing them as function calls, and/or manually importing them, it can be quite straight-forward. But Go doesn't have one framework that pretends to do it all. And IMO, django just pretends. Want to turn your GET/POST-based views into JSON/REST-like endpoints? Add a library, and two extra modules per data type. Want to do something slightly more complicated with the database? Be prepared to write a bunch of code, or look for a library that understands tree/graph-structures. Want to integrate Angular or React? Add another library or two. File conversion? Charting? Monitoring? Repeated tasks? Packing static files? Moving images into the right place for deployment? You get the picture. You may have to good reasons to pick django for your team, but it sounds a bit like you're outsourcing the architecture, hoping that django suffices and the community can support you. But if you understand the needs of your (web) service, flask or basic 'requests' or fastapi are not such bad starts. Once you're at that point, Go's web frameworks can look quite similar, so I'd recommend that if you ever take that step.