我認為關鍵在於是否開始為Julia開發庫。看到玩具示例（即使它們是複雜的玩具）也很好，這很好，證明茱莉亞在任務R不好的情況下將R吹了水。為什麼我認識的許多使用R的人都使用R。他們之所以使用R，是因為幾乎在陽光下進行任何統計任務時，都有人為其編寫了R代碼。 R既是一種編程語言，又是一種統計軟件包-目前，Julia只是前者。 ）仍然難以使用可用的統計工具包。

我同意很多其他意見。 “希望”？當然。我認為Julia多年來從R和Python / NumPy / Pandas以及其他系統所做的對與錯中學到了很多東西。如果我比以前更聰明，並且想寫一種新的編程語言作為將來的統計開發環境的基礎，那麼它看起來很像Julia。

這就是說，事後才可能回答這個問題還需要5年。到目前為止，Julia缺少統計編程系統的以下關鍵方面，該系統可能與R競爭日常用戶：

（列表隨時間更新...）

• 可選排序的因子類型
• 大多數統計檢驗和統計模型
• 有素編程/可再現分析支持
• R類即便是Matlab類的繪圖

要與R，Julia和附加統計信息包競爭，也需要足夠乾淨和完整，以使聰明的非程序員能夠做到，例如社會科學專業的研究生，可以合理地使用它。要達到目標，需要進行大量的工作。

Update：

Julia現在支持缺少數據/ NA的DataFrame，模塊/命名空間，公式類型和 model.matrix 基礎結構，繪圖（排序），數據庫支持（但尚未提供給DataFrames）以及通過關鍵字傳遞參數。現在還提供一個IDE（Julia Studio），Windows支持，一些統計測試以及一些日期/時間支持。

對我來說，數據分析語言的一個非常重要的事情是具有查詢/關係代數功能以及合理的默認值和麵向交互的設計，並且理想情況下，這應該是該語言的內置功能。 IMO，沒有我使用過的FOSS語言能有效地做到這一點，甚至R也沒有。

data.frame交互操作非常笨重-例如，它在調用時打印整個數據結構，\ $語法很難以編程方式使用，查詢需要冗餘的自引用（即 DF [DF $ x < 10] ），連接和聚合都很麻煩。 Data.table解決了大多數此類煩惱，但由於它不是核心實現的一部分，因此大多數R代碼都沒有利用其功能。

python中的熊貓也遭受相同的錯誤。

這些問題看似挑剔，但這些錯誤會累積起來，最終總會耗費大量時間，最終很明顯。

我相信Julia能否成功進行數據分析在這種環境下，必須致力於在用戶友好的表數據類型上實現SQL類型運算符（不佔用SQL語法）。

我可以按照Dirk和EpiGrad所說的簽字；然而，還有另一件事使R在其利基市場中成為獨特的語言-面向數據的類型系統。

R是專門為處理數據而設計的，這就是為什麼它以向量為中心並且具有諸如data.frame，因子，NA和屬性之類的東西。另一方面，Julia的類型具有數值性能

這可能看起來是無害的，但是任何嘗試使用MATLAB進行統計的人都知道它確實很痛。

p>因此，至少對於我來說，Julia無法提供我無法用幾行C塊修復的任何內容，並且殺死了許多真正有用的表達方式。

我可以看到Julia取代了Matlab，這對人類是一項巨大的服務。

要取代R，您需要考慮Neil G，Harlan和其他人提到的所有內容，還有一個我認為無法解決的重要因素：易於安裝應用程序及其庫。

現在，您可以下載適用於Mac，Windows或Linux的R的二進製文件。它具有大量的統計方法開箱即用的功能。如果要下載軟件包，只需簡單的命令或單擊鼠標即可。

