DEV Community: Uthman Oladele

Stop Writing Bash Scripts, There's a Better Way

Uthman Oladele — Tue, 03 Mar 2026 07:18:45 +0000

If you've ever written a Bash script longer than 30 lines, you know the feeling.
You come back to it a week later and have no idea what it does. Error handling is
a mess of $? checks, variables are global by default, and debugging feels like
archaeology.

I got tired of it. But I also didn't want to spin up a Python virtual environment
just to move some files around or hit an API. That felt like overkill.

So I built Logos.

What is Logos?

Logos is a small scripting language I wrote in Go. It is designed for the kind of
work Bash handles poorly: readable logic, proper error handling, built-in HTTP and
file operations, and code you can actually come back to a week later.

It is not trying to replace Python. It is not trying to replace Go. It is just a
tool for that middle ground where Bash becomes unreadable but pulling in a full
language feels like too much.

Scripts use the .lgs extension and you run them with the lgs command.

What does it look like?

Here is a simple HTTP request in Logos:

let res = httpGet("https://api.example.com/data")

if res.ok {
    let data = parseJson(res.value.body)
    print(data["message"])
} else {
    print("Error: " + res.error)
}

No exceptions. No try/catch. Functions return a result table with ok, value,
and error fields. You check what you need and move on.

Compare that to doing the same thing in Bash. You are manually checking exit
codes, parsing curl output with awk, and hoping nothing breaks silently.

Why not just use Python?

Python is great. But for quick scripts, you are dealing with virtual environments,
import management, and a language that was not really designed for CLI work. It
also needs to be installed and configured on every machine you run it on.

Logos ships as a single binary. Install it and run your script. That is it.

Why not just use Go?

Go requires a compile step. If you are writing a quick script to back up some
files or hit an API, you do not want to set up a module and run go build every
time you make a change. Logos runs scripts directly, like a shell language should.

Also, Logos can be embedded inside Go applications as a scripting engine. You can
register Go functions, set variables, and run Logos scripts from within your Go
code. That is something Go itself cannot do cleanly.

vm := logos.NewWithConfig(logos.SandboxConfig{
    AllowFileIO:  false,
    AllowNetwork: false,
    AllowShell:   false,
    AllowExit:    false,
})

vm.Register("greet", func(args ...logos.Object) logos.Object {
    name := args[0].(*logos.String).Value
    return &logos.String{Value: "hello " + name}
})

vm.Run(`print(greet("world"))`)

What can it do?

File I/O: read, write, copy, move, delete, glob
HTTP: GET, POST, PATCH, DELETE
JSON: parse and stringify
Concurrency: spawn blocks and spawn for-in loops
A formatter: lgs fmt yourfile.lgs
A compiler: lgs build yourfile.lgs compiles your script to a standalone binary
A REPL: just run lgs with no arguments
A standard library: math, string, array, path, time, logging, testing, and more

A real example

Here is a backup script written in Logos:

let source = trim(prompt("Source directory: "))

if !fileExists(source) {
    print("Error: " + source + " does not exist")
    exit(1)
}

let dest = trim(prompt("Backup destination: "))
let timestamp = replace(dateTimeStr(), " ", "_")
let backupPath = dest + "/backup_" + timestamp

let result = fileMkdir(backupPath)
if !result.ok {
    print("Failed to create backup directory")
    exit(1)
}

let files = fileReadDir(source)
for entry in files.value {
    fileCopy(source + "/" + entry, backupPath + "/" + entry)
}

print("Backup complete: " + backupPath)

Clean. Readable. Easy to come back to.

How to install

curl -fsSL https://raw.githubusercontent.com/codetesla51/logos/main/install.sh | sh

Works on Linux and macOS. Picks the right binary for your OS and architecture
automatically.

Try it

GitHub: https://github.com/codetesla51/logos
Documentation: https://logos-lang.vercel.app/docs

If you have feedback, run into bugs, or want to contribute examples or standard
library utilities, open an issue or a PR. The project is new and I am actively
working on it.

I built this because I wanted it to exist. Maybe you will find it useful too.

From Zero to Programming Language: A Complete Implementation Guide

Uthman Oladele — Sun, 04 Jan 2026 15:19:21 +0000

Ever wondered how Python, JavaScript, or Go actually work under the hood? I spent months researching and implementing different language designs, and compiled everything into a comprehensive guide that takes you from basic lexical analysis to JIT compilation.

What You'll Build

By following this guide, you'll create a complete programming language implementation, starting with a simple calculator and progressively adding:

Lexer & Parser - Transform source code into Abstract Syntax Trees
Interpreters - Direct AST execution (simplest approach)
Bytecode VMs - Stack-based virtual machines like Python's CPython
LLVM Integration - Generate native machine code
Garbage Collection - Automatic memory management strategies

Why This Guide is Different

Most compiler tutorials give you fragments. This gives you complete, runnable code in Go that you can actually execute and modify.

Real Performance Numbers

No hand-waving here. The guide includes actual benchmarks:

Tree-Walking Interpreter:  10-100x slower than native
Bytecode VM:              5-50x slower than native
JIT Compiled:             1-5x slower (can match native)
AOT Compiled:             Baseline (native speed)

Real-world example - Fibonacci(40):

C (gcc -O3): 0.5s
Python (CPython): 45s (90x slower)
Python (PyPy JIT): 2.5s (5x slower)

Progressive Learning Path

The guide is structured for gradual complexity:

Week 1: Build an Interpreter
Start with a tree-walking interpreter - the simplest execution model. You'll have a working language by the end of the weekend.

Week 2: Add a Bytecode VM
Compile to bytecode and build a stack-based virtual machine. Understand how Python and Java work internally.

Week 3-4: Native Code Generation
Use LLVM to generate optimized machine code. Learn what makes Rust and Swift fast.

Beyond: JIT Compilation
Study how V8 and HotSpot achieve near-native performance through runtime optimization.

