CTO Azure: "Kini saatnya berhenti memulai proyek baru dengan C/C++"

• Jika ada skenario yang benar-benar membutuhkan bahasa tanpa GC, gunakan Rust
• Demi keamanan dan keandalan
• Industri harus menyatakan C/C++ sebagai bahasa yang deprecated

[ahwjdekf]

Bahkan orang-orang yang selama ini memuji dan memakai Rust pun katanya langsung kena reality check begitu berhadapan dengan async. Bahkan ada juga keluhan seperti, apakah dengan Rust kita malah tidak disarankan membuat library (karena terlalu rumit, rewel, dan sulit).

[kernel00]

Ada juga orang yang meremehkannya tanpa tahu siapa Mark Russinovich... dia adalah penulis sysinternals tool suite dan buku Windows Internals... orang yang merekayasa balik Windows untuk membuat berbagai tool lalu menjadi Microsoft Fellow...

[ahwjdekf]

Tulisan yang menyindir masalah para fanatik Rust lewat video pendek

https://twitter.com/cmuratori/status/1367627549816152064?lang=en

[ahwjdekf]

Rust bahkan sampai sekarang belum punya specification resmi juga ....

[functor]

C++ memang punya spesifikasi resmi yang "ada", tetapi semua implementasinya (gcc, clang, ...) masih belum lengkap.

[lifthrasiir]

Ini argumen yang umum, tetapi dari sudut pandang orang yang benar-benar sudah banyak membaca spesifikasi dan juga beberapa kali membuat implementasi, saya kurang paham apa arti penting ada atau tidak adanya spesifikasi itu sendiri.

Dalam "spesifikasi" ada berbagai strategi. Ada cara yang berfokus pada perilaku yang tampak dari luar dan ada cara yang menjelaskan perilaku internal; lalu ada pemisahan antara penggunaan bahasa alami dan metode yang dapat dibaca mesin (seperti pseudocode atau definisi matematis). Hal seperti dokumen referensi bahasa Python atau Rust adalah spesifikasi yang menjelaskan perilaku yang tampak dari luar dengan bahasa alami. Pendekatan yang umum terlihat pada standar ISO dan semacamnya adalah spesifikasi yang menjelaskan perilaku internal dengan bahasa alami, tetapi tidak ada jaminan bahwa perilaku internal ini selaras dengan pendekatan implementasi yang nyata; sebagai gantinya, kesesuaiannya dengan standar didefinisikan dengan cara seperti ini: jika implementasi virtual hipotetis yang dibangun dari perilaku internal tersebut dan implementasi nyata saling bertindak sama dari luar, yakni observationally equivalent, maka implementasi itu dianggap sesuai dengan standar. ECMAScript memang dijelaskan dengan bahasa alami, tetapi struktur nyatanya pada dasarnya setara dengan pseudocode yang ditulis dalam bahasa alami, dan ada juga kasus seperti WebAssembly yang menyediakan perilaku internal baik dalam spesifikasi bahasa alami maupun definisi matematis.

Dari sudut pandang implementasi, spesifikasi bahasa alami kurang lebih sama saja. Karena spesifikasi bahasa alami harus dibuat terpisah dari implementasi nyata, secara alami keduanya bisa saja saling menjauh, dan kesalahan juga cukup sering terjadi. Apakah perilaku yang tampak dari luar lebih mudah diimplementasikan atau perilaku internal lebih mudah diimplementasikan, itu berbeda tergantung situasinya; dari sudut pandang bahasa pemrograman, tidak ada alasan yang benar-benar mengharuskan memilih salah satunya. Dalam arti itu, Rust pada dasarnya sudah memiliki spesifikasi, dan memang benar bahwa spesifikasi tersebut menyediakan informasi yang cukup sampai-sampai implementasi alternatif lain bisa muncul.

Kalau Anda ingin menilai kematangan standar hanya dari apakah sudah menjadi standar ISO atau belum, saya bisa memberi tahu kabar bahwa saya menemukan sekitar 100 bug di standar ISO/IEC 18181-1 JPEG XL (dan karena itu 2nd amendment-nya sedang tertunda)...

[xguru]

Di Hacker News juga ada lebih dari 800 komentar.. di sini juga panas ya...
https://news.ycombinator.com/item?id=32905885

