DEV Community: Ezeana Micheal

The Bilingual Developer: Python and Go, The Error Handling Paradigm

Ezeana Micheal — Sat, 27 Jun 2026 06:38:35 +0000

In the previous article, we explored how functions allow us to package logic into reusable blocks. However, a crucial question remains: what happens when that logic goes wrong?

Building applications is not just about writing code for the "happy path," the scenario where everything works perfectly. In reality, our programs interact with the messy, unpredictable outside world. Files we try to open might be missing. Network connections might timeout. Databases might be overloaded. Disk drives might fill up mid-write.

If we ignore these possibilities, our applications will crash spectacularly, leaving users frustrated and data corrupted.

Therefore, a programming language must provide a clear, disciplined way to predict, handle, and recover from failures. This is where Python and Go diverge in one of the most profound ways possible. They represent two completely different schools of thought on how to manage errors. Python embraces the Exception Model, using structured "try/catch" blocks to intercept errors thrown from anywhere. Go rejects exceptions in favor of Errors as Values, forcing developers to handle errors immediately and explicitly by checking return values. Furthermore, when it comes to cleaning up resources (like closing files or releasing network connections), Python offers the elegant with statement (Context Managers), while Go provides the powerful and unique defer keyword.

The Python Way: The Exception Model

Python operates on a philosophy known as EAFP, which stands for "Easier to Ask for Forgiveness than Permission." This is a distinctly optimistic approach. In Python, you write the code you expect to work, and if something bad happens, the program "raises" (or throws) an exception that interrupts the normal flow of execution.

Think of an exception like a fire alarm. When everything is fine, the alarm is silent, and your program runs smoothly. But when a fire starts (an error occurs), the alarm blares. If you have a fire suppression system (except block) ready, you can contain and handle the fire. If you don't, the fire spreads up the chain of command until the whole building (the program) burns down and crashes.

The try / except / else / finally Structure

Python provides a layered structure to manage exceptions. The try block contains the code that might fail. The except block catches specific errors. The else block runs only if no errors occurred, and the finally block runs regardless of what happened—it is the cleanup crew.

Consider this example where we ask a user for a number:

try:  
    user_input = input("Enter a number: ")  
    number = int(user_input)  # This might raise a ValueError  
    result = 100 / number     # This might raise a ZeroDivisionError  
except ValueError:  
    print("Oops! That wasn't a valid number.")  
except ZeroDivisionError:  
    print("You can't divide by zero!")  
else:  
    print(f"The calculation succeeded! Result: {result}")  
finally:  
    print("Thanks for using the calculator.")

If the user types "five", the ValueError is caught, and the program prints a friendly message instead of crashing. Crucially, the finally block always executes, ensuring that no matter what happens, we can close a file or log the attempt.

The Nature of Python Exceptions

One of the defining characteristics of Python's model is that exceptions bubble up. If you don't catch an exception in the function where it occurs, it automatically propagates up to the function that called it, then up to the next, and so on, until it either finds a matching except block or terminates the entire process.

This allows developers to write very clean, readable "happy path" code. The error-handling logic is neatly separated from the business logic. However, this convenience has a dark side. It is entirely possible to write Python code that "swallows" exceptions by catching a generic Exception and doing nothing, or to forget to handle an edge case entirely, leading to unexpected production crashes. Python trusts the developer to be disciplined, but it does not enforce that discipline at the language level.

The Go Way: Errors as Values

If Python's philosophy is optimistic and permissive, Go's philosophy is stoic, pragmatic, and hyper-vigilant. Go explicitly rejects the exception model (with the exception of panic, which is reserved for catastrophic, unrecoverable events). Instead, Go treats errors as first-class values—just like strings, integers, or booleans.

In Go, if a function can fail, it returns an error as part of its standard return signature. The burden of checking for that error falls squarely on the caller. There is no implicit bubbling up of exceptions; the error is just a piece of data passed from one function to another.

Think of it like a pilot going through a pre-flight checklist. At every single step: checking fuel, checking the flaps, checking the radar, the pilot looks at the instrument panel and asks: "Is everything okay?" If at any point the dial reads "Error," the pilot must stop and address it immediately before moving to the next step.

The Ubiquitous if err != nil

The idiomatic pattern in Go is so ingrained that it has become a meme in the developer community. It looks like this:

package main  
import (  
    "errors"  
    "fmt"  
)

func divide(a int, b int) (int, error) {  
    if b == 0 {  
        return 0, errors.New("cannot divide by zero")  
    }  
    return a / b, nil  
}

func main() {  
    result, err := divide(10, 0)  
    if err != nil {  
        fmt.Println("Handled error:", err) // Output: Handled error: cannot divide by zero  
    } else {  
        fmt.Println("Result:", result)  
    }  
}

Notice the pattern: result, err := divide(...). Immediately following that line is an if statement checking if err != nil.

This design forces the developer to confront the possibility of failure at the exact moment it occurs. You cannot ignore the error, because the compiler won't stop you from ignoring it, but the language syntax encourages you to handle it right there.

The Beauty of Verbosity

Many new developers look at Go's if err != nil blocks and complain about verbosity(which I personally enjoy it). A simple 5-line function might have 3 lines dedicated to error handling.

However, this verbosity is an intentional feature, not a bug. By making error handling explicit and visibly "in your face," Go ensures that the state of the program is always known. When you read Go code, you can trace the exact path the data takes. You can see exactly where a function might exit early due to a failure.

This eliminates the surprise element found in Python. In Go, you never have to guess if an underlying library is going to throw a random exception 12 layers deep. The language is brutally honest: every possible failure is declared in the function signature, and every caller is forced to deal with it.

Cleanup and Resource Management: with vs. defer

Handling errors is only half the battle. Often, when an error occurs, we have to gracefully clean up the mess. For example, if you open a file, you must close it. If you lock a mutex, you must unlock it. If a network connection is established, it must be gracefully terminated. Both Python and Go offer sophisticated tools for resource cleanup, but they operate on entirely different scopes.

Python’s Context Managers (with statement)

Python manages resources through the with statement, which leverages the concept of Context Managers.

A context manager is an object that defines two magic methods: enter (executed at the start of the block) and exit (executed when the block finishes, even if an exception occurred).

Consider the classic example of reading a file:

with open("data.txt", "r") as file:  
    content = file.read()

    # The file is automatically closed when the 'with' block ends  
# The file is guaranteed to be closed here, regardless of exceptions in file.read()

The with statement brilliantly bundles acquisition and release into a single, readable line. The exit method handles the cleanup, ensuring the file pointer is closed, database connections are committed, or locks are released the moment you leave the indented block.

The beauty here is scope control. The resource exists only within the boundaries of the with block. This makes Python code highly readable and safe, as long as the developer remembers to use the context manager rather than manually opening and closing files.

Go’s Deferred Functions (defer keyword)

Go does not have a built-in with statement. Instead, it introduces a deceptively simple yet incredibly powerful keyword: defer.

When you prefix a function call with defer, Go schedules that function to run just before the surrounding function returns. It doesn't matter whether the function returns normally, hits a return statement early, or encounters a panic and crashes—the defered call will always execute.

func ReadFile(filename string) error {  
    file, err := os.Open(filename)  
    if err != nil {  
        return err  
    }

    // Defer ensures this runs when the function exits,   
    // regardless of what happens below.  
    defer file.Close() 

    // Perform some operations on the file...  
    data := make([]byte, 100)  
    _, err = file.Read(data)  
    if err != nil {  
        // Even if we return an error here, file.Close() still runs!  
        return err  
    }  
    // If we reach the end, file.Close() still runs!  
    return nil  
}

Notice that defer file.Close() is written immediately after the file is successfully opened. This keeps the resource management right next to the resource allocation, making it easy for developers to see the pairing.

The Power of Stacked defer

Go allows you to defer multiple functions. When you do this, they execute in Last In, First Out (LIFO) order—essentially a stack.

func main() {  
    defer fmt.Println("Third") // Runs last  
    defer fmt.Println("Second") // Runs second  
    defer fmt.Println("First") // Runs first  
}

// Output:  
// First  
// Second  
// Third

This is exceptionally useful when dealing with complex resources like nested locks or database transactions. If you acquire a read lock, then a write lock, defer ensures they are released in the correct reverse order, preventing deadlocks.

The Philosophical Head-to-Head

Let's boil down the key differences to understand the mindsets behind each language.

Python's Philosophy: "You are a responsible adult."