Complete Working Example

The guide includes a full calculator language implementation with:

Lexer (tokenization)
Recursive descent parser
AST generation
Tree-walking interpreter
Variables and expressions

source := `
x = 10
y = 20
z = x + y * 2
`

lexer := NewLexer(source)
parser := NewParser(lexer)
ast := parser.Parse()

interpreter := NewInterpreter()
interpreter.Eval(ast)

fmt.Printf("z = %d\n", interpreter.vars["z"]) // z = 50

This isn't pseudocode - it's actual running Go code you can build on.

What's Covered

The Compilation Pipeline

Lexical Analysis: Breaking source code into tokens
Syntax Analysis: Building Abstract Syntax Trees
Semantic Analysis: Type checking and symbol resolution
Code Generation: Bytecode, LLVM IR, or direct interpretation

Execution Models Deep Dive

Interpreters

Direct AST execution
Simplest to implement
Best for scripting and configuration languages

Virtual Machines

Stack-based vs register-based architectures
Bytecode design and instruction sets
Function calls and stack frames
Control flow implementation

LLVM Integration

Generating LLVM IR
Type system mapping
Optimization passes
Cross-platform native code generation

JIT Compilation (Advanced)

Profiling and hot path detection
Runtime code generation
Deoptimization strategies
Type specialization

Garbage Collection

Deep dive into automatic memory management:

Reference Counting - Immediate reclamation, can't handle cycles
Mark-and-Sweep - Handles cycles, stop-the-world pauses
Copying/Generational - Best performance, most complex

Each approach includes working implementations and trade-off analysis.

Real-World Insights

The guide doesn't just teach theory - it explains practical decisions:

Why does Python use bytecode instead of direct interpretation?
How does JavaScript achieve near-native performance?
Why are Go compilation times so fast?
What makes Rust's borrow checker possible?

Trade-offs Made Clear

Development Complexity:

Interpreter: Weekend project
Bytecode VM: 1-2 weeks
JIT Compiler: Months
AOT with LLVM: 2-4 weeks

Execution Speed:

Interpreter: 10-100x slower than native
Bytecode VM: 5-50x slower
JIT: 1-5x slower (can match native)
AOT: Native speed

Startup Time:

Interpreter: Instant
Bytecode VM: Very fast
JIT: Slow (warmup period)
AOT: Instant (pre-compiled)

Key Highlights

Complete Implementations

Every major component includes full, working code:

Lexer with position tracking and error handling
Recursive descent parser with operator precedence
Stack-based VM with complete instruction set
LLVM IR generation with control flow

No Handwaving

The guide tackles the hard parts:

How to make executable memory for JIT compilation
Platform-specific calling conventions
Why reference counting can't handle cycles
Managing instruction pointer and call stacks

Practical Examples

See how to implement:

Variables and assignments
Arithmetic expressions with correct precedence
Control flow (if/while) in bytecode
Function calls with proper stack frames
Type checking and semantic analysis

Who This Is For

You should read this if you:

Want to understand how programming languages work
Are building a DSL or configuration language
Curious about compiler design but intimidated by Dragon Book
Want to contribute to language projects (Rust, Go, Python)
Need to implement a scripting system for your application

Prerequisites:

Comfortable with Go (or can read and adapt the code)
Basic understanding of data structures (trees, stacks)
Curiosity about how things work under the hood

No CS degree required. No prior compiler knowledge assumed.

Learning Path Recommendation

Start with the complete calculator example - Get something working immediately
Add control flow - Implement if statements and loops using the bytecode examples
Add functions - Use the call frame implementation provided
Explore LLVM - Generate native code when you're ready for more performance
Study GC - Understand automatic memory management

Each step builds on the previous, and you'll have a working language at each stage.

What You'll Gain

After working through this guide:

Deep understanding of how interpreters, compilers, and VMs work
Practical experience building complex systems from scratch
Appreciation for language design trade-offs
Foundation for contributing to real language projects
Confidence to build domain-specific languages

Resources Included

The guide references essential learning materials:

"Crafting Interpreters" by Bob Nystrom
LLVM tutorials and documentation
Real-world language implementations to study
Performance benchmarking techniques

Get Started

The complete guide with all code examples is available on GitHub:

github.com/codetesla51/how-to-build-a-programming-language

Clone the repo, run the examples, and start building your own language today.

Feedback Welcome

This is a living guide. If you find issues, have questions, or want to contribute improvements, please open an issue or PR on GitHub.

Building a programming language is one of the most rewarding projects in computer science. It demystifies the entire software stack and gives you superpowers for understanding any codebase.

Start small. Build a calculator. Add features incrementally. Break things. Fix them. That's how you learn.

Happy language building!

How Buffer Pooling Doubled My HTTP Server's Throughput (4,000 7,721 RPS)

Uthman Oladele — Wed, 12 Nov 2025 16:46:35 +0000

Last week, I shared my journey building an HTTP server from scratch in Go using raw TCP sockets. The performance was decent—around 4,000 requests per second at peak—but I knew there was room for improvement.

Then I learned about buffer pooling, and everything changed.

The Problem: Death by a Thousand Allocations

My original server had a hidden performance killer. For every single HTTP request, the server was doing this:

func handleConnection(conn net.Conn) {
    buffer := make([]byte, 8192)  // New allocation
    conn.Read(buffer)
    // ... process request ...
    // Buffer gets garbage collected
}

Seems innocent, right? But when you're handling thousands of requests per second, this becomes:

Constant memory allocation - Creating new 8KB buffers constantly
Garbage collector pressure - GC running frequently to clean up discarded buffers
CPU cycles wasted - Allocation and deallocation overhead instead of serving requests

At 4,000 RPS, my server was allocating and throwing away 32 MB of memory every single second.

The Solution: Buffer Pooling with sync.Pool

The core idea is brilliantly simple: reuse buffers instead of creating new ones.

