Upcoming RStudio promises package

RStudio is going to introduce promises in R and shiny quite soon and it is going to be a huge step forward in programming in R!

image

I played with the promises package and wrote a hands-on blog post about it -
http://appsilondatascience.com/blog/rstats/2017/11/01/r-promises-hands-on.html. I think it would be beneficial to the community to keep the discussion about the upcoming package here. Feel free to share your questions and opinions about the package. I'll happily dive into the topic with you and will try to find answers to all our questions.

2 Likes

I read your blog. a new package is always welcome. I don't understand multithreaded programming much but I would sure like to learn if that can help me speed up my job. Still, I want to know a 2 things.

1> is it a compliment of future packge.
2> What would happen when a function is already using all the cores. like fread or fwrite.
3> is there a better guide explaining concept of multithreaded operations in R.
4> or Do I need to learn how does multithreaded works.

Please reply. I am very much interested.

Hi @Anantadinath,

1>
It is not tightly coupled with future package.

promises package defines Promise abstraction and operations semantics. So @jcheng, who is the author of the library defines what a Promise is and what you can do with such promise. You can create a Promise by yourself without using future package. See the example in Joe's tests (i.e. ext_promise method): https://github.com/rstudio/promises/blob/master/tests/testthat/common.R. So it is up to you how you want to run code asynchronously (whether it is by using future package or not). The important bit is that you create a Promise object.

promises package includes support for converting future objects (from the future package) into promises. That's why my examples work with future package seamlessly - converting future into Promise happens under the hood.

2>
I don't know an answer to this question. I'll get back to you once I have one.

3 & 4>
R does not support multithreading - it is single-threaded. I think that good place to start reading about running code asynchronously is future package documentation and diving into different plans used there to run code asynchronously - https://cran.r-project.org/web/packages/future/vignettes/future-1-overview.html. R being single-threaded makes the whole concept a bit tricker. If you look at multithreading in other languages like Scala, you'll see that the language is much more advanced and multithreading is much lighter (for example if you use akka actors you'll have a thread pool, one actor weighs <1Kb and you can create a lot of them). It is also much faster than running separate process to parallelize the code.

R is a bit behind other languages when it comes to its capabilities. And that's fine. It has been created for Data Scientists who want to have access to statistical computations and vector operations and have different needs than programmers. R was not intended to be a language where you build complex programs or applications. However we're evolving towards using R in much more demanding use cases and that's why R is evolving and adapting to rise up to the expectations. In the beginning Shiny for example was not intended to be used to build complex applications used by 500 users simultaneously. In my experience I see more and more people building very complicated systems in R and that's why R will keep on evolving and becoming stronger and more and more popular. Hopefully we'll end up with a great language that's fast for experimenting, powerful and reliable for building up bigger projects.

4 Likes

Thanks for your reply guess I will have to learn advance R by hadley and future package in order to be more efficient in R. And I have all the hopes from the language, I have not used any other language as much as this one. I recently learned Rinno and I am contented with it for some time.

But as a piece of advice if its too geeky or hard no one will use it.:stuck_out_tongue_winking_eye: We are somehow wired this way to avoid complicated programming structures.

But I love R and every bit of it. Have fingers crossed for this one too...

Most R users shouldn't have to use the promises package. Maintainers of "support" packages, whose work is already software development, can use promises and future in what their packages do behind the scenes.

2 Likes

I would love to see someone making for loops faster. Or if shiny can handle more requests than it does already. And yes plotly graphs too, they take longer time than ggplot2.

These 3 things are my primary concerns. If these packages can implement these promises. I am more than happy with r performance. In fact this is enough for me

1 Like