It's there a "default" web framework for Go which most of people use?
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.
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.
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.
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.
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.
IMO it's a rough way to make a web page but people keep doing it so it must have some advantages.
The standard library defines some decent interfaces already around HTTP handling and SQL calls. Most libraries are built to integrate with them. Then interfaces like io.Reader and io.Writer mean you can pretty much use anything to read requests and write responses.
This means that usually you're composing libraries and some application code together, rather than building everything on top of some jack of all trades framework. You get to choose the best tool for each job.
Yeah, that’s not the hard part at all. What about routing, converting from/to json/params/cookies safely, sessions, authz/n..
> What about routing, converting from/to json/params/cookies safely All supported out of the box with the standard library. It's also table stakes, and not the hard part.
> sessions, authz/n
This is where you need to step out of the standard