Go's standard library provides sync.Pool for exactly this purpose. Here's how I implemented it:

var requestBufferPool = sync.Pool{
    New: func() interface{} {
        buf := make([]byte, 8192)
        return buf
    },
}

func handleConnection(conn net.Conn) {
    // Get a buffer from the pool
    buffer := requestBufferPool.Get().([]byte)
    defer requestBufferPool.Put(buffer) // Return it when done

    conn.Read(buffer)
    // ... process request ...
}

How It Works

Request 1: Get buffer from pool → Use it → Return to pool
Request 2: Get SAME buffer → Reset & use → Return to pool
Request 3: Get SAME buffer → Reset & use → Return to pool
                              ↓
                    (Zero new allocations!)

Instead of the old wasteful cycle:

Request 1: Allocate → Use → GC cleanup
Request 2: Allocate → Use → GC cleanup
Request 3: Allocate → Use → GC cleanup
                              ↓
                    (Constant allocation churn)

Implementation: Three Strategic Pools

I identified three hot paths where buffers were being repeatedly allocated:

1. Request Buffer Pool (8KB)

var requestBufferPool = sync.Pool{
    New: func() interface{} {
        buf := make([]byte, 8192)
        return buf
    },
}

Used for reading incoming HTTP requests from TCP connections.

2. Chunk Buffer Pool (256 bytes)

var chunkBufferPool = sync.Pool{
    New: func() interface{} {
        buf := make([]byte, 256)
        return buf
    },
}

Used for smaller, chunked reads during request parsing.

3. Response Buffer Pool

var responseBufferPool = sync.Pool{
    New: func() interface{} {
        return new(bytes.Buffer)
    },
}

Used for building HTTP response strings before sending.

The Results: Nearly 2x Performance Gain

I ran the same benchmark suite before and after implementing buffer pooling:

Metric	Before Buffer Pools	After Buffer Pools	Improvement
Peak RPS	4,000	7,721	+93% 🔥
Response Time	0.250ms	0.130ms	48% faster
Memory Allocations	Constant	Minimal	~95% reduction
GC Pressure	High	Low	Significantly reduced

Before vs After Comparison

Before (4,000 RPS):

ab -n 10000 -c 10 -k http://localhost:8080/ping

