Elixir'e Python gömmek, sorun değil

• Son birkaç yılda Elixir, Nx (Numerical Elixir) projesiyle makine öğrenimi ve veri alanındaki yeteneklerini genişletiyor
• Nx, Explorer, Axon, Bumblebee, Scholar gibi projeler ortaya çıktı ve Python ile R ekosistemlerinden öğrenilen dersler temelinde gelişiyor
• Başlangıçta Python kütüphanelerine doğrudan bağımlı olmamaya karar verildi; bunun nedeni Elixir'e optimize edilmiş bir tasarım izlemek ve Python ortamı kurulumunun karmaşıklığından kaçınmaktı
• Ancak bugün bu alanda Elixir benimsenmesini yönlendiren şey Livebook
  • Elixir ve Erlang'ın güçlü yanları üzerine kurulu, yeniden üretilebilirlik, dağıtık çalışma ve uygulama geliştirme açısından ön saflarda yer alan bir notebook platformu
  • Livebook sayesinde Elixir ekosistemine ilk kez adım atmak isteyen ekip ve şirketlerin ilgisi giderek artıyor
• Ancak bir engel var
  • Elixir ve Livebook'u altyapılarına dahil etmek isteyen şirketlerin çoğu halihazırda Python tabanlı iş akışları, paketler ve depolar kullanıyor
  • Bu da bu tercihi yapmak için Elixir'de eşdeğer paketler bulmak ya da her şeyi baştan yazmak gerektiği anlamına geliyor; dolayısıyla veri yığınına Elixir eklemenin riskini ve maliyetini artırıyor
• Bunu çözmek için Python yorumlayıcısını Erlang VM içine gömen Pythonx duyuruldu

Pythonx

• Pythonx, Elixir ile Python arasında otomatik veri dönüşümü, kod değerlendirme ve sanal ortam yönetimi özellikleri sunuyor
• Optical Character Recognition (OCR) gerçekleştirmek için pytesseract paketi kullanılabiliyor
• req ile bir görüntü indirildikten sonra Pythonx.uv_init/1 çağrısıyla Python ve bağımlılıkları indirilip başlatılıyor
• Pythonx.eval/2 ile Python kodu çalıştırılıyor ve sonuç bir Elixir string'ine dönüştürülüyor

İç yapı

• Python'ın referans uygulaması CPython, başka uygulamalara gömülebiliyor
• Python yorumlayıcısının temel işlevleri bir C kütüphanesi olarak sunuluyor
• C/C++ uygulamaları bu kütüphaneyi bağlayıp API'leri kullanarak kod çalıştırabiliyor ve nesnelerle etkileşime girebiliyor
• Elixir, Erlang NIF'leri aracılığıyla C/C++ ile birlikte çalışabilirlik sunuyor
• Pythonx, Python'ı gömmek için NIF'leri kullanıyor ve aynı OS süreci içinde çalışıyor
• Python ile Elixir arasında veri aktarımı verimli şekilde gerçekleşiyor

Livebook'un çok dilli desteği

• Pythonx temel alınarak Livebook'a Python desteği ekleniyor
• Aynı notebook içinde Elixir ve Python'ın birbiriyle etkileşime girmesi mümkün hale geliyor
• Livebook, Python'ı ve bağımlılıklarını otomatik olarak kuruyor; Elixir ve Python değişkenleri arasındaki dönüşümleri yönetiyor
• Yeniden üretilebilir bir ortamı garanti ediyor
• Şu anda kod tamamlama, dokümantasyon gibi ek çalışmalar sürüyor ve Livebook nightly indirip kullanılabiliyor

Kullanırken dikkat edilmesi gerekenler ve alternatifler

• Pythonx'in ana amacı, Python iş akışlarını Livebook ve betikler içinde entegre etmek
• Python'ın global interpreter lock (GIL) yapısı nedeniyle, birden fazla Elixir sürecinden Pythonx çağrıldığında eşzamanlılık sınırlamaları olabilir
• Tek bir Elixir sürecinden çağırmak ya da Python kütüphanesinin eşzamanlı çağrıları işleyip işleyemediğini doğrulamak gerekir
• Alternatif olarak System.cmd/3 veya Port kullanılarak birden fazla Python süreci yönetilebilir
• Yapay zeka iş akışları için Bumblebee üzerinden önceden eğitilmiş modeller çalıştırılabilir
• ONNX modellerini çalıştırmak için Ortex kullanılabilir
• LLM tarafında üçüncü taraf API'ler kullanılabilir veya şirket içinde Llama.cpp Docker konteyneri çalıştırılabilir
• HTTP tabanlı arayüzler kullanıldığında Elixir'in Instructor ve LangChain gibi araçlarından yararlanılabilir

Fine projesi

