Ketika seseorang melihat kode Corda , mereka segera menyadari bahwa itu ditulis dalam Kotlin - bahasa pemrograman baru dari JetBrains, yang dapat dikompilasi untuk JVM dan Javascript. Itu adalah pilihan yang tidak biasa, dan dalam artikel ini saya ingin berbagi beberapa alasan untuk keputusan ini dan pengalaman "tahun kami bersama Kotlin dalam produksi".
Kenapa Kotlin?
Solusi ini dapat dibagi menjadi dua bagian:
- Platform mana yang digunakan? JVM, .NET, Node, Python / Ruby, Go, Haskell atau sesuatu yang dikompilasi (dalam kode mesin)?
- Bahasa apa yang digunakan jika Anda memilih JVM? Jawa? Jika tidak, lalu mengapa? Dan jika tidak, lalu apa lagi: Scala, Ceylon, Clojure, Kotlin, Python, Ruby, Javascript atau Haskell (karena mereka semua memiliki implementasi untuk JVM).
Alasan memilih JVM sebagai platform sudah terkenal di lingkungan aplikasi perusahaan, dan tidak ada gunanya memikirkan hal ini. Cukuplah untuk mengatakan bahwa jika Anda memerlukan runtime lintas-platform yang dapat diskal dan aman dengan pengumpulan sampah , dan dengan banyak perpustakaan yang terdokumentasi dengan baik yang memecahkan masalah bisnis dasar, maka pilihannya dikurangi hanya menjadi JVM dan .NET.
Pada awal pengerjaan Corda, proyek itu tidak memiliki nama dan sulit membayangkan bahwa di masa depan akan berkembang menjadi sebuah produk. Bahkan, ketika proyek, yang menjadi Corda, dimulai pada Desember 2015 (pada hari pertama saya di tempat kerja), tidak ada rencana untuk membuat sistem akuntansi terdistribusi korporat baru. Corda dimulai sebagai seperangkat prototipe untuk mengeksplorasi ide-ide dan persyaratan baru yang diminati Kelompok Kerja Arsitektur Konsorsium, terutama yang terkait dengan visibilitas data yang terbatas dan model data yang memberikan skalabilitas dari “rangkaian array transaksional keluaran UTXO”. bersama dengan programabilitas kontrak pintar Ethereum yang penting secara umum.
Karena kenyataan bahwa tidak jelas apakah prototipe ini akan berubah menjadi sesuatu, atau hanya berfungsi sebagai informasi untuk produk lain di pasar, kami menghadapi pilihan yang sulit. Di satu sisi, kami ingin mengeksplorasi algoritma dan struktur data dengan cepat dan produktif. Di sisi lain, harus tetap ada peluang potensial untuk membuat produk perusahaan besar dan cepat mempekerjakan orang untuk itu.
Java jelas memenuhi persyaratan ini, tetapi kurangnya kemampuan modern dalam bahasa secara signifikan mengurangi produktivitas dan, lebih tepatnya, moral pengembang.
Pengetikan dinamis belum dipertimbangkan - manfaat dari kebenaran, alat pengembangan, dan kinerja yang disediakan oleh pengetikan statis terlalu besar untuk diabaikan.
Bahasa yang secara fundamental berbeda dari yang paling populer juga tidak dipertimbangkan, karena kami ingin dapat mempekerjakan ahli keuangan. Dan, meskipun menciptakan tim di sekitar bahasa seperti Haskell sepenuhnya mungkin , menemukan seseorang dengan pengalaman perbankan yang serius dan bahasa malas (malas) murni (fungsional) yang hidup secara acak di London tampak berisiko. Selain itu, sifat dasar dari produk menyiratkan bahwa "pengguna" kami sebenarnya adalah pengembang plugin dan aplikasi yang menggunakan platform, dan tidak ada gunanya mengharuskan mereka untuk mempelajari paradigma dan alat yang sama sekali baru. Pilihan bahasa kami seharusnya tidak membatasi pengguna terlalu banyak.
Akibatnya, persyaratan ini meninggalkan kita dengan Kotlin, Scala dan Ceylon. Bahasa-bahasa ini sangat mirip dan cukup menarik. Kami memilih Kotlin karena alasan berikut:
- Integrasi yang hampir mulus dengan Java
- Secara khusus, program Kotlin menggunakan versi yang ditingkatkan (ditingkatkan-kompiler) dari koleksi JDK standar, yang dengan demikian memastikan bahwa tidak ada masalah integrasi karena penggunaan perpustakaan koleksi lainnya. Kami mengirim dan menerima koleksi ke dan dari perpustakaan Java di mana saja, jadi penting bahwa ini tidak menimbulkan masalah.
- Dari kelas Kotlin, kita mendapatkan Java API yang tampak biasa dengan metode
get / set / is sesuai dengan tipenya. Tidak ada penjelasan khusus atau tindakan lain yang diperlukan untuk ini. Karena Corda menyediakan API yang dirancang untuk penggunaan transparan oleh pengembang Java, ini merupakan keuntungan besar: dari kode biasa, Anda mendapatkan API yang tidak dapat dibedakan dari API Java dengan hanya beberapa peringatan (misalnya, secara eksplisit membutuhkan pengecualian yang diperiksa dari Jawa memerlukan eksplisit). penjelasan metode)
- Memasukkan fungsi-fungsi kecil seperti
map / filter / fold / groupBy (alih-alih berharap JVM akan melakukannya sendiri) dilakukan oleh kompiler. Sayangnya, kompiler JIT JVM, meskipun secara keseluruhan sangat baik, tidak dalam semua kasus menghilangkan overhead penggunaan fungsi-fungsi tingkat tinggi yang berlimpah. Penggunaan Kotlin mengkompensasi hal ini, selain memungkinkan Anda untuk mengontrol pelaksanaan program dari dalam fungsi lambda (catatan: misalnya, pengembalian non-lokal ). Ini adalah salah satu fitur yang kurang dikenal, tetapi pada saat yang sama, bermanfaat. Karena di mana pun kita menulis kode dengan gaya fungsional, maka jika itu diterjemahkan dengan buruk ke dalam kode mesin, kita dapat menciptakan masalah kinerja untuk diri kita sendiri. - Karena fakta bahwa kode pada Kotlin diterjemahkan ke dalam kode Java yang cukup mirip, hampir semua alat berorientasi Java yang ada bekerja di luar kotak . Ini tidak selalu benar dalam kasus bahasa lain. Sebagai contoh, Quasar mengalami kesulitan dalam menginstruksikan kode Scala karena membutuhkan penjelasan metode, dan Scala menerjemahkan lambdas ke dalam metode yang tidak dapat dijelaskan. Lamblin Kotlin biasanya tertanam (lihat di atas), atau mungkin dijelaskan lain.
- Dokumentasi yang luar biasa dan perpustakaan standar yang kecil membuatnya sangat cepat untuk dipelajari. Kami tidak menunjukkan dalam lowongan kami perlunya pengalaman di Kotlin, dan kami mempekerjakan orang tanpa sepengetahuannya memberikan 1-3 tahun setelah itu anggota baru tim dapat menulis kode idiomatik.
- Berdasarkan pilihan kandidat yang mewawancarai kami, IntelliJ adalah IDE paling populer (mereka memiliki alat pilihan gratis). Di antara bahasa-bahasa pasca-Jawa, IntelliJ mendukung Kotlin yang terbaik.
- Saya sudah memiliki pengalaman yang memuaskan dengannya, dan karena itu, saya yakin bahwa rekan-rekan barunya juga akan menyukainya.
Jika itu bukan untuk Kotlin, kami mungkin memilih Scala: Kotlin sebagian besar terinspirasi olehnya dan keduanya adalah bahasa yang baik.
Tahun kita bersama Kotlin
Seperti apa - setahun bekerja dengan bahasa baru dalam konteks aplikasi perusahaan?
Yang paling penting adalah, tanpa ragu, untuk mendengar dari kolega bahwa mereka benar-benar suka bekerja dengannya. Bahasa pemrograman adalah masalah pribadi untuk semua orang, dan orang biasanya memiliki pendapat yang pasti tentang masalah ini. Jika Anda, sebagai tugas pertama di pekerjaan baru, meminta seseorang untuk belajar bahasa baru dan bahkan tidak memperingatkannya terlebih dahulu, maka selalu ada risiko bahwa seorang rekan akan membencinya dan malah menganggapnya menjengkelkan daripada meningkatkan produktivitasnya. Tapi ini bukan masalahnya.
Berikut ini adalah beberapa masalah yang sering muncul di lingkungan pengembangan perusahaan pasca-Jawa / C # yang kami alami sendiri:
- Kode terlihat berbeda tergantung pada siapa yang menulisnya. Secara umum, bukan masalah besar. Tidak seperti Go, yang memerlukan gaya desain tertentu, kode Kotlin dari penulis yang berbeda mungkin terlihat berbeda. Tetapi IntelliJ memiliki alat pemformatan yang menyediakan gaya basis kode terpadu. Ini lebih terbatas daripada untuk Jawa, tetapi itu sudah cukup. Masalah yang lebih halus, terutama dengan kode Scala, adalah oposisi dari gaya pengkodean Java-OOP dan Haskell-FI. Kode scala yang menggunakan pustaka seperti scalaz bisa sulit dibaca untuk pengembang yang berharap melihat Java yang ditingkatkan . Dalam debat ini, Kotlin cukup kuat di sisi Jawa yang lebih baik . Dan, meskipun pemrograman fungsional, dengan cara tertentu, mungkin di Kotlin, komunitas (setidaknya untuk saat ini) belum terpecah menjadi kamp. Kami memiliki kasus ketika kode ditulis seolah-olah itu adalah Haskell, tetapi itu berhasil di codereview.
- Perpustakaan Di Corda kami menggunakan lebih dari 50 perpustakaan open source dan tidak ada masalah dengan itu. Kami tidak pernah menulis bungkus atau lapisan adaptor. Karena sistem pembangunan dalam proyek-proyek di Kotlin, Maven atau Gradle biasanya digunakan - tidak ada pengganti resmi spesifik Kotlin untuk alat-alat ini (meskipun Gradle telah memperkenalkan dukungan Kotlin sebagai bahasa scripting baru!).
- DSL dan SQL. C # memiliki LINQ, Java memiliki JOOQ, dan Kotlin telah Terkena . Ini adalah salah satu area di mana Kotlin agak lebih lemah daripada pesaingnya - Terkena adalah contoh yang bagus untuk menggunakan kemampuan Kotlin untuk membangun DSL, tetapi perpustakaan itu sendiri memiliki API yang tidak stabil dan merupakan proyek sekunder. JOOQ, tentu saja, dapat digunakan dengan Kotlin, dan, menoleh ke belakang, ini tampaknya menjadi pilihan yang lebih disukai.
- IDE / toolkit. Plugin Kotlin untuk IntelliJ, tentu saja, ditulis oleh JetBrains dan, secara keseluruhan, hebat. Namun, itu kurang canggih jika dibandingkan dengan dukungan Java. Fitur editor baru, seperti petunjuk parameter , harus porting secara manual ke Kotlin, dan dukungan itu sendiri, dengan demikian, biasanya tertinggal jauh dari plug-in Java yang jauh lebih tua. Kami juga memperhatikan bahwa plugin IDE cukup sering memberi tahu kesalahan internal, walaupun frekuensi pengecualian IDE telah menurun secara signifikan selama setahun (dan tampaknya mereka tidak mempengaruhi apa pun). Menggunakan alat lain juga tidak menimbulkan masalah, karena apa yang ditulis untuk Java biasanya bekerja di luar kotak . Pengecualian adalah alat yang bekerja dengan kode sumber alih-alih bytecode, dan yang, jelas, tidak dapat digunakan kembali. Dengan semua ini, kompiler Kotlin dan plugin IDE tidak memiliki kelemahan seperti pada Java, bahkan setahun setelah rilis 1.0. Kemungkinan besar Anda tidak akan pernah menemukan kesalahan internal di
javac , tetapi, meskipun sangat jarang, kami masih melihatnya di Kotlin. - Pengakuan oleh pengguna. Pengguna Corda adalah institusi keuangan yang besar dan konservatif. Perusahaan semacam itu lebih suka menggunakan bahasa umum yang sudah mapan. Kotlin, yang tidak satu atau yang lain, jelas menyebabkan kejutan pada saat kami mulai. "Kenapa Kotlin?" - Ini adalah pertanyaan yang, selama setahun terakhir, praktis menghilang, karena orang-orang melihat lebih dekat dan menyadari bahwa ini tidak berisiko seperti biasanya dengan bahasa pemrograman baru. Kami juga mencoba memfasilitasi adopsi dengan memberikan contoh kode yang menunjukkan bahwa membangun aplikasi menggunakan platform tidak memerlukan pengetahuan Kotlin. Hasil ini tidak begitu sukses - banyak pengembang yang bekerja untuk pertama kalinya dengan Corda masih mulai dengan menjelajahi Kotlin. Tidak terlalu jelas apakah ini adalah hasil dari fakta bahwa kami telah memberikan contoh dan dokumentasi penggunaan yang kurang berorientasi pada Java, atau apakah ini hanya alasan yang baik untuk mempelajari alat keren baru. Kami juga telah dibantu oleh meningkatnya adopsi Kotlin di dalam bank investasi besar. Selama tahun lalu, kami telah mendengar dari beberapa anggota konsorsium bahwa tim pengembangan internal mereka mulai serius melihat Kotlin untuk produk mereka sendiri: sering kali didorong oleh ketersediaan alat yang mengubah Jawa menjadi Kotlin, yang memberikan integrasi yang jauh lebih tidak menyakitkan ke dalam basis kode yang ada.
- Dukungan komersial. Risiko menggunakan bahasa yang kurang dikenal adalah mereka dapat berhenti berkembang, atau memiliki tujuan yang tidak konsisten dengan kebutuhan yang terbentuk di sekitar produk, komunitas pengguna (misalnya, dalam hal bahasa penelitian, tujuan utama pengembang adalah untuk membuat artikel ilmiah). Alasan utama kami merasa yakin dengan Kotlin adalah bahwa JetBrains adalah perusahaan yang stabil dan menguntungkan yang telah ada di pasar selama lebih dari 15 tahun. JetBrains dengan cepat mulai mencicipi alat mereka sendiri dengan memperkenalkan Kotlin ke dalam kode produk utama. Dengan demikian, risiko penghentian dukungan agak kecil. Selain itu, JetBrains sudah merupakan perusahaan setengah baya, dan pasar targetnya (IDE dan perangkat pengembang) telah berhenti menjadi baru atau sangat modis, yang mengurangi risiko kemungkinan pengambilalihan perusahaan, yang dapat menyebabkan perubahan strategis yang tidak dapat diprediksi. Dan, meskipun tidak ada paket dukungan komersial untuk Kotlin, dalam praktiknya tim dengan cepat memperbaiki masalah yang diketahui. Saat ini, JetBrains bermaksud untuk merilis pembaruan bahasa berikutnya setelah satu tahun sejak rilis 1.0. Siklus rilis ini sangat mirip dengan siklus pengembangan di lingkungan perusahaan.
Kesimpulannya?
Kami tidak menyesal: pilihan bahasa muda pada awal proyek ini, meskipun berisiko, tetapi seimbang. Dia melakukan pekerjaan yang baik untuk kita dan kita tidak akan mengubah pilihan kita.