AFAIK, no. There are some helper frameworks [1], but none of them is dominant. Two possible reasons: it's quite easy to write a (web) service with the library functions (it even includes a gzip stream), and it's practically impossible to write an ORM framework like you have in Java and Python, so the Go frameworks I've seen are basically a bunch of helper functions.
> 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.
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.
> 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
From what I've seen yes. So in practice every go app is a custom & unique framework. Same problem as react. This was also the norm in php until laravel got popular a few years ago.
IMO it's a rough way to make a web page but people keep doing it so it must have some advantages.
Not a go dev but I have dabbled. I get the impression that the sweet spot for go is not in building standard crud web apps but for specialised network services and tooling. For those reasons big heavy frameworks don’t seem popular.
It’s not that we roll all our own stuff it’s just that most of us avoid opinionated frameworks. Example I’d wager most go backends are using gorm or sqlx because rolling your own orm would be insane for most
