🚀 Go Binary Bukan Sekadar Kode Anda: Membongkar Isi Sebenarnya dari Hasil Build Golang

Banyak developer berasumsi bahwa hasil build Go adalah pure binary dalam artian: hanya berisi kode yang mereka tulis, dikompilasi menjadi machine code, lalu selesai. Asumsi ini tidak sepenuhnya salah — Go memang menghasilkan native executable yang bisa langsung dijalankan tanpa runtime eksternal. Namun ada sesuatu yang sering tidak disadari: binary Go bukan hanya berisi kode aplikasi kamu. Di dalamnya terdapat runtime Go yang ikut ter-embed, membawa seluruh subsistem pendukung fitur bahasa. Memahami apa yang benar-benar ada di dalam binary Go penting agar kamu bisa membuat keputusan yang tepat soal ukuran, performa, dan strategi deployment.

Apa yang Dimaksud Pure Binary?

Istilah pure binary sering dimaknai sebagai executable yang tidak bergantung pada interpreter, VM, atau runtime eksternal — cukup salin file-nya ke server dan jalankan. Dalam definisi itu, Go memang memenuhi kriteria. Tapi ada perbedaan penting yang sering luput:

Tidak butuh runtime eksternal  ≠  Tidak memiliki runtime sama sekali

Go tidak membutuhkan runtime eksternal seperti JVM untuk Java atau Node.js untuk JavaScript. Tetapi Go tetap memiliki runtime internal yang di-link ke dalam binary saat proses build. Runtime ini bukan sesuatu yang opsional — ia adalah prasyarat agar fitur bahasa Go bisa bekerja.

flowchart TD
    A[Source Code .go] --> B[Go Compiler]
    B --> C[Kode Aplikasi]
    B --> D[Runtime Go]
    C --> E[Binary Executable]
    D --> E
    E --> F[Langsung dijalankan\ntanpa instalasi apapun]

Komponen Runtime yang Ter-embed

Runtime Go bukan VM. Ia adalah kumpulan subsistem yang memungkinkan fitur-fitur bahasa Go bekerja. Ketika kamu menjalankan go build, seluruh subsistem ini ikut dikompilasi ke dalam binary.

Garbage Collector

Go memiliki GC bawaan dengan model concurrent mark-and-sweep. Kode pengelolaan memori otomatis ini ikut ter-include sepenuhnya ke dalam binary — termasuk logika untuk menentukan kapan GC berjalan, bagaimana ia menjeda goroutine secara minimal, dan cara ia mengembalikan memori ke OS.

Goroutine Scheduler (M:N Scheduler)

Go menjalankan goroutine menggunakan model M:N, di mana sejumlah M goroutine dipetakan ke sejumlah N OS thread. Scheduler inilah yang mengatur pemetaan tersebut secara dinamis — memindahkan goroutine antar thread, menangani work stealing, dan memastikan goroutine yang diblokir tidak membuang thread OS secara sia-sia.

flowchart LR
    subgraph Goroutines
        G1[goroutine 1]
        G2[goroutine 2]
        G3[goroutine 3]
        G4[goroutine 4]
    end
    subgraph Scheduler["Runtime Scheduler (M:N)"]
        S[Queue & Dispatcher]
    end
    subgraph OS Threads
        T1[thread 1]
        T2[thread 2]
    end
    G1 --> S
    G2 --> S
    G3 --> S
    G4 --> S
    S --> T1
    S --> T2

Stack Management

Stack setiap goroutine dapat tumbuh dan menyusut secara dinamis. Goroutine baru dimulai dengan stack kecil (~2KB), lalu diperbesar secara otomatis saat dibutuhkan. Logika ekspansi dan kontraksi stack ini sepenuhnya dikelola oleh runtime.

Memory Allocator

Fungsi seperti make, new, pembuatan map, dan operasi slice semuanya menggunakan allocator yang berada di runtime — bukan allocator sistem operasi secara langsung. Go menggunakan allocator berlapis yang dioptimalkan untuk pola alokasi yang umum di program Go.

