2024'te Yalın Yazılım İçin Bir Çağrı
(spectrum.ieee.org)- Basit işlevler için bile binlerce bağımlılık ve on milyonlarca satır kodun devreye girdiği bir ortamda, yazılımın şişkinleşmesi başlı başına güvenlik açıklarının büyük bir nedeni haline geliyor
- Güvenlik yalnızca hata yoğunluğuna değil, saldırganın erişebileceği toplam kod miktarına da bağlı; gereksiz yere genişleyen saldırı yüzeyi gerçek ihlallere yol açabiliyor
- Electron JS, Node.js, Docker imajları ve npm·PyPI bağımlılık ekosistemi, dağıtılan kodun miktarını ve kaynağını belirsizleştiriyor; garaj kapısı açan bir uygulamada bile 50 milyondan fazla satır etkin kod yer alabiliyor
- Rust, sanitizer ve fuzzer kod kalitesini artırsa da, belge içindeki kodu otomatik çalıştırmak gibi mantıksal tasarım hataları yalnızca bug temizliğiyle engellenemiyor
- Trifecta, 1.600 satır yeni kod, yaklaşık 5 temel bağımlılık ve toplam 3 MB boyutla görüntü paylaşımı sunarak, sınırlı kod ve bağımlılıkla da modern yazılım yapılabileceğini gösteriyor
Yazılım güvenliğinin tehlikeli hale gelmiş durumu
- Son dönemde yazılım güvenliğinin durumu çok kötü
- Ivanti, MOVEit, Outlook, Confluence, Barracuda Email Security Gateway ve Citrix NetScaler ADC·NetScaler Gateway gibi sektör standardı yazılımlarda son 1 yılda ciddi ihlal vakaları yaşandı
- Apple ve Google gibi kaynakları bol şirketler bile müşterilerini riske atan güvenlik hataları yaptı
- Yazılımın fazla tehlikeli hale geldiği düşüncesi nedeniyle, yazılımı doğrudan çalıştırmak yerine bunu X as a service ya da buluta bırakma tavsiyesi yaygınlaştı
- Bulutun zayıf yazılımları güvenilir hale getirdiği varsayımı da sarsılıyor
- Microsoft'un e-posta platformu, gizli devlet e-postaları da dahil olmak üzere hacklendi
- Azure bulut güvenliği konusunda endişeler sürüyor
- Okta, 2 yıl içinde ikinci ihlalini yaşadı ve ardından Okta kullanıcılarına yönelik hack olayları şüpheli biçimde devam etti
- AB, yazılım güvenliğini ele almak için üç ayrı düzenleme üzerinde ilerliyor
- NIS2: kritik hizmetler için
- Cyber Resilience Act: neredeyse tüm ticari yazılımlar ve elektronik cihazlar için
- Product Liability Directive: sorumluluk kapsamını yazılımı da içerecek şekilde genişletiyor
Güvenlik açıkları hem kod kalitesinden hem kod miktarından doğar
- Yazılım güvenliği iki eksene bağlıdır
- kaynak kod içindeki güvenlik problemi yoğunluğu
- hackerların erişebileceği kod miktarı
- Kod arttıkça risk de büyür
- Hata yoğunluğu düşük olsa bile, milyonlarca satır kod içinde istismar edilebilir açıklar bulunabilir
- iMessage vakası, saldırı yüzeyinin genişlemesinin nasıl sorun yarattığını gösteriyor
- İstenmeyen iMessage'lar bile iPhone'da anında işlenip önizleme üretiyordu
- Apple, çok çeşitli görsel formatlarını destekliyordu ve tuhaf sıkıştırılmış fontlar içeren PDF'ler bile işleme kapsamına giriyordu
- Bu eski format gerçekte bir programlama dili barındırıyordu ve saldırganlar bunu telefonun diğer zayıflıklarını araştırmak için kullanabiliyordu
- Apple, önizlemeyi çok daha az sayıda görsel formatıyla ya da tek bir “güvenilir olduğu bilinen” formatla sınırlayarak saldırı yüzeyini azaltabilirdi
- AB Cyber Resilience Act de tedarikçilerin saldırı yüzeyini en aza indirmesi gerektiğini açıkça söylüyor
Yalnızca daha iyi kod yetmez
- Kod kalitesini artırmaya yönelik hareket zaten var
- Rust gibi bellek güvenli diller
- AddressSanitizer gibi güvenliği güçlendiren araçlar
- Girdileri otomatik dönüştürerek güvenlik açıkları ve bug'lar bulan fuzzer'lar
- Ancak birçok güvenlik sorunu, kodun içindeki bug'lardan çok altında yatan mantıktan kaynaklanıyor
- Barracuda e-posta açığı, virüs taraması için Excel elektronik tablolarını inceleyen üçüncü taraf bir kütüphanenin gerçekte kod çalıştırmasından doğdu
- Belge içindeki kodu otomatik çalıştırma özelliği ekleme kararı, kod içindeki tüm bug'lar giderilse bile çözülmüş olmaz
Ne dağıttığını bilmeme durumu
- Modern yazılım o kadar büyüdü ki, gerçekte ne dağıtıldığını anlamak zorlaştı
- Niklaus Wirth, 1995 tarihli “A Plea for Lean Software” yazısında yazılımların megabayt ölçeğine çıkmasını eleştirmişti
- Onun Oberon işletim sistemi, editör ve derleyici dahil 200 KB idi
- Bugün yalnızca yapılandırma dosyası 200 KB'yi aşan projeler var
- Günümüzde tipik bir uygulama Electron JS tabanlı yapılabiliyor
- Electron JS, Chromium ve Node.js içeriyor
- Node.js, on binlerce JavaScript paketine erişim sağlıyor
- Yalnızca Electron JS kullanımıyla bile, bağımlılıklar dahil en az 50 milyon satır kodun içeri girebildiği tahmin ediliyor
- Uygulamalar yüzlerce ila binlerce yardımcı paket çekiyor ve bağımlılıklar da kendi bağımlılıklarını getiriyor
- Derlemeye tam olarak neyin girdiği her gün değişebilir
- Bazı paketler varsayılan olarak kullanıcıyı reklamverenlere ya da veri broker'larına maruz bırakabilir
- Ev içindeki cihazları kontrol eden bir uygulama, Amazon tarafındaki yazılım yığınına da bağlanabilir ve o yığın da Node.js ile çeşitli bağımlılıklar kullanabilir
- Sonuç olarak, yalnızca garaj kapısını açmak için bile birden fazla işletim sistemi imajı ve birden fazla sunucu üzerinde 50 milyondan fazla satır etkin kod çalışıyor olabilir
Konteynerler ve bağımlılık tedarik zincirinin yükü
- Eskiden derleyici çıktıları ya da yorumlanacak dosya paketleri dağıtılırdı ve kurulumla yapılandırma sırasında paketin içinde ne olduğu düşünülürdü
- Günümüzde ise çoğu zaman yazılımla birlikte çalışma ortamını eşleştirmek için işletim sistemi dosyaları da konteyner içinde dağıtılıyor
- Pratikte neredeyse tam bir bilgisayar disk imajı dağıtılmış oluyor
- Docker Hub'da 350 MB'yi aşan çok sayıda imaj var
- Konteynerler faydalı amaçlarla kullanılabilir, ancak fiili kullanım şekli dağıtılan kod miktarını ciddi biçimde artırabiliyor
- Bağımlılıklardaki güvenlik güncellemelerinin nihai uygulamaya ulaşıp ulaşmadığı da belirsiz
- Google ve Apple'ın hızla dağıttığı görsel işleme bug düzeltmelerinin Electron uygulamalarında hâlâ bulunup bulunmadığını bilmek zor
- npm ekosisteminin geçmişinde paket deposu ele geçirmeleri, hijacking ve aynı adlı paketlerin yeniden canlandırılması gibi olaylar var
- PyPI de benzer sorunlar yaşadı
- Bağımlılıkların gözden geçirilmesi gerekiyor, ancak binlercesinin düzenli olarak kontrol edilmesi gerçekçi değil
- Her şeyi sıfırdan yeniden yazmak da çözüm değil; SQLite gibi, elde yazılandan daha güvenli olma ihtimali yüksek iyi modüller de var
Trifecta: küçük kodla yapılmış bir görsel paylaşım aracı
- Trifecta, minimal ama gerçekten kullanılabilir bir bağımsız görsel paylaşım yazılımı
- Tarayıcıda görseli sürükleyip bırakarak kolayca paylaşmayı sağlıyor
- imgur kullanıldığında tarayıcıya çok sayıda cookie ve tracker yerleşiyor, ayrıca paylaşılan görseli gören kişilere de tracker dayatılabiliyor
- Kendi kendine barındırılan görsel paylaşım araçlarının da çoğu büyük framework'ler üzerine kurulu olduğundan güven vermediği düşünülmüş
- Trifecta, tüm kodun birkaç saat içinde incelenebilmesi için küçük tutulmuş
- yeni kaynak kod: 1.600 satır
- önemli bağımlılık sayısı: yaklaşık 5
- toplam kod boyutu: 3 MB
- Karşılaştırma için anılan başka bir görsel paylaşım çözümü 288 MB Docker imajı olarak dağıtılıyor
- Node tabanlı başka bir fotoğraf paylaşım çözümünün ise 1.600 bağımlılığa ve 4 milyondan fazla satır JavaScript'e sahip olduğu görülmüş
- Trifecta, rastgele insanların görsel yüklediği herkese açık bir site olmaktan çok, şirket ya da bireysel kullanım için uygun
Karmaşıklığı güç sanma sorunu
- Trifecta'ya verilen yaygın tepkilerden biri, dağıtım için Amazon Web Services paketinin kullanılmasını önermek oldu
- Bu, dış hizmetlere bağlı olmayan bağımsız çalışan bir yazılım hedefiyle uyuşmayan bir tepkiydi
- Docker'a haksızlık yapıldığı yönünde tepkiler de oldu, ancak konteynerlerin iyi amaçlarla kullanılabileceği kabul ediliyor
- Niklaus Wirth, 1995 tarihli makalesinde insanların karmaşıklığı sofistike olmakla karıştırma eğilimine dikkat çekmişti
- Tony Hoare'ın dediği gibi, yazılım tasarımında iki yol vardır
- programı hataların apaçık olmayacağı kadar basit yapmak
- programı apaçık hata görünmeyecek kadar karmaşık yapmak
- Wirth, zaman baskısını şişkin yazılımın başlıca nedeni olarak görüyordu
- Zaman baskısı dikkatli planlamayı engeller
- Kabul edilebilir bir çözümü iyileştirmek yerine hızla ekleme ve değişiklik yapmaya iter
- Mühendisin kalite ölçütlerini ve işçiliğini yavaş yavaş aşındırır
- Yazılım patlaması bir doğa yasası değil; yazılım mühendislerinin azaltması gereken bir sorundur
Kod miktarını azaltmak bir güvenlik önlemi haline gelir
- Dünya şu anda fazla miktarda kod dağıtıyor
- bunun çoğu üçüncü taraf kodu
- bir kısmı istemeden dahil ediliyor
- büyük bölümü yeterince incelenmiyor
- Bunun sonucu olarak devasa bir saldırı yüzeyi oluşuyor ve bunun içinde sıradan kalitede çok büyük miktarda kod açığa çıkıyor
- Kod kalitesini artırma çabaları sürse de, birçok istismar mantık hatalarından doğuyor ve bunları tespit etme konusundaki ilerleme görece sınırlı
- Dünyaya açık hale getirilen kod miktarını azaltmak bile büyük bir iyileşme sağlayabilir
- Ürünü piyasaya çıkarma süresi uzayabilir, ancak yaklaşan düzenlemeler tedarikçileri güvenliği daha ciddiye almaya zorlayabilir
- Trifecta ve Oberon, sınırlı kod ve bağımlılıklarla da çok şey yapılabileceğini gösteriyor
1 yorum
Hacker News yorumları
Vernor Vinge’in 『A Deepness in the Sky』 romanında insanlık yalnızca ışık altı hız teknolojisiyle yıldızlar arasına yayılmıştır; yıldızlararası gemiler de çeşitli yıldız sistemlerinin ve uygarlıkların eski teknolojilerinin birbirine karıştığı bir halde tasvir edilir.
Bilgisayar sistemleri de o kadar uzun süre evrimleşmiştir ki kodların çoğunu artık kimse anlamaz; insanlar onları sadece kullanır ve üstüne yeniden katmanlar inşa eder.
Özellikle karakterlerden biri, uzun süreler boyunca askıya alınmış durumda kalıp yolculuk ederek yaşayan insanlar arasında en eskilerden sayılan eski bir sistem mühendisidir; herkesin bu sistemlerin üstüne birçok katman yığdığı gelecekte, kendi dönemindeki çalışma biçimlerini ve açıkları bilmesi ona aksine büyük avantaj sağlar.
Bence Vinge bir şeyi tam isabet yakalamış.
İlki modern bilimin ve çok zeki insanların çözmesi gereken gerçek bir muamma; ikincisi ise daha çok ilgi eksikliğine yakın.
Yeterince para öderseniz yetkin bir mühendis çamaşır makinesini söküp gerçek arızayı tam olarak bulur; ama kimse o maliyeti ödemez, bunun yerine onu atıp yenisini alır.
Eski yazılım bilgisi kesinlikle ikinci kategoriye giriyor. Herhangi bir parçanın içine yeterince girerseniz sonunda onu tamamen anlayabilirsiniz; ama çoğu zaman görmezden gelmek ya da üzerine bir katman daha eklemek çok daha ucuz ve pratiktir.
Gelecekte insanlığın temel aritmetiği unuttuğu, biri bunu yeniden keşfedince de iktidar sahiplerinin bunu savaşta kullanmaya çalıştığı bir hikâye; vermek istediği mesajı anlıyorum ama kurgusu o kadar gerçek dışı ve komik ki etkisini kaybettiğini düşünüyorum.
Daha fazla tartışma için bkz. http://lambda-the-ultimate.org/node/4424
Biz zaten bu tür sorunları yaşıyoruz. 60’larında olan amcam COBOL ile yazılmış eski bir kamyon taşımacılığı yazılımının bakımını yapıyor; böyle eski teknoloji işleri de var. İlgilenirseniz tanıştırabilirim.
Temel sorun left-pad vakasıyla aynı. Denetimsiz bir junior mühendisin bağımlılıkları gelişigüzel kurmasıyla alay ederiz; ama onlarca yıl ve birkaç geliştirici kuşağı geçince yazılımların çoğu eninde sonunda bir ölçüde bilinmeyen bağımlılıklara yaslanır.
2100 yılında bir güncelleme dağıtmanız gerektiğini düşünün; onu o dönemin npm bağımlılık yönetim sistemi üzerinden iteceksiniz. Aynı anda güvenlik güncellemesi gerektiren bağımlı cihazlar Güneş Sistemi ölçeğinde olabilir; trilyonlarca cihaz ve güncel olup olmadıkları bilinmeyen ara önbellekler bulunabilir. Böyle bir bağımlılık ağacının nasıl görüneceğini hayal bile edemiyorum.
Özüne ulaşmak için framework kodunu kazmak zorunda kaldığınız bir ortamda çalışmak da bunaltıcı. Zaman boşa gidiyormuş gibi hissettiriyor.
Şişkinlik, npm’deki çoğu kütüphanede görülüyor. Yazar iyi tasarımı bilmiyor ve her kütüphanenin her işi yapmasını sağlamaya çalışıyor.
Sözde bir karakter kodlaması dönüştürme kütüphanesi; dosya yükleme, kaydetme, internetten indirme, komut satırı aracı gibi şeyleri de aynı depoya koyuyor. Kütüphane yalnızca kendi işini yapmalı, gerisini kullanıcıya bırakmalı.
Rust tarafı da daha iyi görünmüyor. Rust belgelerini düzeltmeye kalkarsanız yaklaşık 1000 crate’in kurulduğunu görüyorsunuz.
Sorun dilde değil; herkesin kütüphane yayımlayabilmesinde ve gerçekten de önüne gelenin yayımlamasında. “Sadece işi bitirmek isteyen” kişiler en çok özelliğe sahip kütüphaneyi seçiyor; kütüphane dışında 3 satırla yapılabilecek kodu yazmak istemedikleri için daha fazla özellik talep ediyorlar. “PDF render etmeyi de ekleyebilir misiniz?” gibi.
Çözümü pek bilmiyorum ama Low Dependency savunuculuğu yapan bir grup ve rozet oluşturup kütüphane yazarlarının bu rozeti istemesini, kullanıcıların da kütüphane seçerken bunu aramasını sağlama fikrini düşündüm.
Buna karşılık az bağımlılığı olan bir kütüphane istiyorsanız, çok iş yapan birkaç kütüphaneyi alırsınız.
Benim bakış açıma göre, güvendiğim bir yazarın yaptığı, az bağımlılığa sahip biraz kalın bir kütüphane daha iyi. Lodash büyük, ama ES6 modül sürümü tree shaking’i destekliyor ve pratikte JavaScript’te eksik olan standart kütüphane rolünü üstleniyor. date-fns de Date için benzer. JavaScript çekirdek kütüphanesindeki boşlukları doldurmak için bu ikisini neredeyse her projeye varsayılan olarak ekliyorum.
Eskiden Ruby on Rails sözleşmeli işi yapmıştım; performans sorunu o kadar kötüydü ki geliştirmeyi release modunda yapıyorduk. Sunucunun dosya değişikliklerini algılayıp otomatik yeniden yükleme yapamadığı bir seviyedeydi.
Bir gün bıkıp derine inmeye başladım; kaç gem çekildiğini hatırlamayacağım kadar çoktu. İçlerinden biri gerçekten de 3 satır koddan tasarruf etmek içindi.
Ondan sonra RoR topluluğundan uzak durdum. Son yıllarda ilk kez tekrar bir RoR sözleşmesi aldım; eskisi kadar kötü olmasa da hâlâ iyi değil.
Bazı topluluklar bağımlılıkların getirdiği riske hiç saygı duymuyor.
Öte yandan herhangi bir Git deposunun Go kütüphanesi barındırabilmesi ve herkesin bunu o URL’den kullanabilmesi gerçekten kullanışlı.
Önce paket üreticileri bunu bir kariyer hâline getirmek istiyor ve ilgi çekmenin tek yolu çok sayıda paket yapmak. Bu yüzden kendi yaptığı diğer paketlere bağımlı paketler üretmeye devam ediyor ve işe yarar bir iki paketini başkalarının koduna sokmaya çalışıyor.
İkincisi, problem çözmenin her zaman yeni bir paket içerdiğine inanan insanlar. Bağımlılık sayısının ne kadar olduğuyla ya da gerçek problemin zor olup olmadığıyla ilgilenmiyorlar. Böylece problemi çözmeyi öğrenmek yerine GitHub’da 4 yıldızlı bir wrapper’ın API’sini öğreniyorlar.
İdeal olarak böyle bir araç, sıkıcı zamanı harcayıp gereksiz paketleri budamalı, her paketin sorumluluğunu en aza indirmeli, ortamı makul şekilde düzenlemeli ve ardından bağımsız olarak cache’leyerek LLM bağımlılığını ortadan kaldırmalı. Yalnızca sorun çıktığında güncelleme denetleyicisini ya da küratörü çağıran bir yapı daha iyi olur.
Açıkçası modern yazılımın en kötü sorunlarından biri olduğunu ve projelerin %50’den fazlasını kullanılamaz hâle getirdiğini düşünüyorum. Sıkıcı ama çözülebilir bir problem olduğu için düzgün bir LLM ajanına tam uygun; olursa çok yardımcı olur.
“Modern bir uçağı gördünüz mü? Hatlarının her yıl nasıl evrildiğini takip ettiniz mi? Sadece uçaklar için değil, insanın yaptığı her şey için, insanın endüstriyel çabasının, hesaplarının ve çizimlerin başında geçirilen gecelerin sonunda tek ve baskın ilkeye, nihai sadeliğe vardığını hiç düşündünüz mü?
Sanki bir doğa yasası varmış da mobilyanın kıvrımını, geminin omurgasını, uçağın gövdesini insan göğsünün ya da omzunun kıvrımı gibi ilkel bir saflığa yaklaşana kadar inceltmek için kuşaklar boyu zanaatkârların deneylerini emrediyormuş gibi. Mükemmelliğe, eklenecek hiçbir şey kalmadığında değil, çıkarılacak hiçbir şey kalmadığında ulaşılıyor gibi.”
— Antoine de Saint Exupéry, Terre des Hommes
“Bir garaj kapısını açmak için 50 milyondan fazla satır aktif kod ve birden çok sunucunun işletim sistemi imajı gerekebilir” diye yazınca gerçekten delice geliyor.
Şu anda bu yazıyı yazdığım makinede ne kadar kodun çalıştığını düşününce başım dönüyor. Hiç incelemediğim, muhtemelen sıkı bir incelemeden de pek geçmemiş kodlar.
Neyse, tekrar npm bağımlılığı kurmaya gidiyorum.
“Yazılım artık insanların doğrudan çalıştırmaması gerektiği kadar tehlikeli sayılıyor. Bunun yerine bir ‘X as a service’ sağlayıcısına ya da kısaca ‘bulut’a bırakmaları söyleniyor. Arabaların çok sık alev aldığı için insanların kendi başına araba kullanmaması, her zaman yanında profesyonel itfaiyeciler bulunan uzmanlara direksiyonu bırakması tavsiyesinin verildiği hayali bir durumla karşılaştırın” benzetmesi, alıp kullanmak isteyeceğim kadar iyi
Eski kız arkadaşım, geçmişte Doğu Bloku’nda büyümüş olmanın makul nedenleriyle “bulut”a güvenmiyordu. Ama alternatifi, en ucuza aldığı HP dizüstü bilgisayarını kaybetmemeyi ummaktan ibaretti. Biraz eğitimden sonra en azından o konuda içi rahatladı
Sorun genel eğitim eksikliği ve bunun sonuçlarının yeterince düşünülmemesi. Sonunda ya riski kabul etmeniz, ya kendiniz öğrenmeniz ya da SaaS ve bulut şirketlerine güvenmeniz gerekiyor. Çok gözyaşı gördüm; kendi kendine öğrenenleri ise pek görmedim
Bu kişisel sorumluluk meselesi, ama kimse o sorumluluğu almak istemediği için işi uzmanlara bırakmak, kendine güvenmekten daha az kötü bir çözüm olabilir. Doğru cevap eğitim, ama umutsuz derecede zor
Yazılım daha yalın hale gelemez. Bunun için zaman, beceri ve yüksek ücretli insanlar gerekir; 12 farklı teknoloji yığını örneğini birbirine yapıştırıp bir Franken-suit yapan kişiler tek başına yetmez
Ben bağımsız geliştiriciyim; geçen yıl node.js öğrenmiş birinin node.js, konteynerler, herhangi bir AWS barındırmalı DB servisi, Lambda, nesne depolama, Cloudflare, YAML, React, Vite ve diğer bağımlılıkları bir günde bir araya getirip klişe ama hâlâ kırılgan bir web uygulaması yapması, her zaman benden daha düşük fiyat veriyor
Yalın, hızlı, çalıştırma maliyeti düşük ve bakımı da daha ucuz yazılım uzun vadede daha ucuz olsa da, bunu kârlı biçimde yazmak zor
Eskiden sistemin sunduğu standart hook’lar ve rutinler sayesinde herkesin arayüzler vb. için bunları kullandığına dair bir hayal vardı. Macintosh Toolbox ya da QuickDraw gibi şeyleri düşünün
Geliştiricinin ana işi program mantığını yazmak olacaktı; değişiklikler ya da eklemeler şeffaf olmalıydı denirdi. Sistem çağrıları, iç kod değişse bile aynı işi sorunsuzca yapacak; yeni özellikler mevcut özelliklerin üst kümesi olacağı için eski kod sorunsuz derlenecek ya da çalışacak, yeni yazılım ise daha fazla yetenek kazanacaktı
Böylece bakımın kolaylaşacağı, arayüzlerin standartlaşacağı ve sistem çağrılarına çok dayanıldığı için kodun da yalınlaşacağı düşünülüyordu. Harici kütüphanelerden kaçınılması gerektiği havası vardı
Bu hayal kısa sürede çöktü; DLL’leri düşünün. Bugünkü birçok paket yönetimi ve paketleme işi, doğru kütüphanenin mevcut olmasını garanti etmeye daha yakın görünüyor
O zamanlar büyük ölçekli yazılım geliştirme hâlâ bebeklik dönemine yakındı; beklendiği gibi olmaması anlaşılır. Artık bu konularda çok fazla kolektif deneyim birikti; merak ettiğim, bu hayalin aklı başında biçimde gerçekleştirilemez olduğu sonucuna mı varıldı, yoksa mevcut dağınıklığı yeterince yaşadığımız için modern bir yeniden denemeye mi yöneldik
Hızlı, yalın, kararlı ve güvenli yazılım istiyorsanız, dördünü aynı anda elde etmek zor olsa bile, mevcut durumun o yöne gidip gitmediğinden pek emin değilim
Erken Lisp dilin içine çok az şey koymuştu, ama Raku npm kütüphanesi olabilecek ufak tefek şeyleri bile dil spesifikasyonuna itiyor
C, kodu nasıl derleyeceğinize kendiniz karar vermenizi sağlıyordu, ama yeni çıkan derlenen dillerin çoğu bir biçimde derleme aracını da birlikte sunuyor
Bu zeminde oldukça etkili olan şeyler var, ama bunlar Wirth’ün çalışmalarını yönlendiren “sen, makine, yeni proje” bağlamının dışında gerçekleşiyor. Sorun, veritabanı ya da tarayıcı motoru gibi devasa bağımlılıkların eşiğini beraberinde getirme eğiliminde olmaları; o bağımlılıkların nasıl yapıldığını beğenmiyorsanız sonunda mutsuz oluyorsunuz
Rust hakkında sürekli söylediğim şey bu
Eski C++ açıklarının %70’i gerçekten bellekle ilgiliyse, kod satırı başına açık sayısı C++’tan %70 daha az olabilir
Ama Rust’ta yüzlerce paketi içeri çekip kod satırı sayısı 10 katına çıkıyorsa iş değişir
100 bin satırın %30’u, 10 bin satırın %100’ünden toplamda daha büyüktür
QT gibi bir şey de Rust ile yazılmış olsaydı kendi içinde yüzlerce crate olurdu, ama kod miktarı ve üstlenilen risk düzeyi tam olarak aynı olurdu
Ama büyük sorun açıklar. Paylaşılan tek bir kütüphanedeki hatayı düzelterek yüzlerce kütüphaneyi düzeltmek mi daha iyi, yoksa yüzlerce kütüphaneyi tek tek düzeltmek mi?
Rust’ın birkaç devasa bağımlılık yerine çok sayıda küçük bağımlılığı kolayca içeri çekmeyi sağlaması bununla alakasız. Daha fazla kod yazmak demek değil
Örneğin Rust’ın
regexcrate’ini bağımlılık olarak mı sayıyorsunuz? C++’ta bu standart kütüphanenin içinde yer alıyorBoost’u C++’ta tek bir bağımlılık olarak mı sayıyorsunuz? Rust olsaydı bu, yaklaşık 30 ayrı crate’e karşılık gelirdi
Rust programlarında C++’a kıyasla ne kadar uzaktan kod çalıştırma vardı? C++’taki uzaktan kod çalıştırma sıklığının Rust’takinden %70’in çok üzerinde fazla olduğunu sanıyorum
Günümüzde uygulamaların genellikle Electron JS ile yapıldığı söyleniyor ama her platformun yerel web kontrollerini kullanıp Electron’ı paketlemeyebileceğiniz yeterince bilinmiyor gibi
Böyle yapınca dağıtılan uygulama kilobayt mertebesinde olabilir. Bu yaklaşım, web view ile iletişim kurabildiği sürece hangi backend dilini ya da teknoloji yığınını kullanırsanız kullanın özgürlük sağlar
Bugünlerde uygulamaların oldukça büyük bir kısmı için PWA mümkün olmalı, değil mi?
Çok emin değilim ama Discord da Electron uygulaması yerine PWA olamaz mı?
En büyük boşluk muhtemelen SQLite’a karşılık gelecek güçlü bir şey ile IndexedDB arasındaki fark olurdu; yine de çoğu uygulamanın IndexedDB’nin B-tree modelinden daha üst düzey bir sorgu diline mutlaka ihtiyaç duyacağını sanmıyorum
suckless felsefesine bir kez daha alkış. Yaşasın
[0 ]https://suckless.org/