Multiple dispatch and meta programming are both wonderful, irrespective of speed benefits.

For example, compare linear algebra syntax in Julia with those in R and Python.

Plus, the flexibility of multiple dispatch applying equally well to any of your own types really makes it feel like you can do anything in Julia.

Metaprogramming, writing code that writes code, can take a while to get used to. But is extremely powerful.

A final point I will make is comparability of Julia code. If you want to for a Bayesian model or solve a differential equation in Julia, you can mix your own types and code and any generically written library code at will, and it will often just work. In R, you're not likely to find that; your Stan code can't call R functions you've written or those from your favorite libraries.

Multiple dispach and meta programming are available in python as well. Although duck typing is usually a better solution and it's not really a killer feature to data analysts anyway.

Compared to python, i'd say julia has the reputation for being generally faster for things you can't use numpy with, and you can more easily scale multiple cpu or machines.

By metaprogramming in Python, do you mean using decorators ? If so that's a far cry from metaprogramming

Import hooks with access to the ast, full object introspection and metaclass are not too shaby.

They are not that used though, too much magic and implicit processing are not promoted in the community.

Not to shabby indeed ! Now have to check whats up with Hy.

Multiple dispatch has to be coded by hand in Python, it isn’t a feature of the language.

Python 3.7 added the ability to use type annotations with the @functools.singledispatch decorator which lets you write functions in a multi-dispatch manner.

As the name suggests, that lets you write functions in a single-dispatch manner. That is different from multiple-dispatch.

Sorry you are right. We only have single dispatch built in. I never had the use case for more so I confused them.

