Right, let’s talk about the one goroutine you’ve been using all along without even knowing it: the main goroutine. It’s the VIP of your program, the first one on the scene, and frankly, a bit of a diva. When it decides to leave the party, the whole club shuts down immediately, regardless of how many other goroutines are still dancing on the tables.

Think of your main() function as less of a function and more as a concert stage. When the program starts, the runtime sets up the stage and the main goroutine, our headliner, walks out and starts performing the code you wrote. This is its one and only job. It doesn’t get a special backstage pass or a different type of scheduler—it’s a goroutine like any other, just the first one.

The Diva Exits: What Happens to Everyone Else?

Here’s the crucial, and often painful, part to understand: when the main goroutine returns, the entire program terminates. No questions asked. No waiting for others to finish. It’s the equivalent of cutting the power to the entire building.

Let’s watch this tragedy unfold. You’ll write this code, run it, and probably see no output. It’s the most common “my goroutines aren’t working” faceplant.

package main

import (
    "fmt"
    "time"
)

func sayHello() {
    time.Sleep(100 * time.Millisecond) // Simulating some work
    fmt.Println("Hello from the other side!")
}

func main() {
    go sayHello() // Fire off the goroutine
    fmt.Println("Main function is done. Goodbye!")
}

Run this. Nine times out of ten, you’ll only see "Main function is done. Goodbye!". Our poor sayHello goroutine is scheduled to run, it takes a mere 100 milliseconds to get its act together, but the main goroutine is already out the door. The OS process ends, and sayHello is unceremoniously executed mid-sentence. The scheduler doesn’t even get a chance to run it.

This is the first and most important lesson of goroutines: the main goroutine is the anchor of your program. Your job is to keep it alive until all its spawned work is complete.

How to Keep the Party Going: sync.WaitGroup

So how do we stop our diva from leaving early? We need a backstage manager—a way for the main goroutine to know how many performers are still working and to wait for them to finish. The standard library gives us the perfect tool for this: sync.WaitGroup. It’s a simple counter that blocks until it hits zero.

Let’s use it correctly.

package main

import (
    "fmt"
    "sync"
    "time"
)

func sayHello(wg *sync.WaitGroup) {
    defer wg.Done() // Signal that this goroutine is done, no matter how it exits.
    time.Sleep(100 * time.Millisecond)
    fmt.Println("Hello from the other side!")
}

func main() {
    var wg sync.WaitGroup

    wg.Add(1) // Tell the WaitGroup: "Wait for one more thing"
    go sayHello(&wg) // Pass a pointer, or you'll be dealing with a copy (yikes).

    fmt.Println("Main is waiting...")
    wg.Wait() // Block here until the WaitGroup counter is zero.
    fmt.Println("Main function is done. Now it's okay to say goodbye!")
}

Now run this version. You’ll see the beautiful sequence:

  1. "Main is waiting..."
  2. "Hello from the other side!"
  3. "Main function is done. Now it's okay to say goodbye!"

Perfect. The main goroutine now politely waits at wg.Wait() like a responsible adult until our sayHello goroutine calls wg.Done(), decrementing the counter and unblocking the main flow.

A Subtle But Important Pitfall: The Pointer Pass

Did you notice we passed &wg to the function? This is critical. A sync.WaitGroup should never be copied after first use. If you pass it by value (wg instead of &wg), you’re making a copy. The Done() call would decrement the counter on the copy, not the original one the main goroutine is waiting on. The main goroutine would wait forever, and you’d have a deadlock. The program would just hang, silently mocking you. Always pass WaitGroups by pointer.

Beyond Waiting: Other Reasons for Termination

WaitGroups are your primary tool, but they’re not the only way the main goroutine can bail. Calling os.Exit() is the ultimate power move. It doesn’t care about defer statements, it doesn’t care about other goroutines. It terminates the program immediately with the exit code you provide. It’s the equivalent of pulling the fire alarm.

func main() {
    go func() {
        time.Sleep(time.Second)
        fmt.Println("This will never, ever print.")
    }()
    os.Exit(42) // The program stops. Right. Now.
}

Use os.Exit() sparingly, usually only in command-line tools where you need to communicate a specific success or failure code to the shell. For almost everything else, returning from main() and using proper synchronization with WaitGroups is the cleaner, safer approach.

The takeaway is simple but non-negotiable: concurrency in Go is a team sport, and the main goroutine is the team captain. Its responsibility isn’t to do all the work, but to coordinate it and ensure everyone finishes their job before it calls it a day. Manage its lifecycle carefully, and your concurrent programs will behave predictably. Let it be a diva, and you’ll be left with a lot of silent, unfinished work.