Griffin - Bank teregulasi penuh berbasis API yang dibangun dengan Clojure

 (juxt.pro)
2 poin oleh GN⁺ 2023-08-30 | 1 komentar | Bagikan ke WhatsApp
  • Platform banking-as-a-service yang memungkinkan perusahaan fintech menghubungkan pembukaan rekening, pembayaran, dan onboarding langsung seperti API perbankan, dan menjadi bank teregulasi setelah memperoleh lisensi bank Inggris pada Maret 2023
  • Sistem berjalan di atas Clojure on Kubernetes on AWS, menggabungkan arsitektur event sourcing yang mengubah sebagian besar input menjadi event dengan penyimpanan FoundationDB
  • FoundationDB adalah strict-serializable key-value store yang mendukung transaksi dan penulisan konkurens, dan Griffin membangun baca/tulis atomik dengan lapisan mirip Datomic hasil port Datascript
  • Logika bisnis dipisahkan dengan berpusat pada log processor kecil yang menerima Clojure map dan menghasilkan Clojure map, sementara akses ke sistem eksternal dibatasi lewat protocol dan proc khusus
  • Immutability Clojure dan kecocokannya untuk audit log dinilai pas untuk kebutuhan layanan keuangan, dan bila digabungkan dengan rekrutmen jarak jauh, lebih mudah menemukan insinyur berkualitas tinggi meski dari kumpulan kandidat yang kecil

Platform bank teregulasi yang disediakan lewat API

  • Griffin adalah platform banking-as-a-service yang membantu perusahaan fintech mengintegrasikan fitur perbankan dengan cepat dan aman
  • Pada Maret 2023, Griffin memperoleh UK banking license dari Financial Conduct Authority dan menjadi bank Inggris yang teregulasi penuh
  • Griffin menyebut dirinya “the bank you can build on” dan menargetkan fondasi seperti AWS untuk perbankan
    • API onboarding pelanggan
    • API pembuatan rekening bank
    • API pembayaran
  • Agar bisa menyediakan fungsi-fungsi ini, fintech secara hukum harus bekerja sama dengan bank, dan saat ini sering kali harus bekerja dengan high street bank lama yang masih memakai mainframe
  • Griffin ingin menyediakan lisensi perbankan sekaligus platform teknologi, agar fintech masa depan bisa membangun layanan di atasnya
  • Meski sudah mendapat lisensi, saat itu Griffin masih berada di tahap mobilization, dan tahap ini berakhir setelah audit selesai, pendanaan tambahan diperoleh, serta penulisan kode dirampungkan
    • Target waktunya adalah Q3 atau Q4 pada tahun tersebut

Latar belakang memilih Clojure

  • Clojure dipilih sebagai bahasa platform karena immutability, ekspresivitas, dan kecocokannya dengan layanan keuangan yang membutuhkan audit log
  • Allen Rohner melihat presentasi Clojure oleh Rich Hickey sekitar 2007, lalu menilai bahwa bahasa itu lebih baik daripada Lisp yang saat itu ia buat sendiri
  • Setelah mendirikan CircleCI pada 2011, ia memakai Clojure dalam jangka panjang, dan melihat bahwa Clojure bekerja baik di CircleCI maupun cocok untuk layanan keuangan
  • Soal JVM, pada beberapa tahun awal ia belum sepenuhnya menyadari kelebihannya, tetapi kemudian penilaiannya berubah dan menganggapnya sebagai keuntungan besar
    • Bahasa startup niche lain bisa mengalami kekurangan library serta masalah performa compiler dan runtime
    • JVM menjadi fondasi yang mengurangi risiko-risiko tersebut
  • Pilihan bahasa mencerminkan karakter perusahaan, dan mereka menilai Clojure adalah pilihan yang lebih kuat dibanding Python atau Java
  • Mereka juga melihat bahwa memakai bahasa niche memang mengurangi jumlah kandidat, tetapi bisa meningkatkan proporsi talenta tingkat tinggi

