OxCaml - OCaml programlama dili için bir genişletme seti

 (oxcaml.org)
1 puan yazan GN⁺ 2025-06-15 | 1 yorum | WhatsApp'ta paylaş
  • OxCaml, OCaml'a performans odaklı özellikler ekleyen bir genişletme setidir
  • Jane Street'in üretim derleyicisi ve aynı zamanda OCaml'ın gelecekteki özellikleri için deney laboratuvarı olarak işlev görür
  • Güvenlik, kullanım kolaylığı ve öngörülebilirliği ön planda tutarak performans kontrolünü genişletmeyi hedefler
  • Fearless concurrency, layout kontrolü, allocation kontrolü gibi çeşitli alanlarda özellikler sunar
  • Açık kaynak olarak sunulduğundan deneysel kullanıcılar ve araştırmacılar özgürce test edip geri bildirim verebilir

OxCaml'e Giriş

OxCaml nedir

  • OxCaml, OCaml programlama dili için hızla gelişen bir genişletme özellikleri kümesidir
  • Bu, Jane Street'in üretimde kullandığı derleyici ve OCaml'da performans merkezli programlama yeteneklerini geliştirmek için deneysel bir platformdur
  • Amaç, bu genişletme özelliklerini uzun vadede resmi OCaml'a kazandırmaktır

OxCaml'in temel tasarım hedefleri

  • Amaç, program davranışının performansını belirleyen unsurları güvenli, kullanışlı ve öngörülebilir şekilde kontrol etmeyi sağlayan bir ortam sunmaktır
  • Bu kontrol, yalnızca gerçekten gerektiğinde seçmeli olarak sağlanır
  • Her şey OCaml ortamı içinde uygulanır

Somut tasarım yaklaşımı

  • Güvenlik: Programcı verimliliğini ve kodun doğruluğunu korumak için dil düzeyinde güvenliği güçlendirir. Geniş ölçüde unsafe dil kullanımı, kullanım zorluğunu artırır

  • Kullanım kolaylığı: Programlama karmaşıklığını artırmadan, type inference avantajlarını koruyarak daha fazla kontrol sağlar

  • Öngörülebilirlik: Temel performans özelliklerini tip sistemi düzeyinde açıkça görünür kılarak kodun performansını akıl yürütmeyi kolaylaştırır

  • Bu genişletmeler yalnızca gereken yerlerde uygulanan pay-as-you-go yaklaşımını benimser. Yani genişletme özelliklerini kullanmıyorsanız mevcut OCaml'ın sadeliğini ve kalıplarını aynen koruyabilirsiniz

  • OxCaml tüm OCaml programlarıyla uyumludur ve içten içe evrimleşmiş bir OCaml'ı hedefler. Mevcut OCaml'ın sunduğu güvenlik, kullanım kolaylığı ve üretkenliği korur

OxCaml genişletme özelliklerine giriş

Fearless concurrency

  • Doğru eşzamanlılık programlamasının son derece zor olması sorununu çözmek için OxCaml, tip sistemi genişletmeleriyle data race'leri statik olarak engeller

Layouts

  • Programcıların bellekteki veri yerleşimini açıkça belirtmesine olanak tanır
  • Modern donanımdaki SIMD işlemci genişletmelerine yerel erişim de sağlar

Allocation kontrolü

  • Bellek tahsisini ayrıntılı biçimde kontrol eden araçlar sunarak garbage collection (GC) yükünü azaltır ve cache verimliliği ile program determinizmini artırır

Yaşam kalitesi iyileştirmeleri

  • Sistem programlama dışında da günlük çalışmalarda faydalı olan özellikler sunar

    • Polymorphic parameters
    • Include functor
    • Labeled tuples
    • Immutable arrays

