Rust on kenji.blog

Penjelasan tentang "Kepemilikan" dan "Peminjaman" di Rust dibandingkan dengan Pointer di C++

Sat, 12 Sep 2026 04:00:00 +0900

Dalam pemrograman sistem modern, menyeimbangkan kinerja dan keamanan memori adalah tantangan abadi. C++ telah berkuasa sebagai raja di bidang ini selama bertahun-tahun, tetapi dalam beberapa tahun terakhir, posisinya mulai terancam oleh Rust. Fitur terbesar Rust terletak pada konsep “Kepemilikan” (Ownership) dan “Peminjaman” (Borrowing), yang menjamin keamanan memori pada saat kompilasi tanpa memiliki garbage collection (GC).

Pada artikel ini, kita akan membandingkan secara rinci pointer C++ (pointer mentah, std::unique_ptr, std::shared_ptr) dan model kepemilikan Rust, serta menjelaskan secara menyeluruh bagaimana kompiler Rust (borrow checker) mencegah Use-After-Free (penggunaan setelah pembebasan) dan data race (perlombaan data), disertai dengan contoh kode dan diagram.

1. Dasar-dasar Manajemen Memori: Stack dan Heap

Untuk memahami dasar-dasar manajemen memori, mari kita tinjau kembali bagaimana sebuah program menggunakan memori. Area memori secara umum dibagi menjadi “Stack” dan “Heap”.

Stack

Ini adalah area di mana variabel lokal saat pemanggilan fungsi dan sejenisnya ditumpuk. Ini memiliki struktur LIFO (Last-In-First-Out) dan alokasi/de-alokasi memorinya sangat cepat. Hanya data yang ukurannya dapat ditentukan pada saat kompilasi yang ditempatkan di sini.

Heap

Data yang ukurannya ditentukan secara dinamis pada saat runtime, atau data yang perlu bertahan melampaui ruang lingkup (scope) fungsi ditempatkan di sini. Data ini diakses melalui pointer (atau referensi).

Dalam C++ atau Rust yang tidak memiliki garbage collection, biaya manajemen memori heap dapat dimodelkan dalam rumus matematika sebagai berikut. Misalkan jumlah total objek adalah $N$, waktu rata-rata yang diperlukan untuk alokasi adalah $T_{alloc}$, dan waktu rata-rata yang diperlukan untuk de-alokasi adalah $T_{dealloc}$, maka total biaya manajemen memori $C_{memory}$ adalah:

$$ C_{memory} = \sum_{i=1}^{N} (T_{alloc, i} + T_{dealloc, i}) + O_{sync} $$

Di sini, $O_{sync}$ adalah overhead untuk kontrol eksklusif (seperti mutex atau operasi atomik) di bawah lingkungan multi-thread. Karena Rust menentukan waktu pembebasan memori pada saat kompilasi, penurunan throughput akibat garbage collection (Stop-The-World) pada saat runtime menjadi nol, sementara $T_{dealloc}$ dieksekusi pada waktu yang pasti dan aman.

graph TD A["Memori Program"] --> B["Stack (Cepat, Ukuran Tetap)"] A --> C["Heap (Dinamis, Lebih Lambat)"] B --> D["Variabel Lokal"] B --> E["Pointer/Referensi"] C --> F["Data yang Dialokasikan Secara Dinamis"] E -.->|"Menunjuk ke"| F

2. Pointer C++: Pertukaran antara Kebebasan dan Bahaya

Mari kita lihat evolusi manajemen memori di C++.

Era Pointer Mentah (Raw Pointers) dan Masalahnya

Pointer mentah (*) yang diwarisi dari bahasa C menawarkan kebebasan tertinggi, tetapi pada saat yang sama menjadi sarang bagi bug serius seperti berikut.

Kebocoran Memori (Memory Leak): Lupa menggunakan delete pada memori yang dialokasikan dengan new.
Dangling Pointer: Mengakses pointer setelah memorinya dibebaskan (setelah delete).
Double Free: Menggunakan delete dua kali pada area memori yang sama.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// C++: Contoh masalah dengan pointer mentah
void rawPointerExample() {
 int* ptr = new int(10);
 // ... beberapa proses ...
 delete ptr;

 // Mengakses kembali secara tidak sengaja (Use-After-Free / Dangling Pointer)
 // Kompiler C++ tidak dapat membuat ini menjadi kesalahan kompilasi
 std::cout << *ptr << std::endl; // Perilaku Tidak Terdefinisi (Undefined Behavior)
}

Kemunculan RAII dan Smart Pointer (Sejak C++11)

Sejak C++11, smart pointer berdasarkan konsep RAII (Resource Acquisition Is Initialization) telah distandardisasi, dan penggunaan langsung pointer mentah sudah tidak disarankan.

`std::unique_ptr`

