Forem: David Ochiel

Zero-Cost Abstractions in Go: A Practical Guide with Real-World Examples

David Ochiel — Mon, 30 Jun 2025 18:29:50 +0000

When I first started with Go, I assumed that writing clean, abstracted code meant sacrificing performance. Then I discovered zero-cost abstractions - patterns that give you maintainability without runtime overhead.

Abstractions are only dangerous when they cost more than they’re worth. Rob Pike

Go is often lauded for its simplicity, speed, and robust concurrency model. But beneath the minimalism lies a powerful capability: writing abstractions that don’t come with a performance price tag, what some languages call zero-cost abstractions.

In this post, we’ll explore how to write idiomatic, abstracted Go code without sacrificing performance, complete with benchmarks, pitfalls, and real-world examples.

What are Zero-Cost Abstractions?
A zero-cost abstraction means the abstraction adds no overhead at runtime compared to writing equivalent low-level code manually.

Think: reusable code that doesn't slow you down.

While Go doesn’t use this terminology explicitly, it has patterns that achieve the same effect, especially when you're careful with allocations, interfaces, and function in-lining.

Example 1: Avoiding Interface Overhead in Performance-Critical Code

❌ Bad: Interface dispatch in hot paths

type Processor interface {
    Process([]byte) []byte
}

func Execute(p Processor, data []byte) {
    result := p.Process(data)
    // ...
}

Problem: Interface method calls involve dynamic dispatch (small runtime lookup).

✅ Good: Generics (Go 1.18+)

func Execute[T any](p func([]byte) []byte, data []byte) {
    result := p(data)
    // ...
}

Advantage: The compiler generates optimized code for each type at compile time.

Using a function parameter (which inlines easily) avoids the dynamic dispatch overhead of interfaces, especially important in high-frequency paths like parsing or encoding.

Example 2: Allocation-Free Data Structures with Slices

Go’s slice internals make it easy to reuse memory.

func FilterInPlace(nums []int, predicate func(int) bool) []int {
    out := nums[:0]
    for _, n := range nums {
        if predicate(n) {
            out = append(out, n)
        }
    }
    return out
}

This code reuses the underlying array, no allocation, no GC pressure. It’s effectively zero-cost, yet generic and readable.

Benchmarking: How Much Do You Save?
Using go test -bench, I compared a version of FilterInPlace that uses a new slice vs. reuses memory:

BenchmarkFilterNewSlice-8     10000000    200 ns/op
BenchmarkFilterInPlace-8      20000000    100 ns/op

A 2x improvement just from a small change in memory usage.

Concurrency Bonus: Channel-less Patterns
Instead of always reaching for channels, try function closures or sync.Pool to build async-safe abstractions without the cost of blocking.

func WorkerPool[T any](workers int, work func(chan T)) {
    ch := make(chan T)
    for i := 0; i < workers; i++ {
        go func() {
            work(ch)
        }()
    }
}

You can keep abstractions modular and performant, especially in systems like log processing or real-time analytics.

Takeaways

Abstractions in Go don’t have to cost you performance.
Avoid heap allocations and interface dispatch in hot paths.
Use slices, generics, and inlining-friendly patterns.
Profile with pprof and go test -bench to confirm.

Time Traveling Through Your Repo: Git Reset vs. Revert

David Ochiel — Fri, 31 May 2024 08:38:48 +0000

Once upon a commit, in the mystical realm of version control... jokes aside 😅. Wassup fellow git adventurers! Today we'll be embarking on a journey through the mysterious realms of version control. We'll dive deep into the git universe to understand the mysterious powers of two commands: reset and revert. Buckle up, because this ride might get a bit bumpy, but fear not, for I shall guide you through with wit and wisdom!

The Maverick Reset

Ah, the mighty git reset, a command so potent, it can make your HEAD spin. But wait! What is this enigmatic "HEAD" in the realm of git?

It's like the captain's chair of your spaceship. It points to the current position within your repository. Picture it as the guiding compass of your git repository, pointing to the very tip of your current branch. It's the nucleus around which your commits orbit, determining what snapshot of your project you're currently viewing or altering.
If you are on the master branch, HEAD will point to the latest commit on that branch. So when you hear about "resetting HEAD," it's like repositioning captain git's chair to a different point in space-time, perhaps to a previous commit or even a different branch altogether.

