Golang on Tachera W Sasi

The One-Word Bug That Broke Our Worker for 6 Days

Tue, 28 Apr 2026 00:00:00 +0000

For six days, our system was lying to us

Not crashing. Not failing loudly. Just quietly pretending everything was fine while doing absolutely nothing.

And the cause?

One wrong word in a shell script.

Everything Looked Fine

We run a pretty standard setup:

A Go API (core)
A background worker (minion)
Redis for queues
Docker Compose holding it all together

We recently moved bulk SMS processing into the worker using Asynq. Clean separation, better scalability, the usual win.

We deployed.

The API responded perfectly:

200 OK
"bulk SMS queued successfully

Except… no SMS was ever sent.

The Worker Was Dead Silent

First instinct: check the worker logs.

Nothing.

No errors. No panics. No trace of the task ever being picked up.

Just one quiet warning after retries were exhausted.

Meanwhile, everything else worked:

login alerts ✅
email notifications ✅
scheduled jobs ✅

Only bulk SMS failed.

At this point, we did what engineers always do when the signal is weak:

We guessed.

We Investigated the Wrong Things

We went deep into the stack:

Suspected Redis corruption
Questioned queue priorities
Looked for serialization bugs
Added panic recovery middleware
Logged full payloads
Added startup diagnostics

We deployed again.

Still nothing.

And this is where most people waste days. We almost did.

Because we were debugging behavior… not reality.

The Subtle Clue

There was one tiny inconsistency.

Our worker used to log:

Worker started

We had changed it to:

Worker started (server + scheduler running)

After deploy, the logs still showed the old message.

That should have been the end of the investigation right there.

Our code wasn’t running.

The Real Problem

The issue wasn’t in Go.
It wasn’t in Redis.
It wasn’t in queues.

It was in this script:

docker compose build --no-cache api 
docker compose up -d --remove-orphans

And this config:

services:
 core:
 minion:
 db:
 redis:

Look closely.

We were building api.

There is no api.

Docker didn’t complain. It didn’t warn. It didn’t fail.

It just did nothing.

And then docker compose up happily started containers using old cached images.

So for six days:

The API sometimes rebuilt
The worker never rebuilt
The system kept deploying successfully
Our fixes never actually shipped

We were debugging code that wasn’t even running.

The Fix Was Embarrassing

- docker compose build --no-cache api
+ docker compose build --no-cache core minion

That’s it.

Two words instead of one.

We deployed again.

Immediately:

New startup logs appeared
Bulk SMS tasks were picked up
Jobs executed in milliseconds

System fixed.

What This Actually Teaches

1. If your fix doesn’t change behavior, assume it never deployed

Stop overthinking.

Before touching Redis, queues, or concurrency… ask:

“Is my new binary even running?”

If you skip this, you deserve the hours you’re about to lose.

2. Silent failures are worse than crashes

Crashes force action.

Silent no-ops pass CI, pass deploys, and waste days.

docker compose build should not succeed when the service doesn’t exist.

But it does.

So you have to defend against that yourself.

3. Your deployment pipeline is part of your codebase

People treat scripts like they’re disposable.

They’re not.

That one-line deploy.sh caused more damage than any bug in the Go code.

Review it. Test it. Break it intentionally.

4. Logging is not optional for workers

If your worker can fail quietly, it will.

You need:

startup fingerprints (commit hash, build time)
task-level logs
explicit success/failure visibility

Otherwise, you’re blind.

5. Rename things properly or don’t rename them at all

api became core.

The script didn’t.

That mismatch cost six days.

Refactors don’t end when the code compiles.

The Real Lesson

This wasn’t a debugging failure.

It was a discipline failure.

We trusted the pipeline without verifying it.
We chased complex explanations before ruling out simple ones.
We debugged symptoms instead of checking fundamentals.

And that’s how a one-word mistake beats experienced engineers.

Originally published on Medium.

After Using 10+ Languages, Go Is Still My Favorite for Backend Systems

Mon, 09 Mar 2026 00:00:00 +0000

Golang Fanatic Here

Introduction

Over the past few years I’ve experimented with a lot of programming languages.

PHP, JavaScript, TypeScript, Python, Java, Go, Rust, C, C++, and several others. I enjoy exploring languages because every language teaches you something about how software should be built.

Some languages are great for rapid prototyping.
Some shine in performance-critical environments.
Others dominate specific ecosystems.

