Tim Rekomendasi Kakao Mengadopsi Rust

Tim rekomendasi Kakao sedang mengembangkan platform baru untuk menggantikan platform machine learning yang ada.

Dengan Python, yang merupakan bahasa utama tim, ada bagian yang agak sulit untuk sekaligus memenuhi performa dan keamanan aplikasi.

Mereka memperkenalkan Rust ke aplikasi metrik pengguna dan menjalankan proses verifikasi untuk menilai apakah implementasi aplikasi dengan Rust memang tepat.

• Rust memproses pekerjaan sekitar 1,9 kali lebih cepat daripada Python
• Penggunaan memori Python sekitar 4,5 kali lebih besar daripada Rust
• Penggunaan CPU Python hingga 3 kali lebih tinggi daripada Rust, dan rata-ratanya sekitar 2 kali lebih tinggi
• Dengan asyncio di Python dan tokio di Rust yang masing-masing diterapkan pada aplikasi tiap bahasa, bahkan dalam lingkungan single-thread dengan pemrosesan asinkron yang diimplementasikan sama, kecepatan pemrosesan pesan Rust sekitar 10 kali lebih cepat daripada Python.

Salah satu kekurangan besar Rust adalah biaya belajar yang tinggi.

Bahkan saat mengembangkan dengan Python, mereka mewajibkan type annotation. Ketika mengimplementasikan aplikasi metrik pengguna dalam dua versi, mereka tidak terlalu merasakan perbedaan besar dalam waktu pengembangan antara Python dan Rust.

Perbedaan yang paling terasa dari sisi produktivitas adalah waktu kompilasi. (termasuk waktu download package dan Docker)

• Rust sekitar 340 detik
• Python sekitar 100 detik

Saat menggunakan Python, data yang dibuat oleh library tanpa informasi tipe akan memiliki tipe Any, sehingga pemeriksaan tipe diabaikan. Hal ini menurunkan akurasi pemeriksaan tipe untuk seluruh proyek.

Ada juga perbedaan seperti Python menggunakan exception, sedangkan Rust menggunakan tipe enum bernama Result.

Alat pengembangan
Untuk Rust, cargo menyediakan banyak fitur secara bawaan.
Alat pengembangan Python sudah sangat matang, dan relatif mudah digunakan hanya dengan instalasi.

[jongpak]

Saya memang tidak punya pengalaman dengan Python maupun Rust, tetapi kalau hanya melihat tulisan itu saja.. saya tidak terlalu merasakan keunggulan besar dari adopsi Rust.

Bukan berarti Rust itu buruk, tetapi eksperimen yang dilakukan untuk mengadopsi Rust juga terasa lemah
(kalau hanya berdasarkan hasil pemrosesan 50 pesan lalu mengklaim beberapa kali lebih cepat berarti beberapa kali lebih baik, menurut saya itu argumennya terlalu lemah..)

Selain itu, perbandingannya juga bukan dengan logika pemrosesan yang sama (sinkron vs asinkron)..
[Library Python yang mendukung pemrosesan pesan asinkron tetapi referensinya tidak banyak] vs [bahasa Rust yang biaya belajarnya tinggi dan punya risiko pemeliharaan karena bergantung pada sedikit orang]
Kalau melihat dua kondisi ini, saya juga ragu apakah aspek keberlanjutan ke depan benar-benar dipertimbangkan secara serius (setidaknya begitu kesan yang saya dapat dari tulisannya)

Karena sifat ETL, sepertinya akan cukup sering ada kebutuhan untuk menguji dengan cepat dan berulang, jadi build time 100 detik vs 300 detik terasa seperti bottleneck besar dalam pengembangan..
Di tulisan itu disebutkan bahwa incremental build sangat unggul, tetapi penjelasannya diganti dengan hyperlink...