我去下載了Julia，這並不簡單。即使下載了二進製文件，也必須安裝gfortran才能獲得正確的庫。我下載了源代碼並嘗試進行 make ，但失敗了，沒有任何真正有用的消息。我有計算機科學的本科和研究生學位，所以如果我願意的話，我可以四處摸索並開始工作。 （我不是。）Joe Statistician會這樣做嗎？如果出於某種原因，您需要從源代碼編譯軟件包，則實際上並沒有什麼困難（只要您在系統上安裝了適當的編譯器等）。您不能忽略此基礎結構，可以通過github進行所有操作，並期望得到廣泛採用。

編輯：我想四處逛逛Julia –看起來很令人興奮。兩個問題：

1）當我嘗試安裝其他程序包時（忘記了它們在Julia中的稱呼），它失敗並顯示了模糊的錯誤。顯然，我的Mac沒有他們所期望的make-like工具。它不僅會失敗，而且還會留下我必須手動刪除的內容，否則其他安裝將會失敗。

2）它們在一行代碼中強制一定的間距。我前面沒有細節，但是它與宏有關，並且在宏和括號之間沒有空格來打開其參數。這種限制確實使我感到煩惱，因為我已經開發了多年的代碼格式和語言，而且實際上在函數/宏名稱和左括號之間留了一個空格。我了解一些代碼格式限制，但是一行中有空格嗎？

朱莉婭語言很新；它在聚光燈下的時間可以用幾週來度量（即使它的顯影時間當然可以用數年來度量）。現在，這些星期是非常激動人心的幾週-例如，在斯坦福大學最近的演講“這才剛剛開始”-但您在更廣泛的基礎架構和軟件包支持方面的要求將花費更長的時間實現。

因此，我將繼續使用R，並且要注意其他替代方法的開發。去年，有很多人對Clojure進行抗議。今年朱莉婭（Julia）是新的統治者。我們看看它是否粘住。

這裡是布魯斯·泰特（Bruce Tate），《七週之七種語言》的作者。這裡有一些想法。我正在為Julia編寫後續書籍。以下是我玩了幾週後的看法。

有兩個基本作用力在起作用。首先，所有語言都有生命週期。 R將有一天被替換。我們不知道什麼時候。新語言的發展非常困難。當一種新語言發展起來時，通常可以解決一些壓倒性的痛點。

這兩件事是相關的。對我來說，我們開始看到圍繞R之類的語言正在形成一個主題。它不夠快，而且比所需的要難。那些可以在一定性能範圍內生活並留在已建立的庫中的人很好。那些不需要更多的人，他們開始尋找更多。

問題是，計算機體系結構正在發生變化，並且要利用它們，必須以某種方式構造語言及其結構。 Julia對並發的看法很有趣。它為這種語言優化了正確的選擇：透明分發和進程之間數據的有效移動。當我將Julia用於典型任務，映射和轉換等時，我只是在調用函數。我不必擔心管道問題。

對我來說，Julia在一個處理器上更快的事實很有趣，但對R而言卻不是太過分。對我而言，有趣的是，隨著處理器越來越依賴多核來提高性能和技術，如果使用正確的語言，那麼計算問題就處於理想的位置，可以發揮最大的優勢。

可以幫助實現此目標的另一個功能確實是宏。目前語言的節奏非常緊張。宏使您可以使用更大，更乾淨的構建塊進行構建。查看庫很有趣，但並不能說明全部情況。您需要查看庫的增長。朱莉婭的軌跡就在這裡。

Clojure對某些人來說很有趣，因為沒有技術語言可以做到R所能做到的，因此有些人希望使用通用語言來填補這一空白。我實際上是個超級粉絲。但是Clojure是一個非常嚴重的大腦扭曲。 Clojure將提供給需要進行技術計算的程序員。它不適合工程師和科學家。有太多東西要學。

所以對我來說，Julia或類似的東西絕對有一天會取代R。這是時間的問題。

每當我看到一種新語言時，我都會問自己自己為什麼不能對現有語言進行改進。

Python的一大優勢是

