Writings on Tachera W Sasi

Why io.Copy Is One of Go's Most Powerful Functions

Mon, 04 May 2026 00:00:00 +0000

Most Go developers use io.Copy() early in their journey.

Usually for:

copying files
downloading HTTP responses
writing buffers

But many never realize this tiny function is sitting at the center of:

proxies
reverse proxies
SSH tunnels
database gateways
streaming systems
TCP forwarders
container runtimes
load balancers

This line:



io.Copy(dst, src)

is deceptively powerful.

Especially when you realize:in Go, sockets are just streams.

And streams are just:

io.Reader
io.Writer

Once that clicks, networking becomes MUCH simpler.

The Beautiful Simplicity

Consider this tiny PostgreSQL TCP proxy:



package main

import (
 "io"
 "log"
 "net"
)
const (
 LISTEN_ADDR = ":5433"
 PG_ADDR = "localhost:5432"
)
func main() {
 ln, err := net.Listen("tcp", LISTEN_ADDR)
 if err != nil {
 log.Fatal(err)
 }
 for {
 client, err := ln.Accept()
 if err != nil {
 continue
 }
 go handle(client)
 }
}
func handle(client net.Conn) {
 defer client.Close()
 server, err := net.Dial("tcp", PG_ADDR)
 if err != nil {
 return
 }
 defer server.Close()
 go io.Copy(server, client)
 io.Copy(client, server)
}

That’s it.

No packet parsing.
No protocol handling.
No PostgreSQL driver.

Yet this already works as a real TCP proxy.

Why?

Because TCP connections in Go implement:

io.Reader
io.Writer

Which means:

you can read from them
write to them
stream data between them

Understanding the Core Idea

This line:



io.Copy(server, client)

means:continuously read bytes from client and write them into server And this line:



io.Copy(client, server)

means:continuously read bytes from server and write them into client Together they create:

bidirectional communication
full duplex streaming

Full Duplex Communication

Most network protocols are two-way conversations.

The client sends data.
The server responds.
Both sides can speak independently.

Your browser and a web server.
SSH client and SSH server.
PostgreSQL client and PostgreSQL server.

All of them rely on duplex communication.

Visually:



client <=========> proxy <=========> server

Your proxy becomes a pipe.

And io.Copy() is what keeps bytes flowing through that pipe.

Why Goroutines Matter Here

This part is critical:



go io.Copy(server, client)
io.Copy(client, server)

Without the goroutine, communication would block.

You need:

one stream for client -> server
another stream for server -> client

simultaneously.

That’s what enables real-time two-way communication.

The goroutine handles one direction.
The main goroutine handles the other.

Tiny code.
Massive capability.

Sockets Are Just Streams

This is one of the most important concepts in systems programming.

In Go:



type Conn interface {
 Read(b []byte) (n int, err error)
 Write(b []byte) (n int, err error)
}

A socket behaves like:

a file
a buffer
stdin/stdout
an HTTP body

Everything becomes composable through interfaces.

This is why Go networking feels elegant.

You stop thinking:“I’m working with TCP packets” and start thinking:“I’m moving streams between readers and writers” That abstraction is incredibly powerful.

Memory Efficiency

Another reason io.Copy() is excellent:
it streams data incrementally.

It does NOT:

load everything into memory
allocate giant buffers
wait for full payloads

Internally, it uses reusable buffers and streams chunks continuously.

This makes it ideal for:

large files
long-lived connections
proxies
streaming systems

Even multi-GB transfers remain memory efficient.

This Pattern Exists Everywhere

Once you notice it, you’ll see this pattern everywhere.

Reverse Proxies

Forward HTTP traffic between clients and servers.

SSH Tunnels

Forward encrypted streams between hosts.

Database Proxies

Like PgBouncer or custom DB gateways.

VPNs

Moving packets through encrypted streams.

Load Balancers

Forwarding connections across machines.

Container Systems

Streaming logs, exec sessions, and IPC.