Ini adalah pointer yang mengekspresikan bahwa kepemilikannya tunggal. Memori secara otomatis dibebaskan saat keluar dari scope. Itu tidak dapat disalin, dan hanya kepemilikan yang dapat “dipindahkan” (move) (menggunakan std::move).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// C++: std::unique_ptr
#include <memory>
#include <iostream>

void uniquePtrExample() {
 std::unique_ptr<int> p1 = std::make_unique<int>(42);
 // std::unique_ptr<int> p2 = p1; // Kesalahan kompilasi (tidak dapat disalin)
 std::unique_ptr<int> p3 = std::move(p1); // Perpindahan kepemilikan

 // Kelemahan C++: p1 menjadi nullptr setelah pemindahan, tetapi aksesnya sendiri dapat dikompilasi
 // Ini akan menyebabkan crash saat runtime (segmentation fault)
 // std::cout << *p1 << std::endl;
}

`std::shared_ptr`

Ini adalah pointer yang memungkinkan beberapa pointer untuk berbagi objek yang sama. Ia menggunakan penghitungan referensi (Reference Counting), dan membebaskan memori ketika hitungannya mencapai 0. Karena operasi penambahan/pengurangan atomik diperlukan, ini menyebabkan sedikit overhead kinerja (setara dengan $O_{sync}$ yang disebutkan sebelumnya).

3. Kepemilikan (Ownership) Rust: Perubahan Paradigma

Rust menjadikan konsep std::unique_ptr dari C++ sebagai inti dari spesifikasi bahasanya, dan memiliki “model kepemilikan” yang bahkan lebih ketat.

3 Aturan Kepemilikan

Sistem kepemilikan Rust didasarkan pada tiga aturan yang sangat sederhana berikut:

Setiap nilai dalam Rust memiliki variabel yang disebut pemiliknya (owner).
Hanya boleh ada satu pemilik pada satu waktu.
Ketika pemilik keluar dari scope, nilai tersebut akan dibuang.

Di Rust, sumber daya “dipindahkan” secara default. Bahkan tanpa menyebutkan std::move secara eksplisit seperti di C++, operasi penugasan memindahkan kepemilikan.

1
2
3
4
5
6
7
8


// Rust: Perpindahan kepemilikan (Move)
fn main() {
 let s1 = String::from("hello"); // Data yang dialokasikan di heap
 let s2 = s1; // Kepemilikan berpindah (move) dari s1 ke s2

 // Perbedaan terbesar dengan C++: Akses ke variabel setelah perpindahan menjadi "kesalahan kompilasi"!
 // println!("{}, world!", s1); // Kesalahan kompilasi: value borrowed here after move
}

Fungsi “membuat variabel yang dipindahkan tidak dapat diakses pada saat kompilasi” ini adalah salah satu alasan mengapa Rust lebih aman daripada std::unique_ptr di C++.

sequenceDiagram participant S1 as "Variabel s1" participant Heap as "Memori Heap ('hello')" participant S2 as "Variabel s2" S1->>Heap: "Mengalokasikan & Memiliki" Note over S1,S2: "let s2 = s1;" S1--xHeap: "Kehilangan Kepemilikan (Tidak Valid)" S2->>Heap: "Mengambil Kepemilikan"

4. Peminjaman (Borrowing) dan Referensi

Jika kepemilikan selalu dipindahkan, kita harus mengembalikan kepemilikan setiap kali kita meneruskan nilai ke suatu fungsi, yang mana itu sangat tidak nyaman. Di sinilah “Peminjaman” (Borrowing) berperan. Ini setara dengan pointer atau referensi dalam C++.

Ada dua jenis peminjaman di Rust:

Referensi Imutabel (Immutable Reference): &T (Mirip dengan const T& dalam C++)
Referensi Mutabel (Mutable Reference): &mut T (Mirip dengan T& dalam C++)

Aturan Kejam dari Borrow Checker

Kompiler Rust memiliki mekanisme bawaan bernama “borrow checker” yang memvalidasi kebenaran referensi. Borrow checker memaksakan aturan ketat berikut:

Dalam suatu scope tertentu, hanya salah satu dari berikut ini yang dapat ada:

Satu referensi mutabel (&mut T)

Beberapa referensi imutabel (&T)

Ini disebut sebagai prinsip “Multiple Readers XOR Single Writer (MRSW)”. Ini dapat diekspresikan dengan matematika XOR (Exclusive OR). Untuk status $S$, jumlah referensi imutabel $N_r$ dan jumlah referensi mutabel $N_w$ harus memenuhi batasan berikut:

$$ (N_r \ge 0 \land N_w = 0) \oplus (N_r = 0 \land N_w = 1) $$