OxCaml'in kullanımı ve uygulanması

  • OxCaml açık kaynaktır; bu sayede araştırmacılar, deneysel kullanıcılar ve geliştiriciler test ve geri bildirim yoluyla katkıda bulunabilir

  • Ancak OxCaml'in genişletme özellikleri için kararlılık ve geriye dönük uyumluluk garantisi verilmez (mevcut OCaml programlarıyla geriye dönük uyumluluk ise korunur)

  • Standart OCaml araçlarının OxCaml'e uyarlanmış sürümleri sunulur

    • Paket yönetimi: dune ve opam ile uyumlu
    • Editör entegrasyonu: LSP-server desteği
    • Kaynak kod biçimlendirme ve dokümantasyon üretimi özellikleri içerir

  • Jane Street tarafından yayımlanan çeşitli kütüphane ve araçlar iki biçimde sunulur

    • Upstream OCaml için: OxCaml genişletmeleri çıkarılmış sürüm
    • OxCaml'e özel: genişletme özelliklerinden yararlanan sürüm

  • Bazı genişletme özellikleri çıkarılamaz; bu nedenle ilgili kütüphaneler yalnızca OxCaml'de kullanılabilir. Gerekli genişletmeler resmi OCaml'a entegre edildiğinde OCaml uyumlu sürümün de yayımlanması planlanır

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-15
Hacker News görüşleri

  • Janet Street ekibinin yaptığı bu projeyle ilgili olarak, bu kişilerin konuk olduğu bir podcast bölümünde OCaml ile çalışırken performans değerlendirmeleri hakkında ilginç bir tartışma olduğunu belirtmek isterim
    GC kullanan bir dili aşırı düşük gecikmeli ortamlarda kullanmanın zorlukları sürüyor
    Örneğin, GC duraklaması yüksek frekanslı alım satımın ortasında olursa ciddi bir sorun yaratabilecek bir durum
    podcast bağlantısı paylaşılıyor

    • Gerçekten de Twitter'da Ron Minsky'ye düşük gecikmeli uygulamalarda neden Rust kullanmadıklarını doğrudan sormuş biri olarak deneyim paylaşılıyor
      Ron'un yanıtında Rust'ın harika olduğu kabul edilirken, tüm kodu tek bir dilde tutmanın değerine odaklanılıyor
      Türler, araçlar, kütüphaneler, deyimsel kullanım biçimleri gibi unsurların paylaşılabilmesi ve projeler arasında geçiş kolaylığı büyük avantaj
      Ayrıca OCaml'ın kendi içinde Rust'ın başlıca avantajlarını iyi biçimde entegre ederek kademeli kullanım mümkün olacak şekilde geliştiği de belirtiliyor
      Rust'ın dezavantajları olarak uzun derleme süreleri, karmaşık tür sistemi ve async/await işleyişine dair memnuniyetsizlik anılıyor
      Her şeyden önce, çok çeşitli çalışma ortamlarına uygun tek bir dil aracı istedikleri vurgulanıyor
      ilgili tweet bağlantısı

    • Asıl temel sorunun GC dili olmasının değil, tüm GC dillerini tek bir kategori gibi ele alan bakış açısının problemli olduğunun altı çiziliyor
      Gerçekten önemli olan sorun, GC dillerinin stack ve değer türlerinin açık biçimde manipülasyonunu desteklememesi olduğunda ortaya çıkıyor
      GC dillerinin üretkenliğini korurken sistem seviyesinde kodlama için ayrıntılı seçenekler istiyorsanız Cedar, Oberon ailesi, Modula-3, D, Nim, Eiffel, C#, F#, Swift ve Go gibi alternatifler anılıyor

    • GC kullanan çalışma ortamları hakkında genel bir noktaya değinilerek, GC duraklamalarını en aza indirmek için JVM'nin paralel toplama algoritmaları gibi seçeneklerin kullanılabileceği söyleniyor
      Ancak bu yöntem tek tip bir garanti sunmadığından sisteme fazladan RAM ayırmak gerekebiliyor
      Daha da ileri gidip sunucuları bilerek fazla kapasiteyle sağlayarak bazı sunucuların kısa süreliğine havuzdan çıkmasına izin verip "offline GC" uygulama yöntemi de var
      Bu yaklaşım istek yönlendirici ve sunucular arası işbirliği gerektirdiğinden, ancak sunucu ölçeklendirmesi için yeterli bütçe varsa anlamlı
      JVM paralel GC açıklaması

    • GC compaction sorunları yüzünden birçok sistemin zorlandığına dair deneyim paylaşılıyor
      Alım satım sistemlerinde genellikle açılıştan sonra allocation'ı en aza indirme politikası uygulanıyor
      JS tarafında "Zero" adında, allocation yapmayan yardımcı araçlar sunan bir kütüphane var

    • Bağlantı kontrol edilmemiş olsa da, alım satım gibi piyasa açılış ve kapanış saatleri olan bir ortamda seans sırasında GC'yi devre dışı bırakıp kapanıştan sonra yeniden başlatmanın mümkün olabileceği yorumu yapılıyor

  • Bu fork'tan upstream'e ilk alınan özelliğin labeled tuple olduğu vurgulanmak isteniyor
    OCaml 5.4'te desteklenmesi planlanıyor
    upstream PR bağlantısı
    ilgili tartışma bağlantısı

    • Bu özellik biraz küçük görünebilir ama oldukça heyecan verici bulunuyor
      Özelliğin yazarının ML2024'te sunduğu makale ve video da ek bilgi olarak paylaşılmak isteniyor
      Youtube videosu
      makale PDF

    • labeled tuple örneği olarak çiftlerde sıra hatalarını önleyebilmesi veriliyor, ancak kişisel olarak F#'ın anonim record yapısı daha çok beğeniliyor
      Örneğin {| product = 6; sum = 5 |} biçiminde alan sırasının önemi olmadığı için hata riski yok

    • Bu fork'taki immutable array de 5.4'e alınmış durumda, sadece sözdizimi biraz farklı

    • Anonim labeled struct ve enum'ların programlama dillerinde en çok istenen özellikler arasında olduğu vurgulanıyor
      Örnek olarak Rust'ta hem labeled hem unlabeled struct tanımlanabiliyor
      Ancak fonksiyon dönüş türünde anonim labeled struct kullanılamaması hayal kırıklığı yaratıyor

      struct Foo(i32, i32);