[kayws426]

Terima kasih atas kerja kerasnya.
Di sisi lain... saya pernah membaca tulisan yang mengatakan bahwa ketika mencoba menafsirkan reaksi seseorang saat sesuatu yang ia sukai diserang, kita perlu berhati-hati agar tidak menyalahkannya pada kepribadian orang tersebut, dan saya pikir itu adalah perkataan yang bagus, karena dalam situasi nyata kemungkinan besar memang sulit untuk memiliki sikap seperti itu.

[ahwjdekf]

Ada komentar di tweet yang cukup mengesankan.

Orang-orang akhirnya menulis kode Rust dengan cara yang "unsafe". - dipotong - Rust memang sejak awal tidak pernah dimaksudkan untuk menggantikan hal-hal itu.

[kayws426]

Untuk bagian ini, saya lampirkan tautan agar orang bisa mengetahui siapa Mark Russinovich.
https://en.m.wikipedia.org/wiki/Mark_Russinovich

[ahwjdekf]

Saya tambahkan satu hal lagi. Orang-orang yang saat memakai C++ terus membuat error dan bug lalu bilang, “Wah, ini tidak bisa dipakai, mending pindah ke Rust yang katanya lagi naik daun... Katanya tidak perlu pusing soal error memori...” orang seperti ini ya tetap sama saja. Dengan Rust pun mereka akan membuat bug yang mirip-mirip juga... Lalu setelah itu mereka akan bilang lagi, bahasa apa lagi ya yang harus dipelajari berikutnya. Orang-orang yang bahkan belum pernah benar-benar mencoba dereferensi pointer di C++ itulah yang terus memuja-muja Rust.

[ahwjdekf]

Orang-orang seperti itu akan mengabaikan begitu saja hal-hal seperti ownership, reference, borrowing yang diklaim Rust sebagai keunggulannya karena sejak kompilasi sudah memunculkan error dan merepotkan, lalu mencampur unsafe dan memakainya sembarangan seolah-olah itu C++.

[functor]

Kalau toh tetap akan mati, kenapa harus hidup?
Logikanya hampir setara dengan ini

[budlebee]

Rasanya seperti melihat argumen bahwa karena orang yang memang suka bikin masalah toh juga tidak memakai sabuk pengaman dan mengabaikan lampu lalu lintas, maka sabuk pengaman dan lampu lalu lintas tidak ada banyak artinya.
Memang bisa saja dikatakan bahwa orang yang hebat akan tetap hebat apa pun yang dipakainya, dan orang yang tidak mampu akan tetap tidak mampu apa pun yang dipakainya, tetapi kalau logikanya dibawa ke sana, pembahasan tentang kegunaan alat jadi tidak bisa dilakukan.

[cr543l]

Masalahnya memang bahasa itu terlalu sulit untuk digunakan, jadi memang ada benarnya juga.

[iolothebard]

Saya akui kalau visual rust sudah keluar -.-k

[binaryeast]

C/C++ sekarang benar-benar tampaknya menuju posisi seperti bahasa Latin. Untuk kepentingan akademis, semua orang sebaiknya mempelajarinya, tetapi untuk dikuasai itu nyaris mustahil, dan karena ini sistem lama, jika dilihat dari konteks sekarang ada banyak bagian yang juga terasa tidak rasional...

[dalinaum]

Lucu juga bagaimana mereka nyaman memakai bahasa yang semuanya unsafe, tetapi untuk bahasa yang memungkinkan unsafe dipakai secara terbatas, kenapa justru dianggap sama sekali tidak boleh.

[functor]

Saya rasa ini semacam Stockholm syndrome.

[williameom]

The Spirit of C

1. Percayalah kepada programmer.
2. Jangan mencegah programmer melakukan apa yang perlu dilakukan.
3. Pertahankan bahasa tetap kecil dan sederhana.
4. Sediakan hanya satu cara untuk melakukan suatu operasi.
5. Buatlah cepat, meskipun portabilitasnya tidak dijamin.

[functor]

Menurut saya pribadi, sepertinya poin nomor 1 sudah keliru dari awal wkwk, karena manusia pada dasarnya memang rentan melakukan kesalahan..

[heal9179]

