Choosing Julia, Matlab, Python or R in economics?

I use all languages for different things, or based on my familiarity with using them for a specific domain of problems. I really like Julia, and I think once the libraries grow, it will be the leader here. It currently has some really specific, and useful libraries for certain tasks. I like R's ecosystem, and being a Lisper, R and Julia are my favorites. Personal bias: Python bores me. I will program in C or C++ if I really need something fast and specific. The bottom line: if you are smart enough to do high-level science and engineering, then you should be able to develop a few skills with each of these in your toolkit. If I had my druthers, APL/J would be my language(s), but don't get me started down that path! Honorable mention, and overlooked, Frink [1]. It is always open on my desktop with a folder of custom programs I have written for different things over the past decade.

[1] https://frinklang.org/

Good to read. Opinionated takes add value. I wasn't completely clear when libraries were being used. For example, did the authors use base R's `read.csv()` or `readr::read_csv()` or something else to load the CSV file? Similarly, though they say R has no facilities for dependency management, that's true in the base language, but the "renv" package does a reasonable job.

I'd add that for very many people, computation speed is second order. I work with datasets of about half a million rows, which is large for economics, and I'm basically OK using R on a ten-year-old laptop. Sometimes a little pipeline management is necessary.

Actually, pipeline software would be a good addition to the article. In my experience, R's "drake" is pretty overengineeered, and I suspect its successor "targets" is not much better. It would be interesting to compare the solutions in other languages.

Another useful addition would be the ease of expressing simple data management tasks. So far my impression is that R with the tidyverse excels. There's not much simpler than

    dataset |> 
      filter(row == cond) |> 
      mutate(a = b + c) |>
      group_by(group_variable) |>
      summarize(x = per_group_computation(a,b,c))

where the code hews very closely to the problem domain.

An important practical consideration is the language employed within the working group, or in the sub-field.

For one-off code written by an expert, this doesn't matter much, and criteria such as those mentioned in the article might be paramount. In many cases, however, code starts off as a modification of something that already exists, and forms a seed from which other new things might spring. If everyone chooses their own language, collaboration can be hard.

In an academic environment, cost is a serious factor that argues against Matlab. Even in a place with a site license, somebody must be paying, and many groups have grown weary of the expense, particularly because it locks their students into a language that might not be available to them wherever they go after graduation.

I was an economist doing econometrics in excel when in 2014 the datasets went being a few 10,000's rows to a few 1,000,000's rows. I found R easiest to learn as a CS outsider because it was less strict about package versions and installation requirements, which made it easier for a beginner to setup and get going. I learned it by googling every little step ('how read in csv', 'how create new column in data.frame' etc) until I had a ~40 line R script that did what I was previously doing by hand in excel. It ran in a few seconds and did what took excel about 10 minutes.

A few years later I wrote an open source economics library in R: https://github.com/stevecondylios/priceR#pricer- It converts between nominal and real prices, converts between 171 currencies, and has a few regex's for pulling numeric data out of text (e.g. salaries out of job descriptions).

Some specific observations regarding the article:

- Comparing computation speed seems a bizarre metric to care about. 6x faster matters on things that take minutes, hours or days, but less so for operations that already run in under 1000ms. Developer experience is usually more important IME.

- The article mentions R library support is superior (which may or may not be true), but it would nice to see the most useful highly-regarded libraries from each language reviewed, or at least mentioned.

- The statement "(Julia) does not have any historical baggage" seems odd since a language doesn't need to be old before people find problems with it. Example from recent HN post: https://yuri.is/not-julia/

As a typescript developer who is now starting his PhD in finance, I asked myself recently which of these languages should I pick, taking into account how easy is to code in each language. To this end I tried to code a quick probability calculator based on the poisson-binomial distribution.

I found that R has the best libraries. It's the easiest language to use but it's also easy to write spaghetti code. Static analysis is a joke.

Writing code in Julia is slower/more tiresome. I have to annotate all structs and function input types. In languages like typescript, I would see this as an investment because tsserver will later use that information for linting and autocompletion, so the net return is clearly positive. In Julia however static analysis is very primitive and limited, you feel like having to write code twice: once for annotations and then again for the implementation, with very limited cross-checking between the two. When writing functions, output types are so hard to annotate that I just skip them completely and only annotate input types. Type errors are usually caught at runtime. The runtime messages are helpful though.

Unfortunately I couldn't even find a reputable Poisson-binomial package for Python so I stopped here. From my limited experience with python in other projects, I think that static analysis using pyright is mature and worth using (nets a positive return, although inferior to tsserver). This experience varies greatly between frameworks and packages, it's only worth to annotate the code if the underlying libraries also provide type hints.

I'm in the neuroscience (mostly EEG analysis), so my experience may not fit into economics field. I went from MATLAB only (and Stata for statistical analysis), through R (liked it a lot) and Python, to Julia-only data processing and analysis pipeline (rarely calling R for some required functions). To me Julia is the future of scientific computing, especially for current and ex MATLAB users.

If the article interests you, this reference is also worth your time:

https://tobydriscoll.net/blog/matlab-vs.-julia-vs.-python/

If visualization is required Matlab with the financial toolbox is a winner before the competition began.

Actually the only non perfect side of matlab is pricing. It also has the best help ever devised in history of cs. U can build a math PhD. Curriculum from matlab help pages.

I'm using a combination of R and Python.

R has more niche libraries (macroeconomics, climate economics, finance and game theory etc) and more open paper codes, Python is easier for me.

My supervisor uses Matlab though.

Haven't heard of anyone using Julia in Economics yet.

Interesting comparison! The criticism of julia is certainly valid, especially in terms of documentation. However, I wouldn't say that core language documentation should necessarily be geared towards any specific field.

In the implementation of the julia code there is a slight performance bug though (not sure if the authors submitted the article - the username certainly suggests it):

    function likelihood(o, a, b, h, y2, N)
        local lik = 0.0
       for i in 2:N
        @inbounds h = o+a*y2[i-1]+b*h
         lik += log(h)+y2[i]/h
        end
        return(lik)
    end

Only one use of y2 is marked @inbounds - in this case, either the second use too or the whole loop could be marked @inbounds (or the loop could be modified to run for all of eachindex(y2), with the first index being explicitly skipped).

The documentation, syntax, and libraries will be better with examples backing the arguments made. Also it will be nice if we had the code sources used. For environment, Python has Spyder that is similar to MATLAB desktop and RStudio.

I often load and process binary data with Matlab into spreadsheet format, because it supports so many file types.

Then process data frames in R or python. R for non-neural models and Python for GPU stuff. Visualizations also R.

A high performance, open source Julia code library for economics: https://quantecon.org/quantecon-jl/

An interesting writeup. Old versus new. So Julia is the language for those doing new things, Python and R for those with specialized applications and Matlab those stuck in legacy teams.

Is it me or they did some actual performance benchmarks without including any reference code? Because there are many different ways to load csv files for example even in R, so we have no clue what they used there. The same goes for "calculations".

When I was doing an economics degree in the 2005-2009 timeframe, Stata was the rage at my university. Have programming languages like Python and R displaced Stata and SPSS in the social sciences?

My take from the article and the discussion below is that libraries is what makes R the best. Is that true? Will python and Julia then catch up? Or is is just best to use R, warts and all?

The largest portion of the article is spent on comparing performance, and then at the end they say that performance doesn't really matter (which is probably true).

s/matlab/octave

Octave is wonderful, and getting better every year.

TLDR: R