Rust Development

Rust menghimpun tiga peran yang di dunia C tersebar di beberapa alat — compiler, build system, dan package manager — menjadi satu kesatuan yang resmi dan selalu serasi. Kabar dari mesin latihan kita jujur saja: rustc dan cargo tidak terpasang di sini, karena Rust memang lazim dipasang per-user lewat rustup, bukan lewat package manager sistem. Kekosongan itu tidak menghalangi kita: keadaan package di repository tetap bisa dibaca lewat apt-cache, dan struktur proyek Cargo bisa kita bangun dengan tangan — persis seperti yang dihasilkan perintah cargo new — lalu kita bedah bagian demi bagian.

rustc, cargo, dan rustup: Tiga Nama Satu Ekosistem #

Tiga nama itu muncul bersamaan di hampir setiap tutorial Rust, jadi kita rapikan dulu pembagiannya:

Pembagian ini menjelaskan mengapa perintah cargo build tidak pernah disebut rustc padahal jelas-jelas mengompilasi: cargo adalah penggerinya — membaca daftar dependensi, mengunduhnya, lalu memanggil rustc di belakang layar untuk tiap crate. Konsep compiler dan build automation sendiri sudah kita bahas di Chapter Compilers dan Build Tools ; di sini kita cukup fokus pada kekhasan Rust.

Dua Jalur Instalasi: apt versus rustup #

Debian menyediakan rustc dan cargo sebagai package biasa — tercatat rapi, diperbarui lewat apt upgrade, dan dipasang ke seluruh sistem dengan root. Kita intip keadaannya tanpa memasang apa pun:

apt-cache policy rustc cargo

Output yang Dihasilkan:

rustc:
  Installed: (none)
  Candidate: 1.85.1+dfsg1-1+deb13u1
  Version table:
     1.85.1+dfsg1-1+deb13u1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages
cargo:
  Installed: (none)
  Candidate: 1.85.1+dfsg1-1+deb13u1
  Version table:
     1.85.1+dfsg1-1+deb13u1 500
        500 http://deb.debian.org/debian trixie/main amd64 Packages

Bedah outputnya:

1. Installed: (none) untuk keduanya: konsisten dengan cerita pembuka — mesin ini tidak memasang Rust lewat jalur mana pun.
2. Candidate: 1.85.1+dfsg1-1+deb13u1: versi Rust yang dikemas Debian 13. Angka -deb13u1 dan dfsg1 adalah penanda pengemasan Debian, bukan bagian dari versi Rust aslinya.
3. Dua nama, satu versi: rustc dan cargo dirilis bersama dari satu repositori sumber — di jalur apt pun keduanya selalu sepasang.

Jalur kedua adalah rustup — installer resmi yang direkomendasikan proyek Rust. Skrip installernya diunduh dari situs resmi Rust (rust-lang.org) dan dijalankan sekali sebagai user biasa tanpa root; hasilnya hidup sepenuhnya di home directory: binary di ~/.cargo/bin dan toolchain di ~/.rustup. Konsekuensinya dua arah. Sisi baiknya: versi selalu terkini, tiap user di satu mesin boleh memakai versi berbeda, dan pembaruan cukup lewat rustup update. Sisi yang perlu disadari: Rust dari rustup tidak tercatat di database dpkg, jadi jalur ini dan jalur apt sebaiknya tidak dicampur untuk binari yang sama.

rustc versus cargo: Kapan Pakai yang Mana #

Untuk satu file main-main, rustc sendiri sudah cukup — mirip gcc pada program C kecil:

cat > halo.rs << 'AKHIR'
fn main() {
    println!("Halo dari Rust!");
}
AKHIR
rustc halo.rs
./halo

Perintah rustc halo.rs menghasilkan binary bernama halo di folder yang sama, lalu ./halo menjalankannya persis seperti binary C hasil gcc — awalan ./ tetap wajib karena direktori kerja tidak masuk PATH. Begitu proyek menuntut lebih dari satu file atau satu dependensi, saatnya pindah ke cargo. Seluruh perintahnya membentuk siklus pendek yang mudah diingat:

Anatomi Proyek Cargo #

Struktur proyek Cargo baku dan kaku — itulah kekuatannya, karena semua proyek Rust di dunia bentuknya sama. Karena cargo new belum tersedia di mesin ini, kita bangun kerangkanya dengan tangan dan periksa hasilnya:

mkdir -p penghitung-word-count/src
cat > penghitung-word-count/Cargo.toml << 'AKHIR'
[package]
name = "penghitung-word-count"
version = "0.1.0"
edition = "2021"