Melalui aturan ini, data race sepenuhnya dihilangkan pada saat kompilasi. Data race terjadi ketika: (1) dua atau lebih pointer mengakses data yang sama secara bersamaan, (2) setidaknya satu darinya melakukan penulisan, dan (3) tidak ada mekanisme sinkronisasi. Rust mencegah data race agar tidak terjadi dengan menghancurkan kondisi (2) pada saat kompilasi.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Rust: Kesalahan kompilasi karena pelanggaran aturan peminjaman
fn main() {
 let mut s = String::from("hello");

 let r1 = &s; // Peminjaman imutabel (OK)
 let r2 = &s; // Peminjaman imutabel (OK)
 // let r3 = &mut s; // Error! Tidak dapat membuat peminjaman mutabel jika ada peminjaman imutabel

 println!("{}, {}", r1, r2);
}

5. Mencegah Inisialisasi Iterator yang Tidak Valid (Iterator Invalidation)

Sebagai contoh konkret di mana kekuatan borrow checker paling terlihat, mari kita lihat bug klasik yang disebut “pembatalan iterator” (iterator invalidation).

Iterator Invalidation di C++ (Crash saat Runtime)

Jika kita memodifikasi std::vector dalam C++ di dalam loop, memori di belakangnya dapat dialokasikan ulang (Reallocation), mengubah referensi menjadi dangling pointer.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// C++: Bug invalidasi iterator
#include <iostream>
#include <vector>

int main() {
 std::vector<int> v = {1, 2, 3};

 // Mendapatkan referensi ke elemen vektor
 int& first = v[0];

 // Menambahkan elemen (Jika kapasitas tidak cukup di sini, area memori baru akan dialokasikan,
 // dan area lama mungkin dibuang)
 v.push_back(4);

 // first mungkin menunjuk ke memori yang sudah dibebaskan! (Perilaku Tidak Terdefinisi)
 std::cout << "The first element is: " << first << std::endl;

 return 0;
}

Pertahanan saat Kompilasi oleh Rust

Mari kita tulis logika yang sama persis di Rust.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// Rust: Mencegah invalidasi iterator pada saat kompilasi
fn main() {
 let mut v = vec![1, 2, 3];

 // Mendapatkan referensi imutabel (Peminjaman dimulai)
 let first = &v[0];

 // Error! Selama `first` meminjam `v` secara imutabel,
 // peminjaman mutabel yang diperlukan untuk `v.push` tidak dapat dilakukan.
 // v.push(4);

 println!("The first element is: {}", first);
}

Seperti ini, di Rust, “mengubah suatu nilai (meminjam mutabel) saat nilai tersebut sedang dibaca (dipinjam imutabel)” dilarang pada tingkat kompiler, sehingga bug fatal seperti Use-After-Free atau pembatalan iterator pasti ditangkap pada saat kompilasi.

graph LR A["Variabel v (Pemilik)"] --> B["Array Heap [1, 2, 3]"] C["Referensi 'first' (&v[0])"] -.->|"Peminjaman Imutabel"| B A -->|X "Peminjaman Mutabel Ditolak!"| D["v.push(4)"] style C stroke:#00FF00,stroke-width:2px style D stroke:#FF0000,stroke-width:2px

6. Kepemilikan Bersama di Rust: `Rc` dan `Arc`

Kepemilikan bersama yang setara dengan std::shared_ptr di C++ juga tersedia di Rust, namun tipenya dipisahkan dengan jelas untuk thread tunggal dan multi-thread.

Untuk Thread Tunggal: `Rc<T>` (Reference Counted)

Rc<T> adalah smart pointer penghitung referensi yang tidak thread-safe. Ia sangat cepat di dalam satu thread tunggal karena menambah dan mengurangi hitungan tanpa menggunakan instruksi atomik. Namun, jika Anda mencoba mengirimnya ke thread lain, itu akan menyebabkan kesalahan kompilasi (karena tidak mengimplementasikan trait Send).

Untuk Multi-thread: `Arc<T>` (Atomic Reference Counted)

Saat berbagi antar thread, kita menggunakan Arc<T> yang melakukan penambahan dan pengurangan secara atomik. Biayanya setara dengan std::shared_ptr di C++.

Lebih jauh lagi, di C++, jika Anda melakukan penulisan secara bersamaan dari beberapa thread ke variabel yang dibagikan dengan std::shared_ptr, data race akan terjadi. Untuk mencegah hal ini, Anda harus menggunakan std::mutex dengan benar secara manual.

Di sisi lain, dalam Rust, data di dalam tidak dapat diubah hanya dengan Arc<T> saja. Jika perubahan diperlukan, ia harus digabungkan dengan Mutex<T>, yang merupakan sebuah mutex.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // Kombinasi dari pembagian thread-safe dan kontrol eksklusif
 // Mirip dengan std::shared_ptr<std::mutex> di C++, tetapi Mutex membungkus data
 let counter = Arc::new(Mutex::new(0));
 let mut handles = vec![];

 for _ in 0..10 {
 let counter_clone = Arc::clone(&counter);
 let handle = thread::spawn(move || {
 // Referensi mutabel internal (&mut i32) hanya dapat diperoleh dengan memanggil lock()
 let mut num = counter_clone.lock().unwrap();
 *num += 1;
 }); // Pembebasan kunci secara otomatis dilakukan oleh RAII saat keluar dari scope
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }

 println!("Result: {}", *counter.lock().unwrap());
}