A huge amount of infrastructure software is basically:carefully managed stream forwarding.

The Hidden Superpower of Go

Go’s standard library encourages composition over complexity.

Instead of giant networking frameworks:

readers
writers
interfaces
goroutines

become enough to build real infrastructure.

This is why Go became dominant in:

cloud infrastructure
Kubernetes tooling
networking software
distributed systems

The primitives are small.
But they scale extremely far.

Final Thoughts

io.Copy() looks boring at first.

But behind that tiny function is a core systems programming idea:move streams between abstractions efficiently Once you deeply understand that:

proxies make sense
tunnels make sense
reverse proxies make sense
networking becomes less magical

And you start realizing:
some of the most powerful infrastructure on the internet is built from surprisingly small primitives.

Originally published on Medium.

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.

What Building malloc Taught Me About Memory

Fri, 13 Mar 2026 00:00:00 +0000

Modern developers rarely think about memory.

We call malloc, new, or let a garbage collector handle everything. Most of the time that’s perfectly fine. But recently I decided to dig deeper and implement a very small version of malloc myself.

Not to replace real allocators. Just to understand what actually happens under the hood.

The result was surprisingly simple and incredibly educational.

This post walks through the core ideas.

Why Understanding Memory Still Matters

Most software today runs on layers of abstraction.

Frameworks → languages → runtimes → operating systems.

That’s powerful, but it also means many developers never see the foundations those layers are built on.

Understanding memory allocation helps with:

• writing faster software
• debugging memory issues
• understanding how runtimes work
• building systems tools
• designing better APIs

Even if you work in higher level languages like Go , these concepts still power everything underneath.

Step 1: Where malloc Gets Memory

When a program runs, memory roughly looks like this:



Code
Globals
Heap ← grows upward
Stack ← grows downward

malloc allocates from the heap.

Under the hood, the allocator asks the OS for more heap space using a system call like sbrk().

Example:



void *ptr = sbrk(1024);

This moves the program break forward by 1024 bytes and returns a pointer to the new memory.

Think of it like extending the end of your program’s heap.

Step 2: The Naive Allocator

The simplest possible allocator would just call sbrk.



void *my_malloc(size_t size) {
 return sbrk(size);
}

But this immediately creates a problem.

If you later call free, the allocator has no idea :

• how big the allocation was
• where the next block starts
• whether a block can be reused

So real allocators store metadata.

Step 3: The Hidden Header Trick

Every allocation secretly stores a small header before the memory returned to the user.

Memory layout:



[ HEADER ][ USER MEMORY ]

The header might contain:



size
is_free
next_block

Example structure:



typedef struct block_header {
 size_t size;
 int is_free;
 struct block_header *next;
} block_header_t;

When the allocator returns memory, it actually returns a pointer after the header.



return (void *)(block + 1);

Which means the user sees:



ptr → usable memory

While the allocator still has its metadata.

Step 4: Tracking Allocations

Blocks are usually tracked using a linked list.



heap_start
 ↓
[block A] → [block B] → [block C]

When malloc runs:

search for a free block big enough
reuse it if possible
otherwise request more memory from the OS

This keeps allocations fast and avoids unnecessary system calls.

Step 5: What free Actually Does

One surprising thing: free usually does not return memory to the OS.

Instead it just marks the block as reusable.



[HEADER free=1][memory]

Future allocations can reuse that block instead of requesting more memory.

What Real Allocators Do Differently

Real allocators (like the ones used by glibc) add several optimizations:

Block splitting



Free block: 100 bytes
Need: 20

Split into:



20 used
80 still free

Block coalescing

Adjacent free blocks merge together to reduce fragmentation.

Large allocation handling

Large allocations often use mmap instead of the heap.

Thread safety

Modern allocators maintain thread local arenas for performance.

What I Learned From This

Building even a tiny allocator reinforced a few important lessons.

Abstractions hide complexity, but the fundamentals still matter

Languages like Go make memory management easier, but the underlying principles are still there.