• 豐富的模塊（不僅是統計信息，還包括繪圖庫，輸出到pdf等）
• 最終需要長期使用的語言構造（大型項目中需要的面向對象構造；裝飾器，閉包等簡化了開發的工作）
• 許多教程和龐大的支持社區
• 如果您有大量數據需要處理並且不介意花幾分錢，就可以訪問mapreduce在集群上運行它。

為了超越R，Julia等，Python可以使用

• 即時編譯開發受限的Python在單台計算機上為您提供更高的速度（但如果您能承受延遲，則mapreduce仍然更好）
• 更豐富的統計庫

Julia不會很快接管R。簽出Microsoft R open。

https://mran.revolutionanalytics.com/open/

這是R的增強版本，可自動使用所有您計算機的核心。它是相同的R，相同的語言，相同的軟件包。安裝時，RStudio還將在控制台中使用它。 MRO的速度甚至比Julia還要快。我做了很多重型計算，並且已經使用Julia一年多了。我最近改用R是因為R有更好的支持，而RStudio是很棒的編輯器。 Julia仍處於初期階段，可能很快就無法趕上Python或R。

以下內容可能不應該作為答案，但將其作為對他人響應的評論加以掩蓋是非常重要的……

我沒有聽到太多關於內存消耗的說法，只是速度。 R的整個語義都是按值傳遞的，這可能會很痛苦，而這一直是對該語言的一種批評（這與已經存在的許多優秀軟件包是一個獨立的問題）。良好的內存管理非常重要，具有處理核心外處理的方法（例如numpy的內存映射數組或 pytables或Revolution Analytics的 xdf格式）。雖然PyPy的JIT編譯器允許使用一些引人注目的Python基準測試，但內存消耗可能會很高。那麼，有人對Julia和內存使用有經驗嗎？聽起來好像Windows“ alpha”版本上存在內存洩漏，這無疑將得到解決，而我仍在等待訪問Linux機器來自己使用該語言。

由於許多前面提到的原因，我認為Julia不太可能會取代R。 Julia是Matlab的替代者，而不是R的替代者。他們有不同的目標。即使在Julia具有完備的統計數據庫之後，也沒有人會在其中教授Intro to Statistics課程。

但是，作為速度優化的編程語言，它在令人難以置信的領域中沒有C / C ++那樣痛苦。如果將其無縫鏈接到R（採用Rcpp樣式），那麼它將在編寫對速度至關重要的代碼段中大量使用。不幸的是，目前沒有這樣的鏈接：

https://stackoverflow.com/questions/9965747/linking-r-and-julia

我是Julia新手，並且具備R能力。到目前為止，我發現Julia有趣的原因是面向性能和兼容性。

GPU工具。我想將CUSPARSE用於統計應用程序。 CRAN結果表示那裡沒有太多東西。 Julia具有可用的綁定，到目前為止似乎可以正常工作。

 使用CUSPARSEN = 1000M = 1000hA = sprand（N，M，.01）hA = hA'* hAdA = CudaSparseMatrixCSR（hA）dC = CUSPARSE.csric02（dA，'O'）＃不完整的Cholesky分解= CUSPARSE.to_host（dC） 

HPC工具。一個人可以與多個計算節點交互使用集群。

  nnodes = 2ncores = 12＃詢問我們控制的節點上的所有內核procs = addprocs（SlurmManager（nnodes * ncores），partition =“ tesla  proc> 

Python兼容性。。可以訪問procs中的工作進程中的工作程序的節點，節點= n個節點。生態系統。例如。找出如何讀取大腦成像數據很簡單：

  import PyCall @ pyimport nibabelfp =“ foo_BOLD.nii.gz” res = nibabel.load（fp）data = res [：get_data ]（）;  

C兼容性。以下代碼使用C標準庫生成一個隨機整數。

  ccall（（ ：rand，“ libc”），Int32，（）） 