Back to our friend reset. Imagine you're in a time machine, and you want to teleport back to a previous commit. Well, git reset is your DeLorean, ready to whisk you away to the past. But beware, fellow time travelers, for with great power comes great responsibility! Git reset without caution can lead to catastrophic consequences. One wrong move, and poof! Your commits vanish into the digital abyss faster than you can say "commitment issues." So, before you hit that reset button, remember to backup your work.

Assuming the following is your commit history, let's talk about the responsibilities you'll have, going the maverick way:

C1 - C2 - C3 - C4 - C5

Types of Reset

Soft Reset: It's akin to a cautious peek into the time-traveling toolbox of coding. You move HEAD to a previous commit, but your changes stay staged, as if hitting the pause button on your code's journey through time. From the commit history above, say you want go back to C2. Running git reset --soft <hash-for-C2> or git reset --soft HEAD~3 will uncommit the changes from C3 to C5, but will keep them staged. To get the hash for your commit, run git log then copy the desired hash. In HEAD~3, 3 is the number of steps it takes to get to C2. Hopefully your "head" is not spinning though. Pick the convention that suits you. Let's look at an example.

Suppose you have the following in your working environment.

.gitignore
app1.py
app2.py

You then decided to commit the two apps.

git add app1.py app2.py
git commit -m "feat: add apps"

Then later realized that you forgot to add the .gitignore file (meaning it is still unstaged), you can do the following.

# HEAD will get the very last commit
git reset --soft HEAD
git add .gitignore
git commit -m "feat: add apps and gitignore"

Mixed Reset: Feeling a bit indecisive? This reset moves HEAD and resets the index to a previous commit, leaving your changes unstaged. Running git reset <hash-for-C2> will keep the changes from C3 to C5 unstaged. With the files in the example above, after committing the two apps, run git reset HEAD. Both the three files will then be unstaged, including the two that were initially committed.

NOTE that with mixed reset, you do not have to include the --mixed flag.

Hard Reset: Ready to go all-in? Brace yourself, because this reset moves HEAD and resets both the index and working directory to a previous commit. It's like a cosmic eraser, wiping away your changes without mercy. Use with caution! To achieve it, run git reset --hard <hash-commit-C2>. This will do away with all the changes after C2 from your repository.

Let's take a look at an example by adding some files to the previous working tree. Assuming you committed the three files, then added one file. The new file (README.md) will be in an untracked status. Run git add . or git add README.md, according to your preference, to add it to your staging area then commit the changes, say, git commit -m "docs: add readme" Let's assume the hash for this commit will be 212w544. Your current working tree should now be as follows:

.gitignore
app1.py
app2.py
README.md

Now by running git reset --hard <commit-hash-before-212w544> the commit 212w544 will be discarded together with it's file (README.md). Your working tree should now be as follows:

.gitignore
app1.py
app2.py

Ready to rewrite history?

After traversing the depths of time with your hard reset, it's now the moment to rewrite history. To discard the contents in your remote repository like github, gitea, or gitlab, run git push <remote-name> <branch-name> --force.
This command will overwrite the history in the remote repository with the changes from your local repository, effectively discarding the unwanted changes.

CAUTION!!!

In case you were working on a project with collaborators, this can potentially cause issues for those who have pulled the changes. Make sure to communicate with your team before force pushing to avoid conflicts.
Ensure you have a backup of the remote repository in case you need to revert the changes.

The Renegade Revert

Now, let's talk about git revert - the rebel with a cause, the anti-hero of version control. Unlike reset, which rewrites history like a stealthy ninja, revert takes a different approach. It acknowledges the past but refuses to let it define the future. Basically it's used to undo changes introduced by a specific commit, creating a new commit that reflects the reversal. It maintains a clear and linear history by documenting the reversal as a new commit.

Here is how it works

Suppose the following is your commit history:

C1 - C2 - C3 - C4 - C5