C++ juga cukup dengan aktif menggunakan smart pointer dan memory pool, jadi..
Menurut saya, ternyata tidak terlalu banyak hal yang mengharuskan kita menangani pointer secara langsung.

Saya pikir kode yang thread-safe pada akhirnya bergantung pada kemampuan programmer itu sendiri.
Apa pun bahasa yang digunakan, kalau kemampuannya kurang bagus,
biasanya akan terlihat pola performa yang aman tetapi rendah, atau kode yang berbahaya.

[hiyama]

Terlalu menakutkan jika kita mempercayakan kemampuan programmer untuk mengemudikan mobil atau menerbangkan pesawat....

[functor]

Kode yang thread-safe pada akhirnya bergantung pada kemampuan programmer itu sendiri <- menurut saya pemikiran ini berbahaya, karena memory / thread safety bukan sekadar soal program crash atau melambat, tetapi bisa berkembang menjadi kerentanan keamanan, jadi menurut saya hal ini tidak boleh diserahkan pada kemampuan individu semata.
Berbagai cara untuk mencegahnya sejak awal sudah lama diteliti, dan ketika pendekatan-pendekatan itu matang, lahirlah bahasa seperti Rust dan berbagai alat lain; menurut saya, dampak software terhadap kehidupan sehari-hari kini sudah terlalu besar untuk mengabaikan semua itu lalu menyalahkan individu.

[mastotron]

Manusia tetaplah manusia, jadi pasti bisa melakukan kesalahan, dan secerdas apa pun programmer, mereka tetap bisa berbuat salah. Bug memori pada akhirnya juga muncul dari kesalahan semacam itu...

Belakangan ini, rasanya pendekatan yang lebih baik bukanlah mengandalkan orang untuk selalu melakukannya dengan benar, melainkan sejak awal menyediakan lingkungan yang membuat kesalahan lebih sulit terjadi.

[ahwjdekf]

Kalau ingin memakai Rust di perusahaan kami, unsafe dilarang digunakan. Setidaknya harus ada aturan seperti ini supaya kita bisa sedikit percaya pada keamanan yang didukung di level bahasa. Tapi, apakah ini masuk akal?

[mastotron]

Tentu saja, di perusahaan yang menggunakan Rust kemungkinan ada kesepakatan bahwa unsafe tidak boleh dipakai kecuali benar-benar diperlukan. Daripada itu, saya justru menyarankan Anda untuk langsung mencoba menulis dengan Rust... Bukankah untuk mengetahui seberapa sering Anda benar-benar perlu memakai unsafe, Anda harus mencobanya sendiri terlebih dahulu?

[ahwjdekf]

Di library yang cukup terkenal seperti tokio, juga ada banyak penggunaan unsafe.

[novemberoscar]

Cukup banyak komentar yang tampaknya melihatnya sebagai all or nothing, seolah kalau bukan All maka tidak ada nilainya sama sekali

Ada kelebihan karena unsafe / safe bisa dibedakan dan diisolasi secara eksplisit, dan orang yang tadinya akan membuat 100 bug memori bisa dibuat hanya membuat 10 bug, tetapi bagaimanapun juga karena unsafe itu ada / bug memori tetap bisa terjadi => lalu disimpulkan bahwa karena itu tidak ada yang lebih baik dibanding C++, saya pribadi tidak yakin apakah pendekatan seperti itu merupakan penilaian yang realistis 😅

[ruinnel]

Dilihat dari jumlah komentarnya memang begitu.....
Tapi sepertinya yang lebih tepat adalah banyak komentar ditulis oleh satu orang dengan pendapat all or nothing...

[csjune]

Saya juga setuju dengan komentar ini. Semakin kita melihat sesuatu secara dikotomis, pada akhirnya yang rugi hanya diri sendiri.

Di dunia kerja, orang biasanya menimbang kelebihan dan kekurangannya lalu memilih yang hasil akhirnya paling menguntungkan. Mengingat karakteristik industri, jika bukan karena memang saat ini tidak punya pilihan selain memakai C/C++, saya rasa area penggunaan Rust makin meluas karena manfaat yang didapat saat memakai Rust lebih besar.