Performance often comes from understanding the layers below you

Understanding memory layout and allocation patterns helps explain why some code performs better than others.

Systems knowledge compounds

Once you understand memory allocators, many other topics suddenly make more sense:

• garbage collectors
• runtime design
• kernel memory management
• high performance servers

Final Thoughts

You don’t need to write your own allocator for production software.

But building one, even a small version, forces you to think like the runtime.

And that perspective is valuable.

The more you understand the layers beneath your tools, the better engineer you become.

GITHUB => https://github.com/tacheraSasi/malloc.git

Originally published on Medium.

What 200+ GitHub Repositories Taught Me

Tue, 10 Mar 2026 00:00:00 +0000

Golang Fanatic here.

After building and experimenting with more than 200 repositories on GitHub , I expected to come away with deep insights about architecture, design patterns, and cutting edge technology.

Instead, the most valuable lessons were much simpler.

Not the fancy stuff.
Not the hype.

Just the fundamentals that actually make projects useful.

Here are the biggest things I learned.

1. Finishing projects matters more than starting them

Most developers love starting projects.

New repo.
Clean codebase.
Perfect architecture.

Everything feels exciting at the beginning.

But the real value comes from finishing something , even if it’s imperfect.

When you finish projects you learn things you can never learn from half-built code:

deployment problems
real-world bugs
usability issues
performance bottlenecks
documentation gaps

Shipping forces reality into your ideas.

A tiny finished tool is worth more than 20 half-built experiments.

2. Simplicity beats cleverness

Early on I loved writing clever code.

Fancy abstractions.
Complex architectures.
Overengineered solutions.

But after maintaining projects over time, you realize something quickly:

Simple code survives.

Complex code becomes a burden.

The best tools I built were usually the ones with:

fewer dependencies
simple APIs
predictable behavior

Good software often looks boring.

That is usually a good sign.

3. Documentation is not optional

You only realize the importance of documentation when you revisit your own project six months later.

Suddenly you are staring at your own code wondering:

“Why did I design it like this?”

Good documentation does three things:

Explains why something exists
Shows how to use it quickly
Reduces future confusion

Even a small README with:

installation
examples
project goals

makes a massive difference.

The best projects respect the reader.

4. Small tools win

Some of my most useful repositories were not full applications.

They were tiny tools.

CLI utilities.
Scripts.
Developer helpers.

Small tools have advantages:

easier to maintain
faster to build
easier for others to adopt

A focused tool that solves one specific problem well can be more impactful than a large system trying to do everything.

5. Consistency beats motivation

Motivation is unreliable.

Some days you want to code for 10 hours.
Other days you want to do nothing.

But building many projects taught me that progress mostly comes from consistency.

Small steps every week:

improving a tool
fixing a bug
cleaning up documentation
finishing a feature

Over time this compounds into a large body of work.

6. Tooling matters more than trends

Developers chase new frameworks constantly.

But the projects that lasted the longest in my repositories were built with tools that had:

great tooling
fast iteration
simple deployment

When the tooling is good, you build faster.

When it’s bad, the project slowly dies.

7. Your portfolio becomes your thinking

Looking back at hundreds of repositories is like looking at a timeline of your thinking.

You see:

bad decisions
experiments
abandoned ideas
improvements over time

And that is the real value.

Not every repo needs to succeed.

Each one captures a moment where you tried to build something and learned from it.

Final Thought

Building many repositories doesn’t make you a better developer by itself.

But finishing projects , learning from them, and continuously improving your approach does.

In the end, the biggest lesson from 200+ repositories is simple:

Build things.
Finish them.
Keep going.

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.

Why Most Engineers Shouldn’t Build Distributed Systems (And Why I Did Anyway)

Thu, 05 Mar 2026 00:00:00 +0000

Distributed systems are one of the most fascinating areas in software engineering.

They’re also one of the fastest ways to accidentally create massive complexity.

