[halfcat]

This whole comment has strong C language “we don’t need a package manager, we write everything ourselves” vibes.

The benefit of something like Django is it provides strong convention, loosely enforced. Everyone on your team needs to know one thing. Everyone can understand the convention, understand each other’s code, new features get added the same way. But it’s also loosely enforced, it’s just Python. So when you need to split from the framework’s convention, you have unlimited escape hatches.

If you want a case study, see Instagram.

[sethammons]

My work has 50 eng teams. We started on django and our internal standards team have depreciated it - no further projects in django. We are applying the strangler pattern the best we can, everything new in Go if we can.

The django code is so intertwined and full of circular imports. Custom db managers to handle our multiple dbs with read-replica routing, custom caching solutions, and everything inherits from something and base classes have insane child-type checks and methods that are only used in one child class. And due to the ease of passing query sets around, we have complex and slow joins and n+1 queries everywhere. And object properties that are actually methods that call and cache from the db, so sneaky n+1.

The unlimited escape hatches in python has turned into welded spaghetti making development and organizational velocity slow.

[bborud]

> “we don’t need a package manager, we write everything ourselves” vibes

Then I'm afraid you misunderstood.

Frameworks is not the only way to build things efficiently. It is actually possible to build things using libraries and consistent ways of structuring things.

Also, we're talking about Go, so please use Go examples. Django isn't interesting in this context. Have a look at how you'd leverage the standard library, and perhaps a couple of libraries in Go to do the same.