> 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?