Errors: Exceptions are for exceptional, unexpected cases. We trust you to handle them with try/except, but if you miss one, the interpreter will tell you.
Cleanup: We provide elegant, block-level tools (with) to ensure resources are cleaned up as soon as you logically leave the context.
Result: Code is compact, readable, and fast to write. The main logic isn't cluttered with constant checks.

Go's Philosophy: "Murphy's Law is absolute."

Errors: Errors are just data. They are not exceptional; they are an expected part of every operation. You must check each one explicitly.
Cleanup: We provide function-level tools (defer). The scope is the entire function, ensuring cleanup happens no matter how complex the logic gets.
Result: Code is verbose, bulletproof, and explicit. There is no magic. You can trace exactly what happens at every single line of execution.

Final Thoughts

The error handling paradigm of a language reveals its soul.

When you code in Python, you write in a trusting environment*. You focus on solving the problem, knowing that if something goes wrong, an exception will give you a very clear stack trace to debug it. It is forgiving, which accelerates prototyping and iteration. **The with statement adds a layer of syntactic sugar that makes resource management almost pleasurable.*

When you code in Go*, you write in a defensive environment.* You are constantly asking, "What if this fails?" You check err != nil religiously. It feels pedantic at first, but over time, it cultivates a profound sense of reliability. By using defer, you ensure that your cleanup is tied to the lifetime of the function, making it incredibly hard to leak resources.

A Python developer moving to Go might initially feel frustrated by the verbosity. But the truth is, Go forces you to be honest about the fragility of the systems you are building. In distributed systems, where network calls fail constantly, the "just let it crash" or "ask for forgiveness" model can be dangerous. Go's explicit model, combined with defer, builds software that is designed to withstand the chaos of the real world.

Mastering both paradigms gives you the wisdom to choose the right tool for the job. For a quick script, Python's exceptions are a lifesaver. For a critical backend server that must run for years without downtime, Go's rigorous error values and cleanup mechanisms are the gold standard.

The Day I Confused Task Queues with Message Brokers And Built the Wrong Thing

Ezeana Micheal — Sat, 27 Jun 2026 06:35:44 +0000

In my journey as a backend developer, I had already spent time working with APIs, databases, authentication flows, and background processing. I understood the basic idea that not everything should occur within a request-response cycle, especially when dealing with expensive operations such as sending emails, processing files, or generating reports. Offloading work to the background felt like a solved problem to me.

That confidence was exactly what led me into confusion.

When I first encountered message brokers and task queues, they looked like different names for the same idea. Both involved queues, both involved workers, and both involved asynchronous processing. In my head, the distinction didn’t seem important, so I treated them interchangeably and assumed that choosing one over the other was just a matter of preference or framework availability.

The real issue was that I had not yet understood the difference in intent between communication and execution. What I thought was a simple design choice actually turned into an architectural mistake that affected how I structured an entire system.

How I Misunderstood the Problem

At the time, I was building systems where the backend had to handle multiple heavy operations. A user could upload files, request reports, or trigger processes that should not block the main API response. Naturally, I reached for a queue-based solution because it is the standard answer for background work.

However, instead of asking what role the system needed to play, I focused on what tool could make things asynchronous. That small shift in thinking created the confusion. I assumed that anything that gets delayed or processed later should automatically go into a queue, without distinguishing whether I was dealing with a job that must be executed or an event that other services should react to.

This is where I started building the wrong abstraction.

Where Task Queues Actually Fit

A task queue exists primarily to assign work that must be completed. It is not concerned with broadcasting information, but with ensuring that a specific job gets executed reliably by a worker. In this model, the system is aware that something needs to be done, and it delegates that responsibility to a background process that will eventually complete it.

For example, generating a PDF report or resizing an image fits naturally into this category. The system issues a clear instruction, and a worker picks it up, executes it, and reports completion. The emphasis is on reliability, retries, scheduling, and tracking the state of a job from pending to completed or failed.

In this world, tools like Celery or BullMQ make sense because they are designed around the idea of jobs, not just messages. They treat work as something that must be done, not just something that has been announced.

Where Message Brokers Actually Fit

Message brokers serve a different purpose entirely. Instead of focusing on work execution, they focus on system communication. A message is not necessarily a task that must be completed by one worker, but rather an event that other systems might be interested in.

For example, when a user places an order in an e-commerce system, the order service does not need to directly know what happens next. Instead, it emits an event like “Order Created,” and different services subscribe to that event based on their own responsibilities. The payment service may initiate billing, the inventory service may adjust stock levels, and the notification service may send a confirmation message.

The key idea here is decoupling. The producer of the message does not care who consumes it or how many consumers exist. It simply announces that something happened, and the rest of the system reacts independently.

The Mistake That Caused Confusion

The mistake I made was designing everything as if it were a task system. I treated every background operation as a job that needed to be executed by a worker. That meant I ended up forcing event-driven communication into a task-oriented model, which created unnecessary coupling and made the system harder to extend.

At the same time, I ignored the fact that some operations were not “tasks” at all, but events that should naturally be consumed by multiple services. This led to a situation where my system became rigid, because everything was structured around a single execution mindset instead of a flexible communication model.

The more I added features, the more obvious the flaw became. Services that should have been independent started depending on a central queue, and what should have been a loosely connected system slowly became tightly coupled.

What I Learned from the Experience

The turning point came when I realized that the real distinction is not about tools, but about intent. A task queue exists to execute work, while a message broker exists to distribute information. One is about responsibility, the other is about awareness.

Once I understood that, my design approach changed. Instead of asking which queue system to use, I started asking what kind of relationship existed between components in the system. If one service needed another service to perform a specific job, I used a task queue. If one service simply needed to inform others that something had happened, I used a message broker.

This separation made the architecture cleaner, easier to scale, and much easier to reason about.

Final Reflection

Looking back, the mistake was not technical. It was conceptual. I was solving the right problem in the wrong mental model, and that is often where most architectural failures begin. Tools like queues, brokers, and workers are powerful, but they only work well when the underlying intent is correctly understood.

The lesson that stayed with me is simple. Before choosing infrastructure, understand whether you are assigning work or sharing information. Everything else becomes much clearer after that. What kind of mistakes have you made? You can comment below.

The Bilingual Developer: Python and Go Core Functions

Ezeana Micheal — Fri, 19 Jun 2026 18:32:56 +0000

The Bilingual Developer: Python and Go Core Functions

So far in our journey, we have explored the building blocks of programming:

How to store data using variables,
How to guide the flow of execution using conditional statements, and
How to repeat actions efficiently using loops.

These tools are enough to write simple scripts that can process data or automate mundane tasks.

However, as you start to write larger, more ambitious applications, a new and significant challenge emerges. Imagine you are building an e-commerce platform. You will need the logic for calculating prices based on complex discount rules, validating user credentials against a database, sending transactional emails, and even securely processing credit card payments.

If you try to cram all of this functionality into one massive, linear/sequential file, the code quickly descends into what developers affectionately refer to as "spaghetti code." The logic becomes intertwined, variables conflict with each other, and making a single change to a pricing rule might unexpectedly break the email system. Tracking down a single bug in a 10,000-line file becomes a detective's nightmare, and collaborating with other developers becomes nearly impossible.

This is precisely where functions come into play.

Why Functions?

A function allows us to encapsulate a specific piece of logic into an independent, reusable, and named block of code. We can define the logic once and then "call" it whenever we need that specific behavior.

Think of a function like a specialized machine on an assembly line. You place raw materials at the entrance (these are the inputs or parameters). The gears and motors inside turn and process those materials (this is the internal processing). Finally, a finished product rolls out at the end (this is the return value).

For example, consider a calculator function: the input would be the numbers and the operation (e.g., 5 + 10), the processing would be the internal addition logic, and the output would be the answer (15). This separation between the "how" (the internal mechanics) and the "what" (the input/output) is what makes functions so powerful.

Both Python and Go rely heavily on functions, but once again, the way they define, structure, and treat these functions showcases a fundamental difference in the philosophies of the two languages.

What is a Function?

At its core, a function is a reusable block of code designed to perform a single, specific task. Think of it as a verb in your program; it acts.

Instead of writing the same code repeatedly, like manually printing a welcome message for each user:

print("Welcome Michael")  
print("Welcome Sarah")  
print("Welcome David")

You can create a function named welcome_user() and simply reuse that one-liner over and over again.

This simple abstraction provides benefits to software development:

Avoiding Repetition (DRY Principle): Standing for Don't Repeat Yourself, this is a core tenet of software engineering. If you need to change the welcome message from "Welcome" to "Greetings", you only need to change the code inside the function once, rather than searching through hundreds of files.
Better Organization: Functions allow you to break a massive, monolithic program into small, digestible, logical modules. You can group related tasks together (e.g., putting all user authentication logic into a single file of functions).
Simplified Debugging: When a bug occurs, functions help isolate the problem. If the pricing calculation is wrong, you know exactly which function to inspect without sifting through irrelevant code for user validation.
Reusable Components: Once you write a function, you can use it in different parts of your application, or even copy it into a completely different project, saving precious development time.

The Anatomy of Function Definition

The very first difference we encounter between Python and Go is the syntax required to declare a function to the compiler or interpreter.

Python: Using def

Python prides itself on readability, and its function definition syntax is an excellent example. It uses the straightforward keyword def, which is an abbreviation for "define."

def greet():  
    print("Hello Developer")

To execute this function, you simply call it by its name followed by parentheses:

greet()

Output:

Hello Developer

We can notice how Python's structure almost reads like plain English: Define a function called greet. Furthermore, Python does not use brackets to define the scope of the function. Instead, it strictly relies on indentation(as we have seen in loops and conditions too). The indented block of code directly underneath the def statement is what belongs to the function. This forces clean, uniform formatting across all Python code.

Go: Using func

Go takes a slightly more terse, brace-oriented approach. It uses the keyword func to declare a function.

func greet() {  
    fmt.Println("Hello Developer")  
}

Calling the function is syntactically similar to Python:

greet()

Output:

Hello Developer

However, the structural differences are immediately apparent. Go uses curly braces { } to define the beginning and end of the function's logic, much like C, Java, or JavaScript. Additionally, Go is strict about syntax; the opening curly brace must be on the same line as the function declaration, otherwise, the compiler will throw an error. While Python relies on the developer to maintain consistent whitespace, Go offloads that structural enforcement to the compiler using braces.

Passing Information: Functions With Parameters

Most functions are not meant to do the exact same thing every single time. They need dynamic information to work with. For instance, instead of creating a function that always prints "Hello Michael", we want a function that works for anyone.

Python Parameters

Python allows you to define parameters inside the parentheses. Because Python is dynamically typed, you just provide the variable name without specifying what kind of data it is.

def greet(name):  
    print("Hello", name)

When you call this function, you pass the value:

greet("Michael")

Output:

Hello Michael

Python's approach emphasizes flexibility. You can pass a string, an integer, or even a list into that name parameter. While this is convenient, it means the interpreter will only realize you passed a wrong type (like a number that breaks the print formatting) when the code is actually running. Although in newer versions of python you can specify a type hint to specify datatype, see more below.

Go Parameters

Go, on the other hand, requires explicit type declarations. When defining the function, you must tell the compiler exactly what data type the name parameter is expected to hold.

func greet(name string) {  
    fmt.Println("Hello", name)  
}

The name string part is mandatory. It tells Go: "This function expects a single argument called 'name', and it must strictly be a string." Calling the function remains the same:

greet("Michael")

This requirement ensures that the Go compiler knows exactly how much memory to allocate for the variable and prevents you from accidentally passing an integer to a function that expects text.

Understanding Function Signatures

In computer science, a function signature acts as the "contract" of a function. It defines the function's name, the types and order of its parameters, and the types of values it returns. This is where Python and Go fundamentally diverge.

Python: Optional Type Hints

Python operates on dynamic typing. By default, Python does not care about the data types, so a signature is simply the name and parameter list:

def add(a, b):  
    return a + b

The interpreter figures out what a and b are only when the function runs.

However, Python 3 introduced "Type Hints" to add optional clarity:

def add(a: int, b: int) -> int:  
    return a + b

Here, we communicate our intention: a and b should be integers, and the output should be an integer. This is fantastic for documentation and helps IDEs catch potential issues. Crucially, however, Python does not enforce these hints. You could still write:

add("Hello", "World")

Depending on the context, this might run perfectly fine (it would concatenate the strings) or crash. The responsibility lies entirely with the developer and third-party tools like mypy.

Go: Mandatory Types

Go is a statically typed language. Types are not optional; they are part of the language's DNA. The function signature is explicitly defined:

func add(a int, b int) int {  
    return a + b  
}

Here, the signature is rigid and unmistakable:

Inputs: a (int) and b (int).
Output: int.

The Go compiler rigorously checks these type definitions during the compilation phase, which happens before the code ever runs. This is known as compile-time safety. Consequently, if you try to compile add("Hello", "World"), the compiler will halt and refuse to build the executable, throwing a type mismatch error instantly.

This difference highlights the core philosophies: Python acts like a flexible workshop where you can modify things quickly with few restrictions, while Go acts like a precision engineering lab where everything must be measured and declared upfront to prevent catastrophic failures later.

Returning Data

Most functions are designed not just to perform an action but to compute a result and hand it back to the part of the program that called them. For example, a calculator function isn't helpful if it just calculates internally and throws the answer away; it must return the answer.

Python: Returning Values

Python uses the return keyword to send data back.

def add(a, b):  
    return a + b

result = add(5, 10)  
print(result) # Output: 15

While Python appears to support returning multiple values, it actually does so using a trick. When you write return "Michael", 25, Python is internally creating a tuple and returning that single container.

def user_info():  
    return "Michael", 25

name, age = user_info() # This is tuple unpacking

The function didn't natively return two separate things; it returned one tuple, and Python gracefully unpacked it into two variables.

Go: Native Multiple Return Values

Go has native support for returning multiple distinct values directly from the function, without wrapping them in a container.

func userInfo() (string, int) {  
    return "Michael", 25  
}

name, age := userInfo()  
// name is now "Michael", age is now 25

The (string, int) part of the signature explicitly declares that this function will produce two separate values. This is a language-level feature, not a trick.

Why Multiple Returns Are a Game-Changer in Go

The native support for multiple return values isn't just a syntactic convenience; it fundamentally shapes how Go handles errors.

In many other languages (including Python), errors are often handled using try/except blocks. These exceptions can be thrown deep inside a function and caught elsewhere, potentially leading to situations where a developer forgets to catch an error entirely, causing the program to crash unpredictably.

Go takes a radically different approach. It discourages exceptions in favor of explicit error handling. The most idiomatic pattern in Go is to return two values:

The actual result (if successful).
An error value (if something went wrong).

func divide(a int, b int) (int, error) {  
    if b == 0 {  
        return 0, errors.New("cannot divide by zero")  
    }  
    return a / b, nil // nil means "no error"  
}

When you call this function, you are forced to immediately acknowledge both the result and the possibility of an error:

result, err := divide(10, 2)  
if err != nil {  
    fmt.Println("Oops:", err)  
} else {  
    fmt.Println("Result:", result)  
}

This pattern appears everywhere in Go. It forces the developer to confront the possibility of failure right at the point of execution, leading to more robust, predictable software.

Python vs. Go: The Underlying Philosophies

Python's Angle: Python focuses on developer velocity and flexibility. It uses def, treats types as optional enhancements, and allows functions to accept a variety of data without strict declarations.

Go's Angle: Go focuses on clarity, maintainability, and safety. It uses func, mandates types, and ensures that the inputs and outputs of every function are crystal clear to both the developer and the compiler.

Finally

Mastering functions is an exciting leap in the programming journey. It marks the transition from writing small, disposable scripts to architecting real, maintainable applications. Functions allow you to take complex, tangled logic and break it down into small, reusable pieces.

A Python developer moving to Go might initially feel constrained, asking, "Why do I have to write all these types and explicitly handle every error?"

I felt this way before, and honestly, its worth it. This constraint is a feature, not a bug. Go pushes you to clearly articulate how data moves through your program, ensuring you understand the flow of information thoroughly before the code even runs. Learning to appreciate this enforced clarity doesn't just make you better at Go; it fundamentally sharpens your discipline as a developer. It trains you to think critically about data flow and architecture, a skill that is invaluable regardless of which language you ultimately choose to write your applications in.

Thanks for reaching the end of my article, like, comment and share, lets keep-on our journey dual-learning.

Why Go's Goroutines Made Concurrency Finally Click for Me

Ezeana Micheal — Fri, 19 Jun 2026 18:12:27 +0000

I’ve been writing Python for a long time, and like many developers in that space, I got used to a certain way of thinking about concurrency: async/await, event loops, and carefully managing when things pause and resume. It worked well but sometimes it felt like I was always negotiating with the runtime instead of just expressing what I actually want: “run these things at the same time.”

Then I started studying Go (programming language), and specifically goroutines.

The Python Mental Model: Concurrency as Coordination

In Python, especially with asyncio, concurrency often feels like structured waiting. With Python (programming language), you typically deal with:

An event loop
async functions
await points that explicitly yield control
Tasks that must cooperate

You don’t just “run things at the same time.” You define where they can pause.

That design is nice, especially for I/O-heavy workloads. But mentally, there’s always overhead:

Where do I await?
Am I blocking the loop?
Why isn’t this coroutine running?

Even when you understand it, concurrency still feels like something you carefully orchestrate.

Enter Goroutines: Concurrency as a Default State

Then I met goroutines. A goroutine is deceptively simple:

go doSomething()

That’s it, no need for an async keyword, event loop management or even explicit suspension points. The runtime handles scheduling. You don’t coordinate concurrency, you declare it.

At first, this feels almost too simple. But that’s the shift: Go already made the hard decisions for you.

The Mental Shift: From Await Points to Independent Workers

To illustrate, Python async feels like a single chef multitasking in one kitchen. Go feels like hiring multiple cooks.

In Python:

One worker switches tasks
You define pause points
Everything shares a single execution flow

In Go:

Each goroutine is a worker
Tasks run independently
You just assign work and move on

That difference is why goroutines clicked: they match how systems feel in real life, not how we simulate them.

Async vs Go: Pros and Cons

Python Async (async/await)

Pros:

Very explicit control over execution flow
Excellent for structured I/O concurrency (web servers, APIs)
Easier debugging in some cases (you can trace await chains)
Fine-grained control over when tasks yield

Cons:

Requires careful mental tracking of the event loop
“Async all the way down” problem (one blocking call breaks everything)
More boilerplate and discipline required
Easy to accidentally mix sync + async and create issues
Concurrency feels manual rather than natural

Go Goroutines

Pros:

Extremely simple syntax (go function())
Concurrency feels natural and lightweight
Runtime handles scheduling automatically
Scales easily to thousands/millions of goroutines
Cleaner mental model for independent tasks

Cons:

Less explicit control over scheduling
Can accidentally create race conditions if not careful
Requires channels or sync primitives for safe communication
Debugging concurrency issues can feel more opaque
“Too easy to start tasks” can lead to uncontrolled goroutine growth

Channels Made It Even Clearer

Goroutines alone are powerful, but channels complete the picture. Instead of shared memory and locks, Go encourages communication:

ch := make(chan int)  
go func() {  
    ch <- 42  
}()  
value := <-ch

The idea is simple:

Don’t share memory. Communicate instead. That forces a clean mental model:

Who sends data?
Who receives it?
What flows through the system?

Why It Clicked After Python Async

Ironically, I don’t think goroutines would’ve made sense to me without first struggling through Python async.

Python taught me:

Concurrency is not parallelism
Blocking matters
Coordination is hard

Go removed the ceremony and exposed the core idea: Concurrency is just structuring multiple flows of work.

Control vs Trust

Python async gives you control, so you decide when things pause. Go gives you trust, the runtime handles scheduling.

That shift is subtle but powerful:

Python: “I will manage concurrency carefully”
Go: “I will describe work and let the system handle it”

At first, trust feels risky. But it’s also what makes Go feel effortless.

Final Thought

Learning Go didn’t just give me a new tool, it changed how I think about concurrent systems. I still use Python and appreciate async/await, but I see it more clearly: it’s structured concurrency with explicit control. And in Go, I stop thinking about pauses . I just think: Start this. Let it run. Communicate when needed. That’s what finally made concurrency click. Its been a pretty fun journey, Let me know your thoughts, Like, Share and Comment what you think.

The Bilingual Developer: Python and Go Looping & Iteration

Ezeana Micheal — Fri, 12 Jun 2026 18:13:42 +0000

In the last article, I wrote about how programs make decisions using conditionals. We went through how a program can make a decision, choosing one path over another based on whether a condition is true or false.

But what if we need to perform the same action multiple times? Let's say you have a list of about 1,000 users and want to email each of them. You wouldn't write the email-sending code 1,000 times. Instead, you would write it once and have the program repeat it for each user. This is where looping comes in.

Looping allows a program to repeatedly execute a block of code until a condition is met or until all items in a collection have been processed. It's one of the most powerful concepts in programming because it helps us automate repetitive tasks and work with large amounts of data efficiently. Whether you're building a web application, analyzing data, processing files, or developing APIs, you'll find loops everywhere. Let's see how Python and Go approach this concept.

Understanding Iteration

Iteration simply means moving through a collection of data one item at a time. For example, if you have:

students = ["John", "Sarah", "David"]

Iteration means accessing:

John
Sarah
David

one after another. Loops are the mechanism that makes iteration possible. We will now consider some types of loops, first the for loop.

The For Loop

A for loop is used when you want to repeat something a specific number of times or go through a collection of items.

Python's Approach: for item in sequence

Python's for loop is designed around iteration. Instead of asking you to manage counters manually, Python allows you to directly loop through a sequence.

students = ["John", "Sarah", "David"]  
for student in students:  
    print(student)

If you read that aloud, it almost sounds like English: “For each student in students, print the student.” That's one of the reasons Python is often praised for readability. Python also provides the range() function when you want to repeat something a specific number of times.

for i in range(5):  
    print(i)

Output:

We can note that Python focuses less on how the loop works internally and more on what you're trying to accomplish.

Go's Approach: The Universal for Keyword

Instead of providing separate loop structures for different situations, Go uses a single keyword: for. This one keyword handles almost every looping scenario.

A traditional Go for loop looks like this:

for i := 0; i < 5; i++ {  
    fmt.Println(i)  
}

This structure contains three parts: initialization; condition; post-action

In this example:

i := 0 initializes the counter
i < 5 determines how long the loop runs (in this case limiting to 5)
i++ updates the counter by 1 after each iteration

When iterating over collections, Go uses the range keyword.

students := []string{"John", "Sarah", "David"}

for index, student := range students {  
    fmt.Println(index, student)  
}

Unlike Python, Go exposes both the position and the value by default.

This reflects Go's preference for being explicit about what's happening during execution.

The While Loop

Not every situation involves iterating through a collection. Sometimes you want code to keep running as long as a condition remains true.

For example:

Keep asking for a password until the user enters the correct one.
Continue processing requests while the server is running.
Retry an operation until it succeeds.

This is where while loops become useful.

Python's Explicit while Loop

Python provides a dedicated keyword for this purpose:

count = 0  
while count < 5:  
    print(count)  
    count += 1

The logic is straightforward, It continues running this block while the condition remains true and each time the loop runs, the condition is checked again So once the condition becomes false, the loop stops.

Go's Approach: Using for as a While Loop

Go does not have a while keyword.

Instead, Go reuses its universal for loop. To create while-loop behavior, you simply remove the initialization and post-action sections.

count := 0  
for count < 5 {  
    fmt.Println(count)  
    count++  
}

Infinite Loops

Sometimes a loop is intended to run forever until something inside it stops execution.

Python:

while True:  
    print("Running...")

Go:

for {  
    fmt.Println("Running...")  
}

You'll often see these in:

Web servers
Background workers
Event listeners
Real-time systems

Breaking and Continuing

To understand breaking and continuing, we should understand that not every loop should run to completion. Sometimes we want to stop a loop early or skip a particular iteration. This is where break and continue become useful.

Using break

The break statement immediately terminates the loop.

Python example:

for number in range(10):  
    if number == 5:  
        break  
    print(number)

Output:

The moment the value reaches 5, the loop stops completely. Go works the same way:

for i := 0; i < 10; i++ {  
    if i == 5 {  
        break  
    }

    fmt.Println(i)  
}

Again, execution stops as soon as the break statement is reached.

Using continue

The continue statement is slightly different. Instead of stopping the loop, it skips the current iteration and moves to the next one.

Python:

for number in range(5):  
    if number == 2:  
        continue  
    print(number)

Output:

Notice that 2 is skipped. Go behaves the same way:

for i := 0; i < 5; i++ {  
    if i == 2 {  
        continue  
    }

    fmt.Println(i)  
}

The current iteration is skipped, but the loop itself continues running.

Python's Angle vs Go's Angle

Looking at loops gives us another glimpse into the philosophy of both languages.

Python's Angle

Python is designed to make iteration feel natural.

for item in sequence
Dedicated while keyword
Readable syntax
Focus on expressing intent clearly

Python often hides implementation details so you can focus on solving the problem.

Go's Angle

Go prefers consistency over having many specialized constructs.

One loop keyword (for)
Multiple looping styles using the same structure
Explicit control over loop behavior
Less language complexity

Go's mindset is:

Learn one loop mechanism and use it everywhere.

Finally

