DEV Community: Dixon Osure

Discovering JavaScript Functions Through the Lens of Go

Dixon Osure — Wed, 13 May 2026 23:30:55 +0000

I recently started learning JavaScript, and I didn't come in blind. I had Go in my head — how it structures things, what it cares about, what it refuses to let you do. And honestly, that made learning JS a strange experience. Not hard, just... revealing.

Every time JS did something different from Go, I found myself asking why. Why does it work that way? What problem is JS solving that Go solves differently? I started learning two things at once — JavaScript, and a deeper appreciation of choices Go made that I'd taken for granted.

This is that journey, through functions.

Go Wants to Know Everything Upfront. JS Doesn't.

The very first thing I noticed: Go demands you declare your types. Every parameter, every return value — the compiler needs to know.

func greet(name string) string {
    return "Hello, " + name
}

JavaScript has no such requirement:

function greet(name) {
  return "Hello, " + name;
}

At first I kept thinking — but what type is name? What if someone passes a number? And the answer is: JavaScript doesn't stop them. It'll just run, coerce the value, and do its best. greet(42) gives you "Hello, 42" without complaint.

This isn't sloppiness — it's a deliberate tradeoff. JS was built to be flexible and forgiving, especially in a browser environment where you don't control the input. Go was built for systems where you really need to know what's going into each function. Two different problems, two different philosophies.

The practical consequence: JavaScript errors tend to show up at runtime, not compile time. You lose the safety net Go's compiler gives you, but you gain a kind of freedom to move fast and figure things out as you go.

JS Solves the "Sensible Default" Problem Natively

In Go, there's no such thing as a default parameter value. If you want a fallback, you handle it yourself:

func greet(name string) string {
    if name == "" {
        name = "stranger"
    }
    return "Hello, " + name
}

The first time I saw JavaScript's version of this, I genuinely paused:

function greet(name = "stranger") {
  return "Hello, " + name;
}

greet();         // "Hello, stranger"
greet("Alice");  // "Hello, Alice"

The default lives right in the signature. It's part of the function's contract — readable, visible, impossible to miss.

What I found interesting is that Go's approach isn't just a missing feature — it reflects a philosophy. Go wants function signatures to be unambiguous. A function either gets a value or it doesn't; you deal with it explicitly. JavaScript's approach says: let the function itself handle graceful fallbacks so the caller doesn't have to think about it.

Neither is wrong. They're just solving the same problem with different priorities.

How Each Language Handles Errors — This One Really Made Me Think

This was the biggest conceptual shift for me, and it changed how I understood both languages.

In Go, errors are just values. A function that can fail returns two things — the result and an error — and you check both:

func divide(a, b float64) (float64, error) {
    if b == 0 {
        return 0, fmt.Errorf("cannot divide by zero")
    }
    return a / b, nil
}

result, err := divide(10, 2)
if err != nil {
    log.Fatal(err)
}

Every function call that can fail makes that failure visible and forces you to deal with it on the spot. You can't accidentally ignore an error.

JavaScript takes a completely different approach — errors are thrown and caught:

function divide(a, b) {
  if (b === 0) throw new Error("Cannot divide by zero");
  return a / b;
}

try {
  const result = divide(10, 0);
} catch (err) {
  console.error(err.message);
}

What struck me is how this changes the shape of the code. In Go, error handling is part of the normal flow. In JavaScript, the structure is separated into try and catch blocks. The function itself returns just one thing; errors travel on a different channel entirely.

The risk with JavaScript's model is that it's easy to forget the try/catch. An unhandled thrown error can bubble all the way up and crash your program in a place far removed from where the problem happened. Go makes that much harder to do by accident.

But I came to see the beauty in JavaScript's model too — especially for deeply nested async code, where passing errors as return values would get messy fast. Exceptions let errors escape cleanly without having to be explicitly threaded through every layer.

Functions as Values — JS Leans Into This Much Harder Than Go

Both Go and JavaScript treat functions as first-class values. You can assign them to variables, pass them around, return them from other functions. I knew this from Go:

double := func(n int) int {
    return n * 2
}

But JavaScript doesn't just allow this — the whole language is built around it. Arrays have built-in methods that take functions as arguments:

const nums = [1, 2, 3, 4, 5];

nums.map(n => n * 2);          // [2, 4, 6, 8, 10]
nums.filter(n => n % 2 === 0); // [2, 4]
nums.reduce((sum, n) => sum + n, 0); // 15

Coming from Go, this was eye-opening. Go has no built-in map or filter — you write loops. JavaScript treats these as fundamental operations on collections, built right into the language.

And those little n => n * 2 things? Those are arrow functions — JavaScript's shorthand for inline functions. You'll see them everywhere:

// These all do the same thing:
function double(n) { return n * 2; }
const double = function(n) { return n * 2; };
const double = (n) => n * 2;
const double = n => n * 2; // parentheses optional for single param

Go has anonymous function literals, but JavaScript went further — arrow functions exist partly for brevity, and partly to solve a specific problem with how this works (more on that below).

Closures Are the Same Idea, But JS Uses Them More Aggressively

Closures — functions that remember the environment they were created in — work the same way in both languages:

func makeCounter() func() int {
    count := 0
    return func() int {
        count++
        return count
    }
}

function makeCounter() {
  let count = 0;
  return () => ++count;
}

const counter = makeCounter();
counter(); // 1
counter(); // 2

