Hacker News Reader

Comment by claytonjy | Hacker News Reader

Maybe 3-4 years ago there was a big push to speedup R by replacing the runtime; at least 3 competing replacements were talked about pretty actively. None of them achieved much mindshare. R trades runtime speed for dev speed, and we juice performance by writing slow stuff in C++ and linking Intel's MKL. The RStudio folks are also making the low-level stuff faster and more consistent through the r-lib family of packages, which are awesome.

Big barriers to adoption here: not a truly drop-in replacement, R people have an aversion to Java (we've all spent hours debugging rJava; luckily most of those packages have been rewritten in C++ now), and nobody likes Oracle.

I think the best-case scenario here is that progress on FastR pushes the R-Core team to improve GNU-R.

View on HN

I never fail to be amazed at all the work the RStudio et al. team do to push R towards the wonderful programming language/environment it could be, rather than what it has been.

I'm in the same boat, and would have gladly left R years ago if not for all their efforts

They recently added terminal to RStudio. I'm so happy not switching between two app Iterm2 and RStudio.

Yep. The python support is starting to get pretty decent as well. I much prefer Rmarkdown for R and python (or both at the same time!) for e.g.

> R trades runtime speed for dev speed

This claim is made about a lot of things, Ruby, Python etc. I think the important point is it that there is no trade going on. It just that these things are all slower / less efficient than they need to be.

Maybe that's true, but I think Julia is the first effort to prove that out in the numerical/statistical world, and while lovely the ecosystem is far behind because of how much newer it is.

javascript showed that dynamically typed languages can be jitted well. It is just hard, and we spread our efforts over so many languages they don't all have the resources to do it.

SELF and Dylan were there first.

sure, but there's plenty of other reasons why JS isn't a contender in this interactive-data-analysis space

oh for sure, but for Python/R the barrier to speed isn't any of their important productivity features (as far as I know) but just a high quality compiler/JIT

If I was Lord Of Computing I wouldn't let languages out of beta until they had a high quality compiler or JIT. Turns out I am not though.

Is PyPy not high quality?

What Julia showed is that if you carefully design the language with JIT in mind, the task is MUCH easier.

Julia gets very good performance without the massive manpower that has gone into Javascript VM's.

There's also microsoft's R-Open (https://mran.microsoft.com/download) which I've found is faster than the out of the box R since it supports better multi-threading of commands.

IIRC most of that is because they use Intel's MKL and a better BLAS; if you like docker, using the Rocker containers uses the better BLAS, and I think adding MKL isn't too hard either.

Reply on news.ycombinator.com