Looping is one of the fast ways programs get work done in programming. Without loops, applications would struggle to process lists, handle user input, analyze data, or automate repetitive tasks. Python gives you specialized, highly readable constructs for iteration. Go gives you a single, versatile tool that can adapt to different situations.Both approaches are effective.

The real skill as a bilingual developer isn't memorizing syntax, but it's understanding the underlying concept. Once you understand what a loop is trying to achieve, switching between Python and Go becomes much easier. The syntax may change, but the logic remains exactly the same: repeat a task until you're done. Thanks for reading this article, hit the like and comment what you think, thanks.

I Rewrote Our REST API in GraphQL, Here's When It's Worth It

Ezeana Micheal — Tue, 09 Jun 2026 09:55:34 +0000

For most of my development career, REST was my only way of building APIs. It was what I learned first, and it stayed with me. I used it in different applications, including business applications, GIS platforms, dashboards, and e-commerce systems. REST felt natural because it was structured around resources, and the HTTP protocol made everything predictable.

I never really had a strong reason to explore GraphQL. It always felt like something that introduced extra level complexity and uncertainty without a clear benefit in a real production environment. That changed when I decided to rebuild part of an existing REST API using GraphQL, not as a replacement, but as an experiment to understand where it actually fits.

How REST Structures Systems

REST works by exposing resources through endpoints. In an e-commerce system, this typically looks like a clear separation of concerns across entities.

GET /products/100

GET /products/100/reviews

GET /products/100/related

GET /sellers/20

Each endpoint returns a specific dataset, and the frontend is responsible for combining them.

A simple product response might look like this:

{  
  "id": 100,  
  "name": "Wireless Headphones",  
  "price": 120,  
  "seller_id": 20  
}

Then another request is required to fetch the seller:

{  
  "id": 20,  
  "name": "Tech Store",  
  "rating": 4.7  
}

This structure works well because it is simple, explicit, and easy to debug. REST aligns strongly with business workflows where operations are clearly defined.

Where REST Starts to Show Limits

The challenge appears when frontend screens become more data-heavy. A single page in a modern application is rarely powered by a single endpoint. For a product page in an e-commerce system, the frontend may need product details, seller information, reviews, inventory, and related products.

With REST, this often becomes multiple sequential or parallel requests.

GET /products/100  
GET /sellers/20  
GET /products/100/reviews  
GET /inventory/100  
GET /products/100/related

The frontend is forced to merge these responses into one coherent view. On fast networks, this is manageable. On slower networks or mobile devices, it introduces latency and complexity in state management.

How GraphQL Changes the Model

GraphQL shifts the responsibility from multiple endpoints to a single query system. So Instead of the server deciding what each endpoint returns, the client defines exactly what it needs.

A GraphQL query for the same product page might look like this:

query {  
  product(id: 100) {  
    name  
    price

    seller {  
      name  
      rating  
    }

    reviews {  
      user  
      comment  
      rating  
    }

    inventory {  
      quantity  
      warehouse  
    }

    relatedProducts {  
      name  
      price  
    }  
  }  
}

The response comes back in a single structured payload:

{  
  "data": {  
    "product": {  
      "name": "Wireless Headphones",  
      "price": 120,  
      "seller": {  
        "name": "Tech Store",  
        "rating": 4.7  
      },  
      "reviews": [  
        {  
          "user": "John",  
          "comment": "Very good quality",  
          "rating": 5  
        }  
      ],  
      "inventory": {  
        "quantity": 34,  
        "warehouse": "Lagos Hub"  
      },  
      "relatedProducts": [  
        {  
          "name": "Bluetooth Speaker",  
          "price": 80  
        }  
      ]  
    }  
  }  
}

Instead of multiple requests, everything is resolved in one round trip.

Backend Structure Comparison

A REST controller typically looks like this:

@app.route("/products/<int:id>")  
def get_product(id):  
    return get_product_by_id(id)

@app.route("/products/<int:id>/reviews")  
def get_reviews(id):  
    return get_reviews_by_product(id)

In GraphQL, the structure shifts to types and resolvers:

class Product(graphene.ObjectType):  
    name = graphene.String()  
    price = graphene.Float()  
    seller = graphene.Field(Seller)  
    reviews = graphene.List(Review)

class Query(graphene.ObjectType):  
    product = graphene.Field(Product, id=graphene.Int(required=True))

    def resolve_product(self, info, id):  
        return fetch_product_with_relations(id)

The important difference lies in how data relationships are modeled. REST separates concerns by endpoint. GraphQL models relationships directly inside the type system.

GIS Example Where GraphQL Becomes More Obvious

In GIS and land management systems, data is naturally relational. A single land parcel is connected to many entities.

With REST, this might require multiple endpoints:

GET /lands/100  
GET /owners/25  
GET /surveys/10  
GET /documents?land_id=100  
GET /transactions?land_id=100

With GraphQL, the same structure becomes:

query {  
  land(id: 100) {  
    parcelNumber

    owner {  
      name  
      phone  
    }

    survey {  
      surveyor  
      date  
    }

    documents {  
      fileName  
    }

    transactions {  
      amount  
      date  
    }  
  }  
}

The response mirrors the real-world relationship between entities instead of forcing the frontend to assemble it manually.

Where GraphQL Does Not Replace REST

GraphQL is not designed for business operations. It is not ideal for workflows that involve state changes, validations, and side effects.

Actions like the following still fit REST better:

POST /orders

POST /login

POST /payments

POST /upload-document

POST /approve-transaction

These operations represent business intent rather than data retrieval. REST communicates that intent more clearly through HTTP semantics.

Protocol and Architectural Difference

REST is built directly on HTTP methods and resource-based URLs. Each endpoint represents a specific resource or operation, and caching is naturally supported at the HTTP layer.

GraphQL typically exposes a single endpoint:

POST /graphql

The complexity moves into the query layer. This flexibility allows precise data fetching but introduces challenges in caching, monitoring, and query optimization.

When GraphQL Is Worth It

GraphQL becomes valuable in systems where data is highly connected and frontend requirements change frequently. This includes dashboards, analytics platforms, GIS systems, social applications, and mobile apps that require aggregated data from multiple sources.

REST remains stronger in systems that are workflow-driven, transactional, and action-oriented.

Finally,

After working with both approaches, the conclusion is not that one replaces the other. It is that they solve different categories of problems. REST is better suited for business operations and system workflows. GraphQL is better suited for flexible data retrieval in highly relational systems.In most real-world architectures, the right answer is not choosing one over the other, but understanding where each one fits and combining them intentionally.

What’s your opinion? Let me know in the comments below, give a good read, like and share.

The Bilingual Developer: Python and Go Conditionals

Ezeana Micheal — Fri, 05 Jun 2026 16:09:06 +0000

So far, we've talked about how data is stored in memory and the different data types available in Python and Go. Storing data is only part of programming. At some point, our programs need to make decisions.

When thinking about real-world applications, you can think:

Should a user be allowed to log in?
Is a student eligible for admission?
Has a customer completed payment?
Should an email notification be sent?

In all these situations, the program needs to decide what action to take based on certain conditions. This is where conditionals come in. Conditionals allow a program to make decisions based on whether a condition is true or false.

Although Python and Go solve the same problem, they approach conditionals in slightly different ways. In this article, we’ll explore both.

The Syntax Shift: How Python and Go Define Code Blocks

One of the first things you'll notice when writing conditionals in Python and Go is that they define code blocks differently.

In Python, Indentation Matters

Python uses a combination of colons (:) and indentation to indicate which code belongs to a condition.

age = 18  
if age >= 18:  
    print("You are an adult")

Notice two things:

The condition ends with a colon (:).
The code inside the condition is indented.

The indentation is not optional.

For example:

age = 18  
if age >= 18:  
print("You are an adult")

This produces an error because Python relies on indentation to understand the structure of your program. Python's philosophy here is simple:

Code should be readable and visually organized.

By forcing indentation, Python ensures that developers write code in a consistent format.

In Go, Curly Braces Define Structure

Go takes a different route. Instead of indentation, it uses curly braces {} to define blocks of code.

age := 18  
if age >= 18 {  
    fmt.Println("You are an adult")  
}

The braces tell Go exactly where the conditional block starts and ends. Even if you change the spacing or indentation, Go still understands the structure because the braces define it. One important thing to note is that Go does not require parentheses around conditions.

if age >= 18 {  
    fmt.Println("Adult")  
}

Not:

if (age >= 18) {  
    fmt.Println("Adult")  
}

While the second style is common in some languages, Go intentionally keeps the syntax cleaner.

If/Else Chains

A single condition is useful, but real applications often need multiple possible outcomes.