Channel dan Select

Operasi channel bukan fitur OS. Ia diimplementasikan seluruhnya oleh runtime, termasuk mekanisme sinkronisasi, antrian goroutine yang menunggu send/receive, dan implementasi select untuk multiplexing channel.

Panic, Recover, dan Stack Trace

Sistem penanganan error tingkat rendah Go — panic, recover, dan stack trace yang informatif — semuanya ditangani oleh runtime. Ketika panic terjadi, runtime yang mencetak stack trace lengkap ke stderr.

Interface Dispatch dan Reflection

Type assertion, interface dispatch, dan paket reflect membutuhkan metadata tipe yang disimpan di binary. Runtime menyediakan tabel tipe (itab) yang memungkinkan operasi-operasi ini berjalan secara efisien.

Melihat Isi Binary Secara Langsung

Kamu bisa memverifikasi keberadaan runtime di dalam binary menggunakan beberapa tool standar.

Mulai dengan program sederhana:

package main

import "fmt"

func main() {
    fmt.Println("Halo Dunia")
}

Build:

go build -o app main.go

Lalu jalankan nm untuk melihat daftar simbol:

nm app | grep runtime | head -20

Kamu akan melihat ratusan simbol dengan prefix runtime. — mulai dari runtime.goexit, runtime.mallocgc, hingga runtime.gcBgMarkWorker. Semua itu ada di dalam binary “Hello World” kamu.

Untuk melihat ukuran tiap section:

size app

Output-nya akan menunjukkan pembagian antara section text (kode), data (data statis), dan bss (data yang belum diinisialisasi). Section text akan jauh lebih besar dari kode aplikasi aktualmu karena berisi runtime.

Static vs Dynamic Linking

Secara default, tanpa CGO, Go melakukan static linking — seluruh dependency dikompilasi dan di-link langsung ke dalam satu binary.

# Cek apakah binary bersifat static
ldd ./app

Pada binary Go murni (tanpa CGO), output-nya adalah:

not a dynamic executable

Ini berarti binary benar-benar berdiri sendiri. Tidak perlu library sistem yang ter-install di mesin tujuan.

Sebaliknya, ketika menggunakan CGO (misalnya untuk mengakses library C), binary bisa memiliki dependency dinamis:

ldd ./app-with-cgo
# linux-vdso.so.1
# libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
# /lib64/ld-linux-x86-64.so.2

Binary seperti ini membutuhkan library tersebut ter-install di mesin tujuan. Untuk memaksa static build bahkan dengan CGO:

CGO_ENABLED=0 go build -o app main.go

Binary yang dibangun dengan CGO_ENABLED=0 tidak bisa menggunakan package yang bergantung pada library C seperti database/sql dengan driver native, atau package yang menggunakan syscall tingkat rendah. Selalu verifikasi kompatibilitas sebelum menonaktifkan CGO di production.

Mengapa Binary Go Lebih Besar dari C?

Perbandingan ukuran program Hello World sederhana:

Go berada di posisi tengah: tidak butuh runtime eksternal seperti Java, tapi binary-nya lebih besar dari C karena membawa runtime yang jauh lebih kaya fitur.

Penyebab utama ukuran binary Go yang lebih besar:

✗  Runtime GC dan scheduler ikut ter-bundle
✗  Symbol table untuk stack trace
✗  Debug information (DWARF) secara default
✗  Metadata tipe untuk reflection

Untuk mengecilkan ukuran binary di production:

# Hapus symbol table dan DWARF debug info
go build -ldflags="-s -w" -o app main.go

Hasilnya bisa mengurangi ukuran binary hingga 30–40%. Tapi perlu diingat: flag ini menghilangkan informasi debug, sehingga stack trace saat panic menjadi kurang informatif.

