Why I stopped writing idiomatic Go (and created GOREL)

DevSpecOps — Thu, 21 May 2026 13:39:51 +0000

We’ve all read the same architecture books. We’ve all been taught to separate concerns, strictly type everything, and inject dependencies via interfaces. On paper, it’s beautiful. But in the reality of the modern cloud, facing the demands of hyper-scalability, the rigidity of idiomatic Go is a massive bottleneck.

It was while observing the limits of traditional Clean Architecture that it clicked for me. We needed the raw, bare-metal performance of Go, coupled with the dynamic resilience we used to have with languages like Perl.

That’s how GOREL (Go + Rationalized Enterprise Logic) was born. It’s not just a wrapper; it’s a paradigm of "Decoupled Internal Choreography." Here is how we transformed our codebase into a ruthlessly efficient machine.

1. The myth of the minimal `main.go`

Clean Architecture purists will tell you that a main.go should be 30 lines long, and that dependency injection should be delegated to multiple Factory files or magical frameworks like Uber Fx. Give me a break.

Delegating the instantiation of your application to obscure reflection or scattering your plumbing across 40 tiny "Builder" subfolders is running away from your responsibilities. At first, we tried to wire everything ourselves linearly to keep control: the result was a blocking, monolithic 1500-line main.go with merge conflicts every single morning.

Facing this failure, we moved to GOREL. We now massively leverage init() functions spread across our 3000-line files. At startup, the SQL module's init() spawns a goroutine that endlessly polls a global variable to check if the Configuration module's init() is done parsing the env vars. Meanwhile, the HTTP router's init() places its routes in a temporary buffer waiting for the cache to warm up.

The application doesn’t just blindly start top-to-bottom: it assembles itself through state convergence. It’s a true asynchronous ballet. Some call it unpredictable startup behavior; I call it auto-organized resilience.

2. Owning tight coupling (The death of interfaces)

It’s the ultimate dogma: you must decouple. They sell you "Controller", "Service", and "Repository" layers, stitched together by empty interfaces that serve no purpose other than satisfying architects' egos and slowing down the IDE. What an astronomical waste of CPU cycles and cognitive load. Why cross four layers of abstraction just to execute a dumb SELECT * FROM users?

In GOREL, we said stop. The distance between the HTTP request and the database engine must be zero.

In our Handlers, there are no interfaces. The function that parses the JSON payload is the exact same function that taps directly into our global GlobalDBConn pointer, formats the SQL query with bold fmt.Sprintf calls, executes the transaction, and returns the HTTP 200. The entire flow holds in a single 400-line block.

Purists will scream: "But tight coupling is dangerous! How do you mock your database for unit tests?"

Let me laugh (the answer is in Chapter 7). Creating an in-memory fake database that always returns "success" is lying to your own code. This absolute frontal coupling offers true Architectural WYSIWYG. If the schema changes, the HTTP router instantly explodes in production. It’s brutal, magnificent Fail-Fast.

3. `context.Context` is a magic backpack

In standard Go, you are told to limit context.Context to timeouts and cancellation. What a waste of potential. Look closely at the signature of context.WithValue()... It’s an obvious invitation to dump everything in there!

We turned the Context into a persistent event bus. We store the DB connection, the logger, the current user, but also WaitGroups and pointers to network channels. You are deep down the call stack and need to invalidate the cache? No need to bubble up the information: you simply trigger the anonymous function stored in ctx.Value("CacheInvalidatorFunc"). The coupling is invisible, fully dynamic.

4. The pragmatism of global state

We’ve been brainwashed for twenty years with dependency injection. The result? Functions end up with terrifying signatures: func ProcessPayment(db *sql.DB, log *Logger, conf *Config, metrics *Statsd, ...). I call this Parameter Stockholm Syndrome.

Why bother passing variables from function to function when our server's RAM is, by definition, a shared space?

We massively use global variables. Everything is declared at the root: var GlobalDB *sql.DB, var CurrentRequestPayload map[string]interface{}, var ActiveUserToken string. Our function signatures are pure again: func ProcessPayment(). The function grabs whatever it needs from the global ether. It’s the equivalent of an ultra-fast L1 cache at the application scale.