For example:

A score above 70 is an A.
A score above 60 is a B.
A score above 50 is a C.
Anything lower is a fail.

This is where if/else chains become useful.

Python's elif

Python introduces the elif keyword, which stands for "else if."

score = 75  
if score >= 70:  
    print("Grade A")  
elif score >= 60:  
    print("Grade B")  
elif score >= 50:  
    print("Grade C")  
else:  
    print("Fail")

The program checks each condition from top to bottom. As soon as one condition evaluates to True, Python executes that block and skips the rest. This keeps the code concise and easy to read.

Go's else if

Go achieves the same thing using else if.

score := 75

if score >= 70 {  
    fmt.Println("Grade A")  
} else if score >= 60 {  
    fmt.Println("Grade B")  
} else if score >= 50 {  
    fmt.Println("Grade C")  
} else {  
    fmt.Println("Fail")  
}

Functionally, this behaves exactly like Python's elif. The main difference is syntax. Python creates a special keyword (elif). Go combines two existing keywords (else if).

Quick Comparison

Python	Go
if	if
elif	else if
else	else
Uses indentation	Uses braces

Pattern Matching and Multi-Way Decisions

Sometimes an application needs to compare a value against many possible options. Imagine you're building a system that handles user roles:

Admin
Staff
Student
Guest

Using multiple if statements can become messy. Both Python and Go provide a cleaner solution, but they do it differently.

Python's match/case

Starting from Python 3.10, Python introduced match/case.

role = "Admin"  
match role:  
    case "Admin":  
        print("Full access")  
    case "Staff":  
        print("Limited access")  
    case "Student":  
        print("Student access")  
    case _:  
        print("Guest access")

Think of match as saying:

"Compare this value against several patterns and execute the matching block."

The underscore (_) acts as a default case. One reason match/case is powerful is that it can do more than simple value comparisons.

It can match:

Values
Lists
Tuples
Object structures
Complex patterns

This makes it much more powerful than traditional switch statements found in many languages.

Go's switch Statement

Go uses switch.

role := "Admin"  
switch role {  
case "Admin":  
    fmt.Println("Full access")  
case "Staff":  
    fmt.Println("Limited access")  
case "Student":  
    fmt.Println("Student access")  
default:  
    fmt.Println("Guest access")  
}

At first glance, this looks similar to Python's match/case. However, Go's switch statement has a few interesting capabilities.

Switch Without an Expression

One unique feature of Go is that a switch can be used without directly switching on a variable.

score := 75  
switch {  
case score >= 70:  
    fmt.Println("Grade A")  
case score >= 60:  
    fmt.Println("Grade B")  
default:  
    fmt.Println("Fail")  
}

This behaves almost like an organized replacement for a long if/else if chain.

Multiple Values in a Case

Go also allows multiple matching values.

day := "Saturday"  
switch day {  
case "Saturday", "Sunday":  
    fmt.Println("Weekend")  
default:  
    fmt.Println("Weekday")  
}

This can make decision logic much cleaner.

Conclusion: Python's Angle vs Go's Angle

Python's Angle

Python focuses on readability and expressiveness.

Indentation clearly shows structure.
elif makes multi-condition chains easy to read.
match/case supports powerful pattern matching.
The language tries to make decision logic feel natural and close to plain English.

Go's Angle

Go focuses on simplicity and predictability.

Curly braces explicitly define blocks.
else if keeps the language small by reusing existing keywords.
The switch is versatile enough to replace many if/else chains.
The language avoids adding too many specialized features.

Thanks for reading. Hope you learned something new. Read, like and comment, thanks.

7 REST API Mistakes I Made as a Junior Developer

Ezeana Micheal — Tue, 02 Jun 2026 16:27:15 +0000

REST APIs are one way applications exchange information, especially between the client and server sides of modern systems. APIs are created on the server and consumed by web, mobile, or desktop clients.

When I started my career as a junior developer, I built several APIs that worked, but I learned lessons through experience. My APIs were not always designed with scalability, maintainability, or even best practices in mind. As I gained more experience, I discovered some mistakes that I repeatedly made and learned how to correct them.

Here are seven REST API mistakes I made as a junior developer and the lessons I learned from them.

1. Not Versioning My APIs Early

One of the biggest mistakes I made was launching APIs without versioning them from the start. At first, this seemed fine because there was only one client consuming the API. However, as the requirements changed, introducing breaking changes became difficult because existing clients depended on the old structure.

What I Learned is this:

Always version your APIs from day one, even if you don't think you'll need multiple versions.

For Example:

/api/v1/users
/api/v1/orders

Versioning helps to give you the flexibility to evolve your API without breaking existing consumers.

2. Overloading GET Endpoints

I used to create GET endpoints that returned every piece of information about a resource, including large nested objects and related records. This often resulted in slow responses and unnecessary data transfer.

What I Learned is this:

Not every endpoint needs to return full details. It's perfectly acceptable to have(For Example):

GET /users

To return a summarized view:

{  
  "id": 1,  
  "name": "John Doe",  
  "email": "john@example.com"  
}

And then use:

GET /users/1

To return complete information about the user. This approach improves performance and reduces payload sizes.

3. Exposing My Database Structure Directly

Early in my career, I mapped database tables directly to API responses. As a result, clients became tightly coupled to the database design.

Bad Example:

{  
  "tbl_user_id": 1,  
  "tbl_user_fname": "John"  
}

What I Learned is this:

An API should represent business resources, not database tables. A cleaner response would be:

{  
  "id": 1,  
  "first_name": "John"  
}

This gives us the freedom to modify our database without affecting API consumers.

4. Not Implementing Pagination Early

One mistake I made was returning entire datasets from the API. This worked fine during development when there were only a few records, but it quickly became a performance issue as the application grew.

What I Learned is this:

Large datasets should be paginated from the beginning. Instead of:

GET /users

Returning thousands of records, use pagination:

GET /users?page=1&limit=20

Pagination improves performance, reduces bandwidth usage, and provides a better experience for API consumers.

5. Not Thinking About Authentication and Authorization Early

As a junior developer, I focused heavily on making endpoints work and sometimes overlooked who should be allowed to access them.

What I Learned is this:

Authentication and authorization should be part of the API design process from the start.

Ask questions such as:

Who can access this endpoint?
Should this action require login?
Are there admin-only operations?
What happens if an unauthorized user makes a request?

Implementing proper access control early helps prevent security issues during development and future refactoring.

6. Not Standardizing Error Responses

In some projects, every endpoint returned errors differently. One endpoint might return a message, another might return a list of errors, while another might return a completely different structure.

What I Learned is this:

Error responses should follow a consistent format throughout the API.

For example:

{

  "success": false,
  "message": "User not found",
  "error_code": "USER_NOT_FOUND"
}

A standardized error structure makes debugging easier and allows frontend developers to handle errors consistently across the application.

7. Skipping Documentation

As a junior developer, I often assumed that my API endpoints were self-explanatory. They weren't. Even I sometimes forgot how certain endpoints worked after a few weeks.

What I Learned is this:

Good documentation saves time for both API consumers(Frontend developers and others) and future maintainers.

Document:

Endpoint URLs
Request methods
Request parameters
Authentication requirements
Response examples
Error responses

Clear documentation reduces misunderstandings and speeds up integration efforts.

Conclusion

Building APIs that simply work is relatively easy. Building APIs that are maintainable, scalable, and pleasant for other developers to consume requires more thought and experience.

Looking back, these mistakes taught me valuable lessons about API design. Today, whenever I create a new REST API, I focus on versioning early, keeping responses consistent, using proper HTTP methods, avoiding database leakage, and designing endpoints with long-term maintainability in mind.

The best API designs are often the simplest ones: predictable, well-documented, and easy for other developers to understand. Thanks for going through my article. Please leave a like and comment. Thanks.

The Bilingual Developer: Python and Go Primitive Data Types

Ezeana Micheal — Fri, 29 May 2026 15:50:56 +0000

As discussed in the previous article on the variables about the need of programming languages to store information. This article will be about how the different data is stored. Let’s slow it down a bit and really think about it. If storage is where data lives… then data types are basically how that data is shaped inside memory. And depending on the language you’re using, that “shape” changes a lot. Primitive data types are the most basic building blocks used to represent values inside a program.

When learning both Python and Go, understanding their primitive data types is one of the fastest ways to understand the design philosophy behind each language.

Understanding Primitive Data Types

Primitive data types are the simplest forms of data a programming language can handle directly. They represent single values such as:

Text
Numbers
Boolean values (true or false)
Fixed constant values

Text and Characters