flowchart LR
    subgraph "Binary Go (default)"
        A1[Kode Aplikasi]
        A2[Runtime Go]
        A3[Symbol Table]
        A4[DWARF Debug Info]
    end
    subgraph "Binary Go (-s -w)"
        B1[Kode Aplikasi]
        B2[Runtime Go]
    end
    A1 --> |"go build -ldflags='-s -w'"| B1

Implikasi Arsitektural

Pemahaman tentang apa yang ada di dalam binary Go memiliki implikasi langsung pada cara kamu merancang dan men-deploy aplikasi.

Keuntungan

Distribusi binary Go sangat sederhana. Cukup salin satu file ke server target — tidak perlu menginstal runtime, mengatur environment, atau mengelola dependency sistem. Ini menjadikan Go sangat cocok untuk distribusi ke container minimal seperti scratch atau distroless:

# Multi-stage build untuk container minimal
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o app .

FROM scratch
COPY --from=builder /app/app /app
ENTRYPOINT ["/app"]

Container seperti ini bisa berukuran hanya beberapa MB — jauh lebih kecil dari container yang harus menyertakan runtime JVM atau Node.js.

Cross-compilation juga sangat mudah karena runtime sudah ter-embed:

# Build untuk Linux dari macOS
GOOS=linux GOARCH=amd64 go build -o app-linux main.go

# Build untuk Windows dari Linux
GOOS=windows GOARCH=amd64 go build -o app.exe main.go

Konsekuensi yang Perlu Diperhatikan

Runtime yang ter-embed membawa overhead tertentu. GC membutuhkan memori tambahan untuk struktur internalnya. Scheduler membutuhkan overhead CPU untuk mengelola goroutine. Startup time sedikit lebih lama dibanding program C murni karena runtime harus diinisialisasi terlebih dahulu sebelum main() dipanggil.

Untuk aplikasi serverless atau Function-as-a-Service di mana cold start adalah concern utama, overhead startup runtime Go ini bisa menjadi pertimbangan. Binary yang dikompilasi dengan CGO_ENABLED=0 dan flag -ldflags="-s -w" umumnya memiliki startup yang lebih cepat karena binary lebih kecil dan OS memuat-nya lebih cepat ke memori.

Checklist Sebelum Deploy Binary Go

BUILD:
  □ Gunakan CGO_ENABLED=0 jika tidak butuh library C
  □ Tambahkan -ldflags="-s -w" untuk production build
  □ Verifikasi target GOOS dan GOARCH sudah benar
  □ Jalankan ldd untuk memastikan status static/dynamic sesuai ekspektasi

CONTAINER:
  □ Gunakan multi-stage build untuk memisahkan build dan runtime image
  □ Pertimbangkan scratch atau distroless sebagai base image
  □ Verifikasi binary berjalan di dalam container sebelum push

DEBUGGING:
  □ Simpan binary debug (tanpa -s -w) untuk keperluan profiling
  □ Aktifkan pprof endpoint jika perlu profiling di production

Ringkasan

• Binary Go bukan pure binary tanpa runtime — di dalamnya ter-embed runtime Go lengkap yang mendukung GC, goroutine scheduler, channel, panic/recover, dan reflection.
• Runtime eksternal tidak dibutuhkan — inilah yang membedakan Go dari Java atau Python, bukan ketiadaan runtime sama sekali.
• Static linking adalah default — tanpa CGO, binary Go sepenuhnya berdiri sendiri dan tidak bergantung pada library sistem di mesin tujuan.
• Ukuran binary lebih besar dari C — karena runtime yang kaya fitur ikut ter-bundle, bukan karena Go tidak efisien.
• Gunakan -ldflags="-s -w" untuk mengurangi ukuran binary production dengan menghapus symbol table dan DWARF debug info.
• Cross-compilation sangat mudah — cukup set GOOS dan GOARCH, runtime yang sesuai akan ikut ter-embed secara otomatis.
• Container scratch bisa digunakan karena binary Go tidak membutuhkan library sistem untuk berjalan (dengan CGO_ENABLED=0).