struct Bar{sum: i32, product: i32}
fn can() -> (i32, i32)
fn cant() -> {sum: i32, product: i32}

  • Bu fork'un SIMD desteklediğini bilmiyordum
    unboxed type, açık stack allocation özelliği ve Windows desteği de eklenirse, kişisel olarak OxCaml'ın F# yerine game dev gibi tüketici odaklı ortamlarda gayet kullanılabilir hale gelebileceği söyleniyor

    • Şu anda 128-bit SSE/NEON çalışıyor ve yakında AVX desteği de gelecek
      Windows desteği tamamen engellenmiş değil ama biraz çalışma gerekiyor
      Kişisel olarak OxCaml'a SIMD desteğinin eklenmiş olması özellikle not ediliyor

  • Yeni bir opam switch kullananlar için ortam değişkeni ayarı ipucu paylaşılıyor
    env OCAMLPARAM="alert=-unsafe_multidomain,_," opam install cohttp-lwt-unix
    alert'lerin hataya yükseltilmesi, mevcut paketlerin kurulumu sırasında gereksiz yere kurulumun bozulmasına yol açabiliyor
    İlgili alert'i OCAMLPARAM ortam değişkeniyle devre dışı bırakarak kurulum sorunları önlenebilir

  • Golang için mükemmel bir vscode eklentisine alışkın olduğunu söyleyerek, OCaml ekosisteminin de vscode ile bütünleşme planı olup olmadığı soruluyor
    vscode entegrasyonu kurulumu çok kolaylaştırmıştı

    • OCaml vscode eklentisinin kendisi zaten dune, menhir, reason gibi yeni sözdizimlerinin entegrasyonunu büyük ölçüde destekliyor
      OxCaml popülerlik kazanırsa entegrasyonun ilerlemesi de doğal olarak mümkün görünüyor
      Kişisel olarak emacs kullandığım için ayrıntılı yorum yapamam ama bunun doğal akış olacağı düşünülüyor

  • OcaML'in mikro boyutlu bir sürümünden söz edilmek isteniyor
    mlite proje bağlantısı

  • Bu projenin kamuya açılma amacının, LLM'lerin bilgiyi indeksleyip açık modellerde kullanması olup olmadığı soruluyor

    • LLM'lerin normal OCaml konusunda bile çok zayıf olduğu ve veri miktarının az olduğu, OxCaml içinse materyalin daha da kıt olduğu düşünüldüğünde bunun hiç olası görünmediği söyleniyor
      Bu amaç için kendi dokümantasyon MCP'sini oluşturmak daha anlamlı olurdu

    • Sinyal değeri yeterince güçlü olmadığı için pratikte pek anlamı olmadığı belirtiliyor
      Örneğin Gleam tamamlama konusunda bile LLM performansı çok düşük; açık desenler ve hata yönergeleri verilse bile başarısız olabiliyor
      Bu yüzden OxCaml hakkında bilgi sağlama amacı için sinyalin zayıf kaldığı düşünülüyor

  • OxCaml'ın ML ailesi lehçesinin bir lehçesinin uzantısı olması ilginç bir gözlem noktası olarak görülüyor
    Bir sonraki adımın nasıl görüneceği merakla bekleniyor

    • Var olan dillere sürekli özellik ekleyenlerle en baştan yeni dil yaratanlar arasında hangisinin daha problemli olduğu zaman zaman sorgulanmış
      Kendisi ikinci gruba daha yakın ama programcıların araçları oldukları gibi bırakmama yönünde genetik bir eğilimi olduğu düşünülüyor

    • Belki F#'ı da tanıtabilirsiniz diye yarı şaka bir çağrı yapılıyor

  • Bu projenin "oxidized" adını kullanmasının nedeninin, Rust'ın hedeflediği özelliklerle ilgili olup olmadığı; yani gerçekten Rust kullanmasından değil, fearless concurrency, GC'den kaçınma gibi hedeflerden geldiği doğrulanmak isteniyor
    İsmin biraz kafa karıştırıcı olabildiği ifade ediliyor

    • Aslında Rust adının pas değil, 'Rust' adlı bir küf türünden geliyor olması küçük bir ironi olarak belirtiliyor

    • Jane Street'in uzun zamandır 'Oxidizing OCaml' adlı bir blog serisi yürüttüğü paylaşılıyor

    • Gerçekten de "Oxidizing OCaml with Modal Memory Management" başlıklı makalede de bu terim kullanılmıştı ve makalenin içinde 'oxidize' sözcüğü açıkça tanımlanmış ya da alıntılanmış değil
      Bu biraz tuhaf ama aynı zamanda oldukça akılda kalıcı bir ad gibi duruyor

    • Rust tarafının, özel tracing GC ile entegrasyon konusunda bu proje Rust ile özellik eşitliğine ulaşana kadar daha pratik kalacağı öngörülüyor; çünkü bu yaklaşım genel grafik yapılarıyla çalışırken de en yüksek performansı hedefleyebiliyor
      Aksi halde bunun sadece çok sayıda OxCaml ilişkili kod tabanına sahip oldukları için sürdürülen bir çaba gibi göründüğü değerlendiriliyor