Concurrency in Lux about lux HOT 3 CLOSED

It's extra confusing when you think about JS-land where "promise" is the readable portion of a future-like thing, and the constructor function is the writable portion.

When you get around to making Lux compile to JS, there will need to be at least support for promises to deal with native APIs returning them.

Can the other approaches be implemented in a single-threaded environment like JS?

from lux.

Can the other approaches be implemented in a single-threaded environment like JS?

For that, I'd just need to do the same tricks ClojureScript uses for its core.async implementations.
It's definitely do-able.

When you get around to making Lux compile to JS, there will need to be at least support for promises to deal with native APIs returning them.

That could be done by having a function for translating JS's promises to Lux's.
Another alternative would be to just use a JS-native promise implementation (though I don't know how feasible that would be, as I don't know if there are JS-promises in all modern browsers...)

from lux.

Promise support is decent but not perfect http://caniuse.com/#search=promise

Using native has the benefit of better console debugging, so it might be worth including an optional shim and otherwise using native.

from lux.