Programlama Dilleri

Bazı durumlarda bir tipe ekstra bilgiler dahil ederken bu bilgilerin çalışma zamanında (runtime) gerçekten de saklanmasını istemeyiz. Kulağa garip gelen bir cümle olduğunun farkındayım. Bir örnek üzerinden ilerlersek daha anlaşılır olacaktır ama öncesinde temel bilgileri ele alalım. Rust programlama dilinde PhantomData<T> şeklinde generic bir yapı bulunuyor. PhantomData yapısı ile tanımlanan bir veri çalışma zamanında saklanmaz ama derleyici bu türün kullanıldığını bilir ve buna bağlı olarak ownership, borrowing, lifetimes gibi kuralları işletebilir. Zaten bu türe phantom yani “hayalet” denmesinin bir sebebi de budur; çalışma zamanında var olmayan ama derleyici tarafından bilinen bir tür olarak ifade edilebilir.

Profesyonel olarak mesleki hayatımın neredeyse tamamında C# programlama dilini kullanarak geliştirme yaptım. Çoğunlukla bir arayüzün (Web veya Windows) bir iş sürecini tetiklediği ve bunun arkasında dönen yazılım yaşam döngüsünün bir parçası oldum. C#, Java, Go, Python vb. birçok dil bu tip geliştirmeleri hızlandıracak türlü yeteneğe ve kütüphane desteğine sahip. Bununla birlikte uzun zamandır farklı programlama dillerini de öğrenmeye çalışıyorum ve çok uzun zamandır kafamı kurcalayan şeyler var. Bir programlama dilini tam olarak öğrenmek ne demektir?

İlk programlama dilinden bu zamanlara değişen çok şey var. Üniversite yıllarım kişisel bilgisayarların ve internetin yaygınlaştığı World Wide Web devrimine denk geliyor. O vakitler bölümde gösterilen bilgisayar programlama derslerini düşünüyorum da; GW-Basic, Cobol, C ve C++ … Çoğunda belli seviyeye kadar geldiğimizi anımsıyorum. Aynı yıllarda iş dünyasının hızlandırıcı etkisine de şahit olmuştuk. Sadece klavye ve 8 renkten oluşan siyah terminal ekranları çok uzun zamandır mouse imleçleri ile renklenmişti. Dahası artık iş süreçlerinin internet ortamından yürütülebildiği bir dönemdi. Bu dalgayla birlikte ben ve birçok arkadaşım Delphi, Java, Visual Basic gibi dillere yöneldi. Ben ağırlıklı olarak Delphi tarafına yakındım ama zamanla bu yakınlık yerini C# programlama diline bıraktı.

Yazılım geliştirme galaksisinin en zorlu yolculuklarından birisi sanıyorum ki Domain Driven Design (DDD) rotasında ilerlemek. Büyük çaplı kurumsal projelerde hangi mimari ile çalışacağımıza karar vermek bir yana dursun domain sınırlarını belirlemek, model nesneleri kurgulamak, ortak jargonu çıkarmak ve bu jargonu kod içerisinde nasıl temsil edeceğimize karar vermek gibi pek çok zorluğu beraberinde getiren bir yolculuk. Gerçekten farklı yetkinlikler gerektiğine inandığım bu yaklaşımda gün geçmiyor ki yeni bir konuyu tartışalım. İşte henüz gerçekleştirdiğimiz bir tartışma:

Önceki yazımızda, bir fonksiyona aktarılan parametre üzerinde değişklik yapmak istediğimizde bunun C#, Rust ve Zig programlama dilleri tarafındaki ele alınış biçimlerini farklı örneklerle incelemeye çalışmıştım. Nihayetinde ulaştığım noktada bir nesnenin kendisini tanımlayan değerlerin değiştirilmesinde programlama dili ve hatta kullanılacak yazılım mimarisi bazında farklı yaklaşımlar olduğunu görmüştük. Merak ettiğim bir başka konuysa, multi-thread (çoklu iş parçacığı) ortamlarında ortak veriyi değiştirmek. Aynı veri üzerinde birden fazla thread’in okuma/yazma işlemi yapması çok sık karşılaşılan bir durum. Şu anda elimde managed ortamı olan, yerleşik framework kütüphanelerinde üst düzey soyutlamalar sunan C#, bellek güvenliği konusundaki titiz stratejileri ve zorlamaları ile öne çıkan Rust ve C’nin modern bir versiyonu olarak gördüğüm düşük seviyeli sistem programlama dili Zig var.