Ideally, Julia should give you the best of R (good, integrated data-types, -structures and functionality for statistics etc) and python (a sane, real programming language) - with the benefit of speed - and no/hardly any need to drop to/link to C libraries - "everything" is in Julia, and you can inspect the code "all the way down" (well, to a point - there's of course llvm at the bottom).

Whether Julia is that for you right now probably depends a bit on your needs/use cases.

Until Julia gains some form of aot compiler for static binaries - it's not quite an alternative to python imnho - you can't expect to run Julia scripts everywhere you can run python. Though this is similar to R. And there are of course much bigger ecosystems for python and R code/libraries than currently for Julia.

Personally I think they've done a great job on the design/syntax of Julia - it's a fun language - and that might be the best reason to play with it?

> and python (a sane, real programming language)

So... R is an unreal language then?

Nah, it's just a re-implementation of S, which was really, really old and different from what people expect.

R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming.

Because of the re-implementation of S, it has lots of odd quirks and multiple ways to do things, which Python tends to avoid. Python is definitely more consistent from a programming point of view, but R is a more cohesive system from an analytics point of view.

But yeah, lots of people are hateRs (unfortunately).

Wise words here.

In my humble opinion, applying S's syntactic sugar on top of Scheme-forged core did more bad than good to R. Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible.

As for the two approaches to solving problems (TIMTOWTDI vs Python's "one true way") I think that's a matter of personal preference; I, personally, appreciate the freedom that R gives me. Also, it might be anectodal, but I believe that - to some extent - it promotes thinking "outside the box", especially when you work in a team and review others' code on a daily basis.

> Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible.

On the other hand, if it was not for that compatibility with S we would not be having this conversation: R would be just a footnote in the history of statistical computing like Lisp-Stat.

Exactly! I probably didn't make the trade-offs clear in my original post. I believe that the massive price increases in S-plus licensing may have driven lots of people to start using R, which would definitely not have happened without the S-compatibility.

Your very last point should be heavily against R, not in favour. Having multiple ways to do the same thing is fine when you work by yourself, but in a large team it makes the style of the codebase vary a lot based on who wrote each block of code and makes reviewing others' code more difficult. If you want to get anything done, reading code really shouldn't be your daily challenge of how "outside the box" you can think just so you can understand what is going on.

That's true if we're talking about the overall architecture of the project. And, since R permits so many different coding styles (and paradigms: native functional and several OO), the team should have someone (usually the most senior software engineer) play the role of an architect and design the structure of the code, data structures, API, and so on.

Perhaps having a fixed (and commonly agreed on) set of design patterns - like in Java - makes development easier and smoother, but most of the projects I've worked on have proven successful, so maybe it's not that bad either... :-)

> Nah, it's just a re-implementation of S, which was really, really old and different from what people expect.

Was S "really, really old" when it was re-implemented in R? Gentleman and Ihaka first announced R in 1993 (26 years ago!).

The development of S started in 1976 (i.e. 17 years before R was first released). R was a implementation of S3, "the New S language", which was a major rewrite done in 1988 (it was just five years old when R was announced!).

I use R daily at work, and often reach for it before Python for non-statistical tasks out of comfort.

But R's functions for non-statistical tasks often break the language's idioms. Those dealing with files and connections are especially ugly.

I wouldn't call it insane or unreal, but it's definitely not intended for general scripting.

I don't argue that R is not insane ;-)

As for (a bunch of) functions in the basic library (which, essentially, is a set of packages that you can discard or simply not use), I dare say it has little to do with the language itself. I don't like Python's regular expressions library, for example, but it's only a set of functions (or methods) that you can write on your own! The same goes for R's data-wrangling routines; there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library. Heck, you can even write your own DSL (think: Grammar of Graphics) if you think it could improve your code!

There are several quirks built so deeply into the core of the language that you cannot overcome them ("why can't I overload `+` for character strings??"), but they have nothing to do with the rather poor and unintuitive basic library.

> there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library

A different take on the subject (https://r4stats.com/2017/03/23/the-tidyverse-curse/):

> On the other hand side – I have met a guy using R in production. And he told me that he needs code that stayed the same for 5+ years. That is why he does not use dplyr or any tidyverse, it is still changing too much.

That's right! And I always keep telling my peers that they should think twice before they decide to use tidyverse packages in the production code. What I meant is that in R you always have choice - and even if you feel that the existing solutions don't meet your expectations, you can always write your own (even if it means writing a DSL like Hadley et al. did in ggplot2 or rlang).

Last week I compared a standard regression command across several statistical programs (R, Py, Stata, Matlab, Julia, etc) on a stupidly simple 10x5 matrix, and Julia took ages to run (this is on windows). Even loading the CSV file took seconds in Julia, hundreds of times slower than all of the other packages put together.

I'm not sure if they just suck at Windows, but I was extremely dissapointed... :/

The first time you run code in a REPL Julia will have to compile it. So starting a new REPL, and trying to solve a very small problem one time will currently be a terrible workflow for Julia (unless you don’t care that it may take a few seconds).

If you had run your code again within the same REPL you’d see it runs substantially faster the second time. Likewise, if you had tried to process a large enough matrix or CSV that compilation time should be a minimal subset of the total computing time, and probably not noticeable.

It isn’t a language limitation, just a tooling limitation. The startup times have been getting better as Julia develops, but there is still noticeable overhead the first time code gets run in a new REPL...

Probably it took ages for the first invocation. Because that is when the compiler has to produce native code. The compiled codes then is super fast. Just invoke it a second time (in the REPL) to see the difference.

Obviously that question depends on your motivation, but one good reason is that it is a great way to learn how software actually works.

R makes it very easy to see the underlying R code (you just type the function name), until you get to a ".Call" or ".Primitive": from that point, it is effectively a black box.

But as most of Julia is written in Julia, you can easily inspect and understand how functions work, all the way down. Moreover, by using the @code_* macros, you can also inspect the various stages by which the code is transformed from high level Julia code down to the actual machine code which is running on your computer.

Think about it a moment, which answer would you prefer?

Regardless of the answer, I have plans to learn it simply out of curiosity. I'm just not yet convinced that there are any practical benefits to using Julia over the other languages.

As you said yourself, you have no performances problem with R and Python, so I do not think you need to learn Julia.

However, in fields dealing with larger datasets (e.g. genetics, astrophysics, ...), Python and R are real bottlenecks in data processing pipelines, and are thus often replaced by programs in C/C++/Java/etc. Having a language with the expressiveness and dynamism of Julia on the one hand, and performances in the same order of magnitude than C++ in the other hand is a huge plus.

Do they use Fortran in those fields?

In astrophysics yes (although I only follow the fields through friends), quite a lot of linear algebra/physics reference libraries are in Fortran, and new programs are still being developed in the more modern versions of it.

In Bioinformatics, not at all. Or at least in no direct way that I'm aware of. Sure, R packages indirectly call upon Fortran libraries (LAPACK et al.), but user facing programs are mostly, from my experience, written in C, C++, Java, Python & Perl.

Great, the answer is then: You should give it a try, to a certain extend "Why Julia is nice" is easier experienced than explained.