[dependencies]
anyhow = "1.0"
AKHIR
cat > penghitung-word-count/src/main.rs << 'AKHIR'
fn main() {
    println!("Halo dari Rust!");
}
AKHIR
tree penghitung-word-count
cat penghitung-word-count/Cargo.toml

Output yang Dihasilkan:

penghitung-word-count
├── Cargo.toml
└── src
    └── main.rs

2 directories, 2 files
[package]
name = "penghitung-word-count"
version = "0.1.0"
edition = "2021"

[dependencies]
anyhow = "1.0"

Bedah struktur dan isinya:

1. Cargo.toml di akar proyek: manifes proyek. Isinya ditulis dalam TOML — format konfigurasi ringkas yang juga dipakai banyak tool modern — dan semua yang cargo perlu tahu tentang proyek ada di sini.
2. src/main.rs: titik masuk program; fungsi main adalah tempat eksekusi dimulai, sama perannya dengan main() di Java dan C.
3. Bagian [package]: identitas proyek. name wajib cocok dengan format nama crate (huruf kecil dan tanda hubung), version mengikuti semantik MAJOR.MINOR.PATCH, dan edition menentukan generasi bahasa yang dipakai — 2021 adalah edisi yang umum saat ini.
4. Bagian [dependencies]: daftar crate pihak ketiga. anyhow = "1.0" meminta crate penanganan error yang populer; versi ditulis sebagai string karena di balik layar berarti caret — 1.0 ke atas selama masih di bawah 2.0, konsep yang sama dengan ^3.7 pada composer.json di Chapter PHP Development .
5. tree: memperlihatkan layout final-nya — persis kerangka yang ditulis cargo new.

Saat cargo build pertama kali berjalan, dua artefak baru muncul: folder target/ untuk hasil build (aman dihapus kapan saja, sebagaimana target/ milik Maven di Chapter Java Development ) dan file Cargo.lock yang mencatat versi persis tiap dependensi hasil penyelesaian. Untuk aplikasi, Cargo.lock ikut disimpan di version control; untuk pustaka, kebiasaannya diabaikan.

crates.io dan Pasar Dependensi #

Seluruh crate yang tertulis di [dependencies] diunduh dari crates.io — registry pusat ekosistem Rust. Menambahkannya tidak perlu menyentuh Cargo.toml secara manual: cargo add serde menuliskan baris serde = "..." dengan versi terkini sekaligus mengunduhnya. Setiap crate di sana membawa nomor versi semantik, dan cargo menyelesaikan pohon dependensi — bila dua crate membutuhkan serde versi berbeda, cargo memilih satu yang memenuhi keduanya bila ada. Perintah cargo update me-refresh versi dalam batas caret, sementara cargo build --locked memaksa build persis mengikuti Cargo.lock — jaminan build yang sama di semua mesin.

Mengelola Toolchain dan Komponen #

Kelebihan terbesar rustup adalah pemeliharaan versi. Toolchain hadir dalam tiga kanal — stable yang dirilis tiap enam minggu, beta kandidat rilis berikutnya, dan nightly yang memuat fitur eksperimental — dan semuanya boleh terpasang berdampingan. Proyek pun bisa mengunci kanalnya sendiri lewat file rust-toolchain.toml di akar repositori:

cat > rust-toolchain.toml << 'AKHIR'
[toolchain]
channel = "1.85.0"
AKHIR
cat rust-toolchain.toml

Output yang Dihasilkan:

[toolchain]
channel = "1.85.0"

File dua baris ini dibaca otomatis: begitu kita berdiri di dalam proyek, rustup memakai toolchain yang tertulis, bukan yang menjadi default — jadi satu laptop boleh memelihara proyek stabil dan proyek nightly tanpa saling mengganggu. Di luar toolchain, rustup juga membagikan komponen: rustup component add clippy memasang linter resmi, rustup component add rustfmt pemformat kode, dan rustup target add menambah target kompilasi silang. Mengelola instalasi Rust per-user di Linux dibahas ringkas dari sisi distro di halaman Rust wiki Arch.

Toolchain Rust kini terpetakan utuh: dua jalur instalasi dipahami, anatomi proyek dibedah, dan versi terkelola hingga level proyek. Satu kebutuhan developer masih menganga: sejarah perubahan. Kerangka proyek sebagus apa pun tidak menjawab “apa yang berubah kemarin, dan siapa mengubahnya” — pertanyaan yang dijawab oleh version control, topik Chapter Git dan Version Control .