A lot of engineers jump straight into microservices, container orchestration, and distributed architectures because it sounds scalable and modern.

But in reality, distributed systems introduce an entirely new category of problems.

When your system runs on a single machine, many things are simple.

Function calls are instant.
Memory access is predictable.
Failures are easier to understand.

For example, a local function call might look like this:



func processOrder(orderID string) error {
 order := getOrder(orderID)
 chargeCustomer(order)
 updateInventory(order)
 return nil
}

Everything happens inside one process.
No network. No timeouts. No partial failures.

But once your system becomes distributed, the same operation might involve multiple services communicating over the network.



func processOrder(orderID string) error {
 order, err := orderService.Get(orderID)
 if err != nil {
 return err
 }


 err = paymentService.Charge(order.CustomerID, order.Total)
 if err != nil {
 return err
 }


 err = inventoryService.Reserve(order.Items)
 if err != nil {
 return err
 }


 return nil
}

Now things become much more complicated.

What happens if the payment service succeeds but the inventory service fails?

What if the network times out but the request actually succeeded?

What if the service crashes halfway through the workflow?

These are common distributed system problems.

Failures Become Normal

In distributed systems, failures are not exceptions.

They are expected behavior.

A simple HTTP call can fail in many ways:



resp, err := http.Get("http://node-service/tasks")


if err != nil {
 // network failure 
 retry()
}

But what kind of failure is it?

The server might be down
The network might be slow
DNS might fail
The request might succeed but the response gets lost

Handling these cases correctly requires retries, timeouts, and idempotent operations.

Scheduling Work Across Machines

One of the challenges I encountered while building a cloud orchestration system was scheduling workloads across multiple nodes.

A very simplified scheduler might look like this:



type Node struct {
 ID string
 Capacity int
 Used int
}


func schedule(nodes []Node, job Job) *Node {
 for i := range nodes {
 if nodes[i].Capacity-nodes[i].Used >= job.Resources {
 return &nodes[i]
 }
 }
 return nil
}

This looks simple.

But real systems quickly introduce more challenges:

nodes going offline
jobs failing midway
resource fragmentation
network delays
distributed state

A production system requires heartbeat monitoring, leader election, failure recovery, and task rescheduling.

Suddenly the architecture grows significantly.

Debugging Becomes Harder

Debugging distributed systems is also more complex.

In a monolith, you can follow logs sequentially.

In a distributed system, a single request might pass through several services:



API Gateway -> Auth Service -> Order Service -> Payment Service -> Inventory Service

To debug issues, you often need distributed tracing tools to reconstruct the path of a request.

Without observability, diagnosing issues becomes extremely difficult.

Do Most Companies Need This?

In many cases, the answer is no.

A well designed monolith can scale surprisingly far.

Many successful products run on monolithic architectures much longer than engineers expect.

Distributed systems should only be introduced when they solve a clear scaling or reliability problem.

But There Is Still Value in Learning Them

Even though most systems don’t need distributed architectures immediately, understanding them provides enormous value.

Once you understand how systems fail across networks and machines, you begin designing software differently.

You think more about:

fault tolerance
system boundaries
reliability
observability

Those lessons improve every backend system you build.

Distributed systems are powerful tools.

But like all powerful tools, they should be used carefully.

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.

Escape Analysis in Go: Where Does Your Data Actually Live?

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

If you’ve been writing Go for a while, you’ve probably heard the terms stack and heap tossed around. But have you ever wondered how Go decides where to put your variables? That’s exactly what escape analysis is about and understanding it can help you write faster, more efficient Go code.

Stack vs Heap: A Quick Refresher

Think of memory in two buckets:

Stack Fast, automatically managed. When a function is called, variables are pushed onto the stack. When the function returns, they’re gone. No cleanup needed.
Heap Slower, but longer-lived. Variables here are managed by Go’s garbage collector (GC). They stick around as long as something is referencing them.

The stack is cheap. The heap costs more allocating on the heap puts pressure on the GC, which can slow your program down.