We want to undo the changes introduced by commit C2. Check the hash for your commit by running git log, then do the following:

git revert <hash-for-C2>

If you use the HEAD convention, it will be:

git revert HEAD~3

If there are conflicts during the revert process, resolve them manually. Git will guide you through the conflict resolution process.

After juggling with conflicts like a clumsy magician (sorry, what I mean is, after resolving all the conflicts), run git revert --continue to continue with the revert process. This will finally create a new revert commit, C6, that undoes the changes introduced in C2, leading to the following history:

C1 - C2 - C3 - C4 - C5 - C6

Revert a revert

Some times you can find yourself in a git time loop, reverting a revert, undoing an undo.
This often happens when you revert a commit only to realize it was a mistake, disrupting the fabric of your code continuum. But wait! Is that a glimmer of hope on the horizon? Yes, it's the git time machine offering you a chance to set things right.
All you gotta do is git log to find the hash for the revert commit, in our case it will be the hash for C6.
After getting the hash, run git revert <hash-for-C6>, which will create a new revert commit, C7, that undoes the undone changes introduced in C2, leading to the following history:

C1 - C2 - C3 - C4 - C5 - C6 - C7

The contents of the above history will be like when it started, as below:

C1 - C2 - C3 - C4 - C5

When you are done with your revert(s), if need be, git push the changes to your remote repository.

Choose Your Destiny

Your mission, should you choose to accept any of these methods, is to rewrite history without causing a paradox. If any of your projects vanish or get tangled in a time loop, the keyboards responsible for this article will disavow any knowledge of your actions. This article will never self-destruct... well, unless a glitch in the space-time continuum intervenes. Good luck git adventurers. Some of you might get the humor after traveling "back to the future" 😅. Essentially though you can:

use git reset when:
- you want to rewind the HEAD or branch pointer, and you're okay with completely discarding changes.
use git revert when:
- you want to undo changes in a public branch without rewriting history,
- you want to maintaining a linear progression of commits,
- you want to selectively reverse specific files.

So, which path will you choose? Whichever path you take, experiment, explore, but always tread carefully. Until next time, cheerio 😁.

Push to Multiple Repositories Simultaneously Using Git Hooks

David Ochiel — Wed, 15 May 2024 17:16:28 +0000

Automating repetitive tasks is crucial in software development to enhance workflow efficiency. In this article, we'll dive into leveraging git hooks to automate actions after each commit, to push to two different repositories, one in github, and another in gitea.

What are hooks?

Hooks are scripts that git executes in response to certain events. There are various types of hooks, including pre-commit, post-commit, pre-push, and more. In git, you can use hooks to perform tasks like sending notifications, triggering builds, or updating deployments automatically after each commit. Check out this documentation for more on hooks.

Setting Up a Post-Commit Hook

To set up a post-commit hook in your git repository, follow these steps:

Create a directory, say, myproject using mkdir myproject, where you will place you project files and directories.
Navigate to the directory using cd myproject/, customize your development environment using the git config --global convention, and initialize a git repository, git init.
Create the remote repositories for both gitea and github. For github, you will need to have a PAT for push authentication.

# gitea
git remote add gitea <repository-url>

# github
git remote add github https://<your-token>@github.com/<username>/<repository-name>.git

After that, when you run, git remote you should have the following as your remote repositories:

gitea
github

Navigate to the .git directory and create a post-commit script in the hooks directory. Note that the post-commit script doesn't have to have an extension.

cd .git/
nano hooks/post-commit

The nano text editor will open as in the image below:

Write your desired actions or commands in the script. In this case, copy and paste the following:

# Push changes to Gitea
git push gitea master

# Push changes to GitHub
git push github master

The result should be as per the image below:

To save your file, press CTRL+X, then y, then press ENTER key.

Ensure the script has execute permissions.

chmod +x hooks/post-commit

Start working on your project

# move back from the .git directory
cd ..

# work on your project
touch README.md
git add .
git commit -m "first commit"

So why wait? Start using hooks today and take your development workflow to the next level!

If you have any questions, concerns, or want to share your experiences with hooks, feel free to leave a comment below.

Happy coding :)