Terlepas dari status saya dan bias yang jelas sebagai salah satu pencipta D, saya akan mencoba menjawab dengan jujur; Saya mengikuti jalur Go dan Rust, dan saya benar-benar tahu di mana cucian kotor dicuci di D. Saya mendorong orang-orang di posisi yang sama di komunitas Rust dan Go untuk berbagi pendapat. Jadi disini.
Sebagai permulaan, suatu tempat di pertanyaan itu akan muncul C ++. Apakah itu harus diganti dengan C, atau apakah itu salah satu kandidat untuk mengganti C, tetapi dalam kasus apa pun, C ++ adalah elemen kunci dari persamaan. Ini adalah bahasa terdekat dengan C dan langkah maju yang jelas. Mengingat usia C ++, saya lebih jauh menganggap dalam hal ini bahwa C ++, bersama dengan C, adalah tujuan untuk penggantian.
Setiap bahasa memiliki sejumlah keunggulan mendasar (saya menyebutnya "urutan keunggulan yang besar", selanjutnya disebut sebagai "bonus 10x", karena mereka memenuhi syarat di liga utama sehubungan dengan pendekatan khas), dan sejumlah masalah. Masa depan bahasa-bahasa ini dan keberhasilan mereka dalam mengalahkan C tergantung pada bagaimana mereka secara strategis mengerahkan 10x bonus mereka dan bagaimana cara mengatasi masalah mereka.
Biarkan aku menyingkirkan D dulu
Jelas ini adalah demonstrasi rumah saya sendiri, jadi saya tahu ke mana harus pergi untuk menunjukkan dengan benar hanya apa yang dibutuhkan dan menyembunyikan tempat-tempat kotor. Saya juga dapat berbicara lebih banyak tentang D daripada pasangan lainnya, karena alasan sederhana bahwa saya mengenalnya lebih baik. Berbicara dengan lugas, masalah utama D adalah:
- Penerimaan yang buruk oleh publik setelah bertahun-tahun keberadaannya nominal. Umur panjang masyarakat dapat mengkritik pernyataan seperti itu (D dalam bentuknya saat ini relatif muda, popularitas tumbuh, dll). Tapi sikap ini terus berlanjut dan mempengaruhi pertumbuhan popularitas lebih lanjut dan ini adalah fakta. Akibatnya, manajer dan insinyur skeptis tentang mempopulerkan bahasa yang telah lama merugi. Selain itu, waktu bekerja melawan D sampai tidak ada peningkatan popularitas yang jelas.
- Kisah sedih D terkait pengumpulan sampah (GC). GC adalah penemuan yang hebat, tetapi keputusan untuk menggunakannya dalam D langsung mengisolasinya dari audiens target utama - programmer C dan C ++. Bagi mereka, garis partai tampak seperti “Tidak ingin GC? Tidak masalah! Anda juga dapat menggunakan D dengan RAII atau dengan kontrol manual! ” Terlepas dari kenyataan bahwa secara umum ini benar, pendekatan ini praktis tidak berguna karena kurangnya dukungan untuk perpustakaan standar seperti itu, yang berarti bagi pengguna yang dimaksudkan untuk dilucuti ke celana pendek dan mulai dengan penciptaan infrastruktur dasar. Bahkan bagi mereka yang tidak keberatan dengan GC, kualitas implementasinya agak tidak menarik. Secara umum, kita dapat mengatakan bahwa D mendapatkan semua kekurangan dari GC, tetapi tidak mengambil keuntungan.
- Kurangnya visioner yang ada secara historis. Karena tidak mendapat dukungan perusahaan, D memimpin masyarakat maju, di mana lebih mudah menemukan insinyur yang cerdik daripada manajer proyek atau pemimpin karismatik. Seiring waktu, keberhasilan upaya D dalam promosi dan promosi diri telah membuahkan hasil negatif. Dokumen perencanaan pertama bertanggal 1 Januari 2015, dan iterasi berikutnya (Visi / 2015H2 - D Wiki) keluar empat bulan lebih lambat dari yang direncanakan, yang merupakan contoh bagus dari ironi diri dalam hal perencanaan
Tentu saja ada masalah-masalah lain, tetapi mereka juga merupakan konsekuensi dari yang di atas, atau memiliki konsekuensi yang jauh lebih kecil.
Saya pikir bonus 10x untuk D adalah sebagai berikut (sekali lagi, ketika saya mengatakan 10 kali, ini bahasa sehari-hari "lebih baik dengan pesanan"):
- Dalam 10x, kompilasi lebih cepat daripada C ++ untuk kode yang sebanding. Lubang ini tidak dapat ditutup secara mendasar dalam C ++, dan sangat sulit untuk melompat dalam bahasa lain. (Go mengkompilasi sedikit lebih cepat daripada D, tetapi kode yang dihasilkan lebih lambat) Pengalaman menggunakan bahasa sistem yang mengkompilasi begitu cepat ke dalam kode cepat adalah transformatif dari praktik lama dan sangat menjanjikan. Dikombinasikan dengan kekuatan abstraksi dalam D, ini pada dasarnya membuat D pilihan yang baik untuk menulis kode yang sangat optimal karena alasan sederhana bahwa bereksperimen itu murah.
- 10x lebih cepat dari bahasa scripting dengan fasilitas yang sebanding. D sangat cocok untuk tugas sehari-hari scripting nyaman. Siklus kompilasi / peluncuran tetap sama cepat, dan manfaat dalam kecepatan sangat besar. Juga, tidak ada masalah "lari ke batas" - jika skrip menjadi besar, di D selalu ada cukup alat bahasa dan modularitas. Tentu saja ada lalat di salep, misalnya di Python ada banyak perpustakaan yang sudah jadi. Tetapi bonus 10x sangat mendasar di sini - bahasa sistem tidak memiliki begitu banyak gula sintaksis, dan bahasa skrip sangat tertinggal dalam hal kecepatan.
- 10x lebih mudah untuk diintegrasikan dengan C dan C ++ daripada bahasa lainnya. D menggunakan struktur yang sama dalam memori seperti C dan C ++; dan dibangun di atas mereka, tetapi membaca lapisan yang mendasarinya tetap gratis dalam hal kecepatan. Pustaka C standar dapat diakses sepenuhnya tanpa penalti - baik dalam hal kecepatan, maupun dalam sintaksis, dan meskipun beberapa perbaikan diperlukan untuk kesederhanaan serupa dalam hal pustaka C ++, banyak pustaka C sudah tersedia (https://github.com/D- Pemrograman ...). Dapat dinyatakan secara harfiah bahwa tidak ada bahasa lain yang dapat mencapai tingkat integrasi ini.
- 10 kali lebih baik daripada bahasa sistem lainnya dalam generik dan metaprogramming. Dalam D, introspeksi statis, compile-time computing (CTFE), dan pembuatan kode berbasis-campuran (pencampuran-kode) membentuk koktail Molotov, yang sangat sulit untuk bercampur dengan benar dalam bahasa lain, baik yang baru maupun yang selamat; dalam game ini Go sangat gila sehingga bahkan tidak memotong chip; C ++ 17 hilang tanpa harapan di hutan yang gelap; dan Rust hanya mencoba mengoceh.
Pergi ke Pergi
Saya harus menekankan bahwa ini semata-mata pendapat saya, namun patut Anda perhatikan. Masalah Go adalah sebagai berikut:
- Perlambatan mendasar karena panggilan tidak langsung dan pengumpul sampah (GC). Hampir tidak ada aplikasi Go yang signifikan yang dapat ditulis tanpa menggunakan panggilan tidak langsung dan GC, yang merupakan fungsi pusat. Ini adalah hambatan utama untuk kinerja inti Go. Respons Go sebagian besar bersifat taktis - misalnya, meningkatkan kinerja GC. Namun, tidak mungkin untuk memenangkan tantangan mengganti C secara taktis.
- Politik. Garis partai di Go sangat kuat dan tangguh dalam sejumlah masalah, baik kecil maupun besar. Salah satu contoh masalah besar adalah bahwa pendekatan terhadap obat generik sangat tidak berarti dan kejam sehingga membuat obat generik kata dengan huruf "G"; seluruh topik berubah menjadi air mata berdarah, menghalangi setiap upaya untuk membangun dialog yang konstruktif. Saya pikir mempolitisasi masalah teknis dalam jangka panjang adalah model yang sangat merugikan, dan saya berharap Go akan menemukan cara untuk memperbaikinya.
- Kesederhanaan lebih buruk daripada pencurian. Pergi sangat sederhana (permainan kata-kata, Jalan-jalan, perhatikan) - bahkan ada lelucon tentang itu. Namun, seiring waktu hal ini menjadi bermasalah; Go code adalah pedestrian yang putus asa - Go coders mendapati diri mereka sendiri menulis hal yang sama berulang-ulang dari sudut pandang semut, karena Go tidak dapat mengabstraksi konsep atau algoritma yang paling sederhana sekalipun. Konsep yang belum diimplementasikan oleh perpustakaan integrasi sulit untuk diimplementasikan. Ada reaksi negatif dari programmer yang menggunakan Go untuk satu proyek dan tidak lagi ingin menggunakannya lagi. Alangkah baiknya jika Go membuat hidup lebih baik bagi pelanggan reguler.
Bonus Go 10x dalam persepsi saya adalah sebagai berikut:
- Strategi keterampilan 10x. Setelah periode singkat ketika Go diposisikan sebagai bahasa sistem, diputuskan untuk memposisikannya untuk layanan jaringan. Itu adalah langkah pemasaran hebat yang memanfaatkan kekuatan tim Go (beberapa insinyur layanan jaringan terbaik di dunia). Ini adalah pasar yang sangat panas dan Go baru saja menghirup udara segar bagi dunia, yang sebelumnya didominasi oleh Java EE dengan birokrasi dan bahasa scripting yang lambat. Sekarang Go adalah pemain utama di area ini dan akan sulit untuk bergerak.
- 10x dalam skill Engineering. Go memiliki tim insinyur yang kuat di belakangnya, dan ini adalah faktor utama yang mempengaruhi kualitas bahasa, dan khususnya perpustakaan jaringan dan perangkat. Sejauh ini, teknik yang baik telah sepenuhnya menggantikan kelemahan bahasa.
- 10x dalam keterampilan Branding. Banyak dari kita siap untuk mengakui bahwa motivator utama untuk menggunakan Go adalah hubungannya dengan Google. Ini memberinya otoritas profesionalisme, kualitas dan stabilitas. Tentu saja, merek bukanlah segalanya, tetapi sudah menjadikan Go bahasa yang layak; dia seharusnya tidak terlalu baik. Merek akan melakukan sisanya.
Terakhir, Rust
Biarkan saya mengingatkan Anda lagi bahwa ini hanya pendapat saya. Saya pikir Rust menghadapi beberapa masalah menarik:
- Kepribadian yang tidak harmonis. Setelah membaca sejumlah kode Rust, anekdot seperti “Bung melewatkan hari-hari berayun kaki” muncul, diilustrasikan dengan komik - komik dengan orang-orang dengan tubuh dan kaki bersilang (kira-kira Terjemahan. Dalam bahasa Rusia, “Colossus dengan kaki tanah”, tetapi tidak akurat) Rust menempatkan Rust Manajemen memori yang akurat dan aman diutamakan dan itu merupakan pusat dunia. Tiba-tiba, ini jarang menjadi masalah, yang mengarah pada fakta bahwa sebagian besar perencanaan dan pengkodean dikhususkan, pada kenyataannya, untuk pekerjaan administrasi (yang bahasa dengan GC diotomatiskan tanpa melihat). Penggunaan kembali memori yang aman dan telah ditentukan sebelumnya adalah tugas yang serius, tetapi bukan satu-satunya, atau setidaknya bukan yang paling penting dalam program. Akibatnya, Rust menghabiskan sumber daya desain bahasa yang tidak proporsional hanya untuk itu. Akan menarik untuk melihat bagaimana Rust membengkak untuk aspek lain dari bahasa tersebut; satu-satunya pilihan adalah memperluas bahasa, tetapi pertanyaannya adalah seberapa banyak abstraksi dapat membantu dengan kebutuhan yang tidak menyenangkan untuk mengendalikan sumber daya di semua tingkatan.
- Sintaks asing. Sintaks Rust berbeda [dari semua], tetapi tidak ada keuntungan yang jelas dalam eksotisme semacam itu. Ini mengganggu orang-orang yang berasal dari bahasa keluarga Algol, yang harus berurusan dengan sintaks yang sangat berbeda, di samping kebutuhan untuk mengelola secara manual semua akuntansi dengan sumber daya.
Bonus 10x Rust adalah:
- 10 kali ahli teori terbaik. Dari ketiganya, hanya Rust yang memiliki ahli teori kelas dunia dalam mengembangkan bahasa pengkodean. Hal ini dapat dilihat dari keakuratan deskripsi teknis bahasa dan kedalaman pendekatan teknis.
- 10x lebih banyak keamanan daripada bahasa sistem lainnya. Tentu saja, ini seharusnya ada di sini, kita hanya dapat memperdebatkan biaya dari pendekatan ini.
- 10 kali PR terbaik (PR, iklan, kira-kira Per.) Ada periode yang agak lama ketika Rust adalah favorit komunitas, yang tidak dapat salah: untuk masalah apa pun, Rust entah punya solusi atau harus mendapatkannya dengan rilis 1,0. Realitas rilis 1.0 mengganggu bulan madu ini dan ditandai (dalam ukuran dan harapan saya) oleh penurunan tajam dalam minat umum, meskipun faktor-faktor ini cenderung memperpanjang. Plus, pada akhirnya, Rust adalah bahasa yang layak dengan prestasi nyata, dan ia berada dalam posisi yang baik untuk mengubah hype yang berlarut-larut ini menjadi pasar yang stabil.
Secara singkat
Apakah salah satu dari bahasa ini mampu menggantikan C, C ++, atau kedua bahasa secara bertahap dalam sistem perangkat lunak yang ada, dan apakah bahasa-bahasa ini akan menjadi prioritas untuk proyek-proyek yang saat ini memilih C atau C ++ secara default, semua tergantung pada kemampuan bahasa-bahasa ini untuk menggunakan keuntungan mereka dan menemukan solusi kreatif untuk masalah mereka masing-masing.
Catatan penerjemah.Maaf untuk artikel lama, saya baru saja menemukannya di akhir seri tentang pemrograman yang andal, dan sepertinya cukup menyenangkan untuk dikutip. Namun, di RuNet, terjemahan, dan memang diskusi lengkap, tidak ditemukan.