When Go Meets Forth: From Error Handling to Stack Thinking

What happens when modern language design collides with the minimalist beauty of a forgotten classic.

Photo by Radowan Nakif Rehan on Unsplash

Why Go takes a different path

If you haven’t read my previous successful post on Go, I’d highly recommend starting there before diving deeper into this one.

[embed]Go: The Language That Powers the Cloud (and Maybe the Future of AI) (A deep dive into why Go feels so different — and why that matters.)blog.stackademic.com

Not a Medium member? You can read this story for free here ↗.

Today we dive into one of the most misunderstood parts of Go:

error handling — and how it connects to Go’s take on object-oriented programming (OOP).

Go does not use traditional try-catch exception handling.

Instead, it draws a sharp line between recoverable and unrecoverable errors.

Recoverable ones (like a missing file) are returned as explicit return values, forcing you to acknowledge them — no surprises, no hidden control flow.

err := ioutil.WriteFile(src.Name(), []byte("hello"), 0644)
if err != nil {
    log.Error(err)
}

At first glance, this may look tedious — but it’s Go’s way of saying:

“Be explicit. Don’t hide what can fail.”

The elegance of defer, panic, and recover

Go adds a subtle layer of structure with defer, allowing you to clean up just before a function exits — even when something goes wrong.

f, err := os.Open("myfile.txt")
if err != nil {
    return err
}
defer f.Close() // runs on exit, even after a panic
// read, write ...

When things truly go off the rails — array index out of range, nil pointer dereference — Go throws a panic.

You can still catch it gracefully with recover() inside a deferred function, but Go encourages you to treat such cases as fatal bugs, not business logic.

Exceptions vs. explicit errors — a quiet debate

Every language community has fought this battle.

Exceptions are powerful but unpredictable.

They can fly through the call stack unseen, break control flow, and make it unclear where errors are truly handled.

image by author

Go took the opposite road:

*make error handling explicit.*

It’s not always pretty, but it’s transparent — and transparency is often underrated in system programming.

Go and OOP: The minimalist interpretation

Go is not a classical object-oriented language, but it embraces OOP principles through composition and interfaces.

There are no classes — instead, there are structs, and methods bound to them.

type User struct {
    Name string
}

// Method bound to User
func (u User) Greet() string {
    return "Hello, " + u.Name
}

Encapsulation happens through naming:

• Capitalized identifiers are exported (public).
• Lowercase ones are private to the package.

Composition instead of inheritance

Instead of traditional inheritance, Go uses embedding — you compose behavior rather than inherit it.

type Person struct {
    Name string
}

type Employee struct {
    Person
    Role string
}

This “composition over inheritance” keeps Go flexible and avoids deep class hierarchies.

It’s inheritance without the baggage — or as Rob Pike once said,

“Go prefers simple building blocks over complex frameworks.”

Interfaces and polymorphism — Go’s quiet magic

Polymorphism in Go doesn’t require explicit declarations.

If a type implements all methods of an interface, it automatically satisfies that interface.

type Speaker interface {
    Speak() string
}

type Dog struct{}

func (d Dog) Speak() string {
    return "Woof!"
}

func MakeItSpeak(s Speaker) {
    fmt.Println(s.Speak())
}

MakeItSpeak(Dog{}) // "Woof!"

No “implements” keyword.

No boilerplate.

Just behavior.

The hidden dynamism: any

Go’s any type (alias for interface{}) accepts everything — it’s a form of controlled dynamism.

Used sparingly, it lets you write generic utilities without losing type safety.

A detour through language history

Programming languages evolve like ecosystems — each adapting to different constraints.

Some species fade into niches, but their DNA lives on.

One of these is Forth — a language so minimal that it feels alien at first glance, yet profoundly influential.

Forth: The language that runs on a stack and a dream

Forth doesn’t just execute code — it builds it.

It’s a stack-based language using Reverse Polish Notation (RPN):

3 4 +   →  pushes 3, pushes 4, adds → result: 7

No parentheses.

No syntactic sugar.

Just raw operations on a stack.

Key concepts:

• Minimalism: No fixed keywords. The entire language is built from words — defined in a dictionary.
• Stack machine: Operands go on a stack; operations pop and push results.
• Extensibility: You can literally define new language constructs on the fly.
• No types, no syntax rules: You’re responsible — but also completely free.

Forth’s simplicity made it ideal for embedded systems and bootloaders.

It can even serve as a tiny operating system — its interpreter is that compact.

Why does Forth still matter?

Because it reminds us of something essential:

Programming doesn’t have to be complicated to be powerful.

Forth embodies the idea of trusting the programmer — a concept Go also embraces, though in a much safer and structured way.

Both share a mindset:

• Don’t hide what’s going on.
• Keep the language small.
• Let developers compose behavior rather than inherit it.

Bonus thought: From Forth to Go — simplicity scales

If Go is like building with Lego bricks,

then Forth is carving your own blocks out of raw wood.

Both reward clarity and precision — just at different layers of abstraction.

Next up: we’ll take a closer look at functional programming with Go.

Closing Thoughts

Go’s approach to error handling and object orientation teaches a subtle but powerful lesson: clarity often beats cleverness.

Instead of hiding behind exceptions or deep inheritance trees, Go forces us to face our errors, return them explicitly, and build our logic on solid ground.

It’s not as glamorous as a try–catch block or a class hierarchy — but it’s transparent, predictable, and beautifully simple.

And then there’s Forth, quietly reminding us where so many of our modern ideas came from.

Minimalist, raw, stack-based — it’s a living fossil of computing, yet strangely modern in its spirit. Understanding it is like looking into the DNA of programming itself.

A Note from Me

I’m currently exploring the philosophy behind programming languages — how design choices shape not just code, but how we think as developers.

If you’ve ever caught yourself wondering why a language was built the way it is, or what lessons old systems still hold today — you’re in good company.

Follow along — there’s a lot more to uncover.

— Dustin

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, **Instagram. You can also subscribe to our [weekly newsletter](https://newsletter.plainenglish.io/)**.

And before you go, don’t forget to clap and follow the writer️!