Yang perlu diperhatikan adalah Mutex<T> di Rust bukan sekadar mekanisme penguncian, tetapi “membungkus data yang harus dilindungi sebagai sebuah tipe”. Dengan ini, kesalahan seperti “mengakses data karena lupa mengambil kunci” dapat sepenuhnya dicegah pada tingkat kompilasi. Sistem dirancang sedemikian rupa sehingga hak akses (referensi) ke data di dalamnya tidak dapat diperoleh kecuali kunci (lock()) telah didapatkan.

Kesimpulan: “Pemeriksaan Sebelumnya” oleh Kompiler, atau “Tanggung Jawab Sendiri” oleh Pengembang?

Pointer dan smart pointer C++ menawarkan kontrol tingkat tinggi dan kinerja kepada para pengembang, tetapi penggunaannya yang benar bergantung pada disiplin pengembang. Meskipun C++ menjadi jauh lebih aman dengan diperkenalkannya RAII dan std::unique_ptr, “perilaku tidak terdefinisi” seperti akses setelah perpindahan atau pembatalan iterator masih tidak dapat dicegah sepenuhnya pada tingkat bahasa.

Di sisi lain, Rust mendeteksi kesalahan-kesalahan ini pada saat kompilasi dan bukan saat runtime, dengan memasukkan aturan Kepemilikan (Ownership) dan Peminjaman (Borrowing) ke dalam kompiler. Jaminan kuat bahwa “jika dapat dikompilasi, maka memori aman” adalah alasan terbesar mengapa Rust dengan cepat mendapatkan dukungan dalam pemrograman sistem.

Bertarung dengan borrow checker Rust (Fight the borrow checker) adalah rintangan besar bagi pemula, namun itu hanya kompiler yang dengan ketat mengambil alih perhitungan kompleks tentang “melacak masa pakai pointer” yang awalnya dilakukan di kepala oleh pemrogram C++.

Mempelajari Rust setelah memahami kebebasan dan bahaya pointer C++ akan membantu Anda untuk lebih memahami secara mendalam filosofi “mengapa dirancang seperti ini” di balik model kepemilikan.

Artikel ini adalah studi perbandingan metode manajemen memori di C++ dan Rust. Kami harap ini berfungsi sebagai referensi untuk memilih bahasa yang tepat berdasarkan persyaratan masing-masing proyek.

Kelebihan dan Kekurangan yang Dirasakan Insinyur C++ Setelah Mempelajari Rust

Sat, 12 Sep 2026 03:00:00 +0900

Pendahuluan: Fajar Baru Pemrograman Sistem

Dalam rekayasa perangkat lunak modern, C++ dan Rust berdiri di garis depan pemrograman sistem sebagai dua raksasa utama. Selama bertahun-tahun, C++ telah berkuasa sebagai raja mutlak di domain yang menuntut performa ekstrem dari perangkat keras, seperti sistem operasi, perangkat tertanam (embedded devices), mesin game (game engines), dan sistem perdagangan frekuensi tinggi (HFT). Saya sendiri sebagai insinyur C++ senior, mulai dari belantara pointer mentah di era C++98, melalui gelombang modernisasi C++11 (pengenalan smart pointer, lambda expressions, dan auto), hingga mendampingi spesifikasi yang terus membengkak di C++14/17/20, telah terus menulis kode.

Namun baru-baru ini, sebagai solusi untuk kelemahan struktural yang dimiliki C++—terutama kerentanan keamanan yang disebabkan oleh “kurangnya keamanan memori” (sekitar 70% dari CVE konon disebabkan oleh memori) dan “spesifikasi yang semakin kompleks tanpa akhir dan perilaku tidak terdefinisi (UB)"—Rust telah menunjukkan kebangkitan yang dramatis. Adopsi resminya ke dalam kernel Linux, serta proyek migrasi skala besar ke Rust oleh perusahaan-perusahaan teknologi raksasa seperti Microsoft, Google, dan AWS, bukanlah sekadar tren sementara, melainkan menandakan pergeseran paradigma dalam pemrograman sistem.

Dalam artikel ini, dari sudut pandang teknis yang berkaitan erat dengan fondasi spesifikasi bahasa, saya akan membandingkan dan menjelaskan secara mendalam “kelebihan” dan “kekurangan” yang dirasakan oleh seorang insinyur C++ tulen setelah benar-benar mempelajari Rust secara mendalam dan menggunakannya dalam praktik.