Lapisan data yang dibangun dengan FoundationDB

  • Arsitektur Griffin berjalan di atas Clojure, Kubernetes, dan AWS, serta hampir seluruhnya dibangun dengan event sourcing
  • Basis datanya menggunakan FoundationDB
  • FoundationDB adalah strict-serializable key-value store yang mendukung transaksi
    • Berawal sebagai startup di Silicon Valley
    • Diakuisisi Apple pada 2015
    • Sekitar 2018, Apple merilisnya kembali sebagai open source
    • Apple memakainya di produksi iCloud
  • Apple menjalankan benchmark yang menunjukkan FoundationDB dapat beroperasi di kisaran 1 juta transaksi per detik
  • Strict serializable termasuk tingkat tertinggi dalam konsistensi database
  • API dasarnya mendekati get a key dan set a key, bukan SQL
  • Griffin mem-port Datascript ke FoundationDB untuk membangun lapisan mirip Datomic
    • Memungkinkan query atomik di atas penyimpanan data strict-serializable
    • Mendukung baca dan tulis berbasis transaksi
  • FoundationDB bukan model single writer, tetapi mendukung concurrent writes
  • Griffin membutuhkan lebih dari 1.000 transaksi per detik, dan kebutuhan itu terpenuhi

Event sourcing dan log processor

  • Semua input ke sistem Griffin menjadi event
    • API request
    • webhook pihak ketiga
  • Event masuk ke message log, dan di Griffin event direpresentasikan sebagai Clojure map dengan field type, key/value, dan spec
  • Seluruh sistem dibangun sebagai reaksi terhadap event
  • Log processor kecil disebut proc
    • Proc bekerja seperti “mendengar message type A, lalu sebagai respons mengeluarkan B atau C”
    • Setiap proc memiliki private state sendiri
  • Aliran message dapat dibentuk sebagai graf, dan event bergerak sampai mencapai terminal node
  • Misalnya, web server menerima event HTTP, mencatat permintaan pembayaran, lalu menunggu event payment created atau payment rejected sebelum merespons klien
    • Alur ini menggunakan Netty asynchronous HTTP handler
  • Semua event dicatat ke FoundationDB
    • Setiap log processor memiliki private data sendiri seperti namespace tersendiri di dalam FoundationDB
    • Proc memantau pencatatan tipe event tertentu, lalu mencatat kembali event miliknya sendiri ke FoundationDB
  • FoundationDB menyediakan fitur untuk memantau perubahan key DB, sehingga efisien untuk membangun reactive system
  • Jika database dipakai bersama sistem messaging terpisah, ada kemungkinan race condition
    • Misalnya satu message menuju disk dan satu lagi menuju jaringan, sehingga pengamat bisa melihat keduanya dalam urutan berbeda
    • Griffin memakai pendekatan mencatat ke FoundationDB untuk menyederhanakannya menjadi satu jalur

Monorepo dan isolasi logika bisnis

  • Griffin menggunakan monorepo
  • Saat ini, demi efisiensi, banyak log process dijalankan di JVM yang sama
    • Masing-masing tetap independen dan bisa dijalankan sebagai JVM process terpisah
    • Saat ini ada proc dalam skala ratusan rendah yang berjalan di satu JVM
  • Logika bisnis dijaga sesederhana dan sebersih mungkin
    • Namespace log processor individual hampir seluruhnya berupa pure Clojure
    • Hampir tidak ada library pihak ketiga
    • Side effect juga sangat sedikit
  • Log processor kurang lebih adalah fungsi yang menerima Clojure map sebagai input dan mengembalikan satu atau lebih Clojure map
  • State proc memiliki protocol sehingga tidak perlu mengetahui implementasi di sisi lain
    • Saat pengujian bisa memakai database in-memory
    • Saat berjalan nyata bisa menulis ke FoundationDB
  • Antarmuka ke dunia luar dijaga sekecil mungkin
  • Sebagian besar proc hanya bisa menulis ke state internalnya sendiri dan mengeluarkan message
    • Tidak bisa melakukan network call
    • Tidak bisa memanggil AWS
    • Tidak ada operasi eksternal lain
  • Saat perlu berkomunikasi dengan sistem eksternal, digunakan proc khusus dengan dispatch handler tersendiri
    • Proc yang berkomunikasi dengan AWS
    • Proc yang berkomunikasi dengan clearing bank
    • Proc yang berkomunikasi dengan API lain

Ekosistem Clojure yang digunakan

  • Di dalam logika bisnis, hampir tidak ada library yang dipakai
  • Pada area yang bersentuhan dengan dunia luar, seperti API web server atau service gateway, mereka memakai
    • ring
    • netty
    • reitit
  • Clojure spec digunakan secara luas
  • Untuk integrasi AWS, mereka memakai library Cognitect aws-api
  • Untuk komposisi aplikasi dan pengelolaan resource, mereka memakai pendekatan berdasarkan tulisan blog closeable
    • Pendekatannya adalah bahwa with-open sudah cukup tanpa Component atau Integrant
    • Mendapat lexical scope, dan urutan deklarasi binding memaksa urutan komposisi
    • Mereka memakai helper kecil untuk mendeklarasikan objek state atau objek stateless yang tidak mengimplementasikan Closeable di dalam blok with-open

