Seberapa matangkah proyek bahasa komputasi ilmiah "Julia"?

Saya sedang mempertimbangkan mempelajari bahasa baru untuk digunakan untuk proyek pemodelan numerik / simulasi, sebagai pengganti (sebagian) untuk C ++ dan Python yang saat ini saya gunakan. Saya menemukan Julia , yang terdengar sempurna. Jika ia melakukan semua yang diklaimnya, saya dapat menggunakannya untuk mengganti C ++ dan Python di semua proyek saya, karena dapat mengakses kode perpustakaan komputasi ilmiah tingkat tinggi (termasuk PyPlot) serta menjalankan loop dengan kecepatan yang mirip dengan C. Saya juga akan mendapat manfaat dari hal-hal seperti coroutine yang tepat yang tidak ada di salah satu bahasa lainnya.

Namun, ini adalah proyek yang relatif baru, saat ini pada versi 0.x, dan saya menemukan berbagai peringatan (diposting di berbagai tanggal di masa lalu) bahwa itu tidak cukup siap untuk penggunaan sehari-hari. Akibatnya, saya ingin beberapa informasi tentang status proyek sekarang (Februari 2014, atau setiap kali jawaban diposting), untuk membantu saya menilai apakah saya secara pribadi harus mempertimbangkan menginvestasikan waktu untuk mempelajari bahasa ini pada tahap ini.

Saya akan menghargai jawaban yang berfokus pada fakta-fakta spesifik yang relevan tentang proyek Julia ; Saya kurang tertarik pada pendapat berdasarkan pengalaman dengan proyek lain.

Secara khusus, komentar oleh Geoff Oxberry menunjukkan bahwa API Julia masih dalam keadaan fluks, membutuhkan kode untuk diperbarui ketika itu berubah. Saya ingin mengetahui sejauh mana hal ini terjadi: area API mana yang stabil, dan mana yang cenderung berubah?

Saya kira biasanya saya kebanyakan akan melakukan aljabar linier (misalnya menyelesaikan masalah eigen), integrasi numerik ODE dengan banyak variabel, dan merencanakan menggunakan PyPlot dan / atau OpenGL, serta angka-angka C-style tingkat rendah (misalnya untuk simulasi Monte Carlo ). Apakah sistem perpustakaan Julia sepenuhnya dikembangkan di bidang ini? Secara khusus, apakah API lebih atau kurang stabil untuk jenis kegiatan tersebut, atau apakah saya akan menemukan bahwa kode lama saya cenderung rusak setelah memutakhirkan ke versi baru Julia?

Akhirnya, apakah ada masalah lain yang layak dipertimbangkan dalam memutuskan apakah akan menggunakan Julia untuk pekerjaan serius saat ini?

Julia, pada titik ini (Mei 2019, Julia v1.1 dengan v1.2 akan keluar) cukup matang untuk komputasi ilmiah. Rilis v1.0 menandai berakhirnya kerusakan kode tahunan . Dengan itu, banyak perpustakaan komputasi ilmiah memiliki waktu untuk sekadar tumbuh tanpa gangguan. Tinjauan umum paket Julia dapat ditemukan di pkg.julialang.org .

Untuk komputasi ilmiah inti, perpustakaan DifferentialEquations.jl untuk persamaan diferensial (ODE, SDEs, DAEs, DDEs, simulasi Gillespie, dll.), Flux.jl untuk jaringan saraf, dan perpustakaan JuMP untuk pemrograman matematika (optimisasi: linier, kuadratik, mixed integer, etc. programming) adalah tiga pilar utama ekosistem komputasi ilmiah. Pustaka persamaan diferensial khususnya jauh lebih berkembang daripada apa yang akan Anda lihat dalam bahasa lain, dengan tim pengembangan besar yang mengimplementasikan fitur-fitur seperti integrator EPIRK , Runge-Kutta-Nystrom , persamaan diferensial keterlambatan diferensial Stiff / Differential-Algebraic , danintegrator persamaan diferensial stokastik kaku waktu kaku , bersama dengan banyak barang lainnya seperti analisis sensitivitas adjoint , DSL reaksi kimia , matriks bebas Newton-Krylov, dan kompatibilitas penuh GPU (transfer data gratis), dengan pelatihan persamaan diferensial saraf , semua dengan hasil patokan fantastis (penafian: saya adalah pengembang utama).

