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.
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.