Requests per second:    4000.12 [#/sec]
Time per request:       0.250 [ms] (mean)

After (7,721 RPS):

ab -n 10000 -c 10 -k http://localhost:8080/ping

Requests per second:    7721.45 [#/sec]
Time per request:       0.130 [ms] (mean)

Key Takeaways

1. Memory Management Matters—A Lot

Even in a garbage-collected language like Go, being mindful of allocations can dramatically impact performance. The GC is smart, but avoiding work is always faster than doing work efficiently.

2. Profile Before Optimizing

I initially thought my bottleneck was request parsing or routing logic. A quick profiling session revealed that memory allocation was the real culprit.

3. sync.Pool Is Your Friend

For any frequently allocated/deallocated objects (buffers, temporary structs, builders), sync.Pool is a simple way to get significant performance gains.

4. The 80/20 Rule Applies

Three strategic buffer pools gave me a 93% performance improvement. This took maybe 30 minutes to implement once I understood the concept.

Important Caveats

This Is Still a Learning Project

While 7,721 RPS sounds impressive, this benchmark tests a simple /ping endpoint that returns "pong". Real-world applications with:

Database queries
Business logic
File I/O
External API calls

...will see significantly lower RPS (typically 100-500 for most web apps). Buffer pooling helps with the networking layer, but your application logic will likely be the bottleneck in production.

Not a Silver Bullet

Buffer pooling helps when:

You're allocating the same size/type repeatedly
The objects are expensive to create
Allocation shows up in profiling

It won't help if your bottleneck is CPU-bound computation, database queries, or external API calls.

The Journey So Far

Here's the complete performance evolution of this project:

Initial buggy version: ~250 RPS (Connection handling bugs)
Bug fix: 1,389 RPS (Fixed request handling)
Keep-alive optimization: 1,710 RPS (Connection reuse)
Concurrency optimization: 4,000 RPS (Found optimal load)
Buffer pooling: 7,721 RPS (Memory optimization) 🚀

Total improvement: ~31x from the first version!

Try It Yourself

The full source code is available on GitHub:
https://github.com/codetesla51/raw-http

Clone it, run benchmarks before and after commenting out the buffer pools, and see the difference yourself:

git clone https://github.com/codetesla51/raw-http
cd raw-http
go run main.go

# In another terminal
ab -n 10000 -c 10 -k http://localhost:8080/ping

What's Next?

Now that I've squeezed significant performance out of the memory layer, I'm curious about:

HTTP/2 support - Binary framing instead of text parsing
Connection pooling strategies - How do production servers handle thousands of concurrent connections?
Zero-copy techniques - Can I avoid copying data between buffers entirely?

Have you used buffer pooling in your projects? What performance gains did you see? Drop a comment below—I'd love to hear about your optimization stories!

Building from first principles teaches you things frameworks hide. This project continues to surprise me with how much performance can be unlocked by understanding what's really happening under the hood.

Project Stats:

🚀 7,721 RPS peak performance
🔧 Built with raw TCP sockets in Go
📚 Learning-focused, not production-ready
⚡ +93% performance from buffer pooling alone

Check out the full project on GitHub

Rebuilding Grep in Go: What I Learned About Unix Text Processing

Uthman Oladele — Tue, 11 Nov 2025 12:04:59 +0000

I use grep every day but had no idea how it works. So I built a basic version in Go.

Not to replace grep. Just to stop being the guy who pipes to grep without understanding what's actually happening.

What I Built

A stripped-down grep that does pattern matching with these flags:

-i - Case-insensitive
[](url)-n - Line numbers
-c - Count matches
-v - Invert (show non-matches)
-r - Recursive search
-l - Just list filenames

Plus binary file detection and color output. That's it. No context lines, no fancy regex modes, no performance optimizations.

The Interesting Parts

Binary Files Don't Print Garbage

When grep hits a binary file (executable, image, whatever), it says "Binary file matches" instead of filling your terminal with nonsense.

How does it know?

func IsBinary(filePath string) (bool, error) {
    f, err := os.Open(filePath)
    if err != nil {
        return false, err
    }
    defer f.Close()

    buffer := make([]byte, 1024)
    n, err := f.Read(buffer)
    if err != nil && err != io.EOF {
        return false, err
    }

    if bytes.IndexByte(buffer[:n], 0) != -1 {
        return true, nil
    }

    return false, nil
}

Read 1KB. If there's a null byte (\0), it's binary. Text files don't have null bytes.

Simple check. Works.

Recursive Search Without Exploding

The -r flag searches directories. This means reading entries, checking if they're files or directories, and recursing when needed.

The trick: Don't stop on errors. One locked file shouldn't kill your entire search.

if info.IsDir() {
    if !opts.Recursive {
        return 0, fmt.Errorf("%s is a directory", fileName)
    }

    entries, err := os.ReadDir(fileName)
    if err != nil {
        return 0, fmt.Errorf("error reading directory: %v", err)
    }

    total := 0
    for _, entry := range entries {
        path := filepath.Join(fileName, entry.Name())
        subCount, err := grepFile(pattern, path, opts)
        if err != nil {
            fmt.Fprintf(os.Stderr, "warning: %v\n", err)
            continue  // Keep going
        }
        total += subCount
    }
    return total, nil
}

Log it, move on. Real grep does this. So should you.

Flags Interact in Weird Ways

Case-insensitive search: Modify the pattern before compiling the regex.

if opts.CaseInsensitive {
    pattern = "(?i)" + pattern
}
re, err := regexp.Compile(pattern)

List files only: Stop after the first match.

if matched {
    count++
    if opts.ListFilesOnly {
        fmt.Printf("%s:\n", fileName)
        return count, nil  // Done
    }
}

Invert match: Flip the boolean.

matched := re.MatchString(line)
if opts.Invert {
    matched = !matched
}

Getting these combinations right took a few tries. -r -l should recurse and list filenames. -v -i should invert case-insensitive matches. Test all the combinations.

Color Output

Grep highlights matches in red. To do this:

Find all regex matches in the line
Replace each match with a colored version
Print the result

matchColor := color.New(color.FgRed).SprintFunc()

coloredLine := re.ReplaceAllStringFunc(line, func(m string) string {
    return matchColor(m)
})

ReplaceAllStringFunc walks through matches and applies your function. Easy.

What I Actually Learned

Null bytes are the binary file signal. One check, problem solved.

Compile regex once, use it everywhere. Compiling per-line is stupid slow. Compile once at the start.

Scanner vs ReadFile depends on the file type. Text files get bufio.Scanner for line-by-line reading. Binary files get ReadFile to check the whole thing. Different tools for different jobs.

Recursive operations need error tolerance. One bad file can't crash everything. Log it, continue.

Manual flag parsing sucks. Next time I'm using a library. Checking string prefixes gets old fast.

What's Missing

Real grep has a lot more:

Context lines (-A, -B, -C)
Extended regex (-E)
Fixed string search (-F)
Parallel search
Memory-mapped files for huge files
Proper CLI argument parsing

Mine doesn't. It does basic pattern matching. That's the point - understand the core, skip the extras.

Try It

git clone https://github.com/codetesla51/go-coreutils.git
cd go-coreutils/grep
go build -o grep grep.go
./grep "pattern" file.txt

Basic usage:

./grep "error" logs.txt
./grep -i -n "warning" logs.txt
./grep -r "TODO" ./src
./grep -c "func" main.go

Why This Matters

Grep is everywhere. Understanding how it works changes how you use it. You stop thinking "magic search command" and start thinking "regex matcher with file handling."

Plus, now when someone asks "how does grep detect binary files?" you actually know.

Source: github.com/codetesla51/go-coreutils

More at devuthman.vercel.app

Building a Terminal Calculator That Actually Does Logic: Axion

Uthman Oladele — Sun, 09 Nov 2025 12:45:05 +0000

I built a calculator that does more than just add numbers. It's a full mathematical computing environment in your terminal with logical operations, comparison operators, unit conversions, and persistent memory.

This is an active project - I'm constantly working on it, adding features, fixing bugs, and improving performance.

Why Build Another Calculator?

Because most CLI calculators are just arithmetic. They add, subtract, maybe handle some trig functions, and that's it.

I wanted something that could handle real computational work:

Compare values and return boolean results
Chain logical operations with proper precedence
Convert between units without leaving the terminal
Store variables and reuse them across sessions
Handle scientific notation properly
Remember your calculation history

Basically, a calculator that works the way you think, not just the way computers add numbers.

What It Does

» 2 + 3 * 4
Result: 14

» sin(30) + cos(60)
Result: 1

» 5 > 3
Result: 1

» (5 > 3) && (2 < 4)
Result: 1

» x = sqrt(16)
Result: 4

» convert 100 cm to m
100 cm = 1 m

It's not just a calculator - it's a mathematical environment.

The Core Features

1. Logical and Comparison Operations

This is what sets Axion apart. You can compare values and chain logical operations:

Comparison operators:

>, <, >=, <=, ==, !=
Returns 1 for true, 0 for false

Logical operators:

&& (AND) - returns 1 if both operands are non-zero
|| (OR) - returns 1 if at least one operand is non-zero

Proper precedence:

» 0 || 1 && 0
Result: 0  # evaluated as: 0 || (1 && 0)

» (5 > 3) && (2 < 4)
Result: 1

» temp = 25
» isComfortable = (temp > 18) && (temp < 28)
Result: 1

The precedence order matters:

|| (lowest)
&&
Comparison operators
Arithmetic operators
Parentheses (highest)

2. Variable System with Persistence

Variables persist across sessions:

» radius = 5
Result: 5

» area = pi * radius^2
Result: 78.5398

» isLarge = radius >= 10
Result: 0

Close the calculator, open it again, and your variables are still there. Stored in JSON, loaded automatically.

3. Unit Conversion System

Built-in conversions across three categories:

Length: m, cm, mm, km, in, ft, yd, mi
Weight: kg, g, mg, lb, oz, ton
Time: s, ms, min, h, d

» convert 5280 ft to mi
5280 ft = 1 mi

» convert 2.5 kg to lb
2.5 kg = 5.51156 lb

The system prevents invalid conversions (like trying to convert kilograms to meters).

4. Scientific Computing

Full scientific notation support and mathematical functions:

» 2e-10 + 3.5E+12
Result: 3500000000000

» log(100) + ln(e) + log2(16)
Result: 9.60517

» mean(10, 20, 30, 40, 50)
Result: 30

Available functions:

Trig: sin(), cos(), tan(), asin(), acos(), atan()
Log: ln(), log(), log10(), log2(), custom base with log(x, base)
Stats: mean(), median(), mode(), sum(), product()
Utility: abs(), ceil(), floor(), round(), sqrt(), exp()
Special: factorial with !, mod(), print()

5. Calculation History

Everything you calculate gets stored:

» history
┌─ Calculation History ────────────────────────────┐
│ 2 + 3 * 4                    = 14
│ sin(30) + cos(60)            = 1
│ x = sqrt(16)                 = 4
│ convert 100 cm to m          = 1 m
└──────────────────────────────────────────────────┘

Stored in JSON, persists across sessions.

How It Works Under the Hood

Axion uses a proper compiler-style pipeline:

User Input
    ↓
Tokenizer → Breaks input into tokens (numbers, operators, functions)
    ↓
Parser → Builds Abstract Syntax Tree (AST) with proper precedence
    ↓
Evaluator → Walks the AST and computes the result
    ↓
Output → Color-coded terminal display

The Parser

This was the hardest part. Getting operator precedence right took multiple attempts.

The parser uses recursive descent with precedence climbing. Each precedence level gets its own parsing function:

// Simplified version
func (p *Parser) parseExpression() *Node {
    return p.parseLogicalOr()  // Lowest precedence
}

func (p *Parser) parseLogicalOr() *Node {
    left := p.parseLogicalAnd()
    // Handle || operators
    return left
}

func (p *Parser) parseLogicalAnd() *Node {
    left := p.parseComparison()
    // Handle && operators
    return left
}

func (p *Parser) parseComparison() *Node {
    left := p.parseAddition()
    // Handle >, <, ==, etc.
    return left
}

// And so on...

This structure ensures 2 + 3 > 4 || 0 parses correctly:

Parse 2 + 3 (addition has higher precedence)
Parse > 4 (comparison)
Parse || 0 (logical OR has lowest precedence)

Token Types

The tokenizer recognizes:

NUMBER - integers, decimals, scientific notation
OPERATOR - +, -, *, /, ^, !
COMPARISON - >, <, >=, <=, ==, !=
LOGICAL - &&, ||
FUNCTION - sin, cos, log, etc.
LPAREN/RPAREN - parentheses for grouping
COMMA - function argument separator

The Evaluator

Walks the AST recursively. Each node type has its own evaluation logic:

switch node.Type {
case NODE_NUMBER:
    return parseFloat(node.Value)

case NODE_OPERATOR:
    left := Eval(node.Left)
    right := Eval(node.Right)
    return applyOperator(node.Value, left, right)

case NODE_COMPARISON:
    left := Eval(node.Left)
    right := Eval(node.Right)
    if compareValues(node.Value, left, right) {
        return 1.0  // true
    }
    return 0.0  // false

case NODE_AND:
    left := Eval(node.Left)
    right := Eval(node.Right)
    if left != 0 && right != 0 {
        return 1.0
    }
    return 0.0
}

Comparisons and logical operations return 1.0 (true) or 0.0 (false), which lets you use them in further calculations.

Real-World Use Cases

Physics Calculations

» F = 9.8 * 75  # Force = mass * acceleration
Result: 735

» isValidForce = F > 0 && F < 1000
Result: 1

» E = F * 10    # Energy = force * distance
Result: 7350

Financial Math

» principal = 1000
» rate = 0.05
» compoundInterest = principal * (1 + rate)^10
Result: 1628.89

» isProfit = compoundInterest > principal
Result: 1

Engineering

» voltage = 12
» current = 2.5
» power = voltage * current
Result: 30

» resistance = voltage / current
Result: 4.8

» isSafeVoltage = voltage < 50
Result: 1

Project Structure

Axion/
├── main.go              # Entry point
├── cmd/                 # Cobra CLI commands
│   └── cmd.go          # REPL implementation
├── tokenizer/          # Lexical analysis
│   └── tokenizer.go
├── parser/             # Syntax analysis
│   └── parser.go
├── evaluator/          # Expression evaluation
│   └── evaluator.go
├── units/              # Unit conversion
│   └── units.go
├── history/            # History management
│   └── history.go
└── constants/          # Constants loading
    └── constants.go

Each module has a single responsibility. The Cobra framework handles CLI commands and the interactive REPL.

Test Coverage

Core computational modules have solid test coverage:

Units: 100% (unit conversion system)
Tokenizer: 94% (lexical analysis)
Parser: 76.4% (AST construction)
Evaluator: 74.5% (mathematical computation)

The utility modules (constants, history, settings) and CLI handlers don't have tests yet. They're next on the list.

Installation

Quick install (Linux/macOS):

git clone https://github.com/codetesla51/Axion.git
cd Axion
chmod +x install.sh
./install.sh
source ~/.bashrc

The script builds the binary, creates a symlink in ~/.local/bin, and adds it to your PATH.

Manual install:

git clone https://github.com/codetesla51/Axion.git
cd Axion
go build -o axion
./axion

What I Learned

Operator precedence is harder than it looks. Getting && to bind tighter than || while both bind looser than comparisons required multiple parsing passes.

Recursive descent parsing is elegant. Once you understand the pattern (each precedence level calls the next higher level), it's straightforward to extend.

The Cobra framework is powerful. Building a CLI with subcommands, flags, and help text is trivial with Cobra. Would have taken way longer without it.

Testing matters. The bugs I caught with unit tests would have been nightmares to debug in production. Writing tests as you go saves time.

JSON is good enough for most storage needs. No need for a database when you're just storing variables and history. JSON files work fine and are human-readable.

What's Next

Potential additions:

Matrix operations
Complex numbers
Custom function definitions
Graphing capabilities
More unit categories (temperature, pressure, etc.)
Export calculations to different formats

But the core is solid. It does what it needs to do.

Try It

git clone https://github.com/codetesla51/Axion.git
cd Axion
./install.sh
axion

Then try some calculations:

» x = 10
» y = 20
» (x > 5) && (y < 25)
Result: 1

» convert 5 km to mi
5 km = 3.10686 mi

» print(sin(45))
0.707107

Built with Go and Cobra. Full source on GitHub.

Check out more at devuthman.vercel.app

Building Git from Scratch in Go: What I Learned About Version Control Internals

Uthman Oladele — Sun, 09 Nov 2025 12:36:05 +0000

I didn't understand Git until I broke it open and rebuilt it from scratch. No libraries, no shortcuts - just SHA-256 hashing, tree structures, and commit graphs.

I built a Git implementation in Go without using any Git libraries. No magic, just content-addressable storage and the object model. It works, it taught me more about Git in a week than years of using it, and here's what I learned.

How I Learned This

This wasn't from a single source. I pieced it together from:

CodeCrafters - Their "Build Your Own Git" challenge gave me the structure and pushed me to actually implement things
Random YouTube videos - Honestly, just searching "how git works internally" and watching whatever came up. Some were helpful, most weren't
"Building Git" book - Wasn't really helpful for what I needed, but it did clarify some object format details

Most of the learning came from trial and error. Breaking things, reading error messages, and debugging for hours.

Why Build This?

I use Git every day but had no idea how it actually works. Just git add, git commit, and hope nothing breaks. I wanted to understand what's really happening under the hood.

The goal wasn't to make something production-ready. I just wanted answers:

Why are commits so cheap?
How does Git deduplicate files automatically?
What the hell is a "tree object"?
Why is branching fast?

Turns out the best way to understand something is to build it yourself.

What It Does

Go-Git implements the core stuff:

go-git init                    # Initialize repository
go-git config                  # Set user identity
go-git add <files...>          # Stage files
go-git commit -m "message"     # Create commit
go-git log                     # View history

It handles content-addressable storage, the staging area, tree objects, commit history, and zlib compression. Basically everything Git does to manage your code, minus branches, merges, and remotes.

The Three Main Ideas

1. Content-Addressable Storage

Every object (file, directory, commit) gets stored by its SHA-256 hash:

.git/objects/ab/c123def456...
            ↑↑  ↑↑↑↑↑↑↑
            │   └─ Rest of hash (filename)
            └───── First 2 chars (subdirectory)

This is actually genius. Same content = same hash = automatic deduplication. You could store the same README.md across 100 commits and it only takes up disk space once.

Your file's hash IS its address. No need for a separate indexing system.

2. The Three Trees

Git tracks files through three layers:

Working Directory  →  Staging Area  →  Repository
   (your files)        (.git/index)     (.git/objects)

go-git add moves files from working directory → staging area
go-git commit snapshots staging area → repository

The staging area is literally just a text file mapping paths to hashes:

100644 abc123... README.md
100644 def456... src/main.go

When you commit, Git hashes this whole thing into a tree object.

3. Tree Objects (The Hard Part)

Files get stored as blobs. Directories get stored as trees.

Simple project structure:

project/
  README.md
  src/
    main.go
    lib/
      helper.go

Git stores it like this:

Commit (abc123)
    ↓
Root Tree (def456)
├─ blob: README.md (hash: abc123)
└─ tree: src/ (hash: def456)
      ├─ blob: main.go (hash: ghi789)
      └─ tree: lib/ (hash: jkl012)
            └─ blob: helper.go (hash: mno345)

Here's what finally clicked for me: Trees don't contain their children - they just reference them by hash. That's why Git is fast. If a directory doesn't change, same hash, just reuse the tree. No need to re-store anything.

The tricky part: You have to build trees bottom-up (deepest first) because parent trees need their children's hashes.

You can't hash src/ until you know the hash of src/lib/. Can't hash the root tree until you know the hash of src/. The order matters, period.

This took me over 5 hours to get right.

What Was Hard

Tree Building Order

First try: Build trees top-down, starting from root. Immediately failed - you don't have the child tree hashes yet.

Fix: Sort directories by depth, build the deepest ones first:

sort.Slice(dirs, func(i, j int) bool {
    return strings.Count(dirs[i], "/") > strings.Count(dirs[j], "/")
})

Then for each directory, check if any trees you've already built are its children and add them.

Binary vs Hex Encoding

Tree objects store hashes as 32 binary bytes, not 64-character hex strings.

My bug:

content += entry.BlobHash  // Wrong! This is a 64-char hex string

The fix:

hashBytes, _ := hex.DecodeString(entry.BlobHash)
content = append(content, hashBytes...)  // 32 binary bytes

This made my trees twice as big as they should've been. Spent an hour debugging because it was subtle - objects were still readable but tree traversal was completely broken.

Excluding .git/ When Staging

When you do go-git add ., you don't want to accidentally add .git/objects/ to the index.

First attempt: Check if the path contains .git. Problem: this also excluded files like my.git.file.

The right way:

if d.Name() == ".git" && d.IsDir() {
    return filepath.SkipDir
}

filepath.SkipDir during directory traversal is the way to go.

How Objects Work

Every object follows this format:

<type> <size>\0<content>

Gets compressed with zlib, stored at .git/objects/<hash[:2]>/<hash[2:]>.

Blob:

blob 13\0Hello, World!

Hash it → a0b1c2d3... → Store at .git/objects/a0/b1c2d3...

Tree:

tree 74\0100644 README.md\0<32-byte-hash>040000 src\0<32-byte-hash>

Modes:

100644 = regular file
040000 = directory (tree object)

Commit:

commit <size>\0
tree abc123...
parent 789xyz...
author Uthman <email> timestamp
committer Uthman <email> timestamp

Initial commit

Commits form a directed acyclic graph. go-git log just walks backwards through this chain from HEAD.

What I Actually Learned

Content-addressable storage is elegant. Hash = address. This one idea enables deduplication, integrity checking, and efficient storage.

Trees are graphs, not nested structures. A tree object doesn't "contain" subtrees - it references them by hash. This indirection is what makes Git efficient. Multiple commits can share the same tree if a directory didn't change.

Building bottom-up is necessary. You can't hash a parent without knowing its children's hashes. The order matters fundamentally.

Compression matters. Without zlib, .git/objects/ would be 3-4x larger. Git uses compression everywhere for a reason.

Binary formats are tricky. Working with \0 null bytes and binary hash data requires careful handling. Text formats would be easier but less efficient.

What's Missing

This is a learning project, not production software:

No branches (only main exists)
No merge operations
No diff/status commands
No remote operations (push/pull/fetch)
No .gitignore support
No packed objects (each object is a separate file)
Plain text index (real Git uses binary format)

These limitations exist because this project focuses on Git's core: the object model, staging, and commits. Adding branches/merging/remotes would be another 2-3x the code and shift focus from fundamentals to features.

Try It Yourself

git clone https://github.com/codetesla51/go-git.git
cd go-git
./install.sh

# Or build manually:
go build -buildvcs=false -o go-git
ln -s $(pwd)/go-git ~/.local/bin/go-git

Then:

mkdir my-project
cd my-project
go-git init
go-git config

echo "Hello World" > README.md
go-git add README.md
go-git commit -m "Initial commit"
go-git log

Want to really learn? Clone it, break something on purpose (change the hash function to MD5, remove zlib compression), and see what fails. Watch how Git's assumptions about immutability and content-addressing cascade through the system. That's how you really understand it.

Final Thoughts

Building this taught me more about Git in a week than years of using it did. I now understand why commits are cheap (just pointers to trees), how deduplication works (content-addressable storage), and why branching is fast (just moving a pointer).

If you want to truly understand a tool, build it yourself.

Built with Go, no Git libraries used. All hashing, compression, and object storage is custom implementation.

Check out more of my work at devuthman.vercel.app | GitHub

Building an HTTP Server from TCP Sockets: 250 4,000 RPS

Uthman Oladele — Fri, 07 Nov 2025 12:59:48 +0000

Most developers use frameworks like Express or Flask without understanding what happens underneath. I built an HTTP/HTTPS server from raw TCP sockets in Go to learn how web servers actually work - no frameworks, just socket programming and protocol implementation.

The result? A journey from 250 RPS with buggy connection handling to 4,000 RPS at peak performance. Here's how I did it and what I learned.

Why Build This?

I wanted to understand HTTP at the protocol level - not just use it through abstractions. What does "parsing a request" actually mean? How does keep-alive work? What makes one server faster than another?

Building from TCP sockets up forced me to learn:

How HTTP requests are structured byte-by-byte
Connection lifecycle and reuse patterns
TLS/SSL encryption from first principles
Why implementation details matter for performance

What I Built

A lightweight HTTP/HTTPS server that:

Parses HTTP requests directly from TCP socket connections
Routes requests with custom method and path matching
Serves static files with proper MIME type detection
Supports HTTP/1.1 keep-alive for connection reuse
Handles form data and JSON request bodies
Includes optional TLS encryption for HTTPS
Achieves 4,000 requests per second at peak

Tech stack: Pure Go, no web frameworks. Just net package for TCP, crypto/tls for HTTPS, and html/template for rendering.

The Performance Journey

Initial Version: 250 RPS (Buggy)

My first implementation had a critical bug in request processing combined with Connection: close on every response. The server worked but was crawling.

Bug Fix: 1,389 RPS

Fixed the request handling logic but still sent Connection: close on every response. This meant every request required a new TCP handshake - expensive.

Keep-Alive Implementation: 1,710 RPS

Added proper HTTP/1.1 keep-alive support. Connections stayed open for multiple requests. Immediate improvement but not optimal yet.

Peak Performance: 4,000 RPS

Discovered that concurrency level matters significantly. At 10 concurrent connections with connection reuse, the server hit 4,000 RPS with 0.252ms response times.

Total improvement: 16x from initial version

How It Actually Works

1. TCP Connection Handling

listener, err := net.Listen("tcp", ":8080")
if err != nil {
    log.Fatal(err)
}

for {
    conn, err := listener.Accept()
    if err != nil {
        continue
    }
    go handleConnection(conn) // One goroutine per connection
}

Each connection gets its own goroutine. Go's scheduler handles thousands of these efficiently.

2. HTTP Request Parsing

Reading from the socket gives you raw bytes. You need to parse:

Request line: GET /path HTTP/1.1
Headers: Content-Type: application/json
Body: Form data or JSON payload

func parseRequest(conn net.Conn) (*Request, error) {
    reader := bufio.NewReader(conn)

    // Read request line
    requestLine, err := reader.ReadString('\n')
    if err != nil {
        return nil, err
    }

    // Parse method, path, version
    parts := strings.Split(strings.TrimSpace(requestLine), " ")
    if len(parts) != 3 {
        return nil, errors.New("invalid request line")
    }

    method := parts[0]
    path := parts[1]

    // Read headers until empty line
    headers := make(map[string]string)
    for {
        line, err := reader.ReadString('\n')
        if err != nil || line == "\r\n" {
            break
        }
        // Parse header: "Content-Type: application/json"
        // ... header parsing logic
    }

    return &Request{Method: method, Path: path, Headers: headers}, nil
}

3. Keep-Alive Implementation

The breakthrough came from proper connection reuse:

func handleConnection(conn net.Conn) {
    defer conn.Close()

    for {
        req, err := parseRequest(conn)
        if err != nil {
            break // Connection closed or invalid request
        }

        response := router.Handle(req)

        // Send response with keep-alive
        conn.Write([]byte("HTTP/1.1 200 OK\r\n"))
        conn.Write([]byte("Connection: keep-alive\r\n"))
        conn.Write([]byte("Content-Length: " + strconv.Itoa(len(response)) + "\r\n"))
        conn.Write([]byte("\r\n"))
        conn.Write([]byte(response))

        // Connection stays open for next request
        if req.Headers["Connection"] == "close" {
            break
        }
    }
}

This simple change - keeping connections open - improved performance by 23% (1,389 → 1,710 RPS).

4. Routing System

type Handler func(*Request) (string, string)

type Router struct {
    routes map[string]map[string]Handler // method -> path -> handler
}

func (r *Router) Register(method, path string, handler Handler) {
    if r.routes[method] == nil {
        r.routes[method] = make(map[string]Handler)
    }
    r.routes[method][path] = handler
}

func (r *Router) Handle(req *Request) string {
    if handler, exists := r.routes[req.Method][req.Path]; exists {
        statusCode, body := handler(req)
        return createResponse(statusCode, body)
    }
    return createResponse("404", "Not Found")
}

5. HTTPS/TLS Support

Adding TLS was surprisingly straightforward with Go's crypto/tls:

cert, err := tls.LoadX509KeyPair("server.crt", "server.key")
if err != nil {
    log.Fatal(err)
}

config := &tls.Config{Certificates: []tls.Certificate{cert}}
listener, err := tls.Listen("tcp", ":8443", config)

// Same connection handling as HTTP
for {
    conn, err := listener.Accept()
    if err != nil {
        continue
    }
    go handleConnection(conn)
}

The TLS layer handles encryption/decryption transparently. Your HTTP parsing code stays the same.

Performance Analysis

Testing with different concurrency levels revealed interesting patterns:

Concurrency	RPS	Response Time	Notes
10	4,000	0.252ms	Peak performance
50	2,926	0.342ms	Excellent
100	2,067	0.484ms	Very good
500	2,286	0.437ms	Good
1000	1,463	0.683ms	Moderate load

Key insights:

Sweet spot: 10-200 concurrent connections
Sub-millisecond response times at low concurrency
0% failure rate across all tests
Connection reuse was the single biggest optimization

Example Usage

Here's how you'd use this server:

router := server.NewRouter()

// Simple API endpoint
router.Register("GET", "/ping", func(req *server.Request) (string, string) {
    return server.CreateResponse("200", "text/plain", "OK", "pong")
})

// Form handling with browser detection
router.Register("POST", "/login", func(req *server.Request) (string, string) {
    username := req.Body["username"]
    browser := req.Browser // Parsed from User-Agent

    if username == "admin" {
        return server.CreateResponse("200", "text/html", "OK", 
            "<h1>Welcome "+username+"!</h1><p>Browser: "+browser+"</p>")
    }
    return server.CreateResponse("401", "text/html", "Unauthorized", 
        "<h1>Login Failed</h1>")
})

Quick start:

git clone https://github.com/codetesla51/raw-http
cd raw-http
go mod tidy
go run main.go

# Test it
curl http://localhost:8080/ping
# Returns: pong

curl -X POST http://localhost:8080/login \
  -d "username=admin&password=secret"

What I Learned

1. HTTP Is Just Text Over TCP

Seeing the raw bytes demystified HTTP completely. It's not magic - just structured text following a protocol.

2. Connection Reuse Matters

The jump from 1,389 to 1,710 RPS came purely from keeping connections open. TCP handshakes are expensive.

3. Concurrency Level Impacts Performance

More concurrent connections doesn't always mean better performance. The server performed best at 10-200 concurrent requests, then degraded at higher levels.

4. Go's Concurrency Model Shines

One goroutine per connection is simple and scales well. No need for complex event loops or worker pools.

5. TLS/SSL Is Less Scary Than It Seems

With proper libraries, adding encryption is straightforward. The protocol complexity is handled for you.

6. Security Requires Constant Attention

Path traversal protection, request size limits, and proper error handling are essential. Easy to miss when building from scratch.

Limitations

This is a learning project, not production software:

Basic error handling
Simple routing (no regex or path parameters)
No middleware system
Limited HTTP method support
Self-signed certificates only

But that's the point - understanding fundamentals before adding features.

Try It Yourself

The full source code is on GitHub: codetesla51/raw-http

Routes to try:

/ - Home page
/ping - Simple API endpoint
/login - Form handling demo
/welcome - Template rendering

For HTTPS (port 8443), the repo includes self-signed certificates for testing. For production, use Let's Encrypt or another CA.

Conclusion

Building an HTTP server from TCP sockets taught me more about web programming in a week than years of using frameworks. The 16x performance improvement wasn't just about optimization - it was about understanding what actually makes servers fast.

If you're curious about how the tools you use every day actually work, I highly recommend building them yourself. Start small, measure everything, and don't be afraid to make mistakes. My first version was buggy and slow, but that's how you learn.

More projects: devuthman.vercel.app

Source code: github.com/codetesla51/raw-http

Built with Go 1.21+ • Created by Uthman