原文地址：
https://blog.csdn.net/seekiu/article/details/47397067
隨着 Julia 1.0版本的推出，人工智能圈子比較炸鍋， 好像這門小眾語言要趕超Python了， 作為現在編程領域的大佬，Python最被人詬病的就是運算性能，恰巧 Julia 是已高性能並行計算為主打，並且兼顧了語法簡潔和動態性，好奇之下找了找網上的相關資料，發現確實是太小眾了，最后發現了下面這篇文章，覺得有些用處。
以下為原文內容：
上一篇博文中推薦了 Python 的 JIT 編譯器 numba，這兩天又用空余的時間嘗試了一下最近的一個新興語言 Julia。Julia 的目標設定得很高，未來是要成為一個速度上接近甚至超過 Fortran/C 這樣的傳統語言的通用編程語言。然而就我這兩天很初步的嘗試結果看來，它也許有這個能力，但至少目前，對工程計算的人來說，還沒有達到 production-ready 的程度。（當然，這只是基於我個人的編程經驗和需求的結論，很可能不適用於其他人。而且Julia本身是一門相對年輕的語言，很值得持續關注。）
之所以這樣說，有三個方面的理由：
-
作為一個動態語言，它的 JIT 編譯器（在很多情況下）還沒有智能到，讓我可以同時享受動態語言的便利和它的速度優勢。例如最近我在試用 Julia 時最先嘗試的就是把原來用 Numba 寫的函數重寫一遍，然而發現結果非常不好。Julia 版本的函數執行速度相當於純 Python 的速度，與 Numba 版本相差三個數量級，占用的內存也異常地大。后來發現，最主要的原因是三層嵌套循環中，循環長度我按 Python 的習慣定義為變量，而在 Julia 中不變的全局量最好聲明為常量。僅僅這個修改，讓速度提升了兩個數量級，但還不及 numba 的速度。進一步的測試還可以通過一些細小的地方來進一步提升速度，如這篇文章做的那樣，最終高度優化之后速度也許可以達到接近 Fortran。但是，如果要這樣做，為什么不干脆用 Fortran 呢？相比之下，numba 的可用性就要高太多了。不過畢竟它現在的穩定版本還是0.3.10，還需要再給它一點時間發展成熟。
-
作為一個新興、小眾的語言，相關的工具鏈還太弱了。沒有合格的 IDE，Juno 在我看來現在連半成品都還算不上。包管理似乎是用的 Git，有時會出一些奇怪的問題，這時候用
Pkg倒還不如手動去管理。調試程序也比較痛苦，一方面是很多錯誤信息跟沒給差不多，像我這種不熟悉的人基本只能用print一半一半地查，另一方面是相關的調試工具也還不夠好用。 -
文檔、相關信息還太少。已經有不少人開始使用 Julia，但網上公開的信息中，官方的文檔還比較簡陋，其他用戶貼出的博客也很少。這導致在遇到問題的時候，很難快速地難過 Google 直接得到問題的答案，而往往需要在社區中等待圈內人士的解答。
另外一個對 Julia 印象不太好的是，官網給出的 benchmark 沒有多少參考價值，至少其結果中 Python 和 Matlab 都很有問題，多半是單純地逐行翻譯出來的程序。這就跟我把 numba 的程序直接翻譯成 Julia，然后得出結論它很慢一樣，是不公平的比較。
不管怎么樣，Julia 目前看來還是值得持續關注的，但是目前，我還不會考慮把它作為主要的計算語言。