Kendin Yaptığın Build It Yourself programı

• Bağımlılıklar üzerine başka bir düşünce

  • Bağımlılıklara yeni bir bakış açısı öneriliyor. Bağımlılıkların aşırı kullanımını azaltmak ve doğrudan kod yazma yönüne geçmek gerekiyor.

• Bağımlılık sorunu

  • "Bağımlılık tüketimi", geliştiricilerin üretkenlik için kurduğu güncellemeler, yamalar, denetimler ve geçişli bağımlılıkların bitmeyen döngüsüdür.
  • JavaScript ve Rust özellikle bağımlılık sorununa açıktır. Örneğin yeni bir Tokio projesi 28 crate içerirken, Rocket projesinde bu sayı 172'ye çıkıyor.

• Terminal boyutu sorunu

  • terminal_size crate'i, terminal boyutunu ölçmek için basit bir işlev sunar ancak birden fazla ek crate gerektirir.
  • Bu da binlerce başka işlevin derlenmesini gerektiren bir duruma yol açar.

• Bağımlılıkların gerekliliği

  • Platform soyutlama kütüphaneleri üzerine kurulu olduğundan, kod tekrarını önlemek ve derleme sürelerini azaltmak için güncellemeler gerekir.
  • Bunlar çoğu zaman güvenlik sorunlarının başlıca nedeni olur.

• Kodun hedefi

  • Kod, güncelleme gerektirmeyecek şekilde yazılmalıdır. Rust ekosisteminde kararlı kod dezavantajlı duruma düşer.

• Kodu doğrudan yazmanın avantajları

  • Kodu doğrudan yazarsanız yeni crate'lere ihtiyaç olmaz ve bakım gereksinimi azalır.
  • ChatGPT gibi araçlarla bağımlılıksız uygulamalar hızlıca yazılabilir.

• Açık kaynak ve şirket kültürü

  • Şirketlerin kod inceleme kültürü, açık kaynak yazılımları etkiler.
  • Yeni kütüphaneler kullanmak olumlu bir şey olarak görülür.

• Yeni bir bakış açısına ihtiyaç

  • Küçük işlevleri kendisi yazan mühendisler övülmelidir.
  • Büyük crate grafiklerine şüpheyle yaklaşılmalıdır.

• Önemli kütüphaneler

  • Karmaşık sorunları çözen önemli kütüphaneler de vardır. Örneğin grafik kütüphaneleri veya protokol uygulamaları.

• Doğrudan inşa etmenin önemi

  • Uygun olduğunda bir şeyi kendin inşa etmeyi kutlamalıyız.
  • Az bağımlılıkla ya da hiç bağımlılık olmadan açık kaynak kütüphaneler geliştiren kütüphane yazarlarının emeği takdir edilmelidir.

• Sonuç

  • Bağımlılıkları azaltma ve kodu doğrudan yazma yönüne geçilmelidir.
  • minijinja, bağımlılıkları en aza indiren bir örnektir ve yalnızca serde bağımlılığına sahiptir.

[GN⁺]

Hacker News yorumları

• Rust dilini seviyorum ama Rust’ın bağımlılık sorunlarını sevmiyorum. C++’ın bağımlılık yönetimi daha iyi. C++’ta bağımlılıkları kendiniz kontrol edebilirsiniz, ancak Rust’ta çok fazla bağımlılık ortaya çıkıyor ve bu da insanı vazgeçiriyor. Güvenlik açısından da neyi dağıttığımı bilemiyorum. Rust’ın ABI uyumluluğu yok ve paylaşımlı kütüphane kültürü de zayıf. Bu, işletim sistemi paket dağıtım modelini bozuyor.

• Terminal API’si kararlı değil. TIOCGWINSZ ioctl standartlaştırılmış değil ve POSIX’e tcgetwinsize() fonksiyonunun eklenmesi ancak 2024’te gerçekleşti. Windows tarafı ise daha da karmaşık.

• 2006’da yaptığım bir web uygulamasını yeniden ayağa kaldırdım. Yeni CI/CD teknolojilerini öğrenmek için uygulamanın dağıtım sürecini gereğinden fazla tasarladım. PHP ve MySQL kullandım ve kodun çoğunu kendim yazdım. 19 yıllık uygulamayı yeniden ayağa kaldırmak sadece bir saat sürdü. Buna karşılık, şu an iş yerinde kullandığımız Spring Boot uygulamasını bağımlılık sorunları yüzünden güncellemek zor.

• NodeJS kariyerim üzerinde büyük etki yarattı ama NPM çok fazla sorun çıkardı. Yeni bir bağımlılık eklemeye çalıştığınızda başka bağımlılıklarla çakışıyor. Expo tarafında ise varsayılan React Native projesinin Android’de derlenmemesi gibi bir sorun var. Büyük ölçekli projelerin bile çalışmayan şablonlar dağıtabildiğini görmek insana güven veriyor.

• Rust ekosistemi, Go ile karşılaştırıldığında daha fazla bağımlılığa sahip. Go’da arayüzler örtük olarak karşılandığı için ek bağımlılıklara ihtiyaç olmuyor.

• Kütüphanelerdeki soyutlamaların gizli bir maliyeti var. Paket tasarımını değiştirirse kararsızlık ortaya çıkıyor. En basit olan şeyler en uzun ömürlü oluyor. Sadece Rust’ta değil, diğer dillerde de benzer sorunlar gördüm.

• ChatGPT veya Cursor’ın bağımlılıksız implementasyonları hızla üretmesi daha hızlı oluyor. Birçok SaaS/3rd party hizmet bağımlılığı zaten çözülmüş problemler.

• Flask ve Bottle benzer işlevlere sahipti ama Flask daha popüler oldu. Bottle tek dosyalıydı ve bağımlılığı olmadığı için projeye kolayca kopyalanabiliyordu. Ancak modern Python pratiklerini takip etmediği için eski moda hissettiriyor.

• Kendi çözümünü geliştirebilen yetenekli mühendislere ihtiyaç var. Mevcut kütüphanelerden daha iyi çözümler kolayca üretilebilir. Bir projede Markdown varyantı için bir parser yazdım ama ekip arkadaşlarım bakım gerekçesiyle bunu kullanmadı.

• Sadece tek bir fonksiyon kullanırken yüzlerce fonksiyonu derlemek sorunlu. 3rd party bağımlılıklarını güncelleyen bir projede matematik kütüphanesinin yalnızca tek bir metodunu kullanıyorduk. Mühendise Wikipedia sayfasını referans alıp metodu doğrudan kendisinin yazmasını önerdim. Sorun 3rd party bağımlılık kullanmak değil; kütüphanenin yalnızca küçük bir kısmını alabilme kavramına ihtiyaç var. "Microframework" bunun çözümü olabilir.