Go, Node, atau Rust? Tentukan dari Tim Anda

Untuk sebagian besar sistem bisnis, pilih bahasa yang sanggup dirawat tim sekarang dan tim berikutnya. Node.js cocok bila tim Anda berlatar pengembang web. Go cocok untuk layanan yang menyala terus dan kotak kecil penghubung perangkat ke server. Rust cukup untuk bagian kecil yang mahal bila salah atau boros CPU. Penentunya orang, pustaka, dan pembaruan, bukan hasil uji kecepatan.

Di bawah ini saya pecah jawaban itu menjadi empat pemeriksaan untuk menilai usulan vendor, ditambah tabel untuk situasi yang paling sering muncul. Artikel ini melanjutkan pembahasan memilih teknologi yang membosankan, kali ini dengan tiga bahasa yang konkret.

Kenapa uji kecepatan jarang menentukan?

Sistem bisnis lebih banyak menunggu daripada menghitung. Ia menunggu jawaban database, penyedia pembayaran, channel manager hotel, atau perangkat di lokasi dengan sinyal lemah. Misalkan satu permintaan menghabiskan 200 milidetik untuk menunggu database. Bahasa yang menjalankan kode Anda dua kali lebih cepat hanya memangkas beberapa milidetik dari total itu, dan pelanggan tidak akan merasakannya.

Hasil perbandingan kecepatan yang beredar memang mengukur sesuatu yang nyata. Hanya saja, yang diukur biasanya perulangan padat atau penanganan permintaan di server kosong. Biaya sistem Anda ada di tempat lain: jam kerja pengembang untuk mengubahnya, lama mencari pengganti saat pengembang itu pergi, dan akhir pekan yang habis untuk pembaruan versi. Empat pemeriksaan berikut membahas biaya-biaya itu.

Pemeriksaan 1: Siapa yang merawatnya tiga tahun lagi?

Mulailah dari orang. Merekalah bagian sistem yang paling mahal dan paling sulit diganti.

Survei Pengembang Stack Overflow 2025 mencatat 66% responden memakai JavaScript, bahasa yang dijalankan Node.js. Go dipakai 16,4% responden, Rust 14,8%. Angka ini datang dari survei global tentang bahasa yang dipakai, bukan hitungan kandidat atau gaji di Indonesia. Meski begitu, gambarannya jelas: setiap kali Anda bertemu satu pengembang Go atau Rust, ada beberapa pengembang JavaScript di sekitarnya.

Pertanyaan yang berguna lebih sempit daripada "bahasanya populer atau tidak":

• Siapa di tim sekarang yang benar-benar menguasainya?
• Kalau orang itu keluar, bisakah Anda menemukan pengganti di kota yang sama dalam sebulan?
• Apakah di tim vendor ada lebih dari satu orang yang paham kode ini?

Satu ahli dalam bahasa langka berarti proyek bergantung pada satu orang. Untuk perusahaan sepuluh orang, dua pengembang biasa dengan bahasa yang umum biasanya pilihan yang lebih aman.

Pemeriksaan 2: Apakah pustaka yang dibutuhkan sudah ada?

Pustaka (library) adalah kode siap pakai yang dirawat pihak lain. Yang paling penting di sini adalah SDK, paket resmi dari layanan yang tersambung ke bisnis Anda: gerbang pembayaran, pesan, penyimpanan cloud, akuntansi.

Ambil contoh pembayaran di Indonesia. Per Oktober 2026, Midtrans menyediakan pustaka resmi untuk PHP, Node.js, Go, Python, dan Java. Xendit menyediakan SDK resmi untuk PHP, Go, Node.js (TypeScript), dan Python. Rust tidak ada di daftar keduanya.

Artinya, tim Rust harus menulis dan merawat sendiri bagian yang biasanya sudah diurus SDK. Bagian itu meliputi penandatanganan permintaan, pemeriksaan tanda tangan webhook (memastikan notifikasi benar-benar dikirim penyedia), penanganan galat, dan penyesuaian setiap kali penyedia mengubah API-nya. Semua itu juga harus tetap benar ketika permintaan dikirim ulang; lihat pembahasan idempotensi API pembayaran. Rust tetap bisa dipakai, tetapi ada pekerjaan tambahan yang perlu dihitung.

Cocokkan tabel ini dengan daftar integrasi Anda sendiri sebelum memutuskan. Satu SDK yang tidak tersedia bisa menambah pekerjaan berminggu-minggu, dan itu tidak pernah terlihat di hasil uji kecepatan.

Pemeriksaan 3: Berapa biaya menjalankannya?

Di sini Go dan Rust memang unggul, tetapi keunggulan itu tidak sesering yang dijanjikan vendor.

Program Go dan Rust dikompilasi menjadi satu berkas siap jalan. Cukup salin satu berkas itu ke server, lalu jalankan. Node.js membutuhkan runtime, mesin yang menjalankan JavaScript, terpasang di server, ditambah folder berisi paket di samping kode Anda. Untuk pekerjaan yang sama, program Go dan Rust juga cenderung memakai memori lebih kecil.

Pada server cloud untuk sistem UMKM, selisih itu sering kali hanya satu tingkat ukuran server. Jumlahnya kecil dibanding biaya satu hari kerja pengembang. Selisihnya baru terasa di dua tempat:

• Perangkat kecil di lokasi. Kotak gateway dengan memori terbatas, atau lokasi tanpa teknisi, lebih aman dengan satu berkas dan pemakaian memori rendah. Itulah alasan Go cocok untuk gateway IoT.
• Beban berat yang terus-menerus. Pengolahan video, data sensor bervolume tinggi, atau apa pun yang membuat biaya CPU terlihat jelas di tagihan. Di situlah Rust sepadan dengan usahanya.

Kalau keduanya tidak berlaku, biaya server sebaiknya tidak menjadi penentu bahasa.

Pemeriksaan 4: Seberapa berat perawatan setelah serah terima?

Pemeriksaan ini paling sering dilewatkan dalam proposal. Setiap bahasa terus berkembang, dan harus ada orang yang menjaga sistem tetap di versi yang masih didukung setelah pembuatnya pergi. Kecepatan ketiganya berbeda.

Node.js mengikuti kalender rilis. Sistem produksi sebaiknya memakai versi LTS (long-term support), yaitu versi yang dijamin menerima perbaikan untuk jangka waktu tertentu, umumnya 30 bulan. Menurut jadwal rilis Node.js, Node 22 berhenti didukung pada 30 April 2027, dan Node 24 pada 30 April 2028. Node 24 masuk masa perawatan terbatas mulai 20 Oktober 2026, lalu Node 26 menjadi LTS pada 28 Oktober 2026. Dalam praktik, sistem Node perlu dijadwalkan naik versi kira-kira setiap satu sampai dua tahun.

Naik versi Go biasanya cukup dikompilasi ulang. Go berkomitmen agar program yang ditulis untuk Go 1 tetap bisa dikompilasi dan berjalan tanpa diubah. Komitmen ini dinyatakan sebagai niat, bukan jaminan mutlak. Setiap rilis Go didukung sampai dua rilis yang lebih baru keluar. Go 1.27 terbit 19 Agustus 2026, jadi Go 1.25 tidak lagi menerima perbaikan. Naik versi umumnya berarti mengganti nomor versi lalu menjalankan pengujian, bukan menulis ulang.

Rust menjaga kode lama lewat edition. Edition adalah paket perubahan bahasa yang dipakai atas pilihan sendiri. Menurut panduan edition Rust, kode dari edition lama tetap bisa dikompilasi dan bekerja bersama kode baru. Biaya perawatan Rust lebih banyak ada pada mencari orang yang bisa membaca kodenya, bukan pada pembaruan versi.

Paket pihak ketiga juga bagian dari perawatan

Risiko perawatan yang lebih besar sering kali datang dari paket yang dipinjam kode Anda, bukan dari bahasanya. Proyek Node lazim menarik ratusan paket, kebanyakan berupa paket yang dibutuhkan paket lain. Pada 23 September 2025, CISA memperingatkan bahwa worm bernama Shai-Hulud, program jahat yang menyebar sendiri, telah membobol lebih dari 500 paket di npm, gudang paket utama Node.js. Tujuannya mencuri kredensial pengembang dan akun cloud.

Go dan Rust juga punya gudang paket, dan serangan serupa bisa terjadi di sana. Bedanya ada pada kebiasaan. Kode Go cenderung mengandalkan pustaka bawaannya, sehingga banyak layanan Go punya daftar paket luar yang lebih pendek untuk diawasi. Bahasa apa pun yang Anda pilih, minta lockfile, berkas yang mengunci versi persis setiap paket, beserta prosedur tertulis untuk meninjau pembaruan.

Bahasa mana untuk situasi apa?

Mencampur bahasa tidak masalah selama batasnya jelas. Bentuk yang sering saya pakai: satu bahasa utama untuk sebagian besar sistem, lalu satu komponen kecil berbahasa Go atau Rust di belakang antarmuka sederhana, misalnya endpoint HTTP atau antrean pesan. Kalau ahlinya pergi, komponen itu bisa ditulis ulang tanpa menyentuh bagian lain.

Pertanyaan untuk vendor yang mengusulkan sebuah bahasa

1. Selain Anda, siapa yang bisa merawat sistem ini? Minta nama orang atau rencana rekrutmen, bukan jawaban "bahasanya populer".
2. SDK apa saja yang dipakai, dan apakah resmi? Daftarkan setiap integrasi pembayaran, pesan, dan cloud.
3. Sistem berjalan di versi runtime berapa, dan kapan dukungannya berakhir? Untuk Node.js, jawabannya harus menyebut versi LTS dan tanggal akhir dukungannya.
4. Bagaimana pembaruan paket ditinjau? Cari lockfile, jadwal pembaruan, dan orang yang bertanggung jawab.
5. Kalau ada bagian berbahasa lain, kenapa bagian itu? Jawabannya harus menyebut batasan nyata (perangkat, CPU, data dari luar), bukan selera.

Pertanyaan ini sebaiknya diajukan bersamaan dengan pembahasan serah terima dan ketergantungan pada vendor. Memilih bahasa pada dasarnya keputusan tentang orang dan perawatan. Pilih bahasa yang sanggup dipikul tim Anda selama sistem itu hidup, dan pakai bahasa spesialis hanya ketika ada batasan nyata yang membayar biayanya.