- Go dilinin tasarımındaki çeşitli kararlar gereksiz biçimde alındı ya da mevcut deneyim görmezden gelinerek verildi
- Hata değişkenlerinin kapsamını yönetme sorunu, kodun okunabilirliğini ve hata ayıklamayı zorlaştırıyor
nil'in ikili doğası, bellek kullanımı, kod taşınabilirliği gibi birçok alanda sezgisel olmayan ve gerçek dünyaya uymayan tasarımlar görülüyordefer deyiminin sınırlamaları ve standart kütüphanenin istisna işleme yaklaşımı, istisna güvenliğini sağlamayı zorlaştırıyor- Bellek yönetimi ve UTF-8 işleme yetersizlikleri gibi biriken sorunlar, Go kod tabanlarının kalitesini uzun vadede olumsuz etkiliyor
Go diline yönelik uzun vadeli eleştiri
Hata değişkeni kapsamının sezgisel olmaması
- Go sözdizimi, hata değişkeninin (
err) kapsamını gereksiz yere genişleterek hata olasılığını artırıyor
- Örnek kodda
err değişkeni tüm fonksiyon boyunca hayatta kalıyor ve yeniden kullanılıyor; bu da kodun okunabilirliğini ve bakımını kötüleştiriyor
- Deneyimli geliştiriciler, bu kapsam sorunu nedeniyle hata ayıklarken yanlış yönlendirme ve zaman kaybı yaşayabiliyor
- Değişkenleri uygun biçimde daha yerel sınırlara çekmenin sözdizimsel olarak izin verilen bir yolu yok
nil'in iki farklı biçimi
- Go'da
interface türü ile işaretçi türünde nil'in farklı davranması kafa karıştırıcı bir durum yaratıyor
- Aşağıdaki örnekte olduğu gibi,
s'ye (işaretçi) ve i'ye (interface) nil atansa bile s==i farklı değerlendirilebiliyor; yani tutarsız davranış sergiliyor
- Bu,
null işlemede normalde kaçınılmak istenen bir problem ve tasarımda yeterince düşünülmediğinin izini taşıyor
Kod taşınabilirliğinin sınırları
- Koşullu derleme için yorum kullanmak, bakım ve taşınabilirlik açısından belirgin biçimde verimsiz
- Gerçekten taşınabilir yazılım geliştirmiş biriyseniz, bu yaklaşımın ne kadar uğraştırıcı ve hata üretmeye açık olduğunu bilirsiniz
- Tarihsel olarak birikmiş deneyim (kod taşınabilirliği, pratik örnekler) göz ardı ediliyor
- Ayrıntılar için Go programs are not portable yazısına bakılabilir
append sahipliğinin belirsizliği
append fonksiyonu ile slice sahipliği arasındaki ilişki net olmadığı için kodun davranışını öngörmek zorlaşıyor
- Örneklerde,
foo fonksiyonunda bir slice'a append yapıldığında bunun özgün veri üzerinde gerçekte nasıl bir etkisi olacağını önceden anlamak zor
- Dilde bilinmesi gereken bu tür 'quirk'lerin çoğalması hatalara yol açıyor
defer deyiminin yetersiz tasarımı
- RAII (Resource Acquisition Is Initialization) ilkesindeki gibi, kaynak serbest bırakmayı açık biçimde desteklemiyor
- Java ve Python'daki yapısal kaynak yönetimi sözdizimlerine kıyasla, Go'da hangi kaynağın
defer ile serbest bırakılması gerektiği açık değil
- Örnekte olduğu gibi dosya işlemlerinde,
double-close sorununu bile doğrudan ele almak gerekiyor; doğru serbest bırakma sırası ve yöntemi belirsiz kalıyor
Standart kütüphanede istisna işleme
- Go açık istisna (
exception) desteği sunmayan bir yapıya sahip olsa da, panic gibi istisnai durumlar yine de ortaya çıkıyor
- Bazı durumlarda
panic, programı tamamen sonlandırmak yerine sinsice yayılabiliyor
- Standart kütüphanede (
fmt.Print, HTTP sunucusu vb.) istisnaları yok sayan örüntüler bulunduğundan, gerçek istisna güvenliğini garanti etmek mümkün değil
- Sonuç olarak istisna güvenli kod yazmak zorunlu, fakat istisnaları doğrudan kullanmak mümkün değil
UTF-8 işleme ve string'ler
string türüne keyfi ikili veri konsa bile Go özel bir doğrulama yapmadan çalışıyor
- Geçmişte UTF-8 kodlamasından önce oluşturulmuş dosya adları gibi örneklerde, verilerin sessizce atlanmasıyla karşılaşabilirsiniz
- Yedekleme gibi senaryolarda önemli veriler kaybolabilir; bu da gerçek çalışma koşullarını yansıtmayan aşırı basit bir yaklaşım
Bellek yönetiminin sınırları
- RAM kullanımını doğrudan denetlemek zor ve GC'nin (garbage collection) güvenilirliğinin de sınırları var
- Go'nun bellek kullanımı artarak uzun vadede maliyet ve performans sorunlarına dönüşebiliyor
- Birden çok instance ve container ortamında maliyet ve ölçeklenebilirlik sorunları pratikte gerçekten yaşanıyor
Sonuç: Daha iyi bir yol vardı
- Halihazırda etkililiği kanıtlanmış dil tasarımları varken, Go birçok noktada bunlara sırt çevirdi
- Java'nın ilk taslaklarındaki sorunlardan farklı olarak, Go piyasaya çıktığında daha iyi yaklaşımlar zaten mevcuttu
Kaynaklar
Henüz yorum yok.