1. Pergeseran Paradigma Manajemen Memori: Dari RAII ke Kepemilikan dan Peminjaman

RAII pada C++ dan Keterbatasan Smart Pointer

Salah satu penemuan terbesar C++ adalah RAII (Resource Acquisition Is Initialization). Konsep ini, di mana sumber daya dialokasikan di konstruktor dan dibebaskan secara otomatis di destruktor saat keluar dari cakupan (scope), telah membebaskan pengembang dari teror kebocoran memori akibat penggunaan new dan delete secara manual. Mulai C++11, std::unique_ptr dan std::shared_ptr diperkenalkan ke perpustakaan standar, memungkinkan konsep kepemilikan (Ownership) untuk diekspresikan dalam kode.

Namun, smart pointer dan semantik perpindahan (move semantics) C++ memiliki kelemahan fatal di mana verifikasi statis oleh kompilator tidak sempurna.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


#include <iostream>
#include <memory>
#include <string>

void consume(std::unique_ptr<std::string> ptr) {
 std::cout << "Consuming: " << *ptr << std::endl;
}

int main() {
 auto my_ptr = std::make_unique<std::string>("Hello, C++");

 // Memindahkan (move) kepemilikan ke fungsi
 consume(std::move(my_ptr));

 // Bahaya: Di C++, mengakses objek setelah di-move tidak menyebabkan error kompilasi
 // std::move hanyalah sekadar cast ke rvalue reference (T&&), dan kompilator tidak memblokir penggunaannya
 if (my_ptr) {
 std::cout << "Pointer is still valid?" << std::endl;
 } else {
 std::cout << "Pointer is null." << std::endl;
 }

 // std::cout << *my_ptr << std::endl; // Perilaku tidak terdefinisi akibat penggunaan memori setelah dibebaskan (Use-After-Free)
 return 0;
}

Di C++, selalu ada risiko bahwa Anda secara tidak sengaja mengakses objek yang isinya telah dikosongkan (valid tetapi dalam keadaan yang tidak ditentukan) oleh std::move. Ini dapat langsung berujung pada crash saat runtime, atau dalam kasus terburuk, lubang keamanan.

Kepemilikan (Ownership) Rust dan Pertahanan Absolut Borrow Checker

Rust menggabungkan konsep “kepemilikan” ini ke dalam desain inti bahasanya, dan melakukan analisis statis yang ketat melalui fitur kompilator yang disebut Borrow Checker (Pengecek Peminjaman).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


fn consume(s: String) {
 println!("Consuming: {}", s);
} // Di sini s keluar dari scope, dan memori dibebaskan (Drop)

fn main() {
 let my_string = String::from("Hello, Rust");

 // Memindahkan kepemilikan ke fungsi. Di Rust, default-nya adalah semantik move.
 consume(my_string);

 // Error kompilasi! Variabel setelah di-move sama sekali tidak bisa diakses
 // println!("Is it still there? {}", my_string);
}

Di Rust, pada saat kepemilikan sebuah variabel dipindahkan, variabel asli tersebut diperlakukan oleh kompilator setara dengan status “tidak diinisialisasi” dan sepenuhnya memblokir akses selanjutnya. Akibatnya, bug seperti “Use-After-Free (penggunaan memori setelah pembebasan)” dan “Dangling Pointer (pointer menggantung)” secara teoretis tidak akan dapat melewati kompilasi.

graph TD A["C++ std::unique_ptr"] --> B["std::move diterapkan"] B --> C["Kepemilikan Dipindahkan"] C --> D["Pointer Lama Masih Dapat Diakses"] D --> E["Potensi Perilaku Tidak Terdefinisi (UB)"] F["Rust Box / String"] --> G["Dilewatkan berdasarkan Nilai (Move)"] G --> H["Kepemilikan Dipindahkan"] H --> I["Kompilator Memblokir Variabel Lama"] I --> J["Keamanan Memori Dijamin"]

Peminjaman (Borrowing) dan Kontrol Mutabilitas

Yang lebih kuat lagi adalah aturan “peminjaman (Borrowing)” yang merujuk pada sumber daya. Di Rust, aturan berikut ini dipaksakan:

Pada waktu tertentu, hanya satu dari keduanya yang boleh ada: “banyak referensi tidak dapat diubah (immutable reference, &T)” ATAU “satu referensi yang dapat diubah (mutable reference, &mut T)”.
Referensi tidak boleh hidup lebih lama daripada scope data aslinya (batasan lifetime).

Di C++, sangat mudah untuk membuat beberapa referensi atau pointer yang mutable (dapat diubah) ke objek yang sama, dan ini memicu kerusakan status yang tidak terduga (seperti pembatalan iterator). Rust mencegah bug ini sejak awal dengan melarang kombinasi “Aliasing (penamaan alternatif) + Mutability (kemampuan diubah)” di tingkat bahasa.