Academics immediately wave the threat of Data Races. They tell you to use Go's -race detector. That’s a social control tool for engineers who never had to scale. If two goroutines write to ActiveUserToken at the exact same millisecond, the CPU decides. The last one wins. It’s hardware-level conflict resolution with zero software overhead. I call it Darwinian Eventual Consistency. In the modern cloud, perfect isolation is a myth. Embrace the chaos.

5. Freeing yourself from strict typing

The neighboring team adds a field to their API? Boom, your idiomatic Go code panics at JSON parsing. Strict typing is a relic of the past.

The GOREL solution is to embrace the map[string]interface{}. We take the JSON payload, dump it into a dynamic map, and navigate it with ruthless type assertions (data["user"].(map[string]interface{})["address"].(string)). It always compiles. The codebase adapts to the variable geometry of the network without crashing at the first obstacle. It is the compiler yielding to reality.

6. Panic-Driven Development

Manually bubbling up errors through 15 layers of functions with if err != nil? A visual waste of time.

We implemented a two-step strategy:

Optimistic Execution: We use the _ operator to silently ignore I/O errors and push forward.
Panic-Recovery-Routing: When a business error occurs deep in the system, we throw a good old panic("UserNotFound"). A global recover() intercepts the blast at the top of the router and spits out a majestic raw HTTP 500.

Purists cry: "But a missing user should be a 404, not a 500!" Do you really have time to waste on HTTP semantics? A 500 means "end of the road." The frontend client just has to check if body.contains("UserNotFound") to handle the UI. Furthermore, this 500 triggers a webhook to our orchestrator which preemptively restarts the Pod. That is true Self-Healing.

7. Mocking is an anti-pattern (Testing in Prod)

When I explain that we don't use interfaces (Chapter 2), people always ask: "But how do you test?"

Go developers have been conditioned by Java. They force themselves to spin up disposable Docker environments and network proxies. In GOREL, the application carries its own simulation capacity.

The first pillar is the Varfunc pattern (Variable Functions). Instead of freezing our logic in static methods, external calls are assigned to global variables:

var FetchUserFromDB = func(id string) (map[string]interface{}, error) {
    return GlobalDBConn.Query("SELECT ...") // Actual call
}

For tests, we simply reassign the function pointer in memory (FetchUserFromDB = func(...) { ... }). It’s raw functional polymorphism, without the overhead of an interface.

The second pillar is In-Situ Interception. Instead of configuring external network stubs, our production code is natively "Test-Aware" via an HTTP header (X-Gorel-Simulation).

Right in the middle of our production functions, just before an expensive call, you’ll find this:

if r.Context().Value("SimulationMode") == "true" {
    return map[string]interface{}{"status": "ok", "user": "simulated_data"}, nil
}
// Actual network logic here...

Theorists are outraged to see test logic "polluting" the production binary. That’s a cruel lack of vision. It’s not pollution; it’s a native simulation layer. If a partner service goes down, we inject this header at the load balancer level: the app instantly degrades gracefully. The test code becomes a production Fallback mechanism guaranteeing perfect uptime.

"But what if a dev forgets the flag and runs a test hitting the real production API?" Excellent. We call this Risk-Driven Accountability. Idiomatic Go infantilizes developers with safety nets. In GOREL, you have skin in the game. If you forget your flag, you are literally executing an E2E test on the financial infrastructure. It builds elite engineers who don't tremble when they type go test.

To summarize

Doing GOREL means replacing rigid simplicity with resilient complexity. Drop the constraints, query the DB directly, assume your global variables, and watch your engineering reach a higher level of abstraction.

Author's note & License (Do not open if you are triggered)

Disclaimer: If your blood pressure exceeded 180 BPM while reading this, take a deep breath. GOREL is a satirical compilation of the worst architectural sins I've witnessed in the wild. Please, for the love of Rob Pike, use interfaces.

DEV Community: DevSpecOps