Hal yang sedikit membingungkan tentang ekosistem Julia yang sudah matang adalah sifatnya yang kompatible. Pada dasarnya, ketika seseorang membangun fungsi pustaka generik seperti yang ada di DifferentialEquations.jl, Anda bisa menggunakan tipe AbstractArray / Number apa saja untuk menghasilkan kode baru dengan cepat. Jadi misalnya, ada pustaka untuk propagasi kesalahan ( Measurements.jl ) dan ketika Anda memasukkannya ke dalam ODE solver, ia secara otomatis mengkompilasi versi baru dari solver ODE yang melakukan propagasi kesalahan tanpa melakukan sampling parameter . Karena itu, Anda mungkin tidak menemukan beberapa fitur yang didokumentasikan karena kode untuk fitur menghasilkan sendiri, sehingga Anda perlu memikirkan lebih lanjut tentang komposisi perpustakaan.

Salah satu cara di mana komposisi paling berguna adalah dalam aljabar linier. Pemecah ODE misalnya memungkinkan Anda untuk menentukan jac_prototype, membiarkan Anda memberikannya jenis untuk Jacobian yang akan digunakan secara internal. Tentu saja ada hal-hal di perpustakaan standar LineraAlgebra seperti Symmetricdan TridiagonalAnda dapat menggunakannya di sini, tetapi mengingat utilitas kompabilitas dalam algoritma tipe generik, orang-orang sekarang telah pergi dan membangun seluruh perpustakaan jenis array. BandedMatrices.jl dan BlockBandedMatrices.jl adalah pustaka yang mendefinisikan (Block) tipe matriks berpita yang memiliki lukelebihan yang cepat , menjadikannya cara yang bagus untuk mempercepat solusi diskritisasi MOL yang kaku dari sistem persamaan diferensial parsial. PDMats.jlmemungkinkan untuk spesifikasi matriks positif-pasti. Elemental.jl memungkinkan Anda untuk mendefinisikan Jacobian yang jarang didistribusikan. CuArrays.jl mendefinisikan array pada GPU. Dll

Maka Anda memiliki semua jenis nomor Anda. Unitful.jl melakukan pengecekan unit pada waktu kompilasi sehingga merupakan pustaka unit bebas-biaya. DoubleFloats.jl adalah pustaka berpresisi tinggi dan cepat, bersama dengan Quadmath.jl dan ArbFloats.jl . ForwardDiff.jl adalah pustaka untuk diferensiasi otomatis mode-maju yang menggunakan aritmatika bilangan ganda. Dan saya bisa terus mendaftar ini. Dan ya, Anda bisa membuangnya ke dalam pustaka Julia yang cukup umum seperti DifferentialEquations.jl untuk mengkompilasi versi yang secara khusus dioptimalkan untuk tipe-tipe angka ini. Bahkan sesuatu seperti ApproxFun.jlyang berfungsi sebagai objek aljabar (seperti Chebfun) bekerja dengan sistem generik ini, memungkinkan spesifikasi PDE sebagai ODE pada skalar dalam ruang fungsi.

Mengingat keunggulan kompabilitas dan cara tipe dapat digunakan untuk menghasilkan kode baru dan efisien pada fungsi generik Julia, ada banyak pekerjaan untuk mendapatkan implementasi fungsionalitas komputasi inti ilmiah menjadi Julia murni. Optim.jl untuk optimisasi nonlinier, NLsolve.jl untuk menyelesaikan sistem nonlinier, IterativeSolvers.jl untuk pemecah iteratif sistem linear dan sistem eigens, BlackBoxOptim.jl untuk optimasi kotak hitam, dll. Bahkan pustaka jaringan saraf Flux.jl hanya menggunakan CuArrays. Kompilasi kode otomatis jl ke GPU untuk kemampuan GPU-nya. Kompabilitas ini adalah inti dari apa yang menciptakan hal-hal seperti persamaan diferensial saraf dalam DiffEqFlux.jl. Bahasa pemrograman probabilistik seperti Turing.jl juga cukup matang sekarang dan menggunakan alat dasar yang sama.