速度。以為我會看到Distributions.jl包是如何針對R的rmrm進行優化的-我認為它是經過優化的。

  julia> F = Normal（3,1）Distributions.Normal（μ= 3.0，σ= 1.0）julia> @elapsed rand（F，1000000）0.03422067  

在R：

  > system.time（rnorm（1000000，mean = 3，sd = 1））用戶系統運行時間為0.262 0.003 0.266  

Julia 1.0剛剛推出了非常有用的IDE（Juno）。由於Python已經在機器學習中佔據了主導地位，而R繼續在所有其他類型的統計分析中處於主導地位，因此晚了一點。話雖如此，茱莉亞已經在金融和交易算法領域中脫穎而出，因為必須要有快速的開發時間和執行力。我認為，除非出現另一種明顯更好的語言，否則朱莉婭（Julia）的顯赫地位可能看起來像這樣：

（1）開始吃MATLAB的午餐。 MATLAB用戶喜歡MATLAB語法，但幾乎討厭其他所有內容。速度慢，許可證昂貴，處理不是矩陣的複雜數據結構的方式非常有限。我記得有句名言說：“如果Julia取代了MATLAB，那將是對人類的巨大服務”。 MATLAB用戶可以很快地熟練使用Julia，並且對編寫質量比MATLAB所能做的事情要簡單得多的高質量代碼感到印象深刻（快速的結構可以放入數組中并快速迭代嗎？）。不僅如此，研究人員還可以在Julia（一個小團隊的博士生編寫了世界一流的微分方程組）中創建嚴肅的工具箱，而這在MATLAB中是不可能的。

（2）開始接管數值方法和模擬的研究。麻省理工學院正在大力支持朱莉婭，研究界也在傾聽麻省理工學院的聲音。數值模擬和新的數值方法是沒有庫的不確定問題。這就是茱莉亞語言的光芒。如果沒有可用的庫，那麼用Julia編寫快速質量的代碼比其他任何一種語言都容易得多。這將是一種由數學家為數學家編寫的數字/模擬語言（聽起來與R相似嗎？）

（3）機器學習的另一個突破發生了，這給了Julia以優勢。這有點通配符，可能不會發生。 TensorFlow很棒，但是很難破解。 Python已經開始顯示裂縫，並且TensorFlow已開始採用Swift（Julia獲得了榮譽獎）。如果發生另一項機器學習突破，那麼使用Flux.jl之類的Julia程序包將更容易實現和破解。

（4）朱莉婭開始慢慢追上R，這需要一段時間。在MATLAB中進行統計非常痛苦，但是Juila在Distributions.jl方面已經領先於MATLAB。事實是，R工作流可以輕鬆轉換為Julia。 R唯一真正的優點是，統計人員為統計人員編寫了許多軟件包。但是，此過程在Julia中也很容易做到。區別在於，Julia一路走得很快，而且您不必使用另一種語言來提高性能（更“嚴肅”的R包是用C等語言編寫的）。 R的問題是用R編寫的包太慢而無法處理大量數據。唯一的選擇是將軟件包翻譯成另一種語言，從而使R中的開發過程比Julia慢。如果需要翻譯太多R包來處理更大的數據集，R可能會在這些領域開始追趕Julia。

我對使用不同體系結構實現更快的速度和更容易的並行化的承諾很感興趣。因此，我一定會注意Julia的開發，但是直到它能夠處理廣義線性混合模型，具有良好的通用引導程序包，用於構建設計矩陣的簡單模型語言，等效於ggplot2的能力以及廣泛的應用範圍之後，我才不太可能使用它。來自機器學習算法。

沒有統計學家對工具的選擇抱有原教旨主義的態度。我們將盡一切可能使我們最有效地完成工作。我的猜測是我會堅持使用R幾年了，但是很高興得到驚喜。

R中NA的豪華並非沒有性能損失。如果Julia支持具有較小性能損失的NA，那麼這對於stats社區的一部分來說就變得很有趣，但是當將已編譯的代碼與R一起使用時，NA也要進行大量額外的工作。