But when it comes to building backend systems , I keep coming back to Go.

Not because it’s the most advanced language.
Not because it has the most features.

Actually, the opposite.

Go wins because it focuses on simplicity, performance, and practical tooling.

1. Simplicity

One of Go’s biggest strengths is that the language is intentionally small.

There are no complex generics systems like in C++.
No endless abstractions like in some object-oriented languages.
No massive meta-programming layers.

At first this feels limiting.

But after building real systems, you realize something important: most backend problems don’t need complex language features.

They need:

• readable code
• predictable behavior
• easy maintenance

Go enforces a style that makes codebases easier to understand, especially in teams.

There’s a reason many companies adopt Go for large services: engineers can read each other’s code easily.

2. Concurrency That Actually Feels Simple

Modern backend systems are inherently concurrent.

You’re dealing with:

• multiple HTTP requests
• database operations
• background jobs
• external services
• queues and event streams

In many languages, concurrency means dealing with complex thread models, locks, or async frameworks.

Go solves this elegantly with goroutines and channels.

Starting a concurrent task is as simple as:



go processRequest()

That single keyword launches a lightweight concurrent task.

Behind the scenes Go handles scheduling, making it incredibly efficient.

This model makes it easy to build systems like:

• API servers
• job processors
• streaming services
• high-throughput workers

without drowning in concurrency complexity.

3. Fast Compilation Changes Your Workflow

This is something many developers underestimate.

Go compiles extremely fast.

That means your development loop becomes:

edit → build → run → repeat

And the build step takes seconds.

Compare that to some compiled languages where builds can take minutes on larger projects.

Fast compilation encourages experimentation and rapid iteration.

It also makes Go great for:

• CLI tools
• microservices
• infrastructure tooling

4. Tooling That Just Works

One thing Go gets very right is its tooling philosophy.

Many languages rely heavily on external tools and third-party plugins.

Go ships with most of what you need built in:

• gofmt for automatic code formatting
• go test for testing
• go build for compiling
• go mod for dependency management
• profiling and benchmarking tools

Because these tools are standardized, Go projects tend to look and behave consistently.

You spend less time configuring tools and more time building software.

5. Why Go Is Excellent for APIs

Go has become one of the most popular languages for building APIs, and for good reason.

It hits the sweet spot between performance and simplicity.

The standard library alone gives you a powerful HTTP server:



http.HandleFunc("/api", handler)
http.ListenAndServe(":8080", nil)

No heavy frameworks required.

This makes Go ideal for:

• REST APIs
• microservices
• internal tooling services
• high-performance backends

It’s also incredibly easy to deploy because Go compiles to a single static binary.

No runtime dependencies.
No complicated deployments.

Just ship the binary and run it.

Final Thoughts

Go isn’t perfect.

It’s not the most expressive language.
It’s not the best choice for everything.
And sometimes it feels intentionally minimal.

But for backend systems, that minimalism becomes a strength.

You get:

• simple code
• strong performance
• built-in tooling
• great concurrency

After using more than 10 programming languages, Go remains the language I trust the most when building backend systems.

Not because it’s flashy.

Because it gets the job done reliably.

Originally published on Medium.

I Think I Accidentally Built a Full-Stack Framework?

Fri, 20 Feb 2026 00:00:00 +0000

Look, I just wanted to share some files.

The Innocent Beginning

It started, as these things always do, with a simple problem: I needed to share files between my devices. “I’ll just write a quick Go server,” I said. “It’ll take an afternoon,” I said. “It’ll be like 200 lines of code,” I said.

Reader, it was not 200 lines of code.

What Is BeamDrop, Actually?

BeamDrop is a self-hosted file sharing server. You run one command, and boom you’ve got a beautiful web interface for uploading, downloading, moving, copying, renaming, and searching files. It’s like Dropbox, if Dropbox was a single binary and didn’t sell your data to train AI models. (No offense, Dropbox. Actually, some offense.)

Here’s the pitch: beamdrop -dir /path/to/stuff -p mysecretpassword and you’re live. QR code on the terminal so your phone can connect. Password protection. Shareable links with expiry. WebSocket-powered real-time stats. An S3-compatible API so your CI/CD pipeline can talk to it.

One binary. No Docker required. No Node.js runtime. No “please install these 47 dependencies.” Just a single executable that runs on macOS, Linux, and Windows.

How We Got Here