Karena perpustakaan Julia secara mendasar didasarkan pada alat pembuatan kode, seharusnya tidak heran bahwa ada banyak alat di sekitar pembuatan kode. Sistem siaran Julia menghasilkan kernel yang tergabung dengan cepat yang kelebihan beban oleh tipe array untuk memberikan banyak fitur yang disebutkan di atas. CUDAnative.jl memungkinkan untuk mengkompilasi kode Julia ke kernel GPU. ModelingToolkit.jl secara otomatis de-gula AST menjadi sistem simbolik untuk mengubah kode matematika. Cassette.jlmemungkinkan Anda "overdub" fungsi orang lain yang ada, menggunakan aturan untuk mengubah fungsi mereka sebelum waktu kompilasi (misalnya: mengubah semua alokasi array mereka ke alokasi array statis dan memindahkan operasi ke GPU). Ini adalah tooling yang lebih canggih (saya tidak berharap semua orang melakukan komputasi ilmiah untuk mengambil kendali langsung dari kompiler), tetapi ini adalah bagaimana banyak tooling generasi berikutnya sedang dibangun (atau lebih tepatnya, bagaimana fitur menulis sendiri).

Mengenai paralelisme, saya telah menyebutkan GPU, dan Julia memiliki komputasi multithreading dan distribusi yang terintegrasi . Multithreading Julia akan segera menggunakan arsitektur parallel-task runtime (PARTR) yang memungkinkan penjadwalan otomatis multithreading bersarang . Jika Anda ingin menggunakan MPI, Anda hanya dapat menggunakan MPI.jl . Dan tentu saja, cara termudah untuk memanfaatkan semuanya adalah dengan hanya menggunakan pengaturan tipe AbstractArray untuk menggunakan paralelisme dalam operasinya.

Julia juga memiliki ekosistem dasar yang Anda harapkan dari bahasa tujuan umum yang digunakan untuk aplikasi ilmiah. Ini memiliki Juno IDE dengan debugger bawaan dengan breakpoints , ia memiliki Plots.jl untuk membuat semua jenis plot. Banyak alat khusus juga bagus, seperti Revise.jl secara otomatis memperbarui fungsi / pustaka Anda ketika sebuah file disimpan. Anda memiliki DataFrames.jl , perpustakaan statistik , dll. Salah satu perpustakaan terbaik sebenarnya adalah Distributions.jl yang memungkinkan Anda menulis algoritma umum untuk distribusi (misalnya:rand(dist)mengambil sejumlah acak dari distribusi apa pun yang diteruskan), dan ada banyak distribusi univariat dan multivariat (dan tentu saja pengiriman terjadi pada waktu kompilasi, menjadikan ini semua secepat hardcoding fungsi khusus untuk distribusi). Ada banyak perkakas penanganan data , server web , dll. Anda sebut saja. Pada titik ini sudah cukup matang bahwa jika ada hal ilmiah dasar dan Anda akan mengharapkannya ada, Anda hanya Google dengan .jl atau Julia dan itu akan muncul.

Lalu ada beberapa hal yang perlu diingat di cakrawala. PackageCompiler sedang mencari untuk membangun binari dari perpustakaan Julia, dan sudah memiliki beberapa keberhasilan tetapi membutuhkan pengembangan lebih lanjut. Makie.jl adalah seluruh perpustakaan untuk plot yang dipercepat GPU dengan interaktivitas, dan masih membutuhkan beberapa pekerjaan lagi, tetapi itu benar-benar ingin menjadi perpustakaan plot utama di Julia. Zygote.jl adalah pustaka diferensiasi otomatis sumber-ke-sumber yang tidak memiliki masalah kinerja AD berbasis penelusuran (Pelacak Flux, PyTorch, Jax), dan yang sedang mencari untuk bekerja pada semua kode Julia murni. Dll

Sebagai kesimpulan, Anda dapat menemukan banyak gerakan di banyak tempat, tetapi di sebagian besar wilayah sudah ada perpustakaan yang matang matang. Itu tidak lagi berada di tempat di mana Anda bertanya "apakah itu akan diadopsi?": Julia telah diadopsi oleh cukup banyak orang (jutaan unduhan) sehingga ia memiliki momentum untuk bertahan selamanya. Ini memiliki komunitas yang sangat bagus, jadi jika Anda hanya ingin merasakan angin sepoi-sepoi dan berbicara tentang komputasi paralel atau persamaan diferensial numerik, beberapa ruang obrolan terbaik untuk yang ada di Julialang Slack . Apakah itu bahasa yang harus Anda pelajari adalah pertanyaan pribadi, dan apakah itu bahasa yang tepat untuk proyek Anda adalah pertanyaan teknis, dan itu berbeda. Tetapi apakah itu bahasa yang telah matang dan mendapat dukungan dari sekelompok besar pengembang yang konsisten? Itu sepertinya ya, ya.

