Leaving a channel open in Go: is it possible or not? Breakdown for beginners

Introduction: a question that plagues almost every Go beginner

Imagine: you're writing your first serious program in Go. You've figured out goroutines, mastered channels, and even written a couple of working examples. But suddenly you come across a question on Stack Overflow that has gathered thousands of views: "Is it OK to leave a channel open?"

Spoiler: the answer is not as clear-cut as you might hope. Some people shout that an unclosed channel is a mortal sin and a resource leak. Others say that the garbage collector in Go will clean everything up. Where is the truth? Let's figure it out with real examples, without fluff or academic lectures.

For those just getting acquainted with the language — Go (or Golang) offers an elegant synchronization mechanism through channels. But like any powerful tool, channels require careful handling. Especially when it comes to closing them.

Why did this question even arise? The root of the problem

In Go, there's a saying: "Don't close a channel from the receiver side — close it from the sender side." But what to do if the program terminates and the channel remains open? Goroutine leak is the main fear. When a goroutine "hangs" waiting for data from a channel that no one will ever close, it never completes. And uncompleted goroutines mean a memory leak and a broken production environment.

But let's be honest: in small scripts or test utilities, this is not scary. The garbage collector in Go is smart, but it doesn't clean up goroutines — only the memory they occupy. So the question "to close or not to close" comes down to your application's architecture.

Example 1: when NOT closing a channel is fine

Consider a simple scenario: a program reads data, processes it, and terminates. If the channel is used only inside main, and you know for sure that all goroutines will complete — you can avoid closing it.

package main

import "fmt"

func main() {    ch := make(chan int)

    // Sender goroutine    go func() {        for i := 0; i < 5; i++ {            ch <- i        }        // Channel is NOT closed    }()

    // Receiver    for i := 0; i < 5; i++ {        fmt.Println(<-ch)    }    // The program will terminate without errors    fmt.Println("Done, the channel remained open, but it's all good")}

Why does this work? Because main terminates, and all goroutines are destroyed along with the process. The Go garbage collector will clean up the memory. There is no goroutine leak — the program simply ended.

Conclusion: if your program is a script that runs and dies, leaving a channel open is perfectly normal. It won't lead to a leak if you control the lifecycle.

Example 2: when an unclosed channel is a disaster

Now imagine a server that runs 24/7. You have a goroutine that listens to a channel indefinitely:

package main

import (    "fmt"    "time")

func worker(ch chan int) {    // Infinite reading    for val := range ch {        fmt.Println("Processed:", val)    }    // We will never reach here if the channel is not closed    fmt.Println("Goroutine finished")}

func main() {    ch := make(chan int)    go worker(ch)

    // Send data    ch <- 1    ch <- 2    ch <- 3

    // Forget to close the channel    // close(ch)

    time.Sleep(2 * time.Second)    fmt.Println("Program is terminating, but worker is still hanging!")}

What will happen? The worker goroutine will remain hanging in an infinite loop, waiting for new data. It will never complete. Goroutine leak is obvious. Over time, tens of thousands of such goroutines will accumulate, and the server will crash with a memory error.

In this case, closing the channel is mandatory. It is close(ch) that gives the signal to the go