Mungkin pada praktiknya mereka memang sudah meneliti dan meninjau dengan sungguh-sungguh, tetapi setidaknya dari tulisan itu sendiri.. saya tidak bisa benar-benar memahami apa yang membaik dengan adopsi Rust, apa efek yang diharapkan, dan masalah apa yang berhasil diselesaikannya, jadi sulit juga untuk merasa sepakat..

---

Secara pribadi, saya pernah melihat kasus ketika teknologi dipilih demi 'teknologi yang sedang naik daun' atau sekadar satu baris tambahan di karier, tetapi pada akhirnya sebagian besar tidak bisa dipelihara di dalam tim dan justru tersisa sebagai utang teknis.

• Misalnya, meskipun workload kecil dan pemrosesan berurutan sama sekali tidak menjadi masalah, tetap ada yang bersikeras harus memakai Kafka atau pemrosesan asinkron
• Hasilnya, karena menerapkan pemrosesan asinkron tanpa mempertimbangkan situasi tim, troubleshooting menjadi sangat sulit dan pada akhirnya berubah menjadi legacy lain....
• Katanya kalau mengadopsi ooo yang sedang populer belakangan ini akan ada manfaat tertentu.. tetapi begitu muncul ooo lain yang lebih panas, lalu mulai bilang yang itu lebih baik lagi..

Tentu saya tidak mengatakan bahwa tulisan tentang Rust di atas seperti itu, dan saya berharap bukan demikian..
Tetapi karena saya sudah berkali-kali melihat bahwa kerugian dari teknologi yang diadopsi tanpa pertimbangan serius pada akhirnya ditanggung oleh anggota tim, saya rasa itu membuat saya menjadi lebih berhati-hati ketika membaca tulisan promosi teknologi seperti itu.

[ehlegeth]

Pada dasarnya ini terlihat seperti tugas ETL; saya penasaran apakah Java, yang juga punya keunggulan bersama Python di domain ini, tidak dipertimbangkan, dan jika memang dikesampingkan dibandingkan Rust, saya ingin tahu alasannya.

[kayws426]

Sebagian materi perbandingan performa diperoleh melalui pengujian skala kecil, jadi masih terasa sedikit kurang memuaskan.

[ehlegeth]

Makna uji performa bisa sangat berbeda tergantung pada sifat workload, jadi cukup disayangkan karena tidak ada penjelasan tentang bagaimana pengujian dirancang atau bagaimana angka-angkanya diperoleh.
Misalnya, saya penasaran apakah rata-rata aritmetika diambil dengan dasar memproses 50 kasus setelah memproses 5 juta kasus, dan jika demikian, bagaimana penggunaan memorinya dihitung, serta bagaimana perbedaan penggunaan CPU diukur. (Untuk waktu, mungkin yang dimaksud adalah wall-clock time, ya?)
Selain itu, ada interpretasi bahwa, 'jika melihat penggunaan CPU, sebagian besar perbedaan performa antara kedua bahasa berasal dari pekerjaan konsumsi pesan Kafka dan penyimpanan dokumen MongoDB, yang merupakan pekerjaan input/output (selanjutnya, IO),' tetapi pada hasilnya disebutkan wall-clock time Rust sekitar 1/2 dan penggunaan CPU (CPU time?) 1/4,5. Jadi agak sulit memahami logikanya: apakah yang dimaksud adalah perbedaan cara implementasi terkait I/O, atau perbedaan dalam proses menangani data target I/O yang bersifat CPU-intensive. Sebenarnya, keunggulan Rust untuk task yang CPU-intensive sudah cukup dikenal, jadi kalau yang dimaksud adalah yang kedua, rasanya tidak terlalu perlu juga menyebut perbedaan library. Malah, kalau dalam eksperimen itu memang pekerjaan yang CPU-intensive, bukankah seharusnya muncul perbedaan yang jauh lebih besar seperti perbandingan implementasi asyncio/tokio yang juga disebut di tulisan tersebut? Saya justru merasa interpretasinya mestinya adalah bahwa karena ada I/O, perbedaan performanya menjadi tidak terlalu besar.