So What Is Escape Analysis?

Escape analysis is what the Go compiler does at compile time to figure out: “Does this variable need to live on the heap, or can it stay on the stack?”

If a variable is only used inside the function it was created in, it can safely live on the stack. But if a variable “escapes” meaning something outside the function needs to access it it has to be moved to the heap.

The compiler does this automatically. You don’t have to think about it most of the time. But understanding when things escape can help you avoid unnecessary heap allocations.

A Simple Example



func main() {
 x := 42
 fmt.Println(x)
}

Here, x is created and used inside main. It doesn’t escape anywhere. The compiler keeps it on the stack.

Now consider this:



func newNumber() *int {
 x := 42
 return &x // we're returning a pointer to x 
}

Here, we’re returning a pointer to x. That means after newNumber returns, something outside the function is still holding a reference to x. The stack for newNumber is gone at that point so Go moves x to the heap. It has escaped.

How to See What’s Escaping

Go gives you a handy compiler flag to inspect escape analysis decisions:

bash



go build -gcflags="-m" ./...

You’ll see output like:



./main.go:6:2: moved to heap: x
./main.go:10:13: ... argument does not escape

This tells you exactly which variables the compiler decided to allocate on the heap. It’s a great debugging tool when you’re trying to optimize performance.

Common Reasons a Variable Escapes

1. Returning a pointer to a local variable As shown above if you return &x, x has to live on the heap.

2. Storing a value in an interface



var i interface{} = 42

When you assign a concrete value to an interface, Go often needs to heap-allocate it because the interface value needs to carry around type information.

3. Sending to a channel or storing in a slice/map If the runtime can’t prove the value won’t outlive the current scope, it plays it safe and puts it on the heap.

4. Closures capturing variables



func makeCounter() func() int {
 count := 0
 return func() int {
 count++
 return count
 }
}

Here, count is captured by the closure returned from makeCounter. Since the closure can be called long after makeCounter returns, count escapes to the heap.

Does This Matter in Practice?

For most applications, not really Go’s garbage collector is fast and well-tuned. But in performance-sensitive code (think: game loops, high-frequency trading, large-scale data pipelines), reducing heap allocations can make a meaningful difference.

Here’s a rough guide:

Don’t return pointers to small, short-lived values if you don’t need to. Return by value instead.
Pre-allocate slices when you know the size upfront (make([]int, 0, 100)) to avoid repeated heap allocations.
Use**-gcflags= “-m” or benchmarks** to identify hot paths with lots of allocations before optimizing.

Key Takeaways

Go automatically decides whether variables live on the stack (fast, temporary) or the heap (slower, GC-managed).
This decision is made by the compiler using escape analysis.
A variable “escapes” to the heap when it needs to outlive the function it was created in.
You can inspect escape decisions with go build -gcflags="-m".
Understanding escape analysis helps you write more allocation-efficient Go code.

The beauty of Go is that you don’t have to think about this most of the time. But when performance matters, escape analysis is one of those things that separates good Go code from great Go code. Happy coding! 🚀

Originally published on Medium.

Comptime vs. Macros: Metaprogramming in Zig and Rust

Mon, 10 Nov 2025 00:00:00 +0000

Metaprogramming allows code to generate or manipulate other code, often at compile time, boosting flexibility and performance. Two modern languages tackle this differently: Zig with its comptime feature and Rust with macros. Let’s explore both with examples, drawing from recent discussions and developments as of 2025.

Comptime in Zig: Seamless Compile-Time Execution

Zig’s comptime integrates compile-time computation directly into the language, making it feel like regular code. Functions or expressions marked with **comptime** run during compilation, enabling generics, conditional compilation, and more without separate syntax. It’s restrictive by design to avoid complexity, yet powerful for tasks like serialization or ORM.

A simple example: generating a factorial at compile time in Zig.



fn factorial(comptime n: u32) u32 {
 if (n == 0) return 1;
 return n * factorial(n - 1);
}
pub fn main() void {
 const result = comptime factorial(5); // Computed at compile time: 120
 @compileLog(result); // Logs during compilation
}

