Kritikan terperinci terhadap bahasa pengaturcaraan Go telah mencetuskan perdebatan sengit dalam komuniti pembangun, menonjolkan isu-isu berterusan yang telah melanda bahasa ini selama lebih sedekad. Perbincangan tertumpu pada keputusan reka bentuk asas yang dikritik oleh pengkritik sebagai boleh dielakkan dan berpunca daripada pengajaran yang telah dipelajari oleh komuniti pengaturcaraan.
Isu Pengendalian Ralat dan Skop Pemboleh Ubah
Salah satu aspek yang paling kontroversial melibatkan mekanisme pengendalian ralat Go dan peraturan skop pemboleh ubah. Bahasa ini memaksa pembangun ke dalam situasi janggal di mana pemboleh ubah ralat kekal dalam skop lebih lama daripada yang diperlukan, mewujudkan potensi kekeliruan dan pepijat. Tidak seperti bahasa lain yang membenarkan kawalan yang lebih tepat ke atas jangka hayat pemboleh ubah, had sintaks Go menghalang pembangun daripada meminimumkan skop pemboleh ubah dalam corak biasa tertentu. Pilihan reka bentuk ini menjadikan kod lebih sukar dibaca dan lebih terdedah kepada ralat halus, terutamanya apabila pembangun secara tidak sengaja menggunakan semula pemboleh ubah ralat atau merujuknya di luar konteks yang dimaksudkan.
Kritikan Utama Bahasa Go:
- Pengendalian Ralat: Isu skop pembolehubah yang dipaksa dengan corak pengendalian ralat
- Jenis Nil: Dua jenis nil yang berbeza (bertaip vs tidak bertaip) menyebabkan ketidakkonsistenan perbandingan
- Pengurusan Memori: Ketidakbolehramalan pengumpul sampah dan isu pemecahan memori
- Kebolehpindahan: Sistem tag binaan menggunakan komen fail mewujudkan masalah penyelenggaraan
- Mekanisme Defer: Pembersihan sumber berskop fungsi dan bukannya berskop leksikal
- Pengendalian Rentetan: Pengesahan UTF-8 yang tidak konsisten membawa kepada potensi kehilangan data
Masalah Dua Jenis Nil
Pengendalian nilai nil oleh Go menimbulkan cabaran penting yang lain. Bahasa ini secara berkesan mempunyai dua jenis nil yang berbeza - bertaip dan tidak bertaip - yang berkelakuan berbeza dalam perbandingan dan boleh membawa kepada panik masa jalan yang tidak dijangka. Isu ini berlaku apabila pemboleh ubah antara muka mengandungi penunjuk nil, mewujudkan situasi di mana pemboleh ubah mungkin tidak sama dengan nil dalam perbandingan tetapi masih menyebabkan dereferensi penunjuk null apabila kaedah dipanggil. Ahli komuniti melaporkan menghadapi masalah ini dalam kod pengeluaran, di mana ia boleh menjadi sukar untuk dikesan semasa semakan kod.
Kebimbangan Pengurusan Memori dan Kebolehpindahan
Tingkah laku pengumpul sampah bahasa ini telah menarik kritikan daripada pembangun yang bekerja pada aplikasi terhad memori. Sesetengah ahli komuniti melaporkan bergelut dengan bahasa apabila cuba meminimumkan penggunaan memori, terutamanya dalam senario yang memerlukan kawalan memori yang tepat. Tingkah laku pengumpul sampah yang tidak dapat diramal boleh membawa kepada pemecahan memori dan pembersihan yang tertangguh, memaksa pembangun melaksanakan penyelesaian sementara seperti penimbal pra-diperuntukkan dan strategi pengurusan memori tersuai.
Isu kebolehpindahan juga melanda reka bentuk Go, terutamanya sekitar kompilasi bersyarat menggunakan tag binaan. Pengkritik berhujah pendekatan ini, yang bergantung pada komen khas di bahagian atas fail, mewujudkan mimpi ngeri penyelenggaraan untuk kod merentas platform berbanding pendekatan yang lebih moden yang digunakan oleh bahasa lain.
Respons Komuniti dan Perspektif Alternatif
Komuniti pembangun kekal berpecah mengenai kritikan ini. Penyokong berhujah bahawa faedah kesederhanaan dan produktiviti Go mengatasi kelemahan reka bentuknya, terutamanya untuk pembangunan bahagian pelayan dan perkhidmatan API. Ramai pembangun menghargai masa kompilasi pantas Go, perpustakaan standard yang teguh, dan alat pemformatan yang konsisten yang menghapuskan banyak pertikaian pasukan biasa.
Go adalah bahasa yang berprestasi munasabah yang menjadikannya agak mudah untuk menulis perkhidmatan serentak yang boleh dipercayai dan tinggi yang tidak bergantung pada multithreading berat - semuanya berkat model goroutine.
Walau bagaimanapun, pengkritik berpendapat bahawa faedah ini datang dengan kos ergonomik pembangun dan keselamatan jenis. Ada yang mencadangkan bahawa bahasa seperti Rust, Java dengan benang maya, atau bahkan alternatif yang lebih baru mungkin memberikan penyelesaian yang lebih baik untuk keperluan pembangunan moden.
Bahasa Alternatif yang Disebut:
- Rust: Keselamatan jenis dan pengurusan memori yang lebih baik
- Java: Diperbaiki dengan benang maya dan GC moden
- Elixir: Model konkurensi yang unggul untuk kes penggunaan tertentu
- C: Keseimbangan yang baik antara ciri dan sokongan perusahaan
- Zig: Alternatif peringkat rendah dengan abstraksi yang lebih baik
- Carbon: Bahasa dalam pembangunan untuk kebolehoperasian C++
Konteks Yang Lebih Luas
Perdebatan mencerminkan ketegangan yang lebih besar dalam reka bentuk bahasa pengaturcaraan antara kesederhanaan dan kekuatan ekspresif. Walaupun pencipta Go sengaja memilih kesederhanaan berbanding kekayaan ciri, pengkritik berhujah bahawa falsafah ini kadangkala mengakibatkan kerumitan ditolak kepada pembangun dan bukannya menghapuskannya. Komitmen bahasa terhadap keserasian ke belakang juga bermakna bahawa banyak isu asas ini tidak dapat ditangani tanpa merosakkan kod sedia ada.
Semasa landskap pengaturcaraan terus berkembang, komuniti Go menghadapi soalan berterusan tentang sama ada pertukaran bahasa kekal sesuai untuk cabaran pembangunan perisian moden. Walaupun Go terus menyaksikan penggunaan meluas, terutamanya dalam infrastruktur awan dan perkhidmatan mikro, kritikan berterusan ini menunjukkan bahawa pembangun semakin mengharapkan ciri bahasa yang lebih canggih dan ergonomik yang lebih baik daripada alat mereka.
Rujukan: Go is still not good