Griffin - Clojure ile oluşturulmuş, tam düzenlemeye tabi API tabanlı banka

 (juxt.pro)
2 puan yazan GN⁺ 2023-08-30 | 1 yorum | WhatsApp'ta paylaş
  • Fintech şirketlerinin hesap açma, ödeme ve onboarding süreçlerini doğrudan banka API'si gibi entegre edebilmesini sağlayan bir banking-as-a-service platformu; Mart 2023'te Birleşik Krallık bankacılık lisansı alarak düzenlemeye tabi bir banka haline geldi
  • Sistem AWS üzerinde Kubernetes üzerinde Clojure ile çalışıyor; girdilerin çoğunu olaya dönüştüren bir event sourcing yapısını FoundationDB depolamasıyla birleştiriyor
  • FoundationDB, transaction ve eşzamanlı yazmayı destekleyen strict-serializable bir key-value store; Griffin ise Datascript'in portlandığı Datomic benzeri bir katmanla atomik okuma-yazma kurguluyor
  • İş mantığı, Clojure map alıp Clojure map üreten küçük log processor'lar etrafında ayrıştırılıyor; dış sistem erişimi protokoller ve özel proc'larla sınırlandırılıyor
  • Clojure'un değişmezlik yaklaşımı ve denetim kaydına uygunluğu finansal hizmet gereksinimlerine uyuyor; uzaktan işe alımla birleştiğinde küçük aday havuzlarında bile yüksek kaliteli mühendis bulmayı kolaylaştırdığı düşünülüyor

API olarak sunulan düzenlemeye tabi banka platformu

  • Griffin, fintech şirketlerinin bankacılık işlevlerini hızlı ve güvenli biçimde entegre etmesine yardımcı olan bir banking-as-a-service platformudur
  • Mart 2023'te Financial Conduct Authority'den UK banking license alarak tamamen düzenlemeye tabi bir Birleşik Krallık bankası oldu
  • Griffin kendisini “the bank you can build on” olarak tanımlıyor ve bankalar için AWS benzeri bir altyapı olmayı hedefliyor
    • müşteri onboarding API'si
    • banka hesabı oluşturma API'si
    • ödeme API'si
  • Fintech'lerin bu tür işlevleri sunabilmesi için yasal olarak bir bankayla çalışması gerekir; bugün ise çoğu zaman mainframe kullanan geleneksel high street bank'lerle çalışmak zorunda kalırlar
  • Griffin, bankacılık lisansını ve teknoloji platformunu birlikte sunarak geleceğin fintech'lerinin üzerinde hizmet inşa edebileceği bir temel olmayı amaçlıyor
  • Lisans alınmış olsa da o sırada mobilization aşamasındaydı ve bu aşama denetimin tamamlanması, ek fon sağlanması ve kod yazımının bitmesiyle sona erecekti
    • hedef zamanlama o yılın Q3 veya Q4 dönemiydi

Clojure'u seçme gerekçesi

  • Clojure; değişmezlik, ifade gücü ve denetim kaydı gerektiren finansal hizmetlerle uyumu nedeniyle platform dili olarak seçildi
  • Allen Rohner, 2007 civarında Rich Hickey'nin Clojure sunumunu izledikten sonra bunun kendi yaptığı Lisp'ten daha iyi olduğuna karar verdi
  • 2011'de CircleCI'ı kurduktan sonra Clojure'u uzun süre kullandı; CircleCI'da iyi çalıştığını ve finansal hizmetler için de uygun olduğunu düşündü
  • JVM konusunda ilk birkaç yıl avantajlarını tam olarak fark etmese de sonrasında bunu büyük bir artı olarak değerlendirmeye başladı
    • diğer niche startup language seçenekleri kütüphane eksikliği, derleyici ve runtime performansı sorunları yaşayabilir
    • JVM bu riskleri azaltan bir temel sağlar
  • Dil seçimi şirketin karakterini yansıtır; Python ya da Java'ya kıyasla Clojure'un daha güçlü bir tercih olduğu düşünüldü
  • Niche bir dil kullanıldığında aday sayısı azalabilir ama üst düzey yetenek oranı artabilir diye değerlendiriliyor

