<story><title>Faster R with FastR</title><url>https://medium.com/graalvm/faster-r-with-fastr-4b8db0e0dceb</url></story><parent_chain></parent_chain><comment><author>WhompingWindows</author><text>&amp;quot;Moreover, support for dplyr and data.table are on the way. &amp;quot;&lt;p&gt;Well, I can&amp;#x27;t really use it in my day to day work, since that almost always involves cleaning and munging via one of those two packages. And it&amp;#x27;s not like ggplot2 is where my R code is most delayed, usually I&amp;#x27;m working on aggregate data or perhaps a very much smaller analytical dataset which requires much less speed for plotting. My hang-ups are in initial munging phases where the data is still very large, which often calls for data.table over dplyr due to the latter&amp;#x27;s much slower performance.</text></comment>
<story><title>Faster R with FastR</title><url>https://medium.com/graalvm/faster-r-with-fastr-4b8db0e0dceb</url></story><parent_chain></parent_chain><comment><author>claytonjy</author><text>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&amp;#x27;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.&lt;p&gt;Big barriers to adoption here: not a truly drop-in replacement, R people have an aversion to Java (we&amp;#x27;ve all spent hours debugging rJava; luckily most of those packages have been rewritten in C++ now), and nobody likes Oracle.&lt;p&gt;I think the best-case scenario here is that progress on FastR pushes the R-Core team to improve GNU-R.</text></comment>