Rekrutmen dan komposisi tim

  • Griffin melihat rekrutmen Clojure menghasilkan kandidat lebih sedikit, tetapi proporsi kandidat bagus lebih tinggi
    • Dalam rekrutmen Java, bisa saja ada 1.000 CV masuk tetapi hanya 10 kandidat yang bagus
    • Dalam rekrutmen Clojure, mereka menggambarkannya sebagai 13 CV masuk dan 10 di antaranya bagus
  • Dalam kumpulan rekrutmen yang kecil, kerja jarak jauh menjadi penting
    • Dengan mengurangi batasan lokasi, kumpulan kandidat bisa diperluas ke seluruh dunia, dalam 3 zona waktu, atau di seluruh Eropa
  • Mereka menganggap situasi harus merekrut 100 engineer dalam waktu singkat sebagai anti-pattern
  • Jumlah karyawan perusahaan secara keseluruhan sekitar 70 orang
  • Tim engineering sekitar 22–24 orang
    • Sekitar dua pertiganya berada di UK
    • Sekitar sepertiganya berada di EU
    • Kurang lebih 4 orang di Jerman, 4 di Swedia, dan 1 di Irlandia
    • Kantor pusat ada di London, tetapi sebagian besar developer berada di luar London di wilayah UK

Pengujian ketahanan operasional tingkat perbankan

  • Sebagai bank, Griffin harus operationally resilient, yang menurut mereka hampir setara dengan tuntutan untuk tidak mengalami downtime
  • Karena menangani uang, mereka harus benar-benar bisa membuktikan bahwa bahkan saat terjadi masalah, uang pelanggan tidak akan hilang
  • Arah pengujian yang mereka minati mirip dengan pendekatan tim FoundationDB
    • Tim FoundationDB membangun simulator database
    • Mereka menulis sekitar 20 jenis process, yaitu peran-peran di dalam cluster, sebagai aplikasi C++ single-threaded
    • Di atas C++, mereka membangun compiler konkurensi model aktor
    • Semua system call dan network call dilakukan lewat protocol agar kesalahan bisa diinjeksi
    • Multi-threading juga ditangani lewat model aktor berbasis pengiriman message
  • Dalam lingkungan ini, kesalahan dapat diinjeksi secara deterministik
    • Kasus ketika message A dan B dikirim, tetapi tiba di sisi lain dalam urutan B lalu A
    • Kasus ketika terjadi kesalahan penulisan disk saat memproses message
  • Ini bisa dipandang mirip dengan generative testing di test.check, yakni semua nondeterminisme sistem diberi seed dari satu bilangan acak yang bisa dikendalikan
  • Hal-hal yang ingin mereka kendalikan adalah disk errors, network errors, dan message reordering
  • Masalah saat ini adalah tidak ada cara untuk mengendalikan perilaku Java threading libraries, NIO, dan penulisan disk
  • Pendekatannya sejalan secara semangat dengan Jepsen, tetapi ada perbedaannya
    • Jepsen dipandang lebih mendekati brute force dengan menyiapkan beberapa VM lalu mematikan proses
    • Sulit memeriksa status database dari dalam, sehingga cakupan pengujian sulit diketahui
    • Dalam lingkungan yang sepenuhnya bisa dikendalikan, system call atau interleaving message bisa didaftarkan, dan karena semuanya in-memory, verifikasinya juga sangat cepat
  • Tim FoundationDB membangun lingkungan pengujian seperti ini sejak awal, dan hal itu menjadi salah satu alasan yang menumbuhkan kepercayaan terhadap FoundationDB
  • Griffin sedang merekrut, dan informasi lebih lanjut tersedia di Griffin careers page

Bacaan terkait