Strings in Python

In Python, text is represented using the str data type. A string, simply put, is a sequence of characters enclosed in quotation marks.

name = "Michael"  
message = 'Hello World'

Python treats strings as Unicode by default, meaning they can store characters from different languages and symbols.

emoji = "😊"  
language = "Python"

One of Python’s strengths is how simple string manipulation feels.

first_word = "Go"  
last_word = "Python"

full_word = first_word + " " + last_word

print(full_word)

Output:

Go Python

Python does not have a separate character (char) data type. A single character is simply considered a string of length one.

letter = "A"
print(type(letter))

Output:

<class 'str'>

This design keeps the language simpler because developers only need to think about one text type instead of multiple character-based types.

Strings and Runes in Go

Go also uses strings for textual data.

package main

import "fmt"

func main() {  
    name := "Michael"  
    fmt.Println(name)  
}

But Go handles characters differently from Python.

In Go:

A string represents a sequence of bytes.
A rune represents a single Unicode character.

A rune is actually an alias for int32.

var letter rune = 'A'

Notice something important:

Strings use double quotes " "
Runes use single quotes ' '

This distinction is very important in Go.

package main
import "fmt"

func main() {  
    var character rune = 'G'

    fmt.Println(character)  
}

Output:

The output is numeric because Go stores runes internally using Unicode code points.

To print the actual character:

fmt.Printf("%cn", character)

Output:

Go’s approach gives developers more control over memory and encoding behavior, especially for systems programming and high-performance applications.

Numbers

Numbers are another core primitive data type.

Both Python and Go support:

Integers
Floating-point numbers

Integers and Floats in Python

Python makes numeric programming simple.

age = 25  
price = 19.99

Python automatically determines the type.

print(type(age))  
print(type(price))

Output:

<class 'int'>  
<class 'float'>

One important feature of Python is that integers can grow very large automatically.

big_number = 999999999999999999999999999999

Python dynamically allocates memory for large integers behind the scenes.

This flexibility is convenient because developers rarely worry about integer overflow or memory size during basic programming.

Integers and Floats in Go

Go is stricter and more explicit.

var age int = 25

var price float64 = 19.99

Go supports multiple integer sizes:

int8
int16
int32
int64

And floating-point types:

float32
float64

Example:

var smallNumber int8 = 100  
var largeNumber int64 = 9000000000

This explicit sizing is important because each type uses a specific amount of memory.

Type	Size
int8	8 bits
int16	16 bits
int32	32 bits
int64	64 bits

Go forces developers to think more carefully about memory usage and performance.

For example:

var x int32 = 10  
var y int64 = 20

// This causes an error  
// fmt.Println(x + y)

Go does not automatically mix different integer sizes. Developers must explicitly convert types.

fmt.Println(int64(x) + y)

This strictness reduces accidental bugs and improves predictability in large systems.

Booleans

Booleans represent logical truth values.

They are heavily used in:

Conditions
Comparisons
Decision-making statements

Booleans in Python

Python uses:

True and False

Notice the capitalization.

is_logged_in = True  
is_admin = False

Example:

age = 20  
if age >= 18:  
    print(True)

Output:

True

Python’s boolean system is highly flexible because many values can behave as truthy or falsy.

Examples of falsy values:

0

None

""

[]

False

Everything else is generally considered truthy.

Booleans in Go

Go also supports boolean values, but with stricter rules(as usual).

var isLoggedIn bool = true  
var isAdmin bool = false

Notice the lowercase keywords:

true and false

Go does not allow non-boolean values in conditional statements.

This is invalid:

var number int = 1

if number {  
    fmt.Println("Hello")  
}

Python allows similar truthy checks, but Go requires an actual boolean expression.

Correct Go example:

if number == 1 {  
    fmt.Println("Hello")  
}

This design improves clarity and reduces ambiguity.

Constants

Constants are values that should never change during program execution.

Constants in Python

Python does not have a true constant keyword. Instead, developers follow a naming convention using uppercase variable names.

PI = 3.14159  
MAX_USERS = 100

However, Python does not enforce immutability.

PI = 10

This still works. The uppercase naming style simply communicates intent to other developers. Python relies heavily on developer discipline and readability conventions.

Constants in Go

Go provides an actual const keyword.

const Pi = 3.14159  
const MaxUsers = 100

Once declared, constants cannot be modified.

const Age = 20

// Error  
// Age = 30

This enforcement makes programs safer and more predictable. Go constants can also exist without explicitly specifying a type.

const Name = "GoLang"

The compiler determines the appropriate type automatically.

Conclusion

In Python, primitive types are designed to feel natural and easy to use. Developers can move quickly without worrying much about memory sizes or strict typing rules.

In Go, primitive types are more structured and explicit. Developers are expected to think carefully about memory, type safety, and predictability.

Comment , Share and Like, thanks for reading.

The N+1 Query That Killed Our Database, And How I Fixed It

Ezeana Micheal — Mon, 25 May 2026 17:39:38 +0000

Everything Worked…But Not Well

APIs are affected by the way data is retrieved from the database, and that's something that affected a recent teammate and me during development. In our regular development process, during review and maintenance, the APIs worked, responses came back well, no visible errors. But during this process, we noticed that things started to slow down. Endpoints that used to respond fast suddenly began taking longer, CPU usage on the database increased, and retrieval speed became terrible under load.

At first, we thought:

Maybe the server wasn't powerful enough
Maybe network latency was the issue
Maybe too many requests were hitting the API

But the real issue was hiding inside our database queries.

What Actually Is The N+1 Query Problem?

The N+1 query problem is one of the most common performance issues in backend development, especially when working with relational databases and ORMs(as I, a fan of Django, do). I’m gonna explain this more in SQL terms using retrieval speed and database load.

The problem happens when your application performs:

1 query to retrieve parent records
Then N extra queries to retrieve related child records

So instead of making one optimized query, the application keeps asking the database more questions repeatedly. This increases the query count, read time, database load, and the API response time. 1 issue, several systems affected.

A Simple Example

Let's say we have 2 tables:

Users
Orders

We first retrieve all users.

SELECT * FROM users;

Now imagine there are 100 users. Then, for every user retrieved, another query runs to fetch their orders.

SELECT * FROM orders WHERE user_id = 1;  
SELECT * FROM orders WHERE user_id = 2;  
SELECT * FROM orders WHERE user_id = 3;

And it keeps going. So instead of 1 query, you now have 101 queries. That extra load destroys retrieval speed.

Why This Problem Is Dangerous

The dangerous part is that during development, you might not even notice it. If your database only has just about 5 users and 10 orders, Everything still feels fast.

But once production data grows:

Hundreds of users
Thousands of records
More API requests

The database starts struggling badly. This is why some APIs feel fast during testing but start to slow down after deployment.

The Mistake We Made

The issue wasnt obvious at first because the code itself looked completely normal. We had an endpoint that needed to return users alongside their related orders.

Something like:

User information
Their recent orders
Order counts
Related details

The endpoint worked perfectly during development. But internally, Django was fetching related records separately for every user being serialized. Which meant the API kept hitting the database repeatedly behind the scenes.

The code looked clean.

users = User.objects.all()

serializer = UserSerializer(users, many=True)

But in the serializer, related order data was being accessed for every single user.

class UserSerializer(serializers.ModelSerializer):

    orders = OrderSerializer(many=True)

    class Meta:

        model = User

        fields = ['id', 'name', 'orders']

This is where the real problem started. When Django tried to serialize the response, it kept querying orders separately per user. So if there were 500 users, the system would do:

1 query to retrieve users
Hundreds of additional queries to retrieve orders

That is the N+1 query problem. The scary part is that nothing looked wrong from the surface. The endpoint returned the correct data and no errors, just slow performance. And as traffic increased, the database load became worse. It was slow because the application kept repeatedly asking for related data instead of retrieving it efficiently.

The fix was adding query optimization directly to the queryset.

users = User.objects.prefetch_related('orders')

serializer = UserSerializer(users, many=True)

That single optimization drastically reduced the number of database hits. Instead of querying orders repeatedly for every user, Django retrieved them efficiently in bulk. Same endpoint and response, much better performance.

Understanding `select_related()`

One major fix for this problem in Django is:

select_related()

select_related() is used for relationships like:

ForeignKey
OneToOneField

What it basically does is perform a SQL JOIN and retrieve related data in a single query. Instead of this:

users = User.objects.all()

for user in users:  
    print(user.profile.phone)

Which may generate multiple queries…

You do this:

users = User.objects.select_related('profile')  
for user in users:  
    print(user.profile.phone)