This runs entirely at compile time, embedding the result in the binary. Recent projects use comptime for auto-generating DLL loading code or erasure coding optimizations. In 2025, discussions highlight how comptime eliminates the need for macros by treating code uniformly.

Macros in Rust: Declarative and Procedural Power

Rust’s macros come in two flavors: declarative (via macro_rules!) for pattern-matching code generation, and procedural for custom syntax extensions. They’re explicit, ensuring type safety and hygiene (no accidental variable captures). Macros like println! or vec! are everyday examples.

Here’s a declarative macro for a simple vector creator:



macro_rules! my_vec {
 ( $( $x:expr ),* ) => {
 {
 let mut temp_vec = Vec::new();
 $(
 temp_vec.push($x);
 )*
 temp_vec
 }
 };
}
fn main() {
 let v = my_vec![1, 2, 3]; // Expands to Vec with pushes
 println!("{:?}", v);
}

This expands at compile time. Advanced uses include deriving traits or composing derives with crates like macro_rules_attribute. Recent 2025 experiments, like “Crabtime ,” even attempt to emulate Zig’s comptime in Rust using macros, showing cross-inspiration.

Key Comparisons

- Simplicity vs. Explicitness : Zig’s comptime is implicit and blends with runtime code, but changes can break callers unexpectedly. Rust macros are explicit, with strong constraints via traits, reducing errors but adding boilerplate.

- Type Access : Zig provides direct type info at comptime, easing generics. Rust macros handle this through patterns or proc macros, but it’s more involved.

-Use Cases : Both enable generics and optimizations, but Zig avoids a separate macro system, while Rust’s is versatile for DSLs.

In 2025, Zig’s approach is praised for reducing complexity, though Rust’s ecosystem offers more mature tools. If you’re building low-level systems, experiment with both. Zig for elegance, Rust for safety.

Thanks for reading! What’s your take on metaprogramming?

Originally published on Medium.

How TypeScript Enums Compile to JavaScript (And Why It Matters)

Sun, 31 Aug 2025 00:00:00 +0000

When you’re learning TypeScript, it’s easy to overlook that it all boils down to plain JavaScript in the end. Most TypeScript goodies like types, interfaces, and unions vanish after compilation, living only to help catch errors during development. But there’s one feature that sticks around: enums. They’re a bit special, and here’s why.

What Happens with Numeric Enums

Let’s say you create a simple enum like this:



enum Direction {
 Up,
 Down,
 Left,
 Right
}

When TypeScript compiles this, it doesn’t just disappear. Instead, it turns into this JavaScript:



var Direction;
(function (Direction) {
Direction[Direction["Up"] = 0] = "Up";
Direction[Direction["Down"] = 1] = "Down";
Direction[Direction["Left"] = 2] = "Left";
Direction[Direction["Right"] = 3] = "Right";
})(Direction || (Direction = {}));

This code creates a two-way street : you can look up values both ways. For example:



Direction.Up === 0; // true
Direction[0] === "Up"; // true

So, unlike most TypeScript features, enums don’t just exist for type-checking they become real objects in your JavaScript code.

Why This Is a Big Deal

Here’s why you should care:

Bundle Size: Enums generate actual JavaScript code, which can make your final bundle heavier. If you’re not careful, this can add up.
Unexpected Perks: Enums let you do cool things like reverse lookups (e.g., getting “Up” from 0). Handy, but it might catch you off guard if you’re not expecting it.
Lighter Options: If you just need simple constants, you might want to use const enum or plain string literals instead. They’re leaner and don’t add extra code to your JavaScript.

The Bottom Line

Understanding how enums work under the hood helps you write smarter, cleaner code. Every time you use an enum, keep in mind: you’re not just writing TypeScript you’re creating real JavaScript objects that live in your final app. Use them wisely!

Originally published on Medium.

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.