2. Tata Letak Memori dan Overhead Matematis Smart Pointer

Dalam pemrograman sistem, pemahaman yang akurat tentang tata letak memori sangatlah penting. Mari kita bandingkan std::shared_ptr dari C++ dengan std::rc::Rc / std::sync::Arc dari Rust.

std::shared_ptr C++ mengelola sumber daya melalui penghitungan referensi, dan secara default menggunakan operasi atomik (std::atomic) yang aman untuk thread (thread-safe) untuk menambah atau mengurangi jumlah referensi. Overhead pada memori tersebut dapat dirumuskan sebagai berikut:

$$ Overhead_{C++} = sizeof(T) + sizeof(ControlBlock) $$

Di sini, $ControlBlock$ mencakup “Penghitung Referensi Kuat (Strong Ref Count)”, “Penghitung Referensi Lemah (Weak Ref Count)”, dan “Deleter Kustom (Custom Deleter)”. Masalahnya adalah, meskipun hanya digunakan dalam single-thread, overhead dari instruksi atomik (seperti penguncian baris cache, dll.) terjadi tanpa syarat.

Sebaliknya, Rust secara tegas memisahkan smart pointer sesuai dengan tujuan penggunaannya.

Untuk Single-thread: Rc<T> (Reference Counted)
Untuk Multi-thread: Arc<T> (Atomic Reference Counted)

$$ Overhead_{Rc} = sizeof(T) + 2 \times sizeof(usize) $$ $$ Overhead_{Arc} = sizeof(T) + 2 \times sizeof(AtomicUsize) $$

Di Rust, jika menggunakan Rc<T> yang khusus untuk single-thread, Anda dapat sepenuhnya menghindari penalti operasi atomik (abstraksi nol-biaya). Dan melalui mekanisme keselamatan thread (thread-safety) yang dijelaskan nanti, sistem tipe (type system) sepenuhnya mencegah kesalahan dalam memberikan Rc<T> ke thread lain.

3. Keselamatan Thread: Kejutan dari “Fearless Concurrency”

Pemrograman multi-thread di C++ selalu berdampingan dengan ketakutan akan perlombaan data (data race) dan kebuntuan (deadlock).

Bahaya dari Pemisahan Mutex dan Data di C++

std::mutex pada C++ pada dasarnya hanyalah pengontrol eksklusif untuk “blok kode tertentu (critical section)”, dan tidak ada kaitan bahasawi antara “data yang harus dilindungi” dan “mutex”-nya.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#include <iostream>
#include <thread>
#include <mutex>
#include <vector>

std::vector<int> shared_data;
std::mutex mtx;

void worker() {
 // Sekalipun pengembang lupa mendapatkan kunci (lock), proses kompilasi tetap akan lolos
 // std::lock_guard<std::mutex> lock(mtx);
 shared_data.push_back(1); // Perlombaan data (data race) yang fatal!
}

int main() {
 std::thread t1(worker);
 std::thread t2(worker);
 t1.join();
 t2.join();
 return 0;
}

Mutex Rust “Memiliki” Datanya

Di Rust, Mutex<T> menggunakan generik untuk membungkus (memiliki) tipe data yang dilindunginya, T. Untuk mengakses data, Anda diharuskan memanggil lock() untuk mendapatkan objek pelindung (guard object). Menyentuh data tanpa mendapatkan kunci (lock) adalah hal yang tidak mungkin secara tata bahasa (sintaks).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // Data sepenuhnya dienkapsulasi di dalam Mutex
 let shared_data = Arc::new(Mutex::new(Vec::new()));
 let mut handles = vec![];

 for _ in 0..2 {
 // Mengkloning Arc (penghitungan referensi yang aman untuk thread) untuk dibagikan antar thread
 let data_clone = Arc::clone(&shared_data);
 let handle = thread::spawn(move || {
 // Tanpa mendapatkan kunci (lock), akses ke Vec internal tidak bisa dilakukan
 let mut data = data_clone.lock().unwrap();
 data.push(1);
 });
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }
}

Terlebih lagi, di dalam Rust terdapat 2 sifat inti (core traits) yang menjamin keamanan pemrosesan paralel.

Send: Tipe data yang kepemilikannya dapat ditransfer antar thread dengan aman
Sync: Tipe data yang aman jika diakses secara bersamaan oleh beberapa thread

Sebagai contoh, Rc<T> yang tidak aman untuk thread tidak mengimplementasikan trait Send. Oleh karena itu, jika Anda mencoba meneruskannya ke thread::spawn, ini akan langsung menyebabkan error kompilasi. Dengan adanya “Fearless Concurrency (Konkurensi Tanpa Rasa Takut)” ini, pengembang terbebas dari ketakutan akan bug, dan dapat memajukan paralelisasi dengan jauh lebih agresif.