Orang-orang yang beralih ke Rust juga bukan bodoh; kalau setelah mencobanya mereka merasa hasil akhirnya lebih baik daripada C++, ya wajar saja mereka terus memakainya hehe

[alstjr7375]

Tidak ada... Semuanya

[functor]

Sekarang mungkin sudah jarang ada orang yang tidak setuju bahwa Rust adalah Next C++. Sampai-sampai bahasa ini sudah diadopsi sebagai bahasa resmi di kernel Linux.
Namun, apakah Rust benar-benar bahasa yang nyaman digunakan masih agak meragukan... Berkat analisis statis yang dilakukan untuk mencegah masalah keamanan memori sejak awal, waktu kompilasinya cukup menyakitkan, dan karena semantik seperti ownership itu sulit, bahasa ini menuntut pembelajaran yang jauh lebih banyak dibanding bahasa serbaguna seperti Python atau Java.

[dalinaum]

Waktu kompilasi kemungkinan besar memang masalah besar pada LLVM itu sendiri. Karena Facebook berupaya meningkatkan instruction selection di LLVM, situasinya mungkin akan membaik.

[functor]

Setelah saya cek, memang benar begitu. Saya kira banyak waktu dihabiskan untuk type check terkait ownership, ternyata backend LLVM cukup besar juga..

[ahwjdekf]

Saat rust pertama kali muncul, saya sangat tertarik dan sempat mempelajarinya... tetapi begitu melihat bagian unsafe, saya langsung berhenti. Saya benar-benar tidak bisa diyakinkan secara rasional kenapa harus belajar dan memakainya. Toh program yang sedikit saja lebih kompleks pada akhirnya harus menggunakan unsafe. Kalau begitu, stabilitas yang begitu dibanggakan rust juga hilang. Lalu, kenapa harus memakainya?

[mastotron]

Di Rust, unsafe hanya diperlukan saat menulis kode level rendah, jadi untuk menulis aplikasi umum bisa dibilang hampir tidak ada kebutuhan untuk memakainya.

Dan meskipun terjadi masalah memori di dalam blok unsafe, ada kelebihan bahwa secara bahasa sudah dijamin bagian yang bermasalah berada di dalam blok unsafe, sehingga debugging bisa dilakukan dengan lebih mudah.

[functor]

Kalau mau bertanya, karena ada unsafe, "ngapain pakai ini?", bukannya dari awal memang tidak seharusnya pakai C/C++?

[ahwjdekf]

C++ juga terus berevolusi, dan kalau toh akan memakai sesuatu yang unsafe, rasanya lebih baik langsung pakai C++; jadi saya tidak benar-benar merasakan perlunya belajar lalu menggunakan Rust.

[functor]

Tidak semua pemrograman Rust memerlukan unsafe.
Manipulasi memori yang sangat teliti hingga membutuhkan unsafe biasanya sudah dipisahkan ke pengembangan library, jadi saya rasa di sisi pengembangan aplikasi—yang mungkin paling banyak kebutuhannya—hampir tidak akan ada alasan untuk memakai unsafe.
Memang benar C++ juga terus berevolusi, tetapi legacy demi kompatibilitas ke belakang itu terlalu menyakitkan. Kalau Anda sampai tidak puas hanya karena satu unsafe, rasanya Anda juga akan tidak puas dengan semua fitur di C++ haha

[alstjr7375]

Jadi unsafe memang tidak direkomendasikan.
Kalau memakai yang safe, semuanya lebih aman dibanding C/C++ yang pada dasarnya sama-sama unsafe.
https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf

[ahwjdekf]

Tanpa perangkat yang samar dan ambigu seperti unsafe, Rust mungkin bisa menjadi alternatif sejati untuk C++.

[jjpark78]

Saya berharap FFI sedikit lebih ramah.. Saya pernah mencoba bertukar struct kompleks dengan library eksternal lewat FFI, dan ingatan itu sangat menyakitkan.

[alstjr7375]

Bahkan rust to rust pun tidak mudah.. https://github.com/rodrimati1992/abi_stable_crates

[jjpark78]

Melihatnya sebagai kelanjutan dari situasi di mana Microsoft secara aktif mendukung Rust, pernyataan ini tampak sangat wajar.

[colus001]

