> impossible to write an ORM framework like you have in Java and Python
genuinely interested in knowing why it is so. I quite like Go, but I also like Django, so I would like to know why a Django-like ORM would not be feasible.
But if you look at how it works in Python, it's by taking over class definitions in such a way that a field can be both a description of the field and an actual value. That doesn't work in Go (explicit casting the fields at every place you use them could work, but is prone to errors). It "cleverly" overrules operators to turn something like the Python expression `age > 50` into the sql string `age > 50`. Can't be done in Go, unless you define functions for all operators and find a way to reflect on the field name and the current context (`gt("age", 50)`). That's a lot of work to turn one string into the same one. URLs can't be linked to a class by simply importing a file; you'd need to add quite a bit of scaffolding (a factory for each class with a common interface, I guess?). And there are other parts that rely on annotation and whatever that simply can't be ported to Go, so you'd have to turn them into function calls. And Django doesn't give you more than a glorified POST form app out of the box anyway. You have to add more views and serializers to turn it into a modern backend, so why not skip that and use libraries that implement the functionality you do need.
Ok, my dislike shines through, but the gist is that Go doesn't let other code take over the interpretation of the meaning of expressions and statements and inject things into classes like Python does. It all has to be done explicitly. So django-like functionality for Go would have to look very different.
> 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.
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.
The main reason, in my opinion, comes down to how Go as a language was designed. I have written some follow up posts to that, specifically this one: https://andrewpillar.com/programming/2022/10/24/a-simple-cru... wherein I explore creating an ORM-like library via generics in Go, this may be of interest to you if you want a better understanding of how some of these things would work in Go.
genuinely interested in knowing why it is so. I quite like Go, but I also like Django, so I would like to know why a Django-like ORM would not be feasible.