Menurut Hukum Amdahl (Amdahl’s Law), throughput maksimum teoretis untuk bagian yang dapat diparalelkan $P$ dan derajat paralelisme $N$ dinyatakan sebagai berikut:

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

Rust memungkinkan dilakukannya refaktor untuk memaksimalkan $P$ ini dengan sangat aman, mengandalkan sistem tipe.

graph TD A["Keamanan Thread C++"] --> B["Bergantung pada Ingatan Pengembang"] B --> C["Mutex Terpisah dari Data"] C --> D["Risiko Tinggi Perlombaan Data Terselubung"] E["Keamanan Thread Rust"] --> F["Trait Send dan Sync"] F --> G["Mutex Memiliki Data"] G --> H["Perlombaan Data Dicegah pada Waktu Kompilasi"]

4. Penanganan Kesalahan: Pengecualian vs Tipe Data Aljabar

Standar penanganan kesalahan (error handling) di C++ adalah “Pengecualian (Exceptions)”. Namun, pengecualian membuat alur kontrol menjadi tidak jelas, dan menyebabkan penalti performa (seperti stack unwinding dan pembengkakan RTTI). Dalam sistem tertanam atau mesin game, menonaktifkan pengecualian sepenuhnya (-fno-exceptions) dan mengadopsi desain yang mengembalikan kode kesalahan (error code) klasik sangat sering dilakukan. Meskipun std::expected telah diperkenalkan pada C++23, dibutuhkan waktu bagi ekosistem secara keseluruhan untuk mengadopsinya.

Di Rust, konsep pengecualian tidak ada. Kesalahan dikembalikan murni sebagai “nilai”, dan direpresentasikan menggunakan tipe enumerasi (tipe data aljabar) Result<T, E>.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


use std::fs::File;
use std::io::{self, Read};

// Hanya dengan melihat tipe nilai kembaliannya, jelas bahwa kesalahan IO dapat terjadi
fn read_file_content(path: &str) -> Result<String, io::Error> {
 // Dengan operator ?, return awal seketika jika error, dan jika sukses ekstrak isinya
 let mut file = File::open(path)?;
 let mut content = String::new();
 file.read_to_string(&mut content)?;
 Ok(content)
}

Operator ? ini revolusioner. Operator ini menghilangkan persarangan (nesting) dalam (piramida pernyataan if) yang terjadi saat memeriksa kode kesalahan di C++, mempertahankan alur kode yang bersih seperti pengecualian, sekaligus memungkinkan penulisan secara eksplisit pada panggilan fungsi mana kesalahan tersebut disebarkan (propagated).

5. Polimorfisme: Dari Fungsi Virtual dan Templat ke Trait

Polimorfisme dalam C++ diimplementasikan terutama melalui pewarisan kelas dan dispatch dinamis dengan fungsi virtual (virtual), atau dispatch statis menggunakan templat (seperti CRTP).

Pada dispatch dinamis, pointer ke tabel fungsi virtual (vtable), yaitu vptr, tertanam ke dalam objek, menyebabkan terjadinya overhead akibat penyelesaian pointer saat pemanggilan fungsi.

$$ T_{dispatch} = T_{lookup\_in\_vtable} + T_{dereference} $$

Rust membuang “pewarisan kelas” ala orientasi objek klasik dan sebagai gantinya mengadopsi konsep “Traits” (ini mirip dengan Konsep/Concept C++20, namun jauh lebih kaya fitur).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


trait Drawable {
 fn draw(&self);
}

struct Circle { radius: f64 }
impl Drawable for Circle {
 fn draw(&self) { println!("Menggambar Lingkaran dengan jari-jari {}", self.radius); }
}

// Dispatch Statis (Monomorfisasi / Nol Overhead)
fn draw_static<T: Drawable>(item: &T) {
 item.draw();
}

// Dispatch Dinamis (Objek Trait)
fn draw_dynamic(item: &dyn Drawable) {
 item.draw();
}

Fitur terbesar dari dispatch dinamis Rust (dyn Trait) adalah penggunaan Fat Pointer alih-alih memiliki vptr di dalam struktur datanya. Fat Pointer menyimpan “pointer ke data” dan “pointer ke vtable” sebagai pasangan. Karena itu, sangat mudah untuk mengimplementasikan (memperluas) trait kemudian pada tipe yang didefinisikan oleh perpustakaan (library) eksternal untuk dipanggil secara dispatch dinamis.

6. Manajemen Paket dan Sistem Build: Penderitaan CMake vs Karunia Cargo

Salah satu kelemahan terbesar C++ adalah ketiadaan manajer paket (package manager) standar. Tata bahasa CMakeLists.txt yang rumit, kompleksitas penyelesaian dependensi oleh find_package, dan perbedaan pada jalur pustaka (library path) untuk setiap sistem operasi (OS) terus-menerus merampas banyak waktu dari insinyur C++.