Bahkan Torvalds yang keras kepala itu pun sudah mengadopsi Rust, jadi saya tidak merasa perlu terus memakai bahasa yang bahkan makin sedikit orang yang mau mempelajarinya.

[ahwjdekf]

Bug terkait memori tidak akan pernah hilang begitu saja hanya karena memakai Rust. Orang yang membuat bug akan tetap memproduksi bug massal, apa pun bahasanya. C++ sedang dipakai dengan efisien dan baik-baik saja tanpa masalah, jadi kenapa harus dihapus. Benar-benar sembarangan melontarkan pernyataan bombastis seperti bom yang bisa memicu perang.

[functor]

Sulit mengatakan bahwa C/C++ telah digunakan dengan efisien dan baik-baik saja tanpa masalah, karena secara historis sudah sangat banyak bug terkait memori yang meledak di C/C++, dan mungkin masih terus terjadi di suatu tempat hingga sekarang. (Berkat itu, banyak peneliti PL/SE juga jadi bisa mencari nafkah.)
Menurut pengumuman Microsoft, 70% bug keamanan terkait dengan bug memori (https://zdnet.com/article/…)
Hasil investigasi dari proyek Chromium juga serupa (https://www.chromium.org/Home/chromium-security/memory-safety/), dan lagi-lagi hampir 70% merupakan bug terkait memori.

[jjpark78]

Sebagian besar bug kernel Windows adalah error terkait memori,
dan saya pernah membaca artikel lama yang mengatakan bahwa pada bagian yang dikembangkan dengan Rust, error semacam itu berkurang secara drastis..

Karena sejak awal bahasanya sendiri dirancang untuk sangat menganjurkan readonly, rasanya sulit untuk menyangkal bahwa secara desain bahasa, ini lebih aman daripada C++. Namun karena itu juga muncul konsep ownership yang sebelumnya nyaris tak pernah terdengar, sehingga pemrograman jadi lebih sulit.

Ada juga keunggulan performa bahwa, secara statistik, kode Rust yang dibuat seadanya berjalan lebih cepat daripada kode C++ yang dirancang dengan sangat baik.

[lordang]

Sepertinya dia mengatakan sesuatu yang bisa memicu kontroversi. wkwk
Secara pribadi, menurut saya karena C++ sudah terlalu tua, perkembangannya ke arah yang modern jadi lambat karena terhambat kompatibilitas mundur.
Selain itu, karena tetap mempertahankan kompatibilitas mundur secara ketat sambil memasukkan hal-hal modern, jadi ada terlalu banyak cara untuk melakukan hal yang sama, dan menurut saya itu menjadi hambatan masuk yang lebih besar bagi pemula.
Saya juga sekarang merasa Rust lebih baik daripada C++. Sudah saatnya mengakhiri masa-masa mata memerah karena mencari bug terkait manajemen memori.

[jjpark78]

Ya, benar.. kalau ini proyek pengembangan yang dimulai benar-benar dari nol, memang tidak ada alasan khusus untuk memilih C++..

[kandk]

Sangat setuju

[loblue]

Meski ingin memakai Rust, pada praktiknya sejauh ini saya hanya memakainya sebagai pendamping dan belum ada kebutuhan untuk memakainya dalam pekerjaan. Jadi rasanya juga sulit untuk benar-benar terbiasa, dan kalau sempat tidak menyentuhnya sebentar saja jadi lupa lagi... Jelas saya suka dan memang ingin memakainya... hehe

[koreacglee]

Orang-orang yang bahkan belum pernah menulis memory pool sekali pun demi efisiensi penggunaan heap malah ribut banget soal RUST haha
Azure CTO tentu saja bukan opini yang cukup mewakili standar industri, dan bahkan jika dibatasi ke Microsoft pun sama sekali bukan opini yang mewakili posisi Microsoft; paling banter cuma karena tiba-tiba lagi kumat lalu mengocehkan pemikiran subjektifnya sendiri... Kalau orang-orang yang tidak benar-benar bisa C++ pindah ke Rust, apa mereka bakal jadi jago juga? Pokoknya penuh dengan orang-orang yang cuma omong doang.

[functor]

Dari cara bicara Anda saja, kesan vulgar itu terlihat jelas tanpa ada yang ditutupi. Tetap semangat.