Now Django joins the tables together and retrieves everything at once.

So instead of:

1 query for users
Multiple queries for profiles

You now get:

1 optimized query

Much faster and cleaner.

Understanding `prefetch_related()`

Another optimization is:

prefetch_related()

This is used mostly for:

ManyToMany relationships
Reverse ForeignKey relationships

Unlike select_related(), this does not use SQL JOINs directly. Instead, Django performs separate queries but combines the results efficiently in memory.

For example:

users = User.objects.prefetch_related('orders')

Django may run:

SELECT * FROM users;  
SELECT * FROM orders WHERE user_id IN (1,2,3,4...);

Instead of:

SELECT * FROM orders WHERE user_id = 1;  
SELECT * FROM orders WHERE user_id = 2;  
SELECT * FROM orders WHERE user_id = 3;

Which is far more efficient. So rather than hundreds of queries, you may only have two.

The Difference Between `select_related()` And `prefetch_related()`

`select_related()`

Uses SQL JOINs
Best for ForeignKey and OneToOne relationships
Retrieves related data in a single query

`prefetch_related()`

Uses multiple optimized queries
Combines data in Python memory
Best for ManyToMany and reverse relationships

Both solve the same problem differently.

The Result

After fixing the queries:

Response times dropped massively
Database load reduced
API became stable again
Retrieval speed improved significantly

The funny thing is that we didnt upgrade the server. We didnt increase RAM. We didnt change infrastructure. We simply reduced unnecessary queries.

What This Experience Taught Me

One thing this experience taught me is that backend performance is not always about server power. Sometimes your database is suffering simply because of how you are querying it. A badly written retrieval pattern can quietly destroy performance even when your infrastructure is good. Now whenever I build endpoints, I dont just ask “Does this work?” I also ask “How many queries is this generating behind the scenes?” Because sometimes the biggest backend problem is not the logic. Its the retrieval pattern hiding underneath it. Let me know what you think, thanks for reading, like, share, comment and follow for more.

How I Cut API Response Time from 2s to <100ms with Redis Caching

Ezeana Micheal — Fri, 22 May 2026 15:09:42 +0000

Early in my software development years, I had the opportunity to work with a company where I learned backend development. I worked on a system where I was responsible for building the APIs without senior guidance, just documentation, experimentation, and a lot of self-learning.

When learning to design DB models and RESTful APIs. That was it for me, connect everything and let it out via the get request, let it in via the post request, patch things up with the patch request, and delete via the delete request.

Basic crud operations, and I was fine with that, back then. Eventually, I decided to explore the site myself, and damn, it was slow.

Every interaction came with a noticeable delay. So I stopped assuming things were fine and tested the APIs properly. Using Postman, I measured response times. Most endpoints were taking over 5 seconds.

The Problem

Every request was hitting the database directly, even when requesting the same data repeatedly.

The system wasn’t slow because the database was bad.

It was slow because it was doing the same work over and over again.

What Changed?

I did some research, investigations, and found something powerful. Caching, and utilizing redis for it.

What is Caching?

Caching stores frequently accessed data in memory (Redis uses RAM), allowing much faster retrieval compared to querying a database repeatedly. It reduces database load, instead of hitting the database every time it hits the cache instead and returns the result.

Types of Caching (and Why Redis Fits Here)

Not all caching works the same way. In my case, I implemented application-level caching with Redis, but it helps to understand where it sits in the bigger picture.

1. Application-Level Caching

This is what I used. The application stores frequently accessed data in a fast in-memory store like Redis.

Instead of always asking the database:

API → Database → Response

We first check:

API → Redis → Database (only if needed)

This is the most common approach in backend systems because it gives full control over what gets cached and when it gets updated.

2. Database Caching

Some databases internally cache query results or use external layers to store repeated query outputs.

This reduces repeated expensive queries, but it is less flexible compared to Redis-based caching where you control the logic directly inside your API.

3. Distributed Caching

This is when caching is shared across multiple servers using systems like Redis Cluster or Memcached.

It becomes important when your application is no longer running on a single server, but across multiple services or microservices.

Therefore,

Before:

Client → API → DB (every request)

After:

Client → API → Redis → DB (only on cache miss)

Instead of querying the database every time, the API now checks Redis first. If the data exists, it returns immediately. If not, it fetches from the database, stores the result in Redis, and returns it.

Here was my initial API response time without caching,

Here was my API response time afterwards.

I implemented 2 main strategies.

Key-value Caching.
Cache invalidation via Write.

In my API I implemented key value caching for every get request i.e (get /books/ and get /books/:id)

Eliminating First-Request Slowness (Cache Warm-Up)

One downside of caching is the initial delay when the cache is empty.

How did I solve that? a script.

I added a cache warm-up script that runs on deployment and preloads frequently accessed data into Redis. That way, the system starts “warm,” and users don’t experience the initial latency.

At that point, the only time the system feels slow is immediately after cache invalidation.

But having a cache isn't all good if not invalidated well, because write data comes in too, through post , patch, put. So a cache invalidation strategy was needed.

I chose cache invalidation via Write for 2 reasons:

Data will be refreshed once a put, patch, post or delete request comes in, and
Data is not often changed regularly, the data stays for a while because of the type of application we’re dealing with so giving it a time to live and time to die feels too much.

Trade-offs

Every system has tradeoffs as there is no perfect system. The following were the tradeoffs of my decision.

First request after invalidation is slower
Cache keys must be managed carefully
Slight increase in system complexity

But the system is now significantly faster and more efficient.

PS: There are several optimization techniques in backend development, this article is just about caching.

Thanks for reading, what do you think about the approach? Read, like and comment.

The Bilingual Developer: Python and Go Variables

Ezeana Micheal — Fri, 22 May 2026 14:59:35 +0000

At the heart of programming is a simple idea:

Input -> Processing -> Output

But between input and processing lies something more important, storage.

Before a computer can do anything useful with data, it must first store it somewhere. That “somewhere” is memory. And in programming, the way we interact with memory starts with one core concept:

Variables

Programming is just a way of communicating with a computer, telling it what to store, how to transform it, and what to return.

In this article, we’ll explore how two very different languages, Python and Go, handle the same idea: variables.

Variables: The First Mental Model

A variable is simply a named storage location in memory.

For example (What it does is):

“store the number 10”
“label it as x”
“retrieve it later when needed”

Simple concept, but different languages implement it very differently.

And that’s where Python and Go start to diverge.

Python vs Go: Two Different Philosophies

Python and Go both allow you to store data in variables, but they were designed with different priorities:

Python: flexibility and speed of writing code
Go: structure, safety, and predictability

This difference shows up immediately in how variables are declared.

Dynamic vs Static Typing

Python (Dynamic Typing)

In Python, you don’t explicitly declare the type of a variable:

x=10

Python automatically figures out the datatype at runtime.

This is called dynamic typing.

It gives you flexibility:

You can reuse variables freely
You don’t need to define types upfront
It speeds up development

But the trade-off is that errors may only show up when the program runs.

Go (Static Typing)

In Go, you must define the type explicitly:

var x int = 10

Once declared, the type cannot change.

So this is invalid:

x = "hello" // error

This is called static typing.

It forces structure:

Types are known before execution
Errors are caught early (at compile time)
Code is more predictable in large systems

Two Ways of Declaring Variables

Python keeps it simple:

x = 10

That’s it. One way, one rule.

Go gives you two main approaches:

Explicit Declaration

var x int = 10

### Short Declaration (Walrus-style feel)

x := 10

The := operator tells Go:

“Infer the type automatically, but still lock it in permanently.”

So Go gives you convenience — but never sacrifices structure.

The Concept of “Nothing”

Another major difference is how both languages handle empty or uninitialized values.

Python: `None`

In Python, “no value” is represented explicitly:

x = None

This means:

“This variable exists, but it currently holds nothing.”

It is very explicit and readable.

Go: Zero Values

Go does something different.

If you declare a variable but don’t assign a value, Go automatically gives it a default:

var x int
fmt.Println(x) // 0

So instead of null or None, Go uses zero values:

int → 0
string → ""
bool → false

This design avoids uninitialized variables entirely.

While python thinks: “Let me give you freedom and decide later.” Go thinks: “Let me force clarity so you don’t make mistakes later.”

Even something as simple as variables reveals deep design philosophies:

Python prioritizes developer speed and flexibility
Go prioritizes safety and predictability

Both are correct, just optimized for different worlds:

Python → scripting, AI, automation, rapid development
Go → backend systems, scalability, performance-critical services.

Thanks for reading, what do you think about this? Read, like and comment.