C# programlama dilinde sınıf nesne örnekleri (Class Object Instance) metotlara varsayılan olarak referans türü (reference type) olarak iletilir. Bu, metot içinde yapılan değişikliklerin çağıran tarafı etkileyebileceği anlamına gelir. Bu çalışmada söz konusu senaryonun Rust ve Zig gibi programlama dillerinde nasıl ele alındığını incelemeye çalışıyorum. Sırf meraktan…Başlamadan şu notu düşmek isterim; Çalışmamdaki amaç üç dili birbiriyle kıyaslamak değil, her bir dilin bu tip senaryolardaki yaklaşımını incelemek. Normal koşullarda bir stok takip programını Rust veya Zig ile geliştirmeyi tercih etmem.

Rust programlama dili ile ilgili maceralarımıza devam ediyoruz. Gerçi geçtiğimiz günlerde sizin de bildiğiniz üzere unwrap metodunun hatalı bir kullanımı sebebiyle internet sitelerinin %20sini koruyan Cloudfare çöktü ve birçok hizmet uzun süre kullanılamaz hale geldi. Konuyla ilgili detaylı bilgilereşu adresteki yazıdan ulaşabilirsiniz. Ferris şaşkın, ferris üzgün!

Şunu fark ettim ki, hangi programlama dili olursa olsun bilgilerimizi taze tutmanın yollarından birisi öğrenilenleri düzenli olarak not haline getirmek ve yazarak kayıt altına almak. Elbette tek yol bu değil. Mutlaka her gün bir parça da olsa kod yazmak, belki bir proje üzerinden ilerlemek (hiçbir yerde kullanılmayacak olsa bile), onunla ilgili bir makale okumak veya bir video izlemek lazım. Ünlü düşünür Johann Wolfgang von Goethe ne demiş “İnsan her gün bir parça müzik dinlemeli, iyi bir şiir okumalı, güzel bir tablo görmeli ve mümkünse birkaç mantıklı cümle söylemelidir.” Yapay zekanın bilgisayar ve internet’ten sonra yeni bir devrim olma çabasıyla koştuğu şu dönemde iyi bir programcı olmak için daha çok okuyalım, daha çok pratik yapalım, daha çok araştıralım, daha çok dinleyelim derim. Elbette yapay zeka araçlarına sırtımızı da dönmeyelim. Nimetlerinden, verimliliğimizi artıracak ölçüde yararlanalım.

Rust, daha çok öğrenme eğrisinin zorluğu ile tanınan bir sistem programlama dilidir desek sanırım yanlış olmaz. Ownership, borrow-checker, lifetimes, macro’lar, mutex vs derken managed ortamlarda (.Net, Java, Go gibi) geliştirme yapan programcıları epeyce zorlayan konu başlıklarına sahiptir. Şahsen, aynı öğrenme eğrisi zorluğunu yaşamış birisi olarak kodladıkça daha fazla tutulacağınız bir dil olduğunu da belirtmek isterim.

Unmanaged ortamlarda gezinmek birçok yeni veya unutulmuş bilgiyi de karşıma çıkarıyor. Geçtiğimiz günlerde devasa boyutlarda JSON tabanlı logları işlerken Interning stratejisi ile belleğe alınan büyük boyutlu veri kümesinin nasıl optimize edilebileceğini öğrendim. Belli senaryolarda (her zaman da avantajlı olmayabiliyor) çok sık tekrar eden string içerikler için heap bölgesinde tahsisat yapılırken gereksiz alan ayırmak yerine, bunları referans eden tekil pointer’lardan yararlanmak ve hatta benzersiz sayısal değerlerle (örneğin pozitif bir tam sayı ile) bir vektör içerisinde tutup (Intern havuzu olarak da ifade ediliyor) erişimi hızlandırmak mümkün. Tam anlamıyla bellek seviyesinde optimizasyon ve performans kazanımı söz konusu.