Jika tidak, mungkinkah memberikan perkiraan kasar untuk berapa lama saya harus menunggu sebelum mempertimbangkannya lagi?

Perkiraan kasar saya tentang berapa lama waktu yang dibutuhkan bahasa sains komputasi untuk matang sekitar satu dekade.

Contoh 1: SciPy dimulai pada tahun 2001 atau lebih. Pada tahun 2009, Scipy 0.7.0 dirilis, dan integrator ODE memiliki antarmuka ke VODE (yang setara dengan ode15s, kira-kira; ode15sberbasis NDF, VODE adalah BDF / Adams-Bashforth, tergantung). Dengan SciPy 0.10.0, sebuah antarmuka untuk dopri5, yang kira-kira setara dengan MATLAB ode45, sebuah metode pesanan Runge-Kutta ke-4 biasanya diperkenalkan sebagai metode integrasi numerik praktis pertama untuk para sarjana. SciPy 0.10.0 dirilis pada Desember 2011, dan butuh sekitar 10 tahun bagi mereka untuk memasukkan fitur MATLAB yang diperkenalkan ke setiap sarjana teknik yang saya tahu.

Contoh 2: Mathworks didirikan pada tahun 1984. Dalam rilis pertama mereka, mereka menggunakan port LAPACK ke C bernama JACKPAC (setelah Jack Little, seorang insinyur MathWorks yang menulisnya). Mereka tidak menggantinya dengan LAPACK sampai tahun 2000.

Julia mungkin membutuhkan waktu lebih sedikit, tetapi saya memperkirakan sekitar 10 tahun dari pendirian menjadi arus utama. (Sudah sekitar setahun atau lebih; ​​mungkin 9-10 tahun, lalu?)

Apakah sistem perpustakaan Julia sepenuhnya berkembang di bidang-bidang ini? Secara khusus, apakah API lebih atau kurang stabil untuk jenis-jenis kegiatan itu, atau apakah saya akan menemukan bahwa kode lama saya cenderung rusak setelah memutakhirkan ke versi baru Julia?

Saya tidak menggunakan Julia, jadi ambil apa yang saya katakan dengan sebutir garam, karena saya hanya melihat Jeff Bezanson memberikan presentasi tentang Julia. Mereka membungkuk ke belakang untuk memudahkan menautkan dan menggunakan perpustakaan dari C, Python, dan Fortran. Jika Anda tidak dapat menemukan perpustakaan Julia yang melakukan apa yang Anda inginkan, tulis Julia shim untuk perpustakaan dalam bahasa yang lebih mapan. Akibatnya, saya tidak berpikir kurangnya perpustakaan akan menjadi perhatian. Saya pikir kekhawatiran akan memastikan bahwa perubahan pada fitur bahasa inti tidak menggigit Anda. Jika Anda melihat tonggak dalam repo Julia Git, Anda akan melihat bahwa tag "breaking" digunakan sedikit (12 kali dalam rilis 0,2, 5 kali dalam rilis 0,3). Bagi saya, itu menunjukkan bahwa bahasa inti masih berkembang, itulah sebabnya saya ragu untuk menggunakan bahasa itu sekarang.

EDIT: Aurelius membawa poin bagus:

Apa yang membuat Anda menganggap Julia akan benar-benar menjadi arus utama, dan tidak hanya mati dalam ketidakjelasan seperti banyak bahasa lainnya? SciPy / numpy mendapat / mendapat dukungan dari komunitas python yang terus berkembang, yang tidak dimiliki Julia.

Dalam jawaban asli, saya memutuskan untuk menghindari pertanyaan "Apakah Julia akan berhasil menjadi arus utama?" sebanyak mungkin. Gagal itu mudah; sukses itu sulit. Saya pikir perbandingan terbaik dari Julia adalah dengan bahasa komputasi teknis seperti MATLAB, R, dan Octave. Bahasa HPC (Chapel, Fortress, UPC, dll.) Memiliki audiens yang lebih sempit daripada bahasa komputasi teknis, dan bahasa tujuan umum (C, Python, C ++, dll.) Memiliki audiens yang lebih luas daripada bahasa komputasi teknis.

