You are polluting Your Standard Output ( stdout ) in Go

sdh0x — Thu, 09 Jul 2026 15:34:34 +0000

Using fmt.Println for error handling isnt a practical way, especially in linux or unix based systems.

because if you're using bash or zsh or any other shell, there will be 3 types of file descriptors, stdout, stderr, and stdin (which are low level integer table numbers that the kernel assign them for each communication channel )
when logging erros with fmt.Println you're polluting your Standard output data stream ( stdout ( 1 ) ) which might be used for CLI driven utility or similar, and using print() or println() isnt ideal for production grade, because both of them redirect every output to stderr amd both are almost temporary built in functions for fast debugging/bootstrapping that might get removed

Here is the show case :

package main
import "fmt"

func main() {
    println("Directed to stderr")
    fmt.Println("Directed to stdout")
}

When compiling and running as an executable :

[lost learning]$ ./main # Default case
Directed to stderr
Directed to stdout

[lost learning]$ ./main 2>/dev/null # Redirecting the Standard Error to null
Directed to stdout

[lost learning]$ ./main 1>/dev/null # Redirecting the Standard Output to null
Directed to stderr

[lost learning]$ ./main > output # Redirection operator ">" takes only the stdout
Directed to stderr
[lost learning]$ cat output
Directed to stdout

[lost learning]$ ./main 2>&1 | tee output2 # We can merge a stream to another stream 
[lost learning]$ cat output2
Directed to stderr
Directed to stdout
[lost learning]$

Better approach using fmt.Fprintln() and lib os for writing string into stdout or stderr or even stdin, without relying on built in debug functions :

package main

import (
    "fmt"
    "os"
)

func main() {
    fmt.Fprintln(os.Stderr, "Directed to stderr")
    fmt.Fprintln(os.Stdout, "Directed to stdout")
}

Output :

[lost learning]$ ./main # Default
Directed to stderr
Directed to stdout

[lost learning]$ ./main > output
[lost learning]$ cat output # Clean output
Directed to stdout

[lost learning]$ ./main > output 2>&1 # Merge stream 2 to 1
[lost learning]$ cat output
Directed to stderr
Directed to stdout

And i have to mention that there is a better way for debugging and error handling that its pretty recomended especially if you're building a production grade backend, by using libs like log, slog, errors, Errorf ...
so this writeup is only if you don't want to not external libs .

Why using strconv instead of fmt for converting typical data types to string

sdh0x — Sun, 28 Jun 2026 11:54:51 +0000

Why using strconv instead of fmt for converting typical data types to string

alot of us use fmt.Sprint to convert basic data types to string, but it causes performance degradation especially if you are building a CLI utility

fmt.Sprint Causes Heap Escapes

here is a code sample from go tour (i did make changes to it) that checks if X is lower than 0 , if true it formates it as a complex number formula (x + yi)
then x goes to math.Sqrt() function to square root

package main

import (
    "fmt"
    "math"
)

func main() {
    var x float64 = -5 
    var str string  
    if x < 0 {
        str = fmt.Sprint(math.Sqrt(-x)) + "i"
        fmt.Println(str)
    } else {
        fmt.Println(math.Sqrt(x))
    }
}

we need then to convert the float64 to string to show case why you should use strconv* instead of fmt, we used fmt.Sprint, used for converting basic data types to string, this is why we called fmt twice, one for converting and one for printing the output

If we compile with the flag '-m' for the golang compiler which stands for escape analysis to instruct the compiler to print out its optimization decisions, what escaped to the heap and what stayed in the stack frame of the function

we can see that the variable str escaped to the heap besides that all in stack frame of the main function

[lost main]$ go build -gcflags='-m' main.go
# command-line-arguments
./main.go:12:29: inlining call to math.Sqrt
./main.go:13:14: inlining call to fmt.Println
./main.go:15:24: inlining call to math.Sqrt
./main.go:15:14: inlining call to fmt.Println
./main.go:12:35: fmt.Sprint(... argument...) + "i" escapes to heap
./main.go:12:19: ... argument does not escape
./main.go:12:29: ~r0 escapes to heap
./main.go:13:14: ... argument does not escape
./main.go:13:15: str escapes to heap
./main.go:15:14: ... argument does not escape
./main.go:15:24: ~r0 escapes to heap

str did escape to the heap, we dont need that, heap causes overload.

Using strconv

strconv is the best alternative solution combined with a built in function for printing text to the terminal println(str)

package main

import (
    "math"
    "strconv"
)

func main() {
    var x float64 = -5
    var str string
    if x < 0 {
        str = strconv.FormatFloat(math.Sqrt(-x), 'f', -1, 64) + "i" // 'f' stands for no exponent, take a look at strconv doc in pkg.go.dev/strconv
        println(str)
    } else {
        println(strconv.FormatFloat(math.Sqrt(x), 'f', -1, 64))
    }

}

if we compile with the same flag for showing the compiler optimizing decisions

[lost main]$ go build -gcflags='-m' main.go
# command-line-arguments
./main.go:12:38: inlining call to math.Sqrt
./main.go:12:28: inlining call to strconv.FormatFloat
./main.go:15:20: inlining call to math.Sqrt
./main.go:12:28: inlining call to strconv.FormatFloat
./main.go:12:57: ~r0 + "i" does not escape
./main.go:12:28: string(strconv.genericFtoa(make([]byte, 0, max(strconv.prec + 4, 24)), strconv.f, strconv.fmt, strconv.prec, strconv.bitSize)) does not escape
./main.go:12:28: make([]byte, 0, max(strconv.prec + 4, 24)) does not escape

as you can see, there is no "Escaped to the heap" there is only does not escape

why is that ?

fmt.Sprint takes an empty interface{} which has two-pointer structure (eface): one pointer to the dynamic type information, and one pointer to the actual data, when you pass a concrete type (float64) into fmt.Sprint go wraps it into this interface structure.

Devirtualization : this is an optimization method where the compiler attempt to look through the interface, determine the type then call the method directly.

Failure to Devirtualize : because fmt passes your variable down a deeply nested chain of internal functions that rely on reflection, the escape analysis algorithm completely loses visibility. ( Escape analyses is an optimization method where the compiler chooses what stays in the stack and what escapes to the heap ) it cant trace the pointers lifecycle across these interface boundaries

As Safety Net the compiler cannot prove that a variable will not outlive the stack frame of the function so it cannot safely leave it on the stack, as a strict memory safety-net decision by the compiler, the variable escapes to the heap.

DEV Community: sdh0x

You are polluting Your Standard Output ( stdout ) in Go

Why using strconv instead of fmt for converting typical data types to string

Why using strconv instead of fmt for converting typical data types to string

fmt.Sprint Causes Heap Escapes

Using strconv

why is that ?