There are lots of R engines emerging! I’ve interviewed members of each of the teams involved in these projects. In part 1 of this series, we covered the motivation of each project. Part 2 looked at the technical achievements and new features. This part tries to determine which projects are suitable for which users.

Compatibility

CXXR and pqR and forks of GNU R, and have retained full package compatibility. This means that they should work out of the box on your existing R code (though note that both are Linux only and require you to build from source).

The other four engines are complete rebuilds, and consequently have had to recreate compatibility.

TERR currently has over 1200 completely compatible packages, and many more partially compatible ones.

Renjin also has, I think, over one thousand compatible packages. Helpfully, there’s a list of which CRAN packages work, and which don’t. (I haven’t bothered counting the blue dots, but it looks like almost half the packages are compatible.)

Riposte and FastR are at an earlier stage in development FastR has no package support at all, the Riposte is just getting around to it.

Justin Talbot:

A couple of months back I started a big push to transition Riposte from an academic project to a full-featured drop-in replacement for R. Right now, Riposte can load the base and recommended packages with just a few errors, which is a substantial improvement over a couple months back when it couldn’t load even one.

Interestingly, one of the big headaches reported by several engine developers is that some packages make assumptions about the internals of R. So they assume things like numeric vectors being pointers to double arrays, and it makes it harder for other engines to extend the functionality. It seems that some work is needed to the R Language definition to clarify exactly what a package should and should not be allowed to assume.

Licensing

pqR, CXXR, Renjin and FastR are all licensed under the GPL. Riposte is also open source, under the more permissive 2-clause BSD licence.

TERR, by contrast is a closed-source product. It comes in both free and paid for versions.

Ecosystem

Having lots of different engines is mostly great, but fragmentation is a big worry. Web development suffered for a long time (and still does, a little bit) from having to write different code for different browsers. SQL is subtly different for different databases, with vendor-specific extensions rampant.

All the engine developers have stated their intention to work towards (or retain) full compatibility with GNU R, and use that as the reference implementation. Certainly fragmentation is a problem that no-one wants.

Good intentions are all very well, but I was curious to know how much interaction there has been between the different teams, and with R-Core.

Between teams:

Tomas Kalibera previously worked at the University of Kent, where Andrew Runnalls is based. Surprisingly, they didn’t have much contact, as they were working in different areas at the time.

Jan Vitek was on Justin Talbot’s dissertation committee, so there has been some contact between the FastR and Riposte teams.

Justin has also spoken with Alex Bertram of Renjin.

Overall, there hasn’t been that much contact. I think I’d be less worried about fragmentation if the teams talked with each other more. (TERR is an exception in this; as a commercial product, a certain level of secrecy is required.)

A few R-Core names crop up in relation to several projects:

Doug Bates has been involved with CXXR.

Duncan Murdoch helped get some of pqR’s bug fixed merged into GNU R, and Radford Neal has had some contact with Luke Tierney and Robert Gentleman.

Luke Tierney has helped with the bytecode compilation in Renjin.

John Chambers, Ross Ihaka and Simon Urbanek have provided feedback on the TERR project.

Luke Tierney, Duncan Temple-Lang and Robert Gentleman have provided feedback to FastR.

Luke Tierney has helped on Riposte.

So at least some members of R-Core are aware of these projects, and there is some collaboration going on. Personally, I’d quite like to see a more formal arrangement with a language committee trying to refine the R Langauge Definition to aid compatibility between projects. This is probably just a legacy of my time as a civil servant.

The future

As a commercial project, TERR lives or dies by its ability to be sold (it does have a real customer base already, predominantly in the oil & gas, life sciences and consumer goods sectors).

Renjin is supported by BeDataDriven’s consultancy work, so it also has ongoing financial support.

The other four projects are all academic, so their long term support is trickier.

Work on Riposte is supported by Tableau Software, Justin’s employer, but it could use some additional developer time.

Justin Talbot:

Right now the team is just me. Zach has moved on to his dissertation work, the very cool Terra project (http://terralang.org). I’d be more than happy to expand the team if anyone is interested in helping out. Right now Riposte is at a place where there is a lot of easily factorable work in supporting popular packages or R’s internal functions that people could pick up if they wanted to. As I said at the beginning, Riposte’s overriding goal is to figure out how to execute dynamically-typed vector code like R at near the performance of highly optimized C. I think this sets it apart from a number of the other R projects like CXX, Renjin, and pqR, where better performance is nice, but not the driving design goal. If Riposte’s mission interests anyone, please get in contact!

CXXR and pqR are also solo projects and would benefit from developers.

Radford Neal:

I’m treating pqR as a fork, without any expectation that it will necessarily be merged with the version maintained by the R Core Team.

One necessary thread of work on pqR consists of fixing bugs, getting it to work in more environments (Windows, Mac, with GUIs), and adding features from later R Core releases. I’d like to have it compatible soon with R-2.15.1, and later with at least R-2.15.3.

There are still many areas in which performance can be improved
without major design changes.

At some point I’d like to get back to doing statistics, so I hope that
other people will also get involved with pqR.

FastR has a long term goal of being maintained by R-Core.

The hope is eventually that we could turn FastR over to R-Core. It is not necessarily our goal to maintain FastR forever – it should be in the hands of statisticians.

As well as developers, of course, the biggest thing that these projects need is a userbase. Feedback and bug reporting is hugely important, so a great way for you to contribute is to simply to try these projects out. Failing that, telling other R users that these projects exists is an excellent start. Get tweeting!