FoundationDB ile kurulan veri katmanı

  • Griffin mimarisi Clojure, Kubernetes ve AWS üzerinde çalışıyor ve neredeyse tamamen event sourcing ile kurulmuş durumda
  • Veritabanı olarak FoundationDB kullanılıyor
  • FoundationDB, transaction destekleyen strict-serializable key-value store'dur
    • Silicon Valley çıkışlı bir startup olarak başladı
    • 2015'te Apple tarafından satın alındı
    • 2018 civarında Apple tarafından yeniden open source olarak yayımlandı
    • Apple bunu iCloud production ortamında kullanıyor
  • Apple, FoundationDB'nin saniyede yaklaşık 1 milyon transaction işlediğini gösteren benchmark'lar yaptı
  • strict serializable, veritabanı tutarlılığında en yüksek seviye olarak kabul edilir
  • Temel API, SQL'den çok get a key, set a key yaklaşımına yakındır
  • Griffin, Datascript'i FoundationDB'ye portlayarak Datomic benzeri bir katman oluşturdu
    • strict-serializable veri deposu üzerinde atomik sorgular yapılabiliyor
    • transaction tabanlı okuma ve yazmayı destekliyor
  • FoundationDB, single writer değil; concurrent writes desteği sunuyor
  • Griffin'in saniyede 1.000'den fazla transaction'a ihtiyacı var ve bu gereksinim karşılanıyor

Event sourcing ve log processor

  • Griffin sistemindeki tüm girdiler birer event'e dönüşür
    • API request
    • üçüncü taraf webhook
  • Event'ler message log'a girer ve Griffin'de bir event, type alanı ile key/value ve spec içeren bir Clojure map'idir
  • Tüm sistem event'lere verilen tepkiler etrafında kuruludur
  • Küçük log processor'lara proc adı verilir
    • bir proc, “message type A'yı dinler ve tepki olarak B veya C emit eder” şeklinde çalışır
    • her proc kendi private state'ine sahiptir
  • Mesaj akışı bir grafik halinde kurulabilir ve event'ler terminal node'a ulaşana kadar ilerler
  • Örneğin web sunucusu bir HTTP event alır, ardından bir ödeme talebini kaydeder ve sonra payment created ya da payment rejected event'ini bekleyip istemciye yanıt verir
    • bu akış Netty asynchronous HTTP handler kullanır
  • Tüm event'ler FoundationDB'ye yazılır
    • her log processor, FoundationDB içinde kendi namespace'ine benzer private data alanına sahiptir
    • proc'lar belirli event türlerinin yazılmasını izler ve kendi event'lerini yeniden FoundationDB'ye yazar
  • FoundationDB, DB key değişikliklerini izleme özelliği sunduğu için reactive system kurmayı verimli hale getirir
  • Veritabanı ile ayrı bir mesajlaşma sistemi birlikte kullanıldığında race condition riski doğar
    • örneğin bir mesaj diske, diğeri ağa giderse gözlemleyen taraf bunları farklı sırayla görebilir
    • Griffin bu yapıyı tek bir yola indirgemek için FoundationDB'ye yazma yaklaşımını kullanır