1 komentar

 
GN⁺ 2023-08-30
Komentar Hacker News

  • James Trunk, VP of Engineering Griffin saat ini, pernah memberikan presentasi pengantar teknis Clojure yang paling jelas dan menyenangkan yang pernah saya lihat. Direkomendasikan
    https://youtu.be/C-kF25fWTO8?si=PnjMNLdBLJ8zqSu-

  • Masalahnya sekarang adalah tidak ada cara untuk mengendalikan library threading Java yang menjadi fondasinya, NIO, dan perilaku penulisan ke disk; dan melihat sifat sistem seperti itu, sepertinya ini juga tidak akan mungkin ke depannya
    Pada sistem yang memakai urutan permintaan atau penjadwalan pekerjaan yang nondeterministik, Anda tidak bisa mendapatkan eksekusi deterministik. Itu terjadi jika selalu memakai beberapa thread OS, atau menjalankan beberapa proses terpisah dalam pengujian
    Memaksanya menjadi deterministik mungkin bisa saja, tetapi sangat sulit karena semua transisi dalam state machine aplikasi harus disisipi titik sinkronisasi yang dapat dikendalikan oleh pengujian
    Secara praktis, tampaknya satu-satunya cara adalah merancang inti sistem sepenuhnya sinkron, lalu menambahkan konkurensi di lapisan yang lebih tinggi pada saat eksekusi

    • Memang sulit, tapi mungkin. Yang paling penting adalah mengurangi luas permukaan aplikasi. Hampir semua logika bisnis kami berupa fungsi murni, dan procs tidak memiliki efek samping selain hal-hal yang terjadi di balik protokol Clojure (antarmuka Java)
      Karena itu, selama pengujian, semua efek samping dapat diganti dengan stub. Kode “pengguna” kami tidak dapat mengakses library threading, dan threading terjadi di kode “kernel”
      Contoh bagus yang sebenarnya sudah menerapkan pendekatan ini bisa dilihat di https://www.youtube.com/watch?v=4fFDFbi3toc
    • Saya tidak akan mengatakan itu sama sekali mustahil. Saya rasa mungkin saja jika memodifikasi missionary, sebuah DSL konkurensi terstruktur untuk Clojure/ClojureScript sekaligus implementasi process supervision
      missionary sendiri sudah menginstrumentasi flow missionary dan memverifikasi transisi state untuk pengujian internalnya

  • Cukup keren bahwa kedua pendirinya menulis buku berjudul Learning ClojureScript bersama-sama
    https://www.packtpub.com/product/learning-clojurescript/9781...

    • Saya melihat penulis ketiga buku itu adalah Allen Rohner. Saya pernah bekerja dengannya di Compass Labs, dan dia pengembang yang luar biasa berbakat. Dia juga mendirikan CircleCI

  • Kalimat “Kami suka bercanda bahwa kami adalah perusahaan teknologi yang memiliki lisensi bank” adalah kutipan yang bisa terlihat sangat buruk nanti jika ada yang tidak beres

    • Saya rasa saya tidak akan memakai bank dengan sikap seperti ini. Label perusahaan teknologi sering disertai arogansi tidak beralasan, seolah-olah mereka mahir dalam segala hal hanya karena menulis kode
      Perusahaan tempat saya bekerja menyebut dirinya perusahaan riset pendidikan yang mengomersialkan hasil riset lewat perangkat lunak; bagi saya itu jauh lebih masuk akal dan juga membuat budayanya lebih baik
    • Salah satu hal yang saya pelajari di fintech adalah bahwa kode COBOL yang dijalankan bank-bank memang tua dan sulit dirawat, tetapi di dalamnya tersimpan cukup banyak pengetahuan berharga yang harus dipelajari ulang jika dibangun kembali
      Dalam perbankan, biaya untuk mempelajari ulang pengetahuan semacam itu bisa sangat mahal

  • Ini pertanyaan serius, dan maaf kalau terdengar kasar, tetapi mengapa saya harus peduli layanan yang saya pakai ditulis dalam bahasa apa? Mengapa penting bahwa itu ditulis dengan Clojure? Secara profesional saya pengembang Clojure, jadi memang keren melihat sesuatu seperti ini ditulis dengan Clojure, tetapi saya tidak tahu mengapa saya harus peduli
    Ini salah satu hal yang benar-benar tidak saya sukai dari komunitas. Clojure adalah bahasa yang kuat dan saya juga senang memakainya, tetapi di komunitas ada rasa seperti impostor syndrome, seakan-akan kita harus memberi tahu dan membenarkan kepada orang lain bahwa bahasa ini dipakai dalam suatu proyek, dan itu terasa aneh

    • Ini adalah tulisan blog dari perusahaan Clojure yang mewawancarai perusahaan Clojure lain dengan fokus pada tech stack. Di ekosistem bahasa apa pun, tulisan seperti ini tidak jarang, dan tentu saja ditulis serta dibaca oleh orang-orang yang tertarik pada teknologi tersebut
      Saya tidak paham poinnya. Apakah ini dianggap perilaku tidak pantas dalam masyarakat beradab?
      Kedengarannya cukup tidak tahu-menahu. Kalau “tidak tertarik”, Anda tidak perlu ikut campur, dan biarkan penulis menulis apa yang ingin mereka tulis
    • Biasanya cerita seperti ini paling penting untuk bahasa yang belum cukup diterima sehingga orang masih harus khawatir soal izin pemakaian
      Saya ingat pada tahun 90-an pengembang PHP dan Python membagikan contoh seperti ini untuk menjawab pertanyaan bisnis seperti “mengapa tidak memakai Microsoft ASP”
    • Jika strukturnya memungkinkan Anda mengirim kode untuk dijalankan di dalam transaksi sisi server, maka untuk memakai API itu, pengembang mungkin juga harus mengembangkan dengan Clojure
      Atau mungkin saja mereka ingin menarik pengembang agar datang bekerja di perusahaan mereka

  • Mengapa bank-bank API seperti ini selalu ada di Inggris? Sudah bertahun-tahun saya ingin melakukan urusan perbankan dengan curl, tetapi di AS tidak ada yang menyediakannya

    • Perbankan AS tertinggal secara mengejutkan, dan selama puluhan tahun tidak memimpin dunia dari sudut pandang teknologi atau inovasi
      Sebaliknya, Inggris secara aktif mendorong bank baru dan teknologi baru. Transfer instan gratis antar rekening pribadi sudah ada hampir 20 tahun lalu, pembayaran nirsentuh setidaknya 10 tahun, mobile banking puluhan tahun, dan API perbankan yang diwajibkan pemerintah sudah hampir 5 tahun
      Singkatnya, Inggris memiliki sektor perbankan yang sangat aktif yang, menurut standar perbankan, berinovasi dengan cepat, serta lingkungan dan ekosistem yang berkembang baik untuk inovasi yang lebih cepat
      Di AS, tampaknya bank-bank sudah menyerah pada inovasi teknologi puluhan tahun lalu, dan lebih memilih berinovasi dalam biaya serta perlakuan menghukum terhadap nasabah. Karena itu tidak ada lingkungan inovasi baru, dan bagi bank-bank lama jauh lebih mudah menekan pesaing daripada bersaing
      Hingga baru-baru ini Inggris juga punya jumlah bank independen yang sangat sedikit secara mengejutkan; mengapa hal yang sama tidak terjadi kemungkinan besar karena sifat hukum dan regulasi yang banyak menjamin hak nasabah dan secara aktif menghukum bank yang tidak mematuhinya
    • Mendapatkan izin bank baru di AS sulit, tetapi di Inggris jalur untuk menjadi challenger bank relatif jelas. Jarvis juga pindah kembali dari SF ke London untuk memulai Griffin
      Bank-bank di AS yang memiliki API cenderung berfokus pada kemitraan fintech besar, jadi API sederhana pun kemungkinan mahal dibanding rekening bank biasa. Misalnya, Grasshopper Bank di AS adalah salah satu dari sedikit bank yang menyediakan API di atas rekening bank komersial biasa
      Saya bekerja di Treasury Prime, yang mendukung beberapa bank AS yang menyediakan API
    • Setelah krisis keuangan 2008 dan skandal perbankan yang menyusul, beberapa bank terkenal harus diselamatkan dengan uang pembayar pajak, dan pemerintah Inggris saat itu memperkenalkan serangkaian langkah untuk mendorong bank kecil
      Di sisi rekening pribadi, Monzo dan Starling adalah yang paling dikenal di antara apa yang disebut challenger bank[1]
      [1]: https://en.wikipedia.org/wiki/Challenger_bank
    • Di Inggris, pemerintah mewajibkan persyaratan API pada bank. AS menyerahkannya pada “pasar bebas”, yang dalam praktiknya berarti harus memercayai pihak ketiga yang sulit dipercaya seperti Yodlee atau Plaid
    • Sekarang ada https://column.com. Tahun lalu juga dibahas di sini
      Column – bank berizin untuk developer
      https://news.ycombinator.com/item?id=31109170

  • “Ada satu lagi teknologi proprietary tambahan yang harus dijadikan open source. Kami mem-port Datascript ke FoundationDB” — tolong sekali, semoga mereka merilisnya
    Saya penasaran bagaimana itu akan bekerja sebagai alternatif Datomic

    • Seluruh tulisannya terbaca seperti panduan “cara over-engineer proyek demi bersenang-senang”

  • Kalimat “Secara hukum, fintech harus bekerja sama dengan bank untuk melakukan hal seperti ini, dan saat ini itu berarti bank besar tradisional yang memakai mainframe. Griffin adalah bank dan platform teknologi yang akan menjadi fondasi semua fintech masa depan” terasa seperti ditulis pada 2016
    Pasar sudah bergerak. Griffin terlihat bagus, tetapi tertinggal beberapa tahun dari banyak pihak, dan pemain mapan seperti ClearBank sudah menyediakan API perbankan dengan baik
    Masih ada ruang bagi lebih banyak pemain, jadi masuknya Griffin ke pasar disambut baik, tetapi semoga pitch-nya tidak selemah ini

    • Pilihan di pasar masih belum terlalu banyak. ClearBank memang salah satu dari tiga bank dengan produk yang benar-benar lumayan
      Dan API yang bagus saja tidak cukup. Diperlukan keseluruhan model operasional yang cocok dengan basis pelanggan, dan membangunnya jauh lebih sulit
    • Ungkapan “yang akan menjadi fondasi semua fintech masa depan” terdengar seperti single point of failure, dan seperti menunjukkan langsung masalah kapitalisme tahap akhir ketika kompetisi menjadi tak lebih dari ilusi

  • Belum. Tertulis, “Setelah kami menyelesaikan audit, menggalang dana lagi, dan menuntaskan penulisan kode, kami akan melepas roda bantu. Mungkin sekitar kuartal 3 atau 4 tahun ini”

  • Saya benar-benar tidak suka kalau tulisan dimulai dengan “Di startup, Anda harus memakai bahasa paling kuat yang tersedia, dan itu adalah Clojure”
    Itu hanya pendapat Anda. Di startup, tim harus memakai bahasa yang memungkinkan mereka paling cepat membuat dan meluncurkan MVP untuk mendapatkan pelanggan pertama atau investasi. Untuk startup umum, itu bisa saja platform low-code atau no-code, meski kemungkinan besar bukan di fintech
    Kalau mau dipaksakan, karena LLM dan machine learning, Python juga bisa disebut bahasa paling kuat, dan saya biasanya developer PHP. Python mungkin akan menjadi lebih kuat berkat Mojo yang supposedly membuat Python 36.000 kali lebih cepat
    Tetapi saya tidak akan pernah mengatakan bahasa X tertentu adalah satu-satunya bahasa paling kuat untuk dipakai di startup. Itu sepenuhnya keliru dan hanya pendapat

    • Tentu saja itu pendapat. Setiap kali seseorang mengatakan sesuatu, itu adalah pendapat orang tersebut
      Misalnya, menurut saya, saya setuju dengan pendapat itu :-) Bisnis solo founder saya tidak akan mungkin tanpa Clojure dan ClojureScript, dan ini menunjukkan “kekuatan” bahasa tersebut
      Saya menganggap bahasa ini “kuat” karena memungkinkan satu developer menulis dan memelihara aplikasi kompleks selama bertahun-tahun. Ia memberi saya kekuatan
    • Kalimat itu jadi jauh lebih masuk akal jika mengingat JUXT, selain Nubank, adalah salah satu perusahaan spesialis Clojure paling terkenal, dan logonya muncul di bagian bawah hampir semua konferensi yang sedikit saja terkait topik Clojure
      Clojure memiliki komunitas yang cukup inward-looking, lebih banyak tumpang tindih dengan Lisp lain daripada bahasa yang lebih populer seperti Python atau PHP. Jadi klise bahwa Clojure adalah bahasa paling kuat memang sampai batas tertentu benar, tetapi bisa terdengar mengejutkan bagi orang yang tidak memakainya
      Kami para developer Clojure sudah terbiasa, dan sekarang berbicara dengan asumsi superioritas hampir sudah seperti sapaan
    • Python memang sangat kuat, terutama per 2023. Namun anehnya, saya mengorkestrasi LLM dan model difusi dengan Clojure
      Untuk menangani output LLM pun saya lebih memilih Clojure. Tentu saja saya tetap memakai Python di tempat yang memang paling cocok untuk Python