Sesuatu yang saya pikir membantu Julia adalah merancang kinerja tanpa mengorbankan ekspresi. Julia jauh lebih kompetitif dengan bahasa yang dikompilasi seperti C daripada MATLAB, R, atau bahkan Python. Tujuan desain ini juga merupakan fitur yang dapat menarik orang dari bahasa yang ada, seperti:

• Orang-orang yang peduli banyak tentang kinerja dan berasal dari bahasa seperti C dan Fortran, tetapi bersedia untuk mengorbankan kecil sedikit kinerja (mungkin faktor 2ish) untuk pergi dari bahasa dikompilasi untuk sedikit baris bahasa ditafsirkan (bersama dengan repl untuk pengembangan dan pengujian yang lebih cepat).
• Orang yang peduli dengan produktivitas tinggi dan berasal dari bahasa seperti Python, R, dan MATLAB, tetapi menginginkan lebih banyak kinerja. Ketika datang ke eksekusi, Python murni, MATLAB murni, dan R murni lambat. Pengembang dalam bahasa tersebut telah keluar dari cara mereka untuk membungkus perpustakaan dalam bahasa yang dikompilasi, tetapi Anda tidak dapat membungkus semuanya, dan pada titik tertentu, bahasa inti akan memperlambat Anda. Core Julia lebih cepat, yang memungkinkan Anda melakukan lebih banyak sains lebih cepat.
• Orang yang peduli dengan perangkat lunak bebas. Julia ditafsirkan dan bebas (demikian juga Python, Oktaf, dll.); MATLAB tidak.

Julia juga berusaha memfasilitasi paralelisme; Saya tidak merasa sangat memenuhi syarat untuk memperluas pada titik itu, dan saya tidak berpikir itu adalah daya tarik utama dari bahasa itu, tapi saya pikir itu adalah titik penjualan yang sedang mereka kerjakan, dan saya berharap orang lain dapat menjelaskannya.

Namun, bahkan dengan kemampuan teknis di pihak mereka, pembuat bahasa harus melakukan kerja keras untuk mempromosikan bahasa dan menginjili. Jeff Bezanson, Alan Edelman, Stephen Karpinski, dan Viral Shah bekerja sangat keras untuk membuat bahasa tersebut berhasil. Alan Edelman memiliki ikatan yang dalam dengan komunitas ilmu komputer, dan dia pernah mengerjakan proyek tingkat bahasa sebelumnya (terutama, ekstensi Star-P ke MATLAB). Jeff Bezanson telah melakukan sirkuit konferensi untuk mempromosikan Julia ke ilmuwan komputasi dan insinyur untuk sementara waktu. Di MIT, mereka telah melakukan pekerjaan yang baik dalam merekrut siswa dan staf (terutama, Steven G. Johnson) untuk berkontribusi dengan menambahkan perpustakaan ke Julia. Mereka punya artikel di Wired, dan berhasil mendapatkan artikel Wikipedia untuk diri mereka sendiri, semuanya hanya setelah satu tahun. Repo Git mereka memiliki ribuan bintang, ratusan garpu, dan ratusan jam tangan, jadi menurut standar sumber terbuka, proyek mereka telah sukses. Saya pikir mereka telah melakukan semua hal yang benar sejauh ini, jadi ini masalah mempertahankan upaya dan membangun komunitas. Mereka masih bisa gagal, tetapi sejauh ini menunjukkan kepada saya bahwa mereka memiliki peluang yang masuk akal untuk sukses.

Saya percaya Julia layak dipelajari. Saya telah menggunakannya untuk menghasilkan beberapa kode elemen hingga, dan memproduksinya dengan sangat cepat. Saya sangat senang dengan pengalaman saya.

Julia telah memungkinkan alur kerja bagi saya yang sulit untuk dicapai dengan bahasa lain. Anda dapat menggunakannya sebagai bahasa prototyping seperti MATLAB, tetapi tidak seperti MATLAB ketika Anda memiliki kode yang berfungsi dan melalui iterasi profiling untuk mempercepatnya, mengganti hotspot dengan kode C tidak menimbulkan rasa sakit. Mereka telah menjadikan interfacing dengan C (dan Python) sebagai prioritas dalam desain.

Dengan demikian bahasa telah memungkinkan saya untuk bergerak sangat cepat dari formulasi matematika saya ke kode fungsional dan kemudian dari kode fungsional ke kode yang sangat berkinerja tinggi. Saya pikir fitur Julia ini kurang terjual, tetapi ini menambah nilai luar biasa.