• Pythonx, NIF'ler kullanılarak geliştirildi
• NIF'ler, C ile yazılmış Elixir fonksiyonlarıdır ve çok sayıda boilerplate kod gerektirir
• Bellek yönetimi ve hata işleme açısından karmaşıklık vardır
• Bunu çözmek için C++ tabanlı Fine kütüphanesi geliştirildi
• Fine, veri yapısı dönüşümlerini otomatik olarak ele alır, kaynak nesnelerini güvenli biçimde yönetir ve exception fırlatma özelliği sunar
• NIF yazarken kod miktarını önemli ölçüde azaltabilir

Sonuç

• Numerical Elixir projesinin amacı, Elixir'in veri ve makine öğrenimi ekosisteminde kendine özgü bir kimlik kazanması
• Artık birlikte çalışabilirlik temel hedeflerden biri haline gelmiş durumda
• Pythonx, Python'ı Elixir'e gömerek iki dil arasında şeffaf birlikte çalışabilirlik sağlıyor

[aer0700]

Numpy gerçekten harika...

[GN⁺]

Hacker News görüşleri

• Livebook'un işlevselliği çok etkileyici. Elixir'den C++ NIF'leri aracılığıyla CPython'ı doğrudan çağırıp Elixir'e özgü veri yapılarını döndürmesi oldukça temiz bir yaklaşım

  • Prodüksiyon sunucularında Pythonx kullanmak biraz riskli olabilir. Elixir uygulamasıyla aynı OS sürecinde çalıştığı için Elixir/BEAM uygulamasının güçlü hata kurtarma özelliklerini baypas eder
  • Genel olarak Elixir uygulamalarında, kendi BEAM süreçlerindeki hataları zarif şekilde ele alabilen supervisor tree'ler bulunur; bu da Elixir, Erlang ve Gleam gibi dillerin büyük avantajlarından biridir
  • NIF kullanıldığında, Pythonx içinde ele alınmamış bir istisna tüm OS sürecini ve tüm BEAM süreçlerini durdurabilir
  • Rustler, Elixir'de Rust için popüler bir NIF sarmalayıcısıdır; NIF'lerin çok yararlı olduğu durumlar vardır, ancak tüm uygulamayı durdurabilme riski hesaba katılmalıdır
  • Python veya Rust gibi diğer native kodları Ports kullanarak çalıştırmak bu açıdan daha az risklidir

• Elixir topluluğundaki "tanınmış" kişilerin bu yaklaşımı destekleyip aktif olarak geliştirdiğini görmek güzel

  • VM ve runtime, farklı dillere ve teknolojilere orkestrasyon yapmak için çok uygun; sanki standart bir hat ve bir offload hattı varmış gibi hissettiriyor
  • Offload edilen "riskli görünen" fikirlerle güvenli yürütme arasındaki fark çoğu zaman sadece iş yükü oluyor, ama runtime bunu teşvik ediyor
  • NIF olduğu için bir miktar risk var, ancak ayrı bir BEAM instance'ı başlatıp dağıtımı bunun üzerinden yapmak mümkün

• NIF kullanımının güvenliğiyle ilgili sorunlara dikkat çeken başka yorumlar da var

  • Erlang VM scheduler'ı NIF'leri preempt edemez, bu yüzden uzun süren Python çağrıları VM'i durdurma riski taşır
  • GIL eşzamanlı Python yürütmesini engeller, ancak Erlang çağıran taraf birden fazla Python interpreter'ı çalıştırabildiği için Ports tarafında bu sorun olmaz

• Oldukça bilgilendirici bir yazı. Pythonx'in basit bir alt süreç çağrısı değil, aynı süreç içinde çalıştığının açıkça belirtilmesi iyi olmuş

  • Elixir'den Python'da tanımlanmış bir fonksiyonun nasıl çağrıldığına dair bir örnek de eklenebilirdi

• Elixir'in, yapay zeka yarışında JavaScript ve Python'dan daha uygun olmasına rağmen geride kaldığını görmek sevindirici

  • Elixir'in ML temelini en baştan genişletmeye yönelik erken kararını beğeniyorum, ancak hızla gelişen Python kütüphanelerinden yararlanmanın bir yolunun ortaya çıkması da güzel

• Python'dan Elixir/Erlang ekosistemine geçmek bana hep fazla zor gelmişti, ama Pythonx ile kademeli öğrenme çok daha mümkün görünüyor

  • Python'un GIL sorunuyla ilgili olarak free-threading'in denenip denenmediğini merak ediyorum

• Elixir'de, Python'da da olmasını istediğim bazı özellikler var

  • atom'lar, çoğu şeyin macro olması, pipe |>, gerçek immutability, supervisor tree'ler sayesinde gerçek paralellik ve eşzamanlılık, hot code reloading, hata toleransı

• Elixir'in içinde derin şekilde yer almış ve Python'u da yoğun kullanmış biri olarak bunu çok pratik buluyorum

  • C++ NIF'lerini kolayca oluşturmayı sağlayan Fine kütüphanesi daha da fazla ilgimi çekiyor

• Bu proje ve blog yazısı sanki tam benim için yapılmış gibi hissettiriyor. Denemek istiyorum, teşekkürler