R中的許多軟件包都依賴於用傳統語言（C，Fortran或C ++）編寫的例程。在某些情況下，已編譯的例程是在R之外開發的，後來用作R庫軟件包的基礎。在其他程序中，例程首先在R中實現，然後在發現缺乏性能時將關鍵段翻譯為編譯語言。如果可用於實現等效例程的Julia將會很有吸引力。有機會設計NA的低級支持，從而簡化了將R與編譯代碼一起使用時對NA的處理。

大量的R庫代表著許多用戶的努力。這是可能的，因為R提供了原本無法提供/無法承受的功能。如果茱莉亞（Julia）要被廣泛使用，它需要一群用戶，發現茱莉亞（Julia）比其他替代品要好得多，這值得提供非常基本的東西（例如，圖形，日期類，NA等）。 ）（可從現有語言中獲得）。

我會很先進，我沒有R的經驗，但是我和很多人一起工作，認為R是統計分析的出色工具。我的背景是數據倉庫，由於Julia的分佈很容易，但是標準的編程模型比較多，所以我認為它可以替代傳統ETL工具的轉換部分，這些工具通常做得很差，大多數無法實現。輕鬆創建標準化轉換，或重新使用已在先前數據集上執行的轉換結果。如果我想構建一個OLAP多維數據集，而該OLAP多維數據集基本上需要從已經計算出的元組中構建更詳細的元組（事實表），那麼對嚴格定義和類型化元組的支持就顯得格外重要，今天的ETL工具沒有“構建基塊”可言。可以提供幫助，該行業過去通過各種方法解決了此問題，但是需要權衡取捨。傳統的編程語言可以通過提供集中定義的轉換來提供幫助，Julia可以簡化更複雜的數據倉庫系統中常見的非標準聚合和分佈。

您也可以同時使用Julia和R。有 Julia-to-R接口。使用此軟件包，只要有需要的庫，您就可以在調用R的同時與Julia一起玩。

哦，是的，朱莉婭很快就會超越R。主要原因是“宏”，其中95％的語言是在Julia中實現的，並且其無噪音，簡約的語法。如果您沒有使用Lisp類型的語言的經驗，您可能還不了解它，但是您會很快看到R公式接口將如何成為過時和醜陋的機制，並被類似於CL的專用建模微語言取代循環宏。訪問對象的低級引用也是一個很大的好處。我認為R仍然沒有意識到，向用戶隱藏內部實際上不是使事情複雜化，而是簡化事情。

如我現在所見（R大量使用了R，並且剛剛閱讀了Julia手冊） ，Julia對於R的主要缺點是不支持結構繼承（這是有意的）。朱莉婭的類型系統沒有S4雄心勃勃；它也支持多重調度和多重繼承，但是有一個陷阱-只有一個級別的具體類。另一方面，我很少看到R中的類層次結構超過3個級別。

時間會證明一切，但它會比大多數R用戶想像的要早：）

Julia毫無疑問地有可能成為統計學家，讓超級用戶夢想成真，例如SAS，它的強大之處在於用C語言編寫的眾多proc-Julia可以做的就是為您提供帶有源代碼的proc，矩陣作為內置數據類型，通過SAS / iml分配。我毫不懷疑統計人員一旦掌握了這隻小狗的功能，便會蜂擁而至。

Julia的第一個目標用例是數值問題。基本上，您可以將這些分析和計算科學領域分為數據科學（數據驅動）和模擬科學（模型驅動）。Julia正在首先處理仿真科學用例。他們還在處理數據科學案例，但速度較慢。R永遠不會對模擬科學非常有用，但是Julia將會在兩年內非常有用。

它需要能夠將任何功能應用於用戶無法透明地存儲在內存中的大型數據集。
其中至少包括在適合磁盤的數據集上運行混合效果模型，生存模型或MCMC但不在內存上。並儘可能在分佈在多台計算機上的數據集上。