Bir sistem programlama dili olarak tanınan Rust genellikle C veya C++ dillerinde kritik hatalara sebep olan bazı kod parçalarının henüz derleme aşamasında (compile time) tespit edilerek önlenmesi ile de ön plana çıkmaktadır. Rust’ın kendine has bellek yönetim mekanizması (ownership, borrow checker, lifetime ve RAII mekanizması) esas itibariyle bu tip hataların önüne geçebilmek üzerine tasarlanmıştır. Kaynaklarda bu konuyla ilgili olarak Use Aftre Free, Double Free, Dangling Pointer, Buffer Overflow gibi kavramlara rastlamaktayız. Esasında bunlar gerçekten de zaman içerisinde büyük problemlere neden olan açıkların tanımlarıdır. Internet kaynaklarında geçen bazı tarihi olaylar ise aşağıdaki gibidir.

Enum veri türü genellikle Algebraic Data Type olarak da ifade edilmektedir. Özellikle fonksiyonel programlama dillerinden gelenler için bu veri türü oldukça anlamlı. Tuple ve record gibi türler de bu kapsamda ele alınmakta. Yıllardır C# tarafında kodlama yapan birisi olarak enum türünün bu dilde de faydalı amaçlar için kullanıldığını ifade edebilirim. En kötü ihtimalle kafada karışılık yaratacak sayısal değerlerin anlamlı ifadeleri için kullanılabilecek bir değer türü gibi düşünülebilir. Ne varki Rust dilindeki Enum türü çok daha zengin bir veri modeli sunuyor bana kalırsa. Bunu iddia etmiyorum ama gördüğüm bazı örnekler böyle düşündürüyor. Bu kısa yazımızda C# tarafında veya herhangibir nesne yönelimli dilde icra edeceğimiz bir çözümün Rust tarafında struct yerine enum türü ile ele alınırken nasıl fark yaratabileceğini ele almaya çalışacağız. İşe şu basit senaryo ile başlayalım;

WASM ya da bilinen adıyla WebAssembly tarayıcılarda yüksek performans çalışma zamanına çıkabileceğimiz ortamlar için ideal bir çatı sunar. Bu standart, düşük seviyeli binary format üzerine odaklanır ve C, C++ ve Rust gibi dillerle birlikte kullanılması hızlı bir çalışma zamanına olanak sağlar. Pek tabii WASM’ın kullanım alanı bu dillerle sınırlı değildir. Örneğin Microsoft, Blazor soyutlaması ile WASM ortamı için gerekli çıktıları üretmeyi oldukça kolaylaştırır. WASM’ın binary formattaki çıktılarının tarayıcıda çalıştırılması sırasında yine tarayıcıların sağladığı güvenlik protokolleri işletilir. Dolayısıyla tarayıcının çalıştığı sistem kaynaklarına çıkmak ve zararlı yazılım kodlarını işletmek pek mümkün değildir (“pek” diyorum çünkü hackerların sağı solu belli olmaz) Bununla birlikte sunucu tarafı ile olan iletişim klasik olarak servis çağrıları ile sağlanabilir.

ECS, Entity Component System olarak adlandırılan ve birçok oyun motorunda kullanılan bir yaklaşımı ifade eder. Composition over Inheritance prensibini benimseyen Data Oriented bir geliştirme ortamı sağlar. Rust tarafında Bevy gibi bazı oyun motorları built-in olarak bu yapıyı kullanır. Oyun kodlarının daha okunabilir, yönetilebilir ve bakımı kolay şekilde tesis edilmesinde önemli imkanlar sağlar. Plug-In ve Bundle yaklaşımlarının uygulanmasını da kolaylaştırır.

Uzun zamandır vakit buldukça Rust programlama diliyle uğraşıyorum. Onu öğrenmenin, öğrendiklerimi pekiştirmenin en iyi yollarından birisi de bildiklerimi anlatmak, geri bildirim almak ve daha iyisi için uğraşmak. Bu amaçla değişken türlerinin ele alındığı Hello World uygulaması ile başlayan ve aşağıdaki içeriğie sahip olan “Birlikte Rust Öğrenelim” isimli bir video serisi hazırladım. İş sahasında C# programlama dilini kullandığım için yer yer kıyaslamalar yapmaya, örneklerde gerçek hayat senaryolarını baz almaya gayret ettim.

Rust çoğunlukla bir sistem programlama dili olarak öne çıkıyor. Ancak geniş kütüphane desteği sayesinde bildiğimiz iş modellerinin uygulanabildiği türden birçok program da geliştirebiliyoruz. Bende hem rust kodlama pratiklerimi artırmak hem de basit gerçek hayat senaryolarını uçtan uca ele alabilmek adına bu tip bir uygulama geliştirmeye çalıştım. Sonrasında kamera arkasına geçtim.