Dalam banyak kasus saya telah memperoleh kinerja C (dibandingkan dengan kode C saya sendiri) dalam hitungan jam setelah menghasilkan kode elemen hingga fungsional. Sejauh ini jika saya hanya menggunakan fitur Julia, saya biasanya sampai ~ 3X lebih lambat dari C. Setelah ini saya mengganti hotspot dengan fungsi C (Julia datang dengan profiler stack sampling untuk membantu mengidentifikasi ini). Seringkali ini hanya membutuhkan penggantian baris kode hotspot yang menyinggung dengan "ccall," dengan Julia menangani marshalling apa pun.

Saya pikir hal-hal utama yang hilang Julia saat ini meskipun yang membuat saya ragu untuk mempertimbangkannya untuk proyek yang lebih besar adalah kurangnya debugger yang didukung penuh, dan dukungan yang buruk untuk merencanakan (sekarang taruhan terbaik Anda dalam merencanakan sebenarnya hanya sebuah antarmuka ke matplotlib bahwa saya telah istirahat lebih sering daripada tidak). Umpan balik langsung pada kode sangat penting. Saya juga tidak tahu bagaimana bertahan tanpa debugging interaktif, dan dalam hal ini saya sangat dimanjakan oleh MATLAB dan GDB.

Dari pengalaman saya, Julia belum siap untuk penggunaan sehari-hari (ilmiah) (saya sedang berbicara tentang versi stabil maret 2016). Bahasanya sendiri bagus, kaya fitur dan konsisten; sebuah langkah maju yang menyegarkan dari matlab dan python. Tentu ada kasus penggunaan di mana Julia adalah pilihan yang baik bahkan pada tahap awal ini. Tetapi jika Anda membutuhkan perpustakaan ilmiah yang andal dan matang, saya tidak bisa merekomendasikan untuk pindah sekarang. Masalah utama yang saya temui adalah:

• Paket-paket di luar inti Julia tidak dapat diandalkan. Mereka putus dengan pembaruan, perubahan, diganti, kadang-kadang tidak lengkap atau hanya rusak.
• Fitur paralelisme Julia (imo fitur pembunuh matlab potensial yang paling menjanjikan) masih belum matang. Anda akan menemukan kesalahan segmentasi, kebocoran memori, kerusakan, dan kinerja yang mengecewakan. Kadang-kadang mereka tidak bermain dengan baik dengan bagian lain dari julia, misalnya beberapa pemecah untuk sistem linier atau paket di luar inti. Walaupun fitur-fitur ini terdengar menjanjikan, mereka sering gagal bagi saya. Hampir tidak pernah cukup untuk menulis @paralleldi depan for for, di mana secara teori seharusnya.
• Banyak hal-hal kecil, bug kecil dan masalah yang bisa diatasi seseorang: jejak tumpukan panggilan yang tidak begitu bagus dan kadang-kadang salah, sedikit riwayat juru buggy, pemuatan paket yang lambat, kinerja yang buruk dari satu atau paket / fungsi lain, dll. Apa yang mengganggu saya adalah kebanyakan adalah paket PyPlot, pembungkus untuk matplotlib, saat ini tidak ada alternatif untuk itu. Sangat bagus karena ada di sana dan sebagian besar berfungsi. Tetapi jika Anda perlu memplot data, bersiaplah untuk kinerja dan masalah yang sangat lambat.

Ini semua akan menjadi lebih baik. Saya yakin bahwa suatu hari julia akan lebih unggul dari matlab dan python di hampir setiap aspek. Kemungkinan besar paket inovatif akan dikembangkan untuk itu. Sepertinya sudah ada komunitas besar. Bahkan sekarang ada banyak paket dengan kasus penggunaan mulai dari OpenGL hingga Webservers. Menggunakan python atau c libraries sangat mudah, jadi Anda mungkin tidak akan menabrak dinding dalam hal ketersediaan perpustakaan. Kekuatan besar Julia adalah kesukaran yang dengannya seseorang dapat menyatukan fungsionalitas kinerja tinggi dari berbagai sumber dalam bahasa tingkat tinggi yang modern dan konsisten (lihat jawaban di atas). Tetapi secara keseluruhan saya menemukan itu tidak matang atau cukup stabil untuk digunakan secara produktif.