Identical concept. But JavaScript leans on closures much more heavily than Go does — partly because JS doesn't have Go's explicit struct-based encapsulation, so closures often are the encapsulation. Private state in JavaScript is frequently just a variable in a closure that nobody outside can touch.

One thing I learned the hard way: JavaScript also has var (older style), and var does not behave like := in Go. var ignores block scope — a loop variable declared with var is the same variable across all iterations of the loop, which causes bizarre closure bugs. Always use let or const. Treat var like it doesn't exist.

The `this` Problem — Nothing Like It in Go

In Go, methods have explicit receivers. You always know exactly what a method is operating on:

func (c Circle) Area() float64 {
    return math.Pi * c.Radius * c.Radius
}

JavaScript uses this instead:

class Circle {
  constructor(radius) { this.radius = radius; }
  area() { return Math.PI * this.radius ** 2; }
}

That works fine when you call c.area() directly. But JavaScript's this is dynamic — it changes depending on how the function is called, not where it was defined. The moment you pass a method as a callback, this can become something unexpected:

const c = new Circle(5);

// This breaks — `this` is no longer the circle inside the callback
setTimeout(c.area, 1000);

// This works — arrow function captures `this` from the surrounding scope
setTimeout(() => c.area(), 1000);

This was the most genuinely confusing thing I encountered coming from Go. In Go, the receiver is explicit and never changes. In JavaScript, this shifts depending on call context, and you have to know the rules to avoid getting burned.

Arrow functions were invented partly to solve this — they don't have their own this, they inherit it from wherever they were created. That's why you'll see arrow functions used as callbacks so often in JavaScript codebases.

What Go Taught Me About JavaScript

Going through all this, something clicked for me: Go and JavaScript aren't just different syntax for the same ideas. They reflect genuinely different beliefs about what a programming language should optimize for.

Go optimizes for clarity and correctness — types, explicit errors, predictable receivers. JavaScript optimizes for flexibility and expressiveness — dynamic types, exceptions that escape cleanly, this that adapts to context, functions that compose in powerful ways.

Neither got it wrong. They made different bets.

Knowing Go made me a more thoughtful JavaScript learner, because I kept asking why instead of just accepting the syntax. And every time I found an answer, I understood both languages a little better.

Resources:

MDN – Functions
javascript.info — the best free JS learning resource I've found
MDN – Arrow Functions
You Don't Know JS — for when you want to go deep on how JS actually works Good luck. JS is a rabbit hole, but it's a fascinating one. 🙂

Mastering Go Testing: From Basics to Subtests in 3 Minutes

Dixon Osure — Wed, 11 Feb 2026 20:54:43 +0000

Testing in Go is a breath of fresh air. There is no need to learn complicated frameworks or configure assertion libraries. The standard library is all you need.

In this 3-minute guide, we'll help you upgrade your testing skills from "hello world" to professional grade table-driven tests.

Level 1: The Basic Test
In Go, tests live in files ending with _test.go. A test is just a function that starts with Test and takes a *testing.T.
Here is a simple test for an Add function:

func TestAdd(t *testing.T) {
    result := Add(2, 3)
    expected := 5

    if result != expected {
        t.Errorf("Add(2, 3) = %d; want %d", result, expected)
    }
}

We don't use assertions like assert.Equal. We just use if statements and t.Errorf to report failures. Simple!

Level 2: Table-Driven Tests
What if we want to test Add(0, 0), Add(-1, 1), and Add(100, 200)? Copy-pasting the test above is tedious and error-prone.
This is where Table-Driven Tests come in. This is the idiomatic way to write tests in Go. We define our test cases in a slice of structs (the "table"), then simply loop over them.

func TestAdd(t *testing.T) {
    tests := []struct {
        a, b     int
        expected int
    }{
        {2, 3, 5},
        {0, 0, 0},
        {-1, 1, 0},
    }

    for _, tt := range tests {
        result := Add(tt.a, tt.b)
        if result != tt.expected {
            t.Errorf("Add(%d, %d) = %d; want %d", tt.a, tt.b, result, tt.expected)
        }
    }
}

Now, adding a new test case is just adding one line to the slice. Clean, right?

Level 3: Subtests with t.Run
The table-driven approach is great, but what if one case fails? It can be difficult to identify which case failed out of a sea of log messages. What if we want to run just one particular case?

This is where Subtests come in. We'll use t.Run to define a separate test function for each case:
First, let's add a name field to our struct:

func TestAdd(t *testing.T) {
    tests := []struct {
        name     string // New!
        a, b     int
        expected int
    }{
        {"positive numbers", 2, 3, 5},
        {"zeros", 0, 0, 0},
        {"negative", -1, 1, 0},
    }

    for _, tt := range tests {
        // t.Run creates a subtest
        t.Run(tt.name, func(t *testing.T) {
            result := Add(tt.a, tt.b)
            if result != tt.expected {
                t.Errorf("got %d, want %d", result, tt.expected)
            }
        })
    }
}

Why is this better?

Better Output/Easier Debugging: The failed test has a clear name: TestAdd/positive_numbers
Granular Control: You can run individual subtests from the command line.

go test -run TestAdd/zeros

Parallelism: And you can even run subtests in parallel with t.Parallel() inside a loop!

Summary
We started with a simple function and ended up with a scalable, professional testing pattern with only a few lines of code.

Basics: Use t.Errorf to fail tests.
Table-Driven: Use []struct to organize data.
Subtests: Use t.Run for better reporting and control.

Happy testing!