C adalah yang terbaik (2025)
(sqlite.org)- SQLite adalah mesin basis data ringan yang diimplementasikan dalam bahasa C sejak 2000, dan tidak ada rencana untuk menulis ulangnya dalam bahasa lain
- C dinilai sebagai bahasa yang paling cocok untuk SQLite dari sisi kinerja, kompatibilitas, minim dependensi, dan stabilitas
- Bahasa berorientasi objek (C++, Java, dll.) memiliki batasan besar untuk pemanggilan lintas bahasa, dan pendekatan prosedural justru bisa lebih sederhana dan cepat
- ‘Bahasa aman’ seperti Rust atau Go masih belum cukup matang, dan belum sesuai dengan strategi kualitas SQLite (misalnya 100% branch testing, pemulihan OOM)
- Kemungkinan porting ke Rust tetap terbuka di masa depan, tetapi harus memenuhi berbagai syarat seperti kematangan, kompatibilitas, kinerja, dan dukungan alat
1. Mengapa C adalah pilihan terbaik
- SQLite sejak awal pada 29 Mei 2000 diimplementasikan dalam bahasa C standar, dan hingga kini tidak ada rencana untuk beralih ke bahasa lain
- Alasan C cocok untuk implementasi SQLite adalah kinerja, kompatibilitas, dependensi rendah, dan stabilitas
1.1 Kinerja
- SQLite adalah library tingkat rendah yang digunakan secara intensif, sehingga kecepatan sangat penting
- Sebagai contoh, kinerjanya dibuktikan dalam dokumen “Internal Versus External BLOBs” dan “35% Faster Than The Filesystem”
- C memberi kontrol yang dekat dengan perangkat keras sampai sering disebut ‘bahasa assembly yang portabel’, sambil tetap menjaga portabilitas antarplatform
- Bahasa lain mungkin mengklaim “secepat C”, tetapi tidak ada yang mengklaim lebih cepat dari C
1.2 Kompatibilitas
- Hampir semua sistem menyediakan kemampuan memanggil library yang ditulis dalam C
- Misalnya, Android memungkinkan aplikasi Java memanggil SQLite melalui adaptor
- Jika SQLite ditulis dalam Java, maka aplikasi iPhone berbasis Objective-C atau Swift tidak akan bisa menggunakannya
1.3 Dependensi rendah
- Library yang ditulis dalam C memiliki dependensi runtime yang sangat sedikit
- Dalam konfigurasi minimum, SQLite hanya memerlukan fungsi berikut dari pustaka C standar
- memcmp(), memcpy(), memmove(), memset(), strcmp(), strlen(), strncmp()
- Bahkan pada build penuh, yang digunakan hanya malloc(), free(), dan I/O file
- Sebaliknya, bahasa modern menuntut runtime berukuran beberapa MB dan ribuan interface
1.4 Stabilitas
- C adalah bahasa lama dengan sedikit perubahan, sehingga memberikan perilaku yang jelas dan dapat diprediksi
- Saat mengembangkan mesin basis data yang kecil, cepat, dan andal seperti SQLite, penting agar spesifikasi bahasanya tidak sering berubah
2. Mengapa tidak ditulis dengan bahasa berorientasi objek
-
Sebagian pengembang menganggap sistem kompleks hanya bisa dibangun dengan bahasa berorientasi objek, tetapi SQLite tidak demikian
-
Library yang ditulis dengan C++ atau Java pada dasarnya hanya bisa digunakan oleh aplikasi yang ditulis dalam bahasa yang sama
- Sebaliknya, library C bisa dipanggil dari hampir semua bahasa
-
Orientasi objek adalah pola desain, bukan bahasa itu sendiri, dan struktur berorientasi objek juga bisa diimplementasikan dalam C
-
Orientasi objek tidak selalu yang terbaik; dalam beberapa kasus, kode prosedural lebih sederhana dan lebih unggul dalam pemeliharaan maupun kinerja
-
Pada awal pengembangan SQLite (awal 2000-an), Java masih belum matang dan C++ memiliki masalah kompatibilitas antarkompiler yang serius
- Saat itu C jelas merupakan pilihan yang lebih baik, dan sampai sekarang pun hampir tidak ada manfaat nyata dari penulisan ulang
3. Mengapa tidak ditulis dengan ‘bahasa aman’
- Belakangan ini ‘bahasa aman’ seperti Rust dan Go mendapat banyak perhatian, tetapi SQLite tetap dipertahankan dalam C
- Selama 10 tahun pertama SQLite, bahasa aman belum ada
- SQLite memang bisa ditulis ulang dalam Go atau Rust, tetapi ada risiko munculnya bug baru dan penurunan kecepatan
- Bahasa aman menambahkan cabang (branch) tambahan seperti pemeriksaan batas array
- Dalam kode yang benar, cabang tersebut tidak dijalankan, sehingga 100% branch testing menjadi tidak mungkin
- Sebagian besar bahasa aman menghentikan program saat kehabisan memori (OOM)
- SQLite dirancang agar dapat pulih secara normal bahkan dalam kondisi OOM, sehingga perilaku ini bertentangan
- Semua bahasa aman yang ada saat ini masih baru dan berubah dengan cepat
- SQLite lebih memilih bahasa yang lama dan stabil
4. Kemungkinan porting ke Rust
- Ada kemungkinan SQLite ditulis ulang dalam Rust, tetapi porting ke Go hampir mustahil
- Alasannya: Go tidak menyukai assert()
- Prasyarat agar bisa dipindahkan ke Rust
- Rust harus menjadi lebih matang dan lajunya melambat sehingga menjadi ‘bahasa yang lama dan stabil’
- Rust harus bisa menghasilkan library umum yang dapat dipanggil dari semua bahasa
- Rust harus bisa menghasilkan object code yang dapat berjalan pada perangkat embedded tanpa sistem operasi
- Rust harus memiliki ekosistem alat yang mendukung pengujian branch coverage 100%
- Rust harus menyediakan mekanisme pemulihan OOM
- Rust harus membuktikan implementasi dengan kinerja setara C tanpa penurunan
- Pengembang yang merasa Rust sudah memenuhi syarat-syarat di atas dapat langsung menghubungi tim SQLite untuk berdiskusi
5. Kesimpulan
- SQLite adalah mesin basis data yang kecil, cepat, dan andal, dan karakteristik bahasa C selaras dengan tujuan tersebut
- Peralihan ke bahasa berorientasi objek atau bahasa aman tidak memberi manfaat nyata dari sisi kompatibilitas, kinerja, maupun pengelolaan kualitas
- Kesederhanaan dan stabilitas C menopang pemeliharaan jangka panjang dan keandalan SQLite
8 komentar
Lagipula ini proyek yang memang tidak menerima PR, jadi ya... mereka pakai saja apa yang mereka sendiri ingin pakai.
Jika situasinya menuntut sesuatu yang ringkas, tidak ada bahasa yang bisa menggantikan C, C++, atau Rust. Hanya saja, tidak banyak pengembang yang bisa berempati dengan pengembangan sambil mengkhawatirkan overflow atau peretasan pada level bit di struct atau map.
Judulnya terlalu provokatif. Kalau melihat tulisan aslinya, itu adalah artikel tentang mengapa C paling cocok untuk pengembangan sqlite. Semoga semuanya tidak lagi kesal.
Lho, bahkan tulisannya sendiri ternyata sudah ditulis 7 tahun lalu ya? Sepertinya sebagian diperbarui pada 2025 sambil menambahkan isi di bagian belakang... 🤦
Yang penting adalah bisa menilai dan menggunakan bahasa yang sesuai untuk berbagai situasi pengembangan. Memberi judul seperti itu seolah-olah bahasa tertentu selalu yang terbaik menunjukkan tingkat pemikiran setara lulusan SMP...
Menurut saya, keunggulan terbesar C adalah karena ia menyentuh langsung hakikat bahwa "komputer adalah deretan bit". Ada daya tarik pada filosofi C yang sederhana dan
reinterpret castingyang ekstrem, yang membuat pengguna hampir selalu bisa mengetahui akan diterjemahkan menjadi kode mesin seperti apa. Bukan berarti karena itu C bisa dipanggil dari semua bahasa; yang bisa dipanggil adalah ABI, dan di C hal itu hanya karena kita dapat memprediksi (atau memang harus memprediksi) input/output berupa deretan bit seperti apa. Saat membahas kemungkinan implementasi pun, saya rasa penting untuk membedakan apakah sesuatu itu mustahil pada mesin Turing, atau hanya tidak bisa dilakukan dalam bahasa atau framework yang sedang kita pakai sekarang.Opini Hacker News
Saya rasa tidak perlu membenarkan mengapa tidak semua proyek atau programmer memakai Rust atau Zig
Di Hacker News maupun platform lain, ada kecenderungan bahasa-bahasa ini didorong secara berlebihan
Jika hasil dengan C sudah cukup baik dan para pengguna juga puas, tidak ada alasan bagi pihak luar untuk ikut mengomentari
Adalah hal yang alami bagi orang-orang yang tertarik pada perkembangan teknologi untuk mengeksplorasi kemungkinan bahasa baru
Namun meski pihak luar bebas menyampaikan pendapat, proyek tidak punya kewajiban untuk mendengarkannya
Rust memang mengurangi paparan bug, tetapi jenis bug yang sama tetap ada
Pengembang C cenderung lebih peka terhadap race condition, sedangkan di Rust ada risiko terlalu percaya pada anotasi 'aman'
Selain itu, di Rust perbaikannya tidak selalu sederhana sehingga beban refactoring bisa menjadi lebih besar
Pada akhirnya Rust adalah bahasa yang menarik, tetapi bukan obat untuk semua masalah, dan menurut saya tidak boleh dipaksakan
Bahasa seperti Rust atau Zig memang punya niat untuk keluar dari pola objek-oriented tradisional
OOP dulu menarik sebagai kerangka konseptual yang memberi semacam 'pencerahan', tetapi dalam praktiknya sering menambah kompleksitas dan merusak modularitas
Seperti halnya wajar memakai bor listrik alih-alih bor tangan, jika ada alat yang lebih baik maka wajar menggunakannya
Namun alat dan pendidikan untuk menulis kode C yang aman juga perlu berkembang dengan cukup baik
Saya cukup serius sebagai seorang Rustacean, tetapi menurut saya tidak rasional menulis ulang semua proyek ke Rust
Jika proyek C yang sudah teruji dengan baik dipindahkan ke Rust, dalam jangka pendek justru ada kemungkinan bug bertambah
Meski begitu, sebagian orang memang sedang menantang diri untuk menulis ulang ke Rust, misalnya ada Limbo: proyek penulisan ulang penuh SQLite ke Rust
Salah satu keunggulan utama SQLite adalah bisa diakses banyak proses secara bersamaan, dan jika ini hilang maka cakupan pemakaiannya menjadi sempit
Cukup buat sendiri versi baru lalu uji apakah berhasil atau tidak
Saya punya pengalaman memigrasikan RediSearch ke Rust
Itu dilakukan karena belakangan ada banyak kerentanan CVE
Jika SQLite tidak punya masalah seperti itu, alasan untuk pindah ke Rust jadi lemah
Sepertinya butuh puluhan tahun untuk benar-benar memahami kekuatan dan keterbatasan Rust
Khususnya pada aplikasi GUI, kegunaan Rust masih belum jelas
Agar Rust mendapatkan tingkat kepercayaan yang sama, mungkin harus menunggu sampai sekitar 2040
Seperti yang disebut Linus, Rust membutuhkan mekanisme pemulihan OOM (Out of Memory)
Detail terkait bisa dilihat di tautan diskusi LKML
Pada kode embedded atau kernel, fitur alokasi bahkan bisa dimatikan sepenuhnya
Artinya, Rust sebenarnya sudah memberi kendali penuh atas memori
Klaim bahwa “tidak ada bahasa serbaguna yang lebih cepat dari C” adalah perbandingan parsial yang mengabaikan waktu pengembang
Daripada menghabiskan 5 jam dengan C untuk membuat program berdurasi 4 detik, dalam kenyataan bisa saja lebih masuk akal membuat program 5 detik hanya dalam 5 menit dengan bahasa lain
Semakin banyak jumlah pengguna, semakin besar pula nilai akumulatif dari selisih kecepatan yang kecil
Rust masih jauh dari menjadi bahasa yang 'membosankan dan stabil'
C dikelola oleh komite yang konservatif dan sangat menjaga kompatibilitas, sedangkan Rust untuk menyelesaikan masalah lebih mengutamakan inovasi daripada kompatibilitas
Kode dari versi lama tetap bisa terus dibangun dengan compiler baru
Saya rasa ini lebih baik daripada pendekatan seperti C++ yang terus memikul fitur masa lalu
Sebaliknya, bahasa rancangan komite seperti C++ atau Common Lisp menjadi makin kompleks
Rust juga berukuran besar, jadi untuk sistem embedded atau sistem inti penggunaannya harus hati-hati
Saya setuju dengan sikap “jangan merusak sesuatu yang sudah bekerja dengan baik”
Sejarah perkembangan bahasa terasa seperti pengulangan proses memecahkan masalah lalu malah menciptakan kompleksitas baru
C adalah contoh klasik filosofi “Worse is Better”, dan berkat kesederhanaannya ia berhasil selama puluhan tahun
Sebaliknya, Rust mengarah pada “Right Thing™”
Kini beban implementasi langsung sudah berkurang di sebagian besar lingkungan, jadi sekarang itu bisa menjadi pilihan yang lebih baik
Namun tidak perlu memindahkan proyek yang sudah sukses
Untuk proyek baru, kemungkinan besar Rust adalah pilihan yang lebih baik
Kesederhanaan dan stabilitas C adalah keunggulan yang diremehkan
Menurut saya, daripada terus mengubah bahasanya sendiri, lebih baik memoles pustaka standar atau ekosistemnya
Yang penting bukan hanya kesederhanaan, tetapi juga jaminan perilaku deterministik
Misalnya saya menyukai fitur seperti designated initializer, compound literal, alignas, dan memset_explicit
Secara pribadi saya masih menganggap C yang terbaik
Rust punya banyak ide bagus, tetapi juga bahasa dengan kekurangan yang jelas
Saat ini suasananya masih membuat diskusi dingin tentang masalah Rust terasa sulit
Misalnya hal-hal seperti learning curve atau kompleksitas packaging
Pernyataan bahwa “semua sistem bisa memanggil pustaka C” kini sudah tidak benar
Rust dan Zig juga memenuhi kebutuhan itu
Namun pustaka standar Rust sering panic saat OOM alih-alih melakukan pemulihan, dan dokumentasinya juga kurang memadai
extern "C"atauexportagar kompatibel dengan C ABIJika tidak, ABI-nya tidak terdefinisi sehingga justru bisa lebih tidak stabil daripada C++
Masalah ini bisa menjadi lebih besar terutama pada distro Linux yang mendistribusikan crate Rust