DEV Community: Kevin Nambubbi

📂 The Hidden Superpower of Go's io/fs: Why Your Code Deserves a Universal Remote Control

Kevin Nambubbi — Mon, 16 Mar 2026 18:46:46 +0000

🎬 The Moment Everything Clicked
Picture this: It's 2 AM. I'm debugging a Go program that processes text files. My tests keep failing because I forgot to delete a test file from the previous run. Again.

"You know what?" I muttered to my monitor, "There HAS to be a better way."

Turns out, there was. And it had been sitting in the standard library all along.

📖 The Tale of Two File Readers
Let me tell you a story about two developers: Alice and Bob.

Bob's Approach: The Direct Route
go
// Bob's code - seems simple enough
func ProcessFile(path string) error {
data, err := os.ReadFile(path)
if err != nil {
return err
}
// ... process data
return nil
}
Bob is happy. His code works. Life is good.

Until...

He needs to test: "Now I need to create real files for testing 😰"

He needs to read from an embedded file: "Wait, I can't use os.ReadFile for that 😱"

He needs to read from a ZIP: "Do I rewrite everything? 😭"

Alice's Approach: The Universal Remote
go
// Alice's code - works ANYWHERE
func ProcessFile(fsys fs.FS, path string) error {
data, err := fs.ReadFile(fsys, path)
if err != nil {
return err
}
// ... process data (same code!)
return nil
}
Alice's code is like a universal remote that works with any TV:

Real files? ProcessFile(os.DirFS("."), "input.txt")

Testing? ProcessFile(fstest.MapFS{...}, "input.txt")

Embedded? ProcessFile(embed.FS, "input.txt")

ZIP files? ProcessFile(zipFS, "input.txt")

SAME CODE. EVERY TIME.

🎮 Let's Play: Spot the Difference
I'm going to show you two code snippets. Your job? Spot which one will make your life easier in the long run.

Round 1: Reading a Config File
Option A (The Traditionalist):

go
func LoadConfig() (*Config, error) {
data, err := os.ReadFile("./config.json")
if err != nil {
return nil, fmt.Errorf("failed to read config: %w", err)
}
// parse config...
}
Option B (The Visionary):

go
func LoadConfig(fsys fs.FS) (*Config, error) {
data, err := fs.ReadFile(fsys, "config.json")
if err != nil {
return nil, fmt.Errorf("failed to read config: %w", err)
}
// parse config...
}
See the difference? Option B doesn't care WHERE the file comes from. It just needs A file system.

🧪 The Testing Revelation
This is where io/fs goes from "interesting" to "I CAN NEVER GO BACK".

Testing Bob's Code:
go
func TestBobProcessor(t *testing.T) {
// Step 1: Create a real file (messy)
os.WriteFile("test.txt", []byte("hello"), 0644)
defer os.Remove("test.txt") // Hope we don't forget!

// Step 2: Run the test
err := BobProcessor.ProcessFile("test.txt")

// Step 3: Clean up (if we remembered)

}
Problems:

🐢 Slow (actual disk I/O)

🧹 Need cleanup code

🔒 Permission issues

📁 Leftover files when tests crash

Testing Alice's Code:
go
func TestAliceProcessor(t *testing.T) {
// Step 1: Create a VIRTUAL file system (magic!)
mockFS := fstest.MapFS{
"test.txt": {Data: []byte("hello")},
}

// Step 2: Run the test (NO FILES CREATED!)
err := AliceProcessor.ProcessFile(mockFS, "test.txt")

// Step 3: That's it! Nothing to clean up!

}
Benefits:

⚡ Blazing fast (pure memory)

🧼 No cleanup needed

🔒 No permissions to worry about

🏃‍♂️ Tests can run in parallel safely

🎯 The "Aha!" Moment
Here's when I truly understood the power of io/fs:

go
// My text processor now works ANYWHERE
type TextProcessor struct {
fsys fs.FS // The file system to use
}

func NewTextProcessor(fsys fs.FS) *TextProcessor {
return &TextProcessor{fsys: fsys}
}

// In production: use real files
prod := NewTextProcessor(os.DirFS("./data"))

// In tests: use virtual files
test := NewTextProcessor(fstest.MapFS{
"input.txt": {Data: []byte("1E (hex)")},
})

// In CLI tool: let user specify
cli := NewTextProcessor(os.DirFS(userSpecifiedPath))

// In web server: read from embedded static files
web := NewTextProcessor(embeddedStaticFiles)

// In cloud: read from S3 (if you implement fs.FS for S3)
cloud := NewTextProcessor(s3fs.New("my-bucket"))
ONE PROCESSOR. INFINITE POSSIBILITIES.

🎨 The Architecture Diagram (ASCII Art Edition)
text
┌─────────────────────────────────────┐
│ YOUR APPLICATION CODE │
│ (Works with ANY fs.FS!) │
└─────────────┬───────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ fs.FS Interface │
│ "Give me files!" │
└─────────────┬───────────────────────┘
│
┌─────────┴─────────┐
│ │
▼ ▼
┌────────────┐ ┌────────────┐
│ os.DirFS │ │fstest.MapFS│
│ (Real Disk)│ │(In Memory) │
└────────────┘ └────────────┘
│ │
▼ ▼
┌────────────┐ ┌────────────┐
│ Files on │ │ Virtual │
│ your HD │ │ files for │
│ │ │ testing │
└────────────┘ └────────────┘

AND SO MUCH MORE!
     │
     ▼

┌────────────────────┐
│ embed.FS │
│ (Files in binary) │
├────────────────────┤
│ zip.Reader │
│ (ZIP archives) │
├────────────────────┤
│ Custom FS │
│ (Your imagination!)│
└────────────────────┘
💡 The "Wait, What?" Moments
Moment 1: "But I need to WRITE files!"
Yes, io/fs is READ-ONLY. And that's PERFECT:

