Haskell dilettante here… The “IO a” vs “a” reminded me of async vs sync - where the first one returns a promise/future to be awaited on, rather than a result.
Is there any parallel there, or is it an entirely wrong perception I got ?
Of course. Promise is a monad, .then is more or less equivalent to the >>= operator and await makes it look more imperative-ish just like <- in Haskell.
Note that in JS you'll need to be inside an async function to use await, just like in Haskell you'll need to be inside the do notation to use <-. Otherwise, you'll need to play with .then just like you would need to play with >>= in Haskell.
About other languages, one way to achieve asynchronous behavior without having it implemented in the language is using ReactiveX (https://reactivex.io/). It's hard to understand at first, but it if you understand the IO Monad it becomes easy, as it's basically the same.
Yes, except in a lot of languages, a Promise is the representation of the result of a computation that may already be happening, whereas an IO is a computation that will have data injected into it by some interpreter. But it's a very close comparison, in the sense that both represent contexts that future computation can be appended on. Also, in some languages, the Promise type is truly monadic.
There’s a parallel because Promises in a language like JavaScript are “monad-like”, so they’re similar to the IO Monad here. I am not a functional wizard so I’m sure that was not a fair comparison in some way, but it’s how I have thought of it. They’re both a representation of a side effect and require that effect be respected before you can get to the value inside it
Not so much a representation of a side effect (after all List is a Monad as is addition on integers no side effects anywhere in sight) as the reification of a particular category.
JavaScript's `Promise` is particularly interesting because it is a Monad over "all JS values which do not contain a method called `then` in their prototype chain" or as Dominic put it 12 years ago:
> Indeed, I like the way @medikoo phrases it. There's, practically speaking, nothing wrong with being a monad on the category of non-thenables.
Is there any parallel there, or is it an entirely wrong perception I got ?