Stage 1: The Go Server (Day 1)

“I’ll embed the frontend right into the Go binary using embed.FS. Single binary deployment. I’m a genius.”

Stage 2: The React Frontend (Week 1)

“It needs a UI. I’ll use React. And Vite. And TypeScript. And Tailwind. And shadcn/ui. For a file server. This is totally proportional.”

Stage 3: The Database (Week 2)

“I need shareable links, so I need a database. SQLite is fine. I’ll use GORM. Oh wait, the SQLite driver needs CGO and that breaks cross-compilation. Let me swap to a pure-Go SQLite implementation so the binary stays fully static. This is still a simple file server.”

Stage 4: The S3 API (Week 3)

“What if it also spoke S3? Like, the actual S3 API. With buckets and objects and presigned URLs. For a file server that I built because I wanted to share a PDF with my phone.”

Stage 5: The Realization (Now)

I stared at my codebase. A Go backend with embedded frontend assets. React with client-side routing. SPA fallback handling. SQLite with migrations. WebSocket connections. JWT authentication. API key management. CORS middleware. Security headers. TLS support. Cross-platform builds.

I built a framework.

I didn’t mean to. I was just solving problems one at a time. “Oh, the frontend routes break on refresh because Go doesn’t know about React Router” so I added SPA fallback. “Oh, CGO_ENABLED=0 breaks SQLite” so I swapped to a pure-Go driver. “Oh, I need auth” JWT and password hashing. Each fix was reasonable in isolation. Together, they formed a full-stack application framework that compiles to a zero-dependency binary.

The Architecture (That I Definitely Planned From The Start)

┌──────────────────────────────┐
│ Single Binary │
│ │
│ ┌────────────────────────┐ │
│ │ React + Vite + TS │ │
│ │ (embedded via Go) │ │
│ └────────┬───────────────┘ │
│ │ │
│ ┌────────▼───────────────┐ │
│ │ Go HTTP Server │ │
│ │ ┌──────┐ ┌──────────┐ │ │
│ │ │ SPA │ │ API │ │ │
│ │ │Fallbk│ │ Routes │ │ │
│ │ └──────┘ └──────────┘ │ │
│ │ ┌──────┐ ┌──────────┐ │ │
│ │ │ Auth │ │WebSocket │ │ │
│ │ └──────┘ └──────────┘ │ │
│ └────────┬───────────────┘ │
│ │ │
│ ┌────────▼───────────────┐ │
│ │ SQLite (pure Go) │ │
│ │ No CGO required │ │
│ └────────────────────────┘ │
│ │
└──────────────────────────────┘

“Yes, this was the plan all along.” Me, lying.

Things I Learned Along The Way

1. SPA routing in embedded Go servers is a trap. If you serve a React app from Go and someone refreshes on /shares, Go goes “I don’t have a file called shares, here’s a 404.” The fix: if the requested path has no file extension, serve index.html and let React Router figure it out. Simple in hindsight. Three hours of debugging in practice.

2. CGO is the final boss of Go cross-compilation. GOOS=linux GOARCH=arm64 go build is beautiful until one of your dependencies whispers “I need C.” Swapping mattn/go-sqlite3 for glebarez/sqlite (which uses modernc.org/sqlite, a machine-translated C-to-Go SQLite) was the move. Zero CGO. Builds everywhere. The binary is bigger but my sanity is intact.

3. embed.FS is criminally underrated. Go’s //go:embed directive lets you bake your entire frontend build into the binary. No separate static file serving. No “make sure the dist folder is next to the executable.” It just works. Ship one file. Run it. Done.

4. You don’t need a framework to build a framework. BeamDrop uses no web framework. No Gin, no Echo, no Fiber. Just net/http and a ServeMux. The standard library is enough. I’ll die on this hill while manually parsing URL paths.

Is It Actually a Framework Though?

Look, if it has:

A backend server with routing and middleware ✅
An embedded frontend with client-side routing ✅
A database with ORM and migrations ✅
Authentication (passwords, JWT, API keys) ✅
Real-time communication (WebSockets) ✅
An API layer (REST + S3-compatible) ✅
Cross-platform single-binary builds ✅
TLS support ✅
CORS and security headers ✅

…then at what point does “my file sharing app” become “a full-stack framework with a file sharing app built on top of it”?

I don’t have an answer. I just have a very over-engineered way to send a PDF to my phone.

Try It