go
// READ with fs.FS (flexible)
data, _ := fs.ReadFile(myFS, "input.txt")

// WRITE with os (still need this)
os.WriteFile("output.txt", data, 0644)
The separation is beautiful: reading is abstract, writing is concrete.

Moment 2: "What about paths on Windows?"
io/fs uses forward slashes (/) everywhere. ALWAYS. Even on Windows:

go
// DON'T do this (platform-specific)
path := filepath.Join("folder", "file.txt")

// DO this (works everywhere with fs.FS)
path := "folder/file.txt" // Always use /
Moment 3: "Can I use this in MY project?"
YES! And here's how to start:

go
// Step 1: Change your function signatures
// FROM:
func DoSomething(filename string)
// TO:
func DoSomething(fsys fs.FS, filename string)

// Step 2: Use fs.ReadFile instead of os.ReadFile
// Step 3: Pass in the right FS for each use case
🚀 The Challenge
I dare you to refactor ONE of your existing Go projects to use io/fs. Just one function. See how it feels.

Here's a starter template:

go
package main

import (
"io/fs"
"os"
"testing/fstest"
)

// Your refactored function
func MyFunction(fsys fs.FS, path string) (string, error) {
data, err := fs.ReadFile(fsys, path)
if err != nil {
return "", err
}
return string(data), nil
}

func main() {
// Real usage
result, _ := MyFunction(os.DirFS("."), "real.txt")

// Test usage (in real tests, not main!)
mockFS := fstest.MapFS{
    "test.txt": {Data: []byte("mock data")},
}
testResult, _ := MyFunction(mockFS, "test.txt")

}
Try it. You'll thank me later.

🎁 The Gift That Keeps Giving
Using io/fs is like:

🍕 Ordering pizza that can be delivered by ANY restaurant

🔌 Having a plug that works in ANY country

🎮 Playing games that work on ANY console

It's abstraction done RIGHT.

📢 Join the Revolution
The next time you write a function that reads files, ask yourself:

"Do I need the REAL file system, or do I need A file system?"

If the answer is "A file system" (and it almost always is), use fs.FS.

Your future self (and anyone who tests your code) will thank you.

💬 Let's Discuss!
Have you used io/fs in your projects?
What creative file systems have you implemented?
Any "aha!" moments with file abstraction?

Drop a comment below! 👇

P.S. - The next time you see os.ReadFile in your code, imagine it's 1999 and you're using a dial-up modem. fs.ReadFile is your fiber optic connection to the future. 🚀

GoLang #Programming #SoftwareEngineering #CleanCode #DeveloperTips #iofs #GoProgramming

The Surgical Precision of `strings.Cut`: Why You Should Stop Over-Splitting Your Go Code

Kevin Nambubbi — Sat, 21 Feb 2026 08:42:28 +0000

If you are building text-heavy applications—like the ASCII art generator I’ve been tinkering with—you eventually run into a classic Go dilemma: Convenience vs. Performance.

When we need to parse a string, our "Day 1" instinct is almost always to reach for strings.Split. It’s familiar, it’s friendly, and it’s in every tutorial. But if you’re only looking to divide a string into two parts (like a Key:Value pair or a Header:Body), strings.Split isn't just overkill—it’s a resource hog.

Since Go 1.18, there has been a better way: strings.Cut. Let’s look at why this "scalpel" is superior to the "axe" that is Split.

🕵️ The Hidden Cost of `strings.Split`

To understand why Split is heavy, we have to look under the hood at its return type: []string.

When you execute strings.Split(input, ":"), the Go runtime isn't just finding a character; it’s going on a shopping spree with your RAM:

The Full Scan: It traverses the entire string to find every possible match.
The Allocation: It creates a brand-new slice to hold the results.
The Overhead: It generates new string headers for every single segment discovered.

If you’re processing a 5MB ASCII art file just to find the "Title" at the very beginning, Split will still scan all 5 million characters looking for more colons. That is a lot of unnecessary work for your Garbage Collector (GC).

⚡ Enter `strings.Cut`: The Performance Hero

Introduced to simplify common parsing patterns, strings.Cut has a beautifully simple signature:

Why it wins on the scoreboard:

Zero Slice Allocations: It returns two substrings and a boolean. No slice is created, meaning zero extra heap allocation for the container.
Early Exit: The moment it finds the first separator, it stops. If your delimiter is at index 10 of a 10,000-character string, Cut ignores the other 9,990 characters.
Cleaner Logic: You no longer have to check if len(parts) > 1. The found boolean tells you exactly what happened.

🛠️ Refactoring for Elegance

Moving from Split to Cut doesn't just make your app faster; it makes your code more readable.

The "Old" Way (Clunky):

// We only want the first two parts, but we still pay for a slice
parts := strings.SplitN(input, "=", 2)
if len(parts) < 2 {
    return fmt.Errorf("invalid format")
}
key, value := parts[0], parts[1]

The "Go 1.18+" Way (Sleek):

// Direct, intentional, and allocation-free
key, value, found := strings.Cut(input, "=")
if !found {
    return fmt.Errorf("invalid format")
}

🎓 Final Thoughts

As I continue to build out my career in code, I’ve realized that "Good Go" is about being a good neighbor to the runtime.

By switching to strings.Cut, you reduce CPU cycles and keep your memory footprint flat. For an ASCII art program, this means smoother rendering and less lag. For your career, it shows you care about the "How" just as much as the "What."

Next time you need to break a string in two, put down the axe. Use the scalpel.