Erlang’ın geliştiricisi Joe Armstrong, Erlang’ın son 20 yıldaki gelişimi ve dilin geleceğinde neler olduğu hakkında Computerworld’e bilgi vermek için zaman ayırdı.
Erlang adının arkasında ne var?
Ya “Ericsson Language”ın kısaltmasıdır ya da Danimarkalı matematikçi Agner Krarup Erlang’ın adını taşır. Hangisinin doğru olduğunu hiç açıklamadık, dolayısıyla tahmin etmeye devam etmeniz gerekecek!
Geliştirilmesini ne tetikledi?
Bu bir kazaydı. “Yeni bir programlama dili geliştirmek” gibi bir proje hiçbir zaman olmadı. Ericsson’da “telefon uygulamalarını programlamanın daha iyi yollarını bulmak” amacıyla yürütülen bir araştırma projesi vardı ve Erlang bunun sonucu olarak ortaya çıktı.
Dilin çözmeyi amaçladığı belirli bir problem var mıydı?
Evet, küçük bir telefon santrali için en iyi şekilde bir kontrol programı yazmak istiyorduk. Erlang’ın pek çok özelliği bu probleme kadar geri izlenebilir. Telefon santralleri asla durmamalıdır; bu nedenle sistemi durdurmadan kodu yükseltebilmemiz gerekir. Uygulama hiçbir zaman felaketle sonuçlanan bir şekilde çökmemelidir; bu yüzden çalışma zamanında yazılım ve donanım hatalarıyla başa çıkmak için gelişmiş stratejiler geliştirmemiz gerekiyordu.
Erlang neden açık kaynak olarak yayımlandı? Açık kaynak Erlang’ın mevcut sürümü nedir?
Erlang’ın Ericsson dışına yayılmasını teşvik etmek için. Mevcut sürüm 13’tür—yani oldukça olgundur. Yılda yaklaşık iki yeni sürüm yayımlıyoruz.
Erlang ekosistemi nasıl?
Mimari ve uygulamalar hakkında çok sayıda tartışma yaptığımız ve yeni başlayanların sorunlarını çözmeye yardımcı olduğumuz çok aktif bir e-posta listesi var.
Şu anda Erlang’a adanmış birkaç konferans bulunuyor. En eskisi, yılda bir kez Stockholm’de düzenlenen Erlang User Conference’tır. ACM Functional Programming Conference, son birkaç yıldır bir ‘Erlang günü’ düzenliyor ve geçen yıl ‘Erlang Factory’ başladı.
Erlang Factory yılda iki kez düzenleniyor. Son konferans Palo Alto’daydı ve bir sonraki Londra’da olacak. Bu konferanslar birer coşku patlamasıdır. Hiç durmayan büyük ölçekli sistemler kurmak isteyen insanlar için bir buluşma noktası hâline geliyorlar.
Genel bir tablo çıkarmak zor. Erlang, hata toleranslı sunucular yazmak için en uygun dildir. Bunlar, son kullanıcıya özellikle görünür olmayan şeylerdir. Bir masaüstü uygulamanız varsa, nasıl gerçekleştirildiğini öğrenmek oldukça kolaydır. Ancak bir sunucu için bu çok daha zordur. Bir sunucuyla konuşmanın tek yolu, üzerinde uzlaşılmış bir protokoldür; dolayısıyla sunucunun nasıl gerçekleştirildiği hakkında hiçbir fikriniz olmaz.
İş dünyası için Erlang ile yazılmış gördüğünüz en ilginç program(lar) hangileri?
Buna cevap vermek zor; pek çok iyi uygulama var.
Muhtemelen Ejabberd; bu, açık kaynaklı bir Jabber/XMPP anlık mesajlaşma sunucusudur. Ejabberd, pazar lideri XMPP sunucusu gibi görünüyor ve XMPP üzerinde çalışan Google Wave gibi şeyler, muhtemelen pek çok insanı XMPP sunucuları üzerinde uygulama geliştirmeye çekecektir.
Bir diğer aday, AMQP protokolünün açık kaynaklı bir uygulaması olan RabbitMQ olabilir. Bu, dilden bağımsız bir şekilde güvenilir ve kalıcı mesajlaşma sağlar. Paylaşılan bellek olmadan ve tamamen mesaj geçişine dayalı sistemler kurmak, ölçeklenebilir ve güvenilir sistemler yapmanın gerçekten tek yoludur. Dolayısıyla AMQP, Erlang’ın dünyaya bakışıyla çok iyi örtüşür.
Dil ne kadar esnek, genel amaçlı popüler programlama dillerinin yanında nasıl konumlanıyor?
Söylemesi zor. Sıralı performansta kaybettiklerimizi paralel performansta geri kazanıyoruz.
Çok çekirdekli veya bulut altyapısını tam olarak kullanabilmek için programınızın paralelliği kullanması gerekir. Sıralı bir program, çok çekirdekte daha hızlı çalışmaz; hatta zamanla daha yavaş çalışır, çünkü güç tasarrufu için gelecekte saat hızları düşürülecektir. Eğilim, daha fazla ama daha yavaş çekirdeğe doğrudur. Bu nedenle paralel program yazmanın kolaylığı performans açısından hayati önem taşır.
Erlang dünyasında paralel algoritmaların tasarlanması ve uygulanması konusunda yirmi yılı aşkın deneyimimiz var. Sıralı işlem hızında kaybettiklerimizi paralel performans ve hata toleransında geri kazanıyoruz.
Dili, başlangıçta amaçlanmayan bir şekilde kullanıldığını hiç gördünüz mü?
Pek çok kez...
Erlang’ın sınırları nelerdir?
Burada dili uygulamadan ayırmak gerekir. Uygulamanın çeşitli sınırları vardır; örneğin oluşturabileceğiniz maksimum süreç sayısına dair bir üst sınır bulunur. Bu sınır çok yüksektir ama yine de bir sınırdır.
Önümüzdeki 10 ila 20 yıl içinde, çip başına bir milyon çekirdeğe ve petabayt belleklerine sahip olabilir ve “hey—bütün bunları adresleyemiyoruz” diye fark edebiliriz; bu durumda uygulamayı değiştirmemiz gerekecek—ama dil aynı kalacaktır.
Bulutta çalışan devasa programların, henüz düşünülmemiş yeni mekanizmalara ihtiyaç duyduğunu da keşfedebiliriz; bu durumda dili değiştirmemiz gerekebilir.
Dilin geliştirilmesi sırasında aşmanız gereken özellikle zor veya sinir bozucu problemler var mıydı?
Evet. Bir mühendisin işi problemleri çözmektir. Benim mühendis olmamın nedeni de bu. Problemler zor olmasaydı işi yapmanın bir anlamı olmazdı; ancak zamanın yüzde 95’inde problemler “henüz çözülmemiş” durumdadır ve bu sinir bozucudur. Hayal kırıklığı inovasyonla el ele gider—işlerin nasıl yürüdüğünden rahatsız olmasaydınız, yeni şeyler geliştirme ihtiyacı görmezdiniz.
Üçüncü taraf kütüphane bulunabilirliği nasıl?
Parça parça. Bazı alanlarda son derece parlak, diğerlerinde ise yok denecek kadar az. Bu bir tavuk-yumurta durumudur. Çok sayıda aktif geliştirici olmadan pek çok üçüncü taraf kütüphane olmaz ve çok sayıda kütüphane olmadan da geliştiricileri çekemeyiz.
Olan biten şu ki, pek çok erken benimseyen Erlang öğreniyor ve onu bizim hayal etmediğimiz şeyler için kullanıyor. Bu nedenle, uygulamalar geliştirmek için kullanabileceğiniz CouchDB (bir veritabanı) ve MochiWeb (bir web sunucusu) gibi şeyler görüyoruz.
Programlama dilleri, çok çekirdekli işlemciler nedeniyle giderek daha fazla iş parçacığından yararlanıyor. Bu durum Erlang’ın gelişimini ileriye taşır mı?
Kesinlikle. 1986’dan beri paralel programlama yapıyoruz ve artık programlarımızı çalıştırabileceğimiz gerçek paralel donanımlara sahibiz; dolayısıyla teorilerimiz gerçeğe dönüşüyor. Paralel programların nasıl yazılacağını biliyoruz, bunları çok çekirdekler üzerinde nasıl dağıtacağımızı biliyoruz. Paralel programlarımızı nasıl hata ayıklayacağımızı da biliyoruz. Burada bir avantajımız var.
Bilmediğimiz şey, bir çok çekirdekten en iyi performansı elde etmenin en iyi yolunun ne olduğu; bu yüzden perde arkasında pek çok ince ayar yapıyoruz.
Erlang programcısı için iyi haber şu ki, çok çekirdekli programlamanın sorunlarının çoğunu büyük ölçüde göz ardı edebilirler. Sadece Erlang kodu yazarlar ve Erlang çalışma zamanı sistemi, yürütmeyi mevcut çekirdekler üzerine en uygun biçimde yaymaya çalışır.
Erlang’ın her yeni sürümü yayımlandıkça, çok çekirdeklere eşlemeyi iyileştirmeyi umuyoruz. Bunların hepsi son derece dinamiktir; gelecekte hangi çok çekirdekli mimarilerin kazanacağını bilmiyoruz. Az sayıda karmaşık çekirdek mi göreceğiz, yoksa “çip üzerinde ağ” mimarisine sahip (Tilera yongalarında ya da Intel Polaris yongasında olduğu gibi) çok sayıda basit çekirdek mi? Bunu gerçekten bilmiyoruz.
Ama ne olursa olsun, Erlang en yeni yonga setlerine uyum sağlayarak orada olacak.
Gelişiminin ilk günlerinde bu eğilimin geleceğini görüyor muydunuz?
Hayır. Her zaman “bir gün her şey paralel olacak” derdik; ancak çok çekirdek meselesi biz bakmıyorken sessizce geldi. Sanırım donanım tarafındaki insanlar bunu önceden biliyordu, ama değişimin bu kadar hızlı gelmesi biraz sürpriz oldu. Bir anda dizüstü bilgisayarım çift çekirdekli oldu ve masaüstümde dört çekirdek belirdi.
Ve vay canına — çift çekirdek geldiğinde, bazı Erlang programlarım hiçbir değişiklik yapmadan iki kat hızlı çalıştı. Diğer programlar ise iki kat hızlanmadı. Dolayısıyla programın neden iki kat hızlı çalışmadığı, bir anda gerçekten ilginç bir problem hâline geldi.
Sıcak değiştirme (hot swapping) ne gibi avantajlar sunar?
Şaka yapıyorsunuz. Benim dünyamda bir kez başlatılan ve ondan sonra asla durmayan sistemler yapmak isteriz. Zamanla evrim geçirirler. Bir sistemi kodu yükseltmek için durdurmak, bir başarısızlığın kabulüdür.
Erlang, bir uygulamada kodu sıcak şekilde değiştirmek için gereken pek çok ince ayrıntıyla ilgilenir. Çalışırken kodu değiştirirken oldukça dikkatli olmanız gerektiğinden, problemi tamamen çözmez; ancak Erlang’daki yerleşik mekanizmalar bunu ele alınabilir bir problem hâline getirir.
Fonksiyonel mi, buyurucu (imperative) mı? Bize ne söyleyebilirsiniz?
Bu, programlamadaki bir sonraki adımdır. Fonksiyonel programlar büyük ölçüde okulda öğrendiğimiz matematik gibi davranır.
Fonksiyonel programlama, buyurucu programlarda ortaya çıkabilen hata sınıflarının tamamını ortadan kaldırması açısından iyidir. Saf fonksiyonel programlarda değiştirilebilir veri yoktur ve yan etkiler yasaktır. Veri değiştirildiği sırada kilitlemek için kilitlere ihtiyacınız olmaz, çünkü değişim yoktur. Bu durum eşzamanlılığı mümkün kılar; herhangi bir fonksiyonun tüm argümanları gerekirse paralel olarak değerlendirilebilir.
Yorumlanan mı, derlenen mi? Neden bu seçenekler?
Bence bu ayrım yapaydır. Erlang, soyut makine koduna derlenir ve bu kod daha sonra yorumlanır. Gerekirse soyut makine kodu yerel koda derlenebilir. Bu, JVM ve .NET’te kullanılan felsefenin aynısıdır.
Kodu yorumlamak mı yoksa derlemek mi gerektiği tamamen mühendislik sorusudur. Performans, bellek boyutu, taşınabilirlik vb. gereksinimlere bağlıdır. Kullanıcı açısından bir fark yoktur. Bazen derlenmiş kod yorumlanmış koddan daha hızlıdır, bazen de daha yavaştır.
Geriye baktığınızda, dilin gelişiminde değiştirmek isteyeceğiniz bir şey var mı?
Bir şeyleri kaldırmak acı verici derecede zor çıkıyor. Bir dile özellik eklemek çok kolaydır, ama şeyleri kaldırmak neredeyse imkânsızdır. İlk günlerde dile gönül rahatlığıyla şeyler ekler, kötü bir fikir olduklarında da kaldırırdık.
Artık bir şeyleri kaldırmak neredeyse imkânsız.
Buradaki ana sorun testtir. Kelimenin tam anlamıyla milyonlarca satır kod içeren sistemlerimiz var ve bunları test etmek uzun zaman alıyor; bu yüzden yalnızca geriye dönük uyumlu değişiklikler yapabiliyoruz.
Dile eklediğimiz bazı şeyler, geriye dönüp baktığımızda, pek de parlak değildi. Makroları, include dosyalarını ve kayıtları (records) ele alış biçimimizi memnuniyetle kaldırırdım. Ayrıca dilin kendisinin evrim geçirmesine izin veren mekanizmalar da eklerdim.
Uygulama yazılımının evrim geçirmesine izin veren mekanizmalara sahibiz, ancak dilin ve kütüphanelerin kendisi için yok. Dilin bir parçası olarak sürüm denetimi mekanizmalarına ihtiyacımız var. Ama bunu nasıl yapacağımı bilmiyorum. Uzun zamandır bunun üzerine düşünüyorum.
Git veya Subversion gibi harici sürüm denetim sistemlerine sahip olmak yerine, sürüm denetimi ve yeniden düzenlemenin (refactoring) dilin kendisinin içine, ince taneli içgörü ve sürüm kontrolü mekanizmalarıyla yerleştirildiğini görmek isterdim.
Bilgisayar bilimi öğrencileri sonunda yemek yiyen filozofları öğrenmek zorunda mı kalacak?!
Kolay — onlara daha fazla çatal verin.
Son olarak, Erlang’ın geleceğini nerede görüyorsunuz?
Bilmiyorum.
Erlang’ın kaderi, gelecekteki programlama dillerinin tasarımını etkilemek gibi görünüyor. Birkaç yeni programlama dili, eşzamanlılık konusunda Erlang’ın düşünme biçimini benimsedi; ancak hata toleransı ve dinamik kod değiştirme mekanizmaları konusunda aynı yolu izlemediler.
Bulut bilişime ve devasa ölçekte çok çekirdekli sistemlere doğru ilerledikçe, hayat ilginçleşiyor. Paralel süreçlerin büyük bileşimlerini nasıl programlayacağız? Aslında kimse bilmiyor. Bulut tam olarak nedir? Yine, kimse bilmiyor.
Bence sistemler evrim geçirdikçe, büyük ölçekte hata toleranslı sistemleri nasıl programlayacağımızı çözerken Erlang bir yerlerde var olacak.