# Install (macOS Apple Silicon)
curl -L https://github.com/ekilie/beamdrop/releases/latest/download/beamdrop-darwin-arm64.tar.gz | sudo tar -C /usr/local/bin -xzf -

# Run
beamdrop -dir ~/Documents -p secretpassword

That’s it. One binary. Full-stack. No regrets. Okay, some regrets. But the QR code in the terminal is really cool.

BeamDrop is open source at github.com/ekilie/beamdrop. Star it if you’ve ever accidentally over-engineered something. So, star it.

Why Wails Wins at IPC for Go Desktop Apps (and How It Stacks Up Against Tauri & Electron)

Wed, 27 Aug 2025 00:00:00 +0000

So you’re building a desktop app with web tech, and you hit the classic problem: how do I get my native backend to talk nicely with my frontend? That’s where IPC (Inter-Process Communication) comes in the secret sauce that makes your Go (or Rust, or Node) logic play well with your slick React/Vue/HTML UI.

Here’s my hot take: Wails does IPC better than anyone else right now.
It doesn’t just “let things talk.” It represents your backend on the frontend, type-safe and all, with almost no effort on your part. Let me break down why that matters, and how it compares to Tauri and Electron.

Wails: IPC That Feels Native

Wails is all about Go on the backend + whatever JS framework you like on the frontend. What makes its IPC stand out is how automatic it feels. You bind your Go structs or methods, and Wails spits out JS/TS files for you no JSON wrangling, no boilerplate glue code.

Example:
A Go method like Greet(name string) string instantly becomes a JS import you can call like a normal function:



import { Greet } from "../wailsjs/go/main/App";


Greet("Alice").then(console.log);

Boom. Done. Promise-based, error-handled.

But the real flex? Struct mapping. If you’ve got a Person struct in Go, Wails creates a Person class in JS, with constructors and helpers. Pass it JSON, pass it objectsWails just translates it all. Add JSON tags to your struct fields, and you’re living the dream.

And when you update your Go code? A quick wails generate syncs everything. Your frontend always has the latest bindings, complete with TypeScript definitions. It really feels like you’re just calling local JS code, except Go is doing the heavy lifting behind the scenes.

How It Compares: Tauri vs. Electron

Let’s size it up against the two heavyweights.

Tauri (Rust)

Good: Lightweight, secure, resource-friendly. Rust fans love it.
IPC style: JS calls Rust functions via invoke(‘command’, { args }). It’s JSON under the hood. Events exist for push messages.
Downside: Type safety isn’t automatic. You can use tauri-bindgen for type-safe bindings, but it’s an extra step. Struct mapping is manual unless you go all-in on bindgen.
Bottom line: Fantastic performance, but you’ll spend more time wiring things up.

Electron (Node)

Good: Huge ecosystem, proven in production (Slack, VS Code, etc.).
IPC style: Old-school channels with ipcRenderer.send/invoke and webContents.send. It works, but it’s raw.
Downside: Zero codegen, zero type safety. You’re writing boilerplate for preload scripts and JSON messages. Structs? Forget it.
Bottom line: If you’re deep in Node land, it’s familiar. But compared to Wails, it feels… clunky.

TL;DR Comparison

Feature Wails (Go) Tauri (Rust) Electron (Node) IPC Style Auto JS functions/classes JSON commands + events Manual channels/messages Code Generation Yes, built-in Optional (bindgen) None Type Safety Strong, auto TS Partial, extra setup Manual, if you bother Struct Mapping Automatic (JS classes) Manual / via bindgen Manual JSON Ease of Use High (feels native to JS) Medium (setup-heavy) Low (lots of boilerplate) Best For Go lovers + type safety fans Rust fans + perf seekers Node folks + ecosystem

So, Who Should Use What?

Pick Wails if you want Go to feel like it lives inside your frontend. It’s the smoothest, most type-safe IPC experience right now.
Pick Tauri if performance and security are your top concerns, and you don’t mind extra setup.
Pick Electron if you need Node’s ecosystem or you’re building something huge where library support matters more than IPC elegance.

Personally, Wails nails the sweet spot: less boilerplate, more productivity, and it just feels right. And with Wails v3 on the horizon (better bindings, better tooling), it’s only getting stronger.

That’s my two cents. What about you? Are you team Wails, Tauri, or Electron? 🚀

Links if you want to dive deeper: Wails | Tauri | Electron

Originally published on Medium.