Impact of Loom on “functional effects”

[mdedetrich]

@LPTK

Can you please provide us with your definition of “sync” and “async”? I suspect they are nonstandard, and that it’s why people have been talking pas each other in the past discussions.

In everything you say, it seems one could replace “async” by “using green threads” and “sync” by “using OS threads”. I hope I am wrong and I misread you, because this is not at all the accepted definition.

This is why I mentioned earlier that we should be using more precise CS terminology such as concurrency and parallelism, i.e.

@mdedetrich

Firstly this discussion where we use the terminology of sync vs async is missing the bigger picture where fundamentally we are debating on concurrency and parallelism. To make things clear

• Concurrency: An abstraction that lets you represent the notion of preforming multiple computations at the same time
• Parallelism: A hardware/physical feature (i.e. cores/threads) that lets you in reality perform computations at once

Various programming languages for both historical and design reasons have confused/mixed these concepts which underlies what is being discussed here. For example Java (up unti loom) has used threads as its core concurrency model which is great for CPU bound tasks since they bind directly to OS threads but is terrible for IO bound tasks where your bottleneck is not your CPU being busy computing some task but rather waiting for a response on the network/filesystem.

@jdegoes

Future gives us an async data type, all of whose operations are implemented using callbacks, as well as immediately submits the execution of user-defined code to a thread pool, which will initiate concurrent execution of the code.

This is incorrect, Future does not work with callbacks (at least if we are talking about composition/working with Future’s). Callbacks are anonymous functions (aka thunks) that are passed directly into function calls, taken from http://callbackhell.com/ with Javascript which coined the term “callback hell”,

fs.readdir(source, function (err, files) {
  if (err) {
    console.log('Error finding files: ' + err)
  } else {
    files.forEach(function (filename, fileIndex) {
      console.log(filename)
      gm(source + filename).size(function (err, values) {
        if (err) {
          console.log('Error identifying file size: ' + err)
        } else {
          console.log(filename + ' : ' + values)
          aspect = (values.width / values.height)
          widths.forEach(function (width, widthIndex) {
            height = Math.round(width / aspect)
            console.log('resizing ' + filename + 'to ' + height + 'x' + height)
            this.resize(width, height).write(dest + 'w' + width + '_' + filename, function(err) {
              if (err) console.log('Error writing file: ' + err)
            })
          }.bind(this))
        }
      })
    })
  }
})

As you can see with the fs.readdir/files.forEach/widths.forEach functions, they accept another function as the last argument which is your callback. Future’s do not take anonymous functions in their arguments, it’s completely different.

What Future/Promise allows is you to convert from callback style to monadic map/flatMap (or in JS land .then() style) which along with syntax sugar/yield/generators gets rid of the nesting. Even Scala.js documentation has a section on how to use Future’s to get rid of callbacks (see the Future section in From ES6 to Scala: Advanced - Scala.js)