Rather than use a full-fledged framework, I would recommend combining orthogonal packages such as

- julienschmidt/httprouter [1] for routing,

- jmoiron/sqlx [2] for SQL access, and

- gorilla/websocket [3] for websockets

sqlx isn't an ORM; it's more a convenience wrapper around the standard library's database/sql package.

gorm is the nicest ORM I've found, but I think even the well-written ORM packages are unnatural to use because of restrictions in Go's type system.

(Sorry if this isn't the kind of answer you were hoping for.)

[1] https://github.com/julienschmidt/httprouter

[2] https://github.com/jmoiron/sqlx

[3] https://github.com/gorilla/websocket

Iris is a poorly maintained project that I would not recommend for production use.

See the drama unfold at https://www.reddit.com/r/golang/comments/57w79c/why_you_real... and https://www.reddit.com/r/golang/comments/57tmp1/why_you_shou...

This is totally propaganda, they spamm those links without even reading the code. Florin is clearly putting lies to a part of the community to deflame the Iris via the slack golang chat. He's also banned the author of the web framework without notice or any other action from his behalf. Is this a healthy relation between an author of a popular software and a guy who never wrote a single line of code?

Well, it _seemed_ nice. Regardless, I'm a bit more concerned with back-office scaffoldings myself. Any pointers?

I wrote a scaffold generator here you may find interesting.

https://github.com/fragmenta/fragmenta

It’s fairly simple to write some simple generator using the built in text/template package if all you want are admin scaffolds.

Note the dates and you'll see the truth, if you're a programmer you can also read the code, Iris doesn't even use the libraries the 1+ year old article claims to be used there.

I regularly go down this road with go. My conclusion is that it's never going to suit that use case. I'm not even sure it's not technically doable (i think introspection and interface{} can go quite far), but it's just culturally opposed to this kind of project.

People like go for its minimalist approach. Not in the sense that you don't have a lot of code to write, but more in the sense that you are in control of everything that happens, and that you can read an understand every part of your codebase.

ORMs , code gen, magic wrappers, etc is something that people in that community just hate.

> ORMs , code gen, magic wrappers, etc is something that people in that community just hate

Mostly agree except for code-gen --- definitely not so in the real world! I'd say most Gophers on the whole at a minimum don't mind it, and many either outright ---or eventually--- embrace it.

Depends on the nature and purpose(s) of the Go code-base but for many, it's as natural and idiomatic as is the extensive use of the macro preprocessor for many-perhaps-most grown, matured, "non-trivial" C code-bases. (Just fewer pitfalls in exchange for a bit more set-up effort.)

I’m the same way - I have lots of side project ideas I’d love to use Go for but get that early Rails like productivity. I maintain a few Rails apps and now view many of the things I’ve done as hacks to work around the lack of concurrency (though that was just Rails’ reality in late 2000s).

Elixir is close to my ideal though I like static types and a better community around libs would be nice.

You might be interested to check out https://gobuffalo.io/

I understand that, which is why I said "ORM(ish)". But a back-office scaffolding would go a long way to move some of us off of Django.

Why do you want to move off of Django?

Because we're all using Go for other projects (even if piecemeal) and would like to build the entire project in a single language.

i personaly only would use go for very technical, low-level middlewares (as in, just above the OS layer) involving networks.

The good side to it being simple to understand and maintain is that you won't pay a lot of debt if you're adding it to your stack.

There isn't a single language that fits all use case perfectly anyway, so we'd have to just go to the "best tool for the job" approach in the meantime.

> i personaly only would use go for very technical, low-level middlewares.

Care to extend upon why you don't feel go is a good fit for other programming?

I'd argue that what you probably want in a new project (possibly with legacy db), is a graphql wrapper for your db, and a single-page js app (react/vue/elm/etc.) front-end.

Which means the server side would need a way to wrap the db for graphql (along with a way to set up authorization), and the front-end would need to be able to discover/generate the crud parts.

If you really want a "legacy"/"traditional" framework (fat appserver handling form input, rendering html, talking to db backend), I think the mature ones will be hard to beat (eg: django).

Look into https://github.com/markbates/pop

And the rest of Marks (and others) buffalo https://gobuffalo.io/

I really like Goa: https://github.com/goadesign/goa - it has integration with Gorm via Gorma: https://github.com/goadesign/gorma