Rust hadir dengan standar Cargo, yaitu gabungan antara manajer paket dan sistem build terbaik di dunia.

graph TD A["Lingkungan Build C++"] --> B["CMakeLists.txt"] B --> C["Integrasi vcpkg / Conan"] C --> D["Menghasilkan Makefiles / Ninja"] D --> E["Kompilator (GCC/Clang/MSVC)"] F["Lingkungan Build Rust"] --> G["Cargo.toml"] G --> H["Mengambil dependensi dari crates.io"] H --> I["rustc (Cargo build)"] I --> J["Biner Siap Dijalankan"]

Hanya dengan menambahkan satu baris nama dan versi dari pustaka dependensi (crate) ke Cargo.toml, Cargo akan menangani semuanya secara otomatis mulai dari menyelesaikan dependensi transitif, pengunduhan, hingga kompilasi. Selanjutnya, semua rantai perkakas (toolchain) yang diperlukan untuk pengembangan seperti pengujian (cargo test), pembuatan dokumentasi (cargo doc), analisis statis (cargo clippy), dan formatter (cargo fmt), seluruhnya terintegrasi ke dalam satu perintah ini. Kenyamanan ini memiliki daya hancur yang sedemikian rupa sehingga begitu Anda mencicipinya, Anda tak akan mau kembali ke lingkungan build C++.

7. Kekurangan dan Kurva Pembelajaran dalam Mempelajari Rust

Sejauh ini saya telah membicarakan tentang kelebihan Rust, tetapi “dinding” dan kekurangan yang pasti dihadapi oleh insinyur C++ ketika mencoba untuk menempatkan Rust ke dalam praktik pertempuran yang sesungguhnya tentu saja ada.

1. Pergulatan Sengit dengan Borrow Checker

Jika Anda mencoba untuk secara langsung mengimplementasikan struktur data yang di C++ “biasanya dihubungkan dengan pointer mentah (raw pointer)” (seperti doubly linked list, struktur graf, atau struktur yang mereferensikan dirinya sendiri) ke dalam Rust, kode tersebut tidak akan lulus kompilasi karena adanya batasan pada kepemilikan dan lifetime. Untuk memuaskan Borrow Checker, Anda perlu menerapkan pembungkus yang rumit seperti Rc<RefCell<T>>, atau secara fundamental merombak desain menjadi pengelolaan berbasis indeks atau menggunakan arena allocator.

2. Lamanya Waktu Kompilasi

Meskipun kompilasi di C++ menjadi lambat karena templat yang bersarang (nested), waktu kompilasi Rust (terutama clean build dari nol) sama sekali tidak bisa dikatakan singkat. Karena tumpang tindih dari pass optimasi LLVM yang kuat, perluasan makro, dan monomorfisasi (monomorphization) dari generik, waktu build akan menjadi hambatan (bottleneck) dalam proyek skala besar. Selama masa pengembangan, berbagai trik seperti seringnya menggunakan cargo check merupakan hal yang sangat penting.

3. Interoperabilitas dengan Basis Kode C++

Meskipun integrasi dengan bahasa C (FFI) sangat lancar, untuk mengintegrasikan Rust secara langsung dengan basis kode C++ yang ada dan sangat besar (yang banyak menggunakan kelas, templat, dan fungsi virtual) adalah hal yang sangat sulit. Baru-baru ini, alat jembatan seperti cxx dan autocxx memang telah berkembang, tetapi masih terdapat rintangan yang tinggi untuk mencapai transisi yang benar-benar mulus.

Kesimpulan: Haruskah Kita Bermigrasi ke Rust?

C++ di masa mendatang akan terus memainkan peran penting dalam pengembangan mesin game dan infrastruktur besar yang sudah ada. Modernisasi melalui C++20/23 juga sangat luar biasa, memungkinkannya untuk ditulis dengan cara yang jauh lebih aman.

Namun, untuk “proyek pemrograman sistem yang baru dimulai,” saya merasa sekarang lebih sulit menemukan alasan untuk TIDAK memilih Rust. “Kepastian (certainty)” yang ditawarkan oleh Rust, di mana selama kodenya lulus dikompilasi maka Anda terbebas dari ketakutan akan perilaku tidak terdefinisi dan kerusakan memori, serta kemampuan untuk memproses secara paralel dengan aman dan pada kinerja tinggi, secara dramatis meningkatkan model mental seorang insinyur.

Bagi seorang insinyur C++, mempelajari Rust bukan sekadar tentang menghafal sintaksis baru, melainkan sebuah pengalaman terbaik untuk mendapatkan perspektif baru terhadap “metode pengelolaan memori dan thread yang aman”. Saya harap Anda semua juga dapat merasakan secara langsung nyamannya penggunaan Cargo sekaligus ketegasan yang diberikan oleh Borrow Checker.