Bu yazıyı yazdığım tarih itibariyle SGK dökümüm 20 yıl 1 aydır çalışmakta olduğumu ifade ediyor. Sektöre sigortalı bir çalışan olarak adım attığım 1999 yılında Delphi dili ile geliştirme yapan yeni yetme bir bilgisayar programcısıydım. 20 yıllık iş hayatımın %90’ında ise.Net teknolojileri ve C# programlama dilini kullandım, kullanmaya da devam ediyorum. Bu zaman diliminde telekominikasyondan finansa, eğitimden otomotive farklı sektörlerde çalışma fırsatı buldum. Aslında benim dünyam iş modellerinin nesne yönelimli dillerle buluştuğu, birçok yazılım prensibinin uygulanıp teknik borçların hortladığı, büyük ölçekli teknoloji değişimlerinin yapılıp çevik metodolojilerle ilerlendiği içinde Enterprise kelimesinin sıklıkla zikredildiği devasa bir evren. Bu evrende bir çok Neo ve Trinity var. Gündüzleri kurumsal dünyanın rutin çarklarına adapte olup geceleri farklı dünyaların kapılarını açmaya çalışan. Hal böyle olunca insan ister istemez arada bir düzen dışına çıkıp kendi konfor alanını terk ederek bambaşka maceralara dalmak istiyor. Ben bunun için ağırlıklı olarak farklı programlama dillerini öğrenmeye çalışıyorum. Java, Ruby, Python ve Go bunlardan sadece bazıları. Ciddi anlamda ilgilendiğim bir diğer programlama dili ise Rust.

Sıklıkla vurgulandığı üzere Rust programlama dili bellek yönetimi ve güvenliği konusunda son derece hassas kurallar içeriyor. Değişken sahipliği kuralları ve ödünç alma kontrolü (Ownership, Borrow Checker) olası bir çok bellek probleminin henüz derleme aşamasındayken önüne geçilmesini sağlıyor ancak dilin öğrenme eğrisini de oldukça dikleştiriyor (En azından ilk zamanlarda) Esasında C,C++ türevi sayabileceğimiz Rust’ın bir Garbage Collector mekanizması kullanmaması belleğin çalışma dinamiklerini daha iyi bilmemizi gerektiriyor. Ancak sanılanın aksin Rust’ın bir Garbage Collector mekanizması içermemesi bellek yönetimi yapmadığı anlamına gelmemeli. Nitekim Rust bellek yönetimi için Ownership, Resource Acquisition is Initialization (RAII), Borrow Checker, Lifetimes ve Smart Pointers gibi birçok enstrüman kullanmakta.

Belli bir akış içerisinde ele alınan nesneler belli durumlara sahiptirler. Bu durumlar arasındaki geçişler için fonksiyonlardan yararlanılırken bazı kuralların işletilmesi de istenebilir. Örneğin belli bir duruma sahipken diğer bir duruma geçilmesini engelleyen karar mekanizmaları ve koşullar söz konusudur. Hatta programın belli bir t anında içinde bulunabileceği durumlar bellidir. Nesne yönelimli dillerde bu gibi ihtiyaçlar için davranışsal (Behavioral) kalıplardan olan State tasarım deseni sıklıkla kullanılır. Hatta oyun programlamada State Machine türevli motorlarda nesne durumlarının yönetimi için bu desene ait pratikler söz konusudur.

Bir windows forms uygulamasını ya da bir web sayfasını düşünelim. Hatta birden fazla bileşenden (component) oluşan bir mobil uygulama arayüzünü…Temelde ana kontrol üstüne eklenen başka tekil ve karma bileşenlerden oluşan bir bütün söz konusudur. Şimdi de ana saha üzerine gelen bu kontrollerin nasıl çizildiğini, hangi sırayla eklendiklerini düşünelim. Bir çalışma zamanı motoru büyük ihtimalle belli ortak davranışlara sahip olan bileşenleri, ortamın istediği kıvamda (örneğin HTML olarak) çizme görevini üstlenir. Hatta bu sistemlerde bileşen ağacı öyle bir tasarlanır ki, geliştiriciler isterlerse kendi bileşenlerini de tasarlayıp çalışma zamanı motorunun kullanımına sunabilir.