Monorepo ve iş mantığının yalıtılması

  • Griffin monorepo kullanıyor
  • Şu anda verimlilik için birçok log process aynı JVM üzerinde çalışıyor
    • her biri bağımsız olduğu için ayrı JVM process olarak da çalıştırılabilir
    • şu anda low hundreds ölçeğinde proc tek bir JVM üzerinde çalışıyor
  • İş mantığı mümkün olduğunca basit ve temiz tutuluyor
    • tek tek log processor namespace'leri neredeyse tamamen pure Clojure'dan oluşuyor
    • neredeyse hiç üçüncü taraf kütüphane yok
    • side effect de çok az
  • Bir log processor, Clojure map alıp bir veya daha fazla Clojure map döndüren bir fonksiyona yakındır
  • Proc state içinde protokoller vardır; böylece karşı taraftaki gerçek implementasyonu bilmeye gerek kalmaz
    • test sırasında in-memory database kullanılabilir
    • gerçek çalışmada FoundationDB'ye yazılabilir
  • Dış dünya ile arayüz olabildiğince küçük tutulur
  • Proc'ların çoğu yalnızca kendi iç durumuna yazabilir ve mesaj emit edebilir
    • ağ çağrısı yapamaz
    • AWS çağrısı yapamaz
    • başka dış etkileşim yoktur
  • Dış sistemlerle iletişim gerektiğinde özel dispatch handler'ı olan özel proc'lar kullanılır
    • AWS ile iletişim kuran proc
    • clearing bank ile iletişim kuran proc
    • diğer API'lerle iletişim kuran proc

Kullanılan Clojure ekosistemi

  • İş mantığının içinde neredeyse hiç kütüphane kullanılmıyor
  • API web server veya service gateway gibi dış dünya ile temas eden alanlarda şunlar kullanılıyor
    • ring
    • netty
    • reitit
  • Clojure spec yaygın biçimde kullanılıyor
  • AWS entegrasyonu için Cognitect aws-api kütüphanesi kullanılıyor
  • Uygulama yapılandırması ve kaynak yönetiminde closeable blog yazısına dayalı bir yaklaşım benimseniyor
    • Component veya Integrant olmadan with-open yeterlidir anlayışıyla hareket ediliyor
    • lexical scope elde ediliyor ve binding tanım sırası yapılandırma sırasını dayatıyor
    • Closeable implemente etmeyen state nesneleri veya stateless nesneleri with-open bloğunda tanımlamak için küçük bir helper kullanılıyor

İşe alım ve ekip yapısı

  • Griffin, Clojure işe alımında aday sayısı az olsa da iyi aday oranının yüksek olduğunu düşünüyor
    • Java işe alımında 1.000 CV gelse iyi aday sayısı 10 olabilir
    • Clojure işe alımında 13 CV gelse bunların 10'u iyi aday olabilir diye ifade ediyor
  • Küçük işe alım havuzlarında uzaktan çalışma önemli görülüyor
    • bölgesel kısıtlar kalktığında dünya geneli, 3 zaman dilimi içi veya Avrupa çapında daha geniş bir havuz oluşabiliyor
  • Kısa sürede 100 mühendis almak zorunda kalınan durum anti-pattern olarak görülüyor
  • Şirketin toplam çalışan sayısı yaklaşık 70
  • Engineering ekibi yaklaşık 22~24 kişi
    • yaklaşık üçte ikisi UK'de
    • yaklaşık üçte biri EU'da
    • Almanya'da 4, İsveç'te 4, İrlanda'da 1 kişi düzeyinde
    • merkez Londra'da olsa da geliştiricilerin çoğu Londra dışındaki UK bölgelerinde

Banka düzeyinde operasyonel dayanıklılık testleri

  • Griffin, bir banka olarak operationally resilient olmak zorunda olduğunu ve bunun neredeyse hiç kesinti olmaması gerekliliğine denk geldiğini düşünüyor
  • Para yönettiği için sorun çıksa bile müşteri parasının kaybolmadığını gerçekten kanıtlamak zorunda
  • İlgilendikleri test yönü FoundationDB ekibinin yaklaşımına benziyor
    • FoundationDB ekibi bir veritabanı simülatörü oluşturdu
    • yaklaşık 20 process type, yani cluster içindeki roller, single-threaded C++ uygulamaları olarak yazıldı
    • C++ üzerinde actor-model concurrency compiler inşa edildi
    • tüm system call ve network call'lar protokoller üzerinden geçirildi, böylece hata enjeksiyonu mümkün oldu
    • multi-threading de message sending tabanlı actor model ile ele alındı
  • Bu ortamda hatalar deterministik şekilde enjekte edilebiliyor
    • A ve B mesajlarının gönderilip karşı tarafa B, A sırasıyla ulaşması durumu
    • mesaj işlenirken disk write hatası oluşması durumu
  • Bu, test.check içindeki generative testing'e benzer biçimde, sistemdeki tüm belirsizliğin kontrol edilebilir tek bir random number ile seed edilmesi olarak görülebilir
  • Kontrol edilmek istenenler disk errors, network errors ve message reordering
  • Mevcut sorun, Java threading libraries, NIO ve disk write davranışını kontrol etmenin bir yolu olmaması
  • Jepsen ile ruh olarak ortak noktalar var ama yaklaşım farklı
    • Jepsen, birden çok VM üzerinde süreçleri öldürmeye dayanan daha brute force bir yaklaşım olarak görülüyor
    • veritabanı durumunu içeriden incelemek zor olduğu için kapsamı anlamak güçleşiyor
    • tamamen kontrol edilebilir bir ortamda system call veya mesaj interleaving durumları listelenebilir ve her şey in-memory olduğu için çok hızlı doğrulanabilir
  • FoundationDB ekibi bu tür bir test ortamını erken dönemde kurdu ve bu da FoundationDB'ye duyulan güveni artıran unsurlardan biri oldu
  • Griffin işe alım yapıyor; ayrıntılar için Griffin careers page incelenebilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-30
Hacker News yorumları

  • Griffin’in mevcut Mühendislik Başkan Yardımcısı James Trunk, gördüklerim arasında en net ve eğlenceli Clojure teknik giriş sunumunu yapmıştı. Tavsiye ederim
    https://youtu.be/C-kF25fWTO8?si=PnjMNLdBLJ8zqSu-

  • Şu anki sorun, alttaki Java threading kütüphanelerini, NIO’yu ve diske yazma davranışını kontrol etmenin bir yolu olmaması; böyle bir sistemin doğası gereği gelecekte de mümkün olmayacak gibi görünüyor
    Deterministik olmayan istek sırası veya iş zamanlaması kullanan sistemlerde deterministik yürütme elde edemezsiniz. Sürekli birden fazla OS thread’i kullanırsanız ya da testlerde birden fazla ayrı süreç başlatırsanız durum böyle olur
    Zorlayarak deterministik hâle getirmek mümkün olabilir, ama uygulama durum makinesinin tüm geçişlerine testin kontrol edebileceği senkronizasyon noktaları yerleştirmek gerekeceği için çok zor
    Pratikte, sistemin çekirdeğini tamamen senkron tasarlayıp, çalışma zamanında daha üst katmanlarda eşzamanlılık eklemekten başka yol yok gibi görünüyor

    • Zor ama mümkün. En önemlisi uygulamanın yüzey alanını küçültmek. İş mantığımızın neredeyse tamamı saf fonksiyonlardan oluşuyor ve procs, Clojure protokollerinin (Java arayüzleri) ötesinde olanlar dışında yan etkisiz
      Bu yüzden test sırasında tüm yan etkileri stub’larla değiştirebiliyoruz. “Kullanıcı” kodumuz threading kütüphanesine erişemiyor; threading “kernel” kodunda gerçekleşiyor
      Bunun hâlihazırda uygulanmış iyi bir örneğini https://www.youtube.com/watch?v=4fFDFbi3toc adresinde görebilirsiniz
    • Kesinlikle olmaz demem. Clojure/ClojureScript için bir yapısal eşzamanlılık DSL’i olan ve süreç gözetimini uygulayan missionary değiştirilirse mümkün olabilir diye düşünüyorum
      Zaten missionary’nin kendi testleri için missionary akışlarını enstrümante edip durum geçişlerini doğruluyoruz

  • İki kurucunun birlikte Learning ClojureScript adlı kitabı yazmış olması epey güzel
    https://www.packtpub.com/product/learning-clojurescript/9781...

    • Kitabın üçüncü yazarının Allen Rohner olduğunu gördüm. Compass Labs’te birlikte çalışmıştık; inanılmaz yetenekli bir geliştiriciydi. CircleCI’ı da o kurdu

  • “Banka lisansı olan bir teknoloji şirketi olduğumuz konusunda şakalaşırız” cümlesi, işler ters giderse ileride çok kötü görünebilecek bir alıntı

    • Bu tavra sahip bir bankayı kullanacağımı sanmıyorum. Teknoloji şirketi etiketi çoğu zaman, sırf kod yazdıkları için her şeyi iyi yaptıklarını sanan haksız bir kibirle birlikte geliyor
      Çalıştığım yer kendini, araştırma sonuçlarını yazılımla ticarileştiren bir eğitim araştırma şirketi olarak tanımlıyordu; bana çok daha makul gelmişti ve kültürü de daha iyi kılmıştı
    • Fintech’te öğrendiğim şeylerden biri şu: Bankaların çalıştırdığı COBOL kodu eski ve bakımı zor olsa da, yeniden inşa edilirse baştan öğrenilmesi gerekecek epey değerli bilgi içeriyor
      Bankacılıkta bu bilgiyi yeniden öğrenmenin maliyeti çok yüksek olabilir

  • Ciddi bir soru ve sert ifade için kusura bakmayın ama kullandığım hizmetin hangi dille yazıldığını neden umursamalıyım? Clojure ile yazılmış olması neden önemli? Mesleki olarak Clojure geliştiricisiyim, bu tür şeylerin Clojure ile yazıldığını görmek güzel; ama bunu neden önemsemem gerektiğini bilmiyorum
    Toplulukta gerçekten sevmediğim yönlerden biri bu. Clojure güçlü bir dil ve ben de keyifle kullanıyorum, ama toplulukta bir projede bu dilin kullanıldığını başkalarına söyleme ve gerekçelendirme zorunluluğu varmış gibi bir sahtekârlık sendromu hissi var; bu garip

    • Bu, bir Clojure şirketinin başka bir Clojure şirketiyle röportaj yapıp teknoloji yığınına odaklandığı bir blog yazısı. Her dil ekosisteminde bu tür yazılar nadir değil ve doğal olarak o teknolojiye ilgi duyan kişiler tarafından yazılıp okunuyor
      Derdi tam anlayamadım. Bu medeni toplumda uygunsuz bir davranış mı sayılıyor?
      Oldukça bilgisizce geliyor. “İlgilenmiyorsanız” dahil olmak zorunda değilsiniz; yazarın yazmak istediğini yazmasına izin verin
    • Genelde bu tür hikâyeler, henüz yeterince kabul görmediği için kullanım izni konusunda endişe duyulması gereken dillerde en önemli hâle gelir
      90’larda PHP ve Python geliştiricilerinin “neden Microsoft ASP kullanmıyorsunuz” gibi iş odaklı soruları yanıtlamak için bu tür örnekleri paylaştığını hatırlıyorum
    • Sunucu tarafındaki bir transaction içinde çalıştırılacak kod gönderebilen bir yapıysa, o API’yi kullanmak için geliştiricinin de Clojure ile geliştirme yapması gerekebilir
      Ya da kendi şirketlerine gelecek geliştiricileri çekmeye çalışıyor olabilirler

  • Bu API bankaları neden hep Birleşik Krallık’ta oluyor? Yıllardır curl ile bankacılık işlemi yapmak istiyorum ama ABD’de bunu kimse sunmuyor.

    • ABD bankacılığı şaşırtıcı derecede geri kalmış durumda; teknoloji ya da inovasyon açısından onlarca yıldır dünyaya liderlik etmiyor.
      Buna karşılık Birleşik Krallık yeni bankaları ve yeni teknolojileri aktif biçimde teşvik etti. Bireysel hesaplar arasında anında ve ücretsiz para transferi neredeyse 20 yıldır var; temassız ödeme en az 10 yıldır, mobil bankacılık onlarca yıldır, devletin zorunlu kıldığı banka API’leri ise neredeyse 5 yıldır var.
      Kısacası Birleşik Krallık’ta bankacılık ölçütlerine göre hızlı inovasyon yapmış, çok canlı bir bankacılık sektörü var; daha hızlı inovasyon için gerekli ortam ve ekosistem de iyi gelişmiş durumda.
      ABD’de bankalar, onlarca yıl önce teknolojik inovasyondan vazgeçip bunun yerine ücretlerde ve müşterilere cezalandırıcı muamelede inovasyon yapmayı tercih etmiş gibi görünüyor. Bu yüzden yeni bir inovasyon ortamı yok; mevcut bankalar için rekabet etmektense rakipleri ezmek çok daha kolay.
      Birleşik Krallık’ta da yakın zamana kadar bağımsız banka sayısı şaşırtıcı derecede azdı; aynı şeyin neden yaşanmadığı muhtemelen müşteri haklarını güçlü biçimde güvence altına alan ve bunlara uymayan bankaları aktif olarak cezalandıran yasa ve düzenlemelerin niteliğiyle ilgili.
    • ABD’de yeni bir banka lisansı almak zor, ancak Birleşik Krallık’ta challenger bank olmanın yolu nispeten net. Jarvis de Griffin’i başlatmak için SF’den Londra’ya geri taşındı.
      ABD’de API’ye sahip bankalar büyük fintech ortaklıklarına odaklanma eğiliminde; bu yüzden basit bir API bile sıradan bir banka hesabına kıyasla pahalı olacaktır. Örneğin ABD’de Grasshopper Bank, normal ticari banka hesabının üzerine API sunan az sayıdaki bankadan biri.
      Ben, API sunan çeşitli ABD bankalarını destekleyen Treasury Prime’da çalışıyorum.
    • 2008 finans krizi ve ardından gelen bankacılık skandallarından sonra, vergi mükelleflerinin parasıyla birkaç ünlü bankayı kurtarmak gerekti; o dönemde Birleşik Krallık hükümeti küçük bankaları teşvik etmeye yönelik bir dizi önlem getirdi.
      Bireysel hesaplar tarafında Monzo ve Starling, sözde challenger bank’ler arasında en bilinenleri.[1]
      [1]: https://en.wikipedia.org/wiki/Challenger_bank
    • Birleşik Krallık’ta hükümet bankalara API gereksinimlerini zorunlu kıldı. ABD’de bu “serbest piyasa”ya bırakılmış durumda; pratikte bu, Yodlee ya da Plaid gibi güvenilmesi zor üçüncü taraflara güvenmek zorunda kalmak anlamına geliyor.
    • Artık https://column.com var. Geçen yıl burada da ele alınmıştı.
      Column – geliştiriciler için lisanslı banka
      https://news.ycombinator.com/item?id=31109170

  • “Açık kaynak yapılması gereken bir özel teknoloji daha var. Datascript’i FoundationDB’ye port ettim” demiş; lütfen yayımlasın.
    Bir Datomic alternatifi olarak nasıl çalışacağını merak ediyorum.

    • Yazının tamamı “eğlencesine bir projeyi nasıl aşırı tasarlarsınız” rehberi gibi okunuyordu.

  • “Yasal olarak fintech’ler böyle şeyler yapmak için bankalarla çalışmak zorunda ve bugün bu, mainframe kullanan geleneksel büyük bankalar demek. Griffin, geleceğin tüm fintech’lerinin üzerine inşa edileceği banka ve teknoloji platformudur” cümlesi sanki 2016’da yazılmış gibi.
    Pazar çoktan hareket etti. Griffin iyi görünüyor ama birçok yerden birkaç yıl geride; ClearBank gibi yerleşik oyuncular zaten banka API’lerini iyi sunuyor.
    Daha fazla oyuncuya yer var, bu yüzden Griffin’in pazara girmesi sevindirici; ama keşke pitch bu kadar zayıf olmasaydı.

    • Pazarda seçenekler hâlâ aşırı fazla değil. ClearBank gerçekten iyi ürüne sahip üç bankadan biri.
      Ayrıca iyi bir API tek başına yetmez. Müşteri kitlesiyle uyumlu bütün bir operasyon modeli gerekir ve bunu kurmak çok daha zordur.
    • “Geleceğin tüm fintech’lerinin üzerine inşa edileceği” ifadesi tekil hata noktası gibi geliyor ve rekabetin bir yanılsamadan ibaret hâle geldiği geç kapitalizm sorununu olduğu gibi gösteriyor sanki.

  • Henüz değil. “Denetimi tamamlayıp, daha fazla fon toplayıp, kod yazımını bitirdiğimizde yardımcı tekerlekleri çıkaracağız. Bu yılın 3. ya da 4. çeyreği civarında olacak” deniyor.

  • Bir yazının “Startup’larda kullanabileceğiniz en güçlü dili kullanmalısınız; o da Clojure’dur” diye başlamasından gerçekten hoşlanmıyorum.
    Bu sadece sizin görüşünüz. Startup’larda ekip, MVP’yi en hızlı şekilde yapıp yayımlayarak ilk müşterileri ya da yatırımı alabilecekleri dili kullanmalı. Tipik bir startup için bu low-code ya da no-code platformu bile olabilir; fintech’te muhtemelen değildir.
    İlla bir şey söylemek gerekirse, LLM’ler ve makine öğrenimi nedeniyle Python’ın en güçlü dil olduğu da söylenebilir; ben ise normalde PHP geliştiricisiyim. Python, supposedly Python’ı 36000 kat daha hızlı yaptığı söylenen Mojo sayesinde daha da güçlenebilir.
    Ama herhangi bir X dilinin startup’larda kullanılacak tek ve en güçlü dil olduğunu asla söylemem. Bu tamamen yanlış ve sadece bir görüştür.

    • Elbette bir görüş. Birisi ne zaman bir şey söylese, bu onun görüşüdür.
      Örneğin benim görüşüme göre bu görüşe katılıyorum :-) Tek kişilik girişim işim Clojure ve ClojureScript olmadan mümkün olmazdı; bu da bu dilin “gücünü” gösteriyor.
      Tek bir geliştiricinin karmaşık bir uygulamayı yıllarca yazıp bakımını yapabilmesini sağladığı için bu dili “güçlü” görüyorum. Bana güç veriyor.
    • Bu ifade, JUXT’un Nubank hariç en bilinen Clojure uzmanı şirketlerden biri olduğu ve Clojure konusuyla azıcık ilişkili neredeyse tüm konferansların alt kısmında logosu bulunan bir şirket olduğu düşünülünce çok daha anlaşılır oluyor.
      Clojure, Python ya da PHP gibi daha popüler dillerden çok diğer Lisp’lerle örtüşen, epey içe dönük bir topluluğa sahip. Bu yüzden Clojure en güçlü dildir klişesi, bir ölçüde doğruluk payı olsa da kullanmayanlara şaşırtıcı gelebilir.
      Biz Clojure geliştiricileri buna zaten alıştık; artık üstünlüğü varsayarak konuşmak neredeyse selamlaşma seviyesine geldi.
    • Python özellikle 2023 itibarıyla gerçekten güçlü. Ama garip biçimde ben LLM’leri ve difüzyon modellerini Clojure ile orkestre ediyorum.
      LLM çıktılarıyla uğraşırken de Clojure’u daha çok tercih ediyorum. Elbette Python’ın tam